【问题标题】:Alternative solution to my collision detection with complex shapes?复杂形状的碰撞检测的替代解决方案?
【发布时间】:2014-11-06 19:24:08
【问题描述】:

情况: 我目前正在做一个需要复杂形状的碰撞检测的项目:

.

现在整个形状(黑色轮廓)作为常规图像显示给用户(使用 Graphics.DrawImage)。图像被分解为使用 GraphicsPath 保存和绘制的不同的不相交部分。用户单击该部分,如果单击该区域,则填充路径。

问题: 我的问题是图像平均有 338 个部分。

one 部分的 GraphicsPath 保存数据示例:

1:41,1:42,1:43,1:44,1:45,1:46,2:46,3:47,4:47,5:48,6:48,7:48 ,8:48,9:48,10:48,11:49,12:48,13:48,14:48,15:48,16:48,17:48,18:48,19:48,20 :47,21:47,22:47,23:47,24:46,25:46,26:45,27:45,28:44,29:44,30:43,31:43,32:43 ,33:43,34:43,35:42,36:42,37:43,38:43,39:43,40:43,41:44,42:44,43:44,44:45,45 :46,46:46,47:47,48:48,49:48,50:48,51:48,52:48,53:48,53:47,54:47,54:46,54:45 ,54:44,54:43,54:42,54:41,53:40,53:39,52:38,52:37,52:36,51:35,51:34,50:33,50 :32,50:31,50:30,50:29,50:28,50:27,50:26,50:25,50:24,50:23,50:22,51:21,51:20 ,51:19,51:18,51:17,51:16,50:15,50:14,50:13,50:12,50:11,50:10,50:9,50:8,49 :7,49:6,49:5,49:4,48:3,48:2,48:1,47:1,46:1,45:1,44:1,43:1,42:1 ,41:1,40:1,39:1,38:1,37:1,36:1,35:1,34:1,33:1,32:1,31:1,30:1,29 :1,28:2,27:2,26:2,25:2,24:2,23:3,22:3,21:3,20:4,19:4,18:5,17:5 ,16:6,15:6,15:7,14:7,13:8,12:9,11:10,10:11,10:12,9:13,8:14,8:15,7 :16,7:17,7:18,6:19,6:20,6:21,5:22,5:23,5:24,4:25,4:26,4:27,4:28 ,4:29,3:30,3:31,3:32,3:33,3:34,2:35,2:36,2:37,2:38,2:39,

要保存并加载到 GraphicsPath 中然后最终绘制的大量数据。

格式 x:y,...

我的问题:

现在问题来了,这个问题真的很开放,我深表歉意。但是这个问题有更优雅的解决方案吗?更简化的版本?我的主管对我提出的解决方案并不满意,并指示我寻找更好的解决方案。我们愿意使用与 dot net 3.5 兼容的新技术

谢谢大家。

【问题讨论】:

  • 您是否测量了由于路径众多而对性能产生的负面影响?
  • 是的,我知道会有很多 GraphicsPath。我认为它会有一些性能问题,但到目前为止这都是理论。我还没有实现它,但我正在寻找更好的解决方案,因为这个解决方案与我有关
  • 我真的很惊讶有多少路径可以完全顺利地处理 - 在 Windows 手机上。虽然是silverlight而不是gdi+

标签: c# .net-3.5 collision-detection gdi+ graphicspath


【解决方案1】:

我最终选择了手动解决方案。我的解决方案要求用户定义点。更多点=顺利。更少的点 = 更多的多边形。

【讨论】:

    猜你喜欢
    • 2021-12-18
    • 2015-12-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-07-07
    相关资源
    最近更新 更多