Взял Direct3D 9 версию нашего проекта. Поменял файлы заголовков d3d на свои, подменил сдкейные lib-ы на зависимость от directgl, подпилил некоторые зависимости D3DX... И вся эта махина стартанула!!!
Начали трейситься вызовы, создался девайс Direct3D, swap chain, наперечислялись форматы и видеорежимы. Пошла загрузка уровня: создались вершинные декларации (кхм, как BLENDINDICES портировать?), 2D-текстуры, вершинные и индексные буферы, шейдеры (для них я пока сделал заглушку). В итоге упало на попытке чего-то отрисовать :)
Но большего пока и не надо! Как здорово обмануть проект и подсунуть ему фейковую обёртку, которая даже что-то делает. Теперь можно неспеша дебажиться и наращивать требуемый функционал :)
Update
Заставил загружаться в память игровой уровень. Это на самом деле просто, т. к. все ресурсы, которыми оперирует растеризатор, складываются из VB/IB, DXT-текстур, рендер таргетов и шейдеров (роль последних выполняет заглушка).
Интересно, что при заполнении текстуры через LockRect() во флагах обычно указывается 0, что означает, что мы можем как читать, так и писать по указателю. Чтобы только читать, можно указать флаг D3DLOCK_READONLY, но для заполнения нужно что-то вроде WRITEONLY. Можно было бы использовать usage D3DUSAGE_WRITEONLY при создании текстуры, но насколько я понял, этот флаг применяется только к (вершинному) буферу. В общем, для первого (и обычно единственного) lock-а приходится копировать данные из текстуры в PBO, а затем мапить буфер. Я рещил, что можно избежать этого шага, если хранить флажок bDirtyMip=true для текстуры, и на первом lock-e не копировать данные, а просто делать discard пиксельного буфера. После UnlockRect() флажок выставляется в false.
Если данные в текстуре всё равно невалидные и там мусор, то какая клиенту разница, чей это мусор: текстурный или буферный?
Подписаться на:
Комментарии к сообщению (Atom)
Комментариев нет:
Отправить комментарий