将非托管C++与F#混合用于物理学:值得吗?

Car*_*ers 5 .net c++ f# interop

我将开始使用DirectX SDK在非托管C++中编写3D游戏.这将涉及大量的物理和数学,虽然我无法预测它会有多复杂(例如,我不知道我是否会将它并行化).我想,由于F#非常棒的测量单位功能,以及它功能齐全,因此可以很好地并行化,我可以编写一个F#库来进行游戏的数学密集型计算.但:

  • 我对C++缺乏经验,从不与托管代码接口.我不知道这会是多么艰难.
  • 我不知道每次数学密集型计算(每个游戏迭代必须运行至少一个物理方程式),进出管理DLL的减速有多大.
  • 我不确定计量单位和简单并行化的收益是否值得.我的意思是,如果它只是数学,那么无论如何都要很容易用C++进行线程化(没有任何副作用,如果我记得pureC++中有一个关键字可能不允许副作用或某些东西?) - 我想我可以如果我非常小心(我知道我只会使用公制单位),没有计量单位.

值得吗?混合托管和非托管代码是一种常见的做法吗?游戏怎么样?它会成为瓶颈吗?它会让我的抽奖代码变得恐怖而复杂吗?如果你打开一个VC++项目并看到这种情况发生了 - 你的脸会是什么样的(:) :( D:等等)

Was*_*shu 5

从托管代码跳转到非托管代码,或从单个操作的非托管代码跳转到托管代码是昂贵的,并且对于单实例代价高昂的操作而言不值得.也就是说,在调用矩阵乘法时,托管到非托管或非托管到托管成本将高于代码本机实现中的乘法成本,尽管批处理操作有所帮助.

对于您正在讨论的内容,以这种方式使用F#不会产生任何明显的好处.还应该注意,您已经有几个数学库可供使用,例如XNAMath(随DXSDK一起提供)用于基本图形转换.

在物理学的最后,您应该更喜欢使用物理中间件解决方案(PhysX,Bullet等),因为它们更加成熟,经过充分测试,并且从长远来看通常会简化开发.除了学习如何做之外,不建议编写自己的物理实现.