Смешивание неуправляемого C ++ с F # для занятий физикой: стоит? - PullRequest
5 голосов
/ 16 февраля 2011

Я собираюсь начать писать 3D-игру на неуправляемом C ++ с использованием DirectX SDK. В нем будет много физики и математики, хотя я не могу предсказать, насколько сложным он будет (например, я не знаю, буду ли я его распараллеливать). Я думал, что из-за невероятно удивительной функции F # в единицах измерения и того факта, что она функциональна и, следовательно, хорошо распараллеливается, я мог бы написать библиотеку F # для выполнения математических вычислений в игре. Но:

  • Я неопытен в C ++, не обращая внимания на то, как он взаимодействует с управляемым кодом. Я не знаю, насколько это было бы непосильно.
  • Я не знаю, насколько велико замедление, возникающее при входе и выходе из управляемой DLL, для каждого математического вычисления (по крайней мере одно физическое уравнение должно было бы выполняться за каждую итерацию игры).
  • Я не уверен, стоит ли усиление единиц измерения и простое распараллеливание. Я имею в виду, что если это просто математика, то все равно в C ++ будет легко работать с потоками (на самом деле никаких побочных эффектов нет, и если я напомню, что в C ++ есть ключевое слово pure, возможно, оно запрещает побочные эффекты или что-то в этом роде?) - и я Предположим, я мог бы обойтись без единиц измерения, если я действительно осторожен (я знаю, что буду использовать только метрические единицы).

Так стоит ли это? Является ли смешивание управляемого и неуправляемого кода общепринятой практикой? А как насчет игр? Это было бы узким местом? Это сделает мой код прорисовки ужасным и запутанным? Если вы открыли проект VC ++ и увидели, что это происходит - как бы выглядело ваше лицо (:) :( D: и т. Д.)

1 Ответ

5 голосов
/ 16 февраля 2011

Переход от управляемого к неуправляемому коду или от неуправляемого к управляемому коду для отдельных операций является дорогостоящим и не стоит его для отдельных операций. То есть затраты на управляемые или неуправляемые или неуправляемые управляемые затраты при вызове умножения матриц будут выше, чем затраты на умножение в реализации, встроенной в ваш код, хотя пакетные операции помогают.

Для того, что вы обсуждаете, использование F # таким способом не принесет заметной пользы. Также следует отметить, что у вас уже есть несколько математических библиотек, таких как XNAMath (который поставляется с DXSDK) для базовых графических преобразований.

В физическом плане вы должны предпочесть использовать физическое промежуточное программное обеспечение (PhysX, Bullet и т. Д.), Так как они гораздо более зрелые, хорошо протестированные и, как правило, упростят разработку в долгосрочной перспективе. Написание вашей собственной физической реализации не рекомендуется, за исключением случаев обучения КАК это делать.

...