База данных IDA от void17

AlexSpl писал(а):

Код: Выделить всё

class CSpriteFrame : public resource
{

struct CSequence
{
   int numFrames;
   int allocatedFrames;
   CSpriteFrame *f;
};

struct CSprite : public resource
{
   CSequence *s;
   TPalette16 *p16;
   TPalette24 *p24;
   int numSequences;
   int *validSeqMask;
   int Width;
   int Height;

};

Без них неправильное смещение у Width и Height.

Меня поправили на вогфоруме. Моя невнимательность, опять же. В классе CSprite s - это не указатель, а массив указателей, тоесть CSequence ** s;
Точно также, как внутри CSequence не CSpriteFrame *f, а CSpriteFrame** f.

Обновите базу до версии 2.1, там я такую глупую ошибку исправил. А так, впринципе, поля расставлены правильно, согласно оператору new и прочему.

* или ** - всё равно размер 4 и оффсеты не меняются. Уберите эти 4 поля и Draw() перестанет работать.

Приведу пример.
Вот что будет если s и f это просто указатели (*):

 

Код: Выделить всё

void __thiscall CSprite::Draw(
        CSprite *this,
        int seqnum,
        int framenum,
        int sx,
        int sy,
        int sw,
        int sh,
        ushort *dst,
        int dx,
        int dy,
        int dw,
        int dh,
        int dpitch,
        bool hflip,
        bool vflip)
{
  CSpriteFrame::Draw(
    *(CSpriteFrame **)(*(_DWORD *)(*(&this->s->numFrames + seqnum) + 8) + 4 * framenum),
    sx,
    sy,
    sw,
    sh,
    dst,
    dx,
    dy,
    dw,
    dh,
    dpitch,
    this->p16,
    hflip,
    vflip);
}

А вот, что будет если s и f это массивы указателей (**):

 

Код: Выделить всё

void __thiscall CSprite::Draw(
        CSprite *this,
        int seqnum,
        int framenum,
        int sx,
        int sy,
        int sw,
        int sh,
        ushort *dst,
        int dx,
        int dy,
        int dw,
        int dh,
        int dpitch,
        bool hflip,
        bool vflip)
{
  CSpriteFrame::Draw(this->s[seqnum]->f[framenum], sx, sy, sw, sh, dst, dx, dy, dw, dh, dpitch, this->p16, hflip, vflip);
}

Очевидно, второй вариант правильный. Когда переносил из дампа сюда, пока рылся среди типов, пропустил этот момент, т.к. в глазах рябит.
В версии 2.1 базы это исправил.

Поэтому я не просто так те 4 поля убрал, они согласно оператору new не совпадали. Моя невнимательность опять пораждает у других сомнения...

Но дело же не в указателях * и ** (и там, и там по 4 байта). Замена одного на другое не решает проблемы смещения. А с полями пожно получить корректые:

Код: Выделить всё

CSprite *sprite = *(CSprite**)(c->esi + 0x78);
sprite->Draw(0, 2 * (townType + 1), 0, 0, sprite->Width, sprite->Height, pWindowManager->screenBitmap->map, dx, dy,
    pWindowManager->screenBitmap->Width, pWindowManager->screenBitmap->Height, pWindowManager->screenBitmap->ScanlineSize, false, true);

См. sprite->Width и sprite->Height.

Лучше покажите мне на примерах, адреса. Просто у меня с этими функциями проблем вообще никаких нет.
Без адресов сказать не могу, подозреваю что там просто смещенный компилятором указатель, как это происходило с hexcell внутри combatManager-a.
Оператор new не врет, просто компилятор своими оптимизациями вас с толку сбил.

Вечером посмотрю ещё. Но без тех 4-х полей были вылеты. Посмотрю, что реально возвращают sprite->Width, sprite->Height. Если правильные размеры, то поля нужны, если нет, буду смотреть, в чём дело. Но факт в том, что без этих полей в классе CSpriteFrame игра вылетала, а с ними отрисовывает фреймы спрайтов на ура.

Хорошо, я подожду вас. А что за мод, если не секрет? С графикой что-то?

Да, с интерфейсом. Нужно изменить положение некоторых элементов интерфейса. И тут ой как пригодился бы разобранный класс TSingleSelectionWindow. Сейчас приходится получать всё по указателю на this (с->ecx -> с->esi). В принципе, некритично. Можно сделать свой класс TSingleSelectionWindow, нужные поля прописать, а остальные заполнить char gap[x].

Так, только что понял, что в коде я прописал дополнительные 4 поля класса CSpriteFrame, а в базу IDA забыл Может, тогда и TSingleSelectionWindow поднимется. Не может быть, чтобы его сильно переделали. Даже если в Dreamcast совершенно другой интерфейс, графические элементы всё равно используются одни и те же.

* * *
Ещё заметил, что в базе IDA класс CAdvPopup, который в простонародье называют базовым диалогом, наследуется прямо от heroWindow и у него есть 2 дополнительных поля. Но если верить дампу, то наследование идёт через промежуточный класс CHeroWindowEx (как раз эти два поля, только не в конце, а в начале).

Код: Выделить всё

class CHeroWindowEx : public heroWindow
{
public:
   int m_lastIMHoverID;
   int lastHover;
};

class CAdvPopup : public CHeroWindowEx
{
public:
   int exitId;
   int exitCodeX;
   int exitCommand;
};

Везде public, т.к. смысла с правами доступа загоняться нет, особенно для моддинга, где потенциально может пригодиться прямой доступ к любому полю.

Цитата:

99% true, there are definitely a few that are on 1-byte alignment. Hero class being the most well known example.

And I don't quite understand why. Why did they change its alignment?

Они ничего не меняли, по умолчанию 4 байта выравнивание. Так что это компилятор.