Предисловие
Доброго времени суток, речь пойдёт о игровом движке X-Ray, а точнее о его форке X-Ray Oxygen В декабре 2016 года был опубликован проект X-Ray Oxygen. Тогда я разрабатывал его один и не мечтал о том, чем он стал на данный момент.
В марте мне пришла в голову идея: "А почему бы не перенести это всё на x64?". Как вы поняли, именно об этой идее, а точнее её реализации, пойдёт речь.
Сборка проекта
Первым шагом был перенос кода, чтоб собрать всё это дело под x64 платформу. После настройки проектов я столкнулся с первой проблемой… Нет, не Ptr функции, а ассемблерные вставки...
__forceinline void fsincos( const float angle , float &sine , float &cosine )
{ __asm {
fld DWORD PTR [angle]
fsincos
mov eax , DWORD PTR [cosine]
fstp DWORD PTR [eax]
mov eax , DWORD PTR [sine]
fstp DWORD PTR [eax]
} }Прелесть такого кода заключалась в оптимизации, но MSBuilder в x64 его не поддерживал и не поддерживает до сих пор. Большую часть такого кода можно было заменить на std аналоги, были места, которые можно было с лёгкостью поменять на Intrinsics'ы, к примеру, как:
__asm pause;Можно было смело заменить на:
_mm_pause();Так же в движке иногда встречались аналоги функций на нативном коде (Хвала системе CPUID). Но бывали места, от которых приходилось просто избавляться. К примеру MMX инструкции канули в лету. К счастью, они нигде и не вызывались, а просто компилировались и и валялись без дела.
Работоспособность
После всех правок по сборке наступил следующий этап: Как всё это запустить?
Первым предателем стал LuaJIT. К несчастью, LuaJIT стал нормально (ну, почти...) работать в x64 только с версии 2.0.5. И то были небольшие проблемы с аллокацией памяти из малых разрядов. Но, тогда я не знал об этом и первым делом выпилил LuaJIT и накатил ванильный Lua 5.1. Да, это исправило проблему, но скорость… Помним, скорбим. Позже мне на форуме сообщили, что можно попробовать использовать LuaJIT 2.0.4. И да, это помогло, я запустил игру и смог выйти в главное меню!
Но… Счастье было недолгим… Привет смещениям структур, типам данных и xrCDB. Игра не загружала уровень, полетели материалы на объектах и движку это сильно не нравилось. Спустя пару дней я отчаялся окончательно и решил попросить помощи у более опытного программиста под ником Giperion. Я не рассчитывал на его участие в проекте, моей мечтой был просто совет. Но, таким образом, я получил опытного разработчика в проект. С этого момента сформировалась команда.
Следующей проблемой стал OPCODE и типы данных. Пришлось переводить все udword'ы (unsigned int) на uqword'ы (unsigned long long). Только для того, чтобы понять это, пришлось провести под отладчиком около 4 часов.
Но, это было лишь частью проблемы. Настала очередь материалов. Что мы имеем:
union
{
u32 dummy; // 4b
struct
{
u32 material : 14; //
u32 suppress_shadows : 1; //
u32 suppress_wm : 1; //
u32 sector : 16; //
};
};Такой код в x32 спасала волшебная #pragma pack(4), но в x64 почему-то это не спасло. Пришла очередь выравнивания, путём деббага мы выяснили, что для некоторых случаев данные в структуре были валидны, а для других нет. Переделали структуру и сделали конвертер-валидатор. Структура получила следующий вид:
union
{
size_t dummy;
struct
{
size_t material:14; //
size_t suppress_shadows:1; //
size_t suppress_wm:1; //
size_t sector:16; //
size_t dumb : 32; // Да, это волшебный дамб в x64.
};А валидатор был таким:
...
if (rebuildTrisRequired)
{
TRI_DEPRECATED* realT = reinterpret_cast<TRI_DEPRECATED*> (T);
for (int triIter = 0; triIter < tris_count; ++triIter)
{
TRI_DEPRECATED& oldTri = realT[triIter];
TRI& newTri = tris[triIter];
newTri = oldTri;
}
}
else
{
std::memcpy(tris, T, tris_count * sizeof(TRI));
}
...Таким образом, пришлось поменять часть вызовов из-за флага rebuildTrisRequired, но игра смогла запуститься.
Но, со временем настала проблема с партиклами:
real_ptr = malloc( sizeof( Particle ) * ( max_particles + 1 ) );
particles = (Particle*)((DWORD)real_ptr + (64 - ((DWORD)real_ptr & 63)));Этот код не вызывал проблем с оригинальными партиклами. Они были слишком простыми и спокойно вмещались в выделяемую для них память. Но с более сложными и красочными партиклами, которые делали модмейкерами, пришли вылеты по памяти. x64 и вылеты по памяти, как так-то?! Код был переделан, вылеты ушли:
particles = alloc<Particle>(max_particles);Игровые проблемы
Первой проблемой стал, опять, LuaJIT
Полетела userdata для smart cover'ов. Эта проблема была исправлена почти самой последней. Просто переносом правок из релизнувшегося LuaJIT 2.0.5.
Следующая проблема: Физика и вычисление float'ов. control87 и _controlfp для вычисления infinity в x64 были заблокированы… Была огромная проблема с дропом предметов, один раз к трём они падали правильно. Иногда улетали в космос, иногда под террейн. Проблема крылась всего в одной переменной, которой давалось значение infinity. Ситуацию исправил FLT_MAX, одинаковый для всех платформ.
surface.mu = dInfinty // x32
surface.mu = FLT_MAX // x64Последней проблемой стала скорость партиклов. Обратим внимание на следующий код:
DWORD angle = 0xFFFFFFFF;
...
if (angle != *((DWORD*)&m.rot.x))
{
angle = *((DWORD*)&m.rot.x);
fsincos(angle, sina, cosa);
}Вроде бы всё в порядке. Но, 0xFFFFFFFF в x64 имеет другое значение, при конвертации в тип с плавающей запятой. Дело в том, что fsincos имеет Double аналог, а x64 предпочитает double данные. И это значение в double имеет значение намного больше. Ситуацию спасло преобразование в float.
DWORD angle = 0xFFFFFFFF;
...
if (angle != *((DWORD*)&m.rot.x))
{
angle = *((DWORD*)&m.rot.x);
// fsincos(angle, sina, cosa);
fsincos(*(float*)&angle, sina, cosa);
}Заключение
В заключение я хочу сказать всего лишь одно: порт в x64 принёс много новых знаний, которые пригодятся в дальнейшем. Я рассказал вам о многих проблемах при портировании. А дальше всё будет зависить от вас, если вы решите проделать это в каких-либо OpenSource проектах.
Спасибо за прочтение!
