Предисловие

Доброго времени суток, речь пойдёт о игровом движке 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 проектах.

Спасибо за прочтение!