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

This was my old try at TSingleScenarioWindow. I find updating the old api with the new information is the quickest way to do it given I had already done all the alignment work back then - ofc it is now larger than it was during RoE because of RMG.

Цитата:

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

I certainly have no answer for this, at one point I thought it may have been some legacy from Heroes2 that may be in part to blame but obscuring object naming format has Gus' fingerprints over it.
Only reasonable guess I can make is that they modified alignment along the way and something was not working correctly, so the fix was to force alignment-1 there

Удивительно, но

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

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);

debugStr("%d %d", sprite->Width, sprite->Height);

Возвращает правильные размеры (48x32). Классы такие:

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

class _DDCOLORKEY
{
public:
   unsigned long dwColorSpaceLowValue;
   unsigned long dwColorSpaceHighValue;
};

class _DDPIXELFORMAT
{
   unsigned long dwSize;
   unsigned long dwFlags;
   unsigned long dwFourCC;
   unsigned long dwRGBBitCount;
   unsigned long dwYUVBitCount;
   unsigned long dwZBufferBitDepth;
   unsigned long dwAlphaBitDepth;
   unsigned long dwLuminanceBitCount;
   unsigned long dwBumpBitCount;
   unsigned long dwRBitMask;
   unsigned long dwYBitMask;
   unsigned long dwStencilBitDepth;
   unsigned long dwLuminanceBitMask;
   unsigned long dwBumpDuBitMask;
   unsigned long dwGBitMask;
   unsigned long dwUBitMask;
   unsigned long dwZBitMask;
   unsigned long dwBumpDvBitMask;
   unsigned long dwBBitMask;
   unsigned long dwVBitMask;
   unsigned long dwStencilBitMask;
   unsigned long dwBumpLuminanceBitMask;
   unsigned long dwRGBAlphaBitMask;
   unsigned long dwYUVAlphaBitMask;
   unsigned long dwLuminanceAlphaBitMask;
   unsigned long dwRGBZBitMask;
   unsigned long dwYUVZBitMask;
};

class _DDSCAPS2
{
   unsigned long dwCaps;
   unsigned long dwCaps2;
   unsigned long dwCaps3;
   unsigned long dwCaps4;
};

class _DDSURFACEDESC2
{
public:
   unsigned long dwSize;
   unsigned long dwFlags;
   unsigned long dwHeight;
   unsigned long dwWidth;
   long lPitch;
   unsigned long dwLinearSize;
   unsigned long dwBackBufferCount;
   unsigned long dwMipMapCount;
   unsigned long dwRefreshRate;
   unsigned long dwAlphaBitDepth;
   unsigned long dwReserved;
   void *lpSurface;
   _DDCOLORKEY ddckCKDestOverlay;
   _DDCOLORKEY ddckCKDestBlt;
   _DDCOLORKEY ddckCKSrcOverlay;
   _DDCOLORKEY ddckCKSrcBlt;
   _DDPIXELFORMAT ddpfPixelFormat;
   _DDSCAPS2 ddsCaps;
   unsigned long dwTextureStage;
};

class IUnknown
{
};

class IDirectDrawSurface4 : public IUnknown
{
};

class CSpriteFrame : public resource
{
public:
   int DataSize;
   int ImageSize;
   TEncodingMethod EncodingMethod;
   int Width;
   int Height;
   int CroppedWidth;
   int CroppedHeight;
   int CroppedX;
   int CroppedY;
   int Pitch;
   unsigned char *map;
   _DDSURFACEDESC2 ddsd;
   IDirectDrawSurface4 *ddsurf;
   unsigned long compmap_len;
   unsigned char *tempmem;
};

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;

   inline void Draw(int seqnum, int framenum, int sx, int sy, int sw, int sh, void *dst, int dx, int dy, int dw, int dh, int dpitch, bool hflip, bool tblit)
   {
      CALL_15(void, __thiscall, 0x47B610, this, seqnum, framenum, sx, sy, sw, sh, dst, dx, dy, dw, dh, dpitch, hflip, tblit);
   }
};

Если же в классе CSpriteFrame убрать 4 последних поля, которых нет в базе IDA, будут вылеты, что логично: размер класса CSequence уменьшится, и у полей Width и Height будут неверные смещения. Так что, склоняюсь к тому, что эти поля нужны в классе CSpriteFrame.

Хотя, там же всё равно указатели Сейчас проверю без этих полей.

Удивительно, но без этих полей зависания или вылеты

* * *
Так, я разобрался. Зависания и вылеты из-за попытки показать диалог с сообщением (заменил на debugStrWin() и всё стало нормально) Работает как с теми полями, так и без них (всё-таки размер структуры CSprite не меняется, потому что в ней указатель на CSequence). Нужно глянуть конструктор CSpriteFrame, чтобы точно понять, нужны они или нет. Если нет, то почему их выпилили? Особенности Dreamcast'овской реализации?

Хмм, у CSpriteFrame нет конструктора (в базе IDA). Как определить настоящий размер? А вот в дампе есть несколько разных:

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

Строка 443765: (000180) S_GPROC32: [0001:00074600], Cb: 00000064, Type:             0x5571, CSpriteFrame::CSpriteFrame
Строка 443774: (0001E0) S_GPROC32: [0001:00074664], Cb: 000000AA, Type:             0x239F, CSpriteFrame::CSpriteFrame
Строка 443804: (000308) S_GPROC32: [0001:00074710], Cb: 000000BA, Type:             0x239E, CSpriteFrame::CSpriteFrame
Строка 443838: (000480) S_GPROC32: [0001:000747CC], Cb: 0000006E, Type:             0x239D, CSpriteFrame::CSpriteFrame

(инициализации с разными параметрами).

Например,

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

(000480) S_GPROC32: [0001:000747CC], Cb: 0000006E, Type:             0x239D, CSpriteFrame::CSpriteFrame
         Parent: 00000000, End: 00000594, Next: 00000598
         Debug start: 00000010, Debug end: 00000062

(0004C4)  S_REGREL32: sp+00000020, Type:             0x239C, this
(0004D8)  S_REGREL32: sp+00000024, Type:             0x1001, name
(0004EC)  S_REGREL32: sp+00000028, Type:      T_UCHAR(0020), cropped
(000504)  S_ENDARG

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

(0001E0) S_GPROC32: [0001:00074664], Cb: 000000AA, Type:             0x239F, CSpriteFrame::CSpriteFrame
         Parent: 00000000, End: 00000304, Next: 00000308
         Debug start: 0000001C, Debug end: 00000098

(000224)  S_REGREL32: sp+0000002C, Type:             0x239C, this
(000238)  S_REGREL32: sp+00000030, Type:             0x1001, name
(00024C)  S_REGREL32: sp+00000034, Type:       T_INT4(0074), w
(00025C)  S_REGREL32: sp+00000038, Type:       T_INT4(0074), h
(00026C)  S_REGREL32: sp+0000003C, Type:   T_32PUCHAR(0420), data
(000280)  S_REGREL32: sp+00000040, Type:       T_INT4(0074), csize
(000294)  S_REGREL32: sp+00000044, Type:             0x1772, encoding
(0002AC)  S_ENDARG

и т.п.

Возьму пока класс TSingleSelectionWindow из H3API, подставив оригинальные имена полей. Всё равно точнее класса нет. Как бы для моей задачи полностью разобранный класс и не нужен. Просто хочется избавиться от смещений в коде

Перенёс класс TSingleSelectionWindow из H3API и всё поднялось Пример класса, который существенно изменился.

Примерно такой класс получается (все поля не проверял, мог напутать):

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

class TSingleSelectionWindow : public CAdvPopup
{
   unsigned long clickTime;
   unsigned char isCampaignMaybe;
   unsigned char loadGameMode;
   unsigned char saveGameMode;
   int textIndex;
   CSprite* scselcDef;
   CSprite* VictoryIcon;
   CSprite* LossIcon;
   CSprite* TownPix;
   CSprite* Resource;
   CSprite* heroSpecificAbility;
   Bitmap816* GoldBox;
   Bitmap816* Flags[8];
   Bitmap816* Panels[8];
   Bitmap816* HeroPix[163];
   Bitmap816* randomTownQuestion;
   Bitmap816* randomHeroQuestion;
   Bitmap816* randomTown;
   Bitmap816* randomHero;
   Bitmap816* noDice;
   Bitmap816* noHero;
   int sortDirection;
   int currentIndex;
   int currentMap;
   int durationIndex;
   unsigned char inAdvancedOptions;
   unsigned char inScenarioOptions;
   unsigned char inRMGOptions;
   textEntryWidget* edit380;//H3DlgEdit* edit380;
   int _f_384;
   int _f_388;
   H3ScenarioMapInformation mapInfo;
   std::vector<H3ScenarioMapInformation> vector1030;
   std::vector<H3ScenarioMapInformation> vector1040;
   std::vector<H3ScenarioMapInformation> mapsInformation;
   H3ScenarioMapInformation* mapsInfoPtr;
   H3ScenarioPlayer mapPlayersHuman[8];
   H3ScenarioPlayer mapPlayersComputer[8];
   textEntryWidget* saveGameEdit;
   unsigned char mode;
   CNewPlayerUpdateMan* pNewPlayerUpdateMan;
   CNetPlayerHandler netPlayerHandler;
   unsigned char receivedMaps;
   slider* chatSlider;//H3DlgScrollbar* scrollBar1838;
   slider* fileSlider;//H3DlgScrollbar* scrollBar183C;
   slider* durationSlider;//H3DlgScrollbar* turnDurationScroll;
   slider* nameSlider;
   textWidget* chatWidget;//H3DlgText* text1848;
   textWidget* nameList1;//H3DlgText* text184C;
   textWidget* nameList2;//H3DlgText* text1850;
   bool mapChanged;
   CChatEdit* chatEdit;//H3DlgEdit* edit1858;
   int sortWhich;
   int filterSize;
   unsigned char scenarioOptionsStarted;
   unsigned char chatShowing;
   textButton* chatToggle;//H3DlgDefButton* button1868;
   unsigned char receivingMaps;
   CSaveScreen* flagBack;//H3LoadedPcx16* extendedPcx;
   char gameVersion[20];
   CSingleSelectionNetMsgHandler netMsgHandler;//h3func* newGameCampaignVtable;
   char _f_188C[8];
   char _f_1894;
   int iGameVersion;
   int _f_189C;
   unsigned int mapDimension;
   int numberLevels;
   int numberPlayersSelected;
   int _f_18AC;
   int computerPlayersOnlySelected;
   int _f_18B4;
   int waterContentSelected;
   int monsterStrengthSelected;
   textButton* humanComputerButtons[9];//H3DlgDefButton* humanComputerButtons[9];
   textButton* humanComputerTeamsButtons[9];//H3DlgDefButton* humanComputerTeamsButtons[9];
   textButton* computerOnlyButtons[9];//H3DlgDefButton* computerOnlyButtons[9];
   textButton* computerOnlyTeams[8];//H3DlgDefButton* computerOnlyTeams[8];
   textButton* waterContentButtons[4];//H3DlgDefButton* waterContentButtons[4];
   textButton* monsterStrengthButtons[4];//H3DlgDefButton* monsterStrengthButtons[4];
   slider* textScroll;//H3DlgScrollableText* textScroll;
};

Много общего (а именно середина). Начало класса с кучей полей widget* выпилено, зато добавлена куча полей в конец класса (RMG, кпопки, информация о карте).

Вот такой аккуратный код получается в IDA:

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

CSprite::Draw(
      this->TownPix,
      0,
      2 * framenum + 2,
      0,
      0,
      this->TownPix->Width,
      this->TownPix->Height,
      pWindowManager->screenBitmap->map,
      176,
      v9 + 130,
      pWindowManager->screenBitmap->Width,
      pWindowManager->screenBitmap->Height,
      pWindowManager->screenBitmap->ScanlineSize,
      0,
      1);

Всмысле нет конструктора? Есть, их два. В базе они вызываются по адресам, которые я давал, там же оператор new, который показал размер, без этих структур правильный. Вы почему-то меня проигнорировали.





И да, выпилили поля(а, точнее сказать, добавили программисты дримкаст-версии, в оригинальном RoE их тоже не было), потому что особенности реализации. Куча классов там было для портирования, поэтому при переносе из дампа нужно быть осторожным.

Явно никакого ds_engine и ds_sample и др. не было на ПК.

H3ScenarioMapInformation и прочие H3API структуры все в нормальном виде есть в моей базе, посмотрите. SMapHeader имеется ввиду, наверное.

Обновил базу.

К сожалению, "пустая"(без сигнатур) база MacOS-версии.
https://www.macintoshrepository.org/434 ... i-complete

Зато здесь есть названия типов, которых нет в RoE...

Что интересно, к концу разработки героев 3 и началу разработки героев 4, команда программистов NWC перешли на единый стиль snake_case.
Сначала type_name, затем t_name, прямо как в героях 4.
Некоторые из них:

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

t_start_hero_options
t_scenario_start_options
t_crossover_options
t_bonus_options
t_start_resource_bonus
t_start_bonus
t_start_secondary_skill_bonus
t_start_primary_skill_bonus
t_start_artifact_bonus
t_start_building_bonus
t_start_creature_bonus
t_start_spell_scroll_bonus
t_start_spell_bonus
t_complex_net_message
t_map_list_update
t_campaign_type_window
t_custom_campaign_window
t_net_file
t_abstract_random_generator
t_quest_artifact

type_statue_of_legion_artifact
type_artifact_effect
type_elixir_of_life_artifact
type_undead_king_cloak_artifact
type_combat_artifact
type_base_necromancy_artifact
type_angelic_alliance_artifact
type_might_artifact
type_shooter_bonus_artifact
type_spell_artifact
type_creature_growth_artifact
type_income_artifact
type_tome_artifact
type_antiluck_artifact
type_antimorale_artifact
type_antimagic_artifact
type_school_artifact
type_power_artifact
type_duration_artifact
type_luck_artifact
type_morale_artifact
type_spellcaster_artifact
type_movement_artifact
type_necromancy_artifact
type_knowledge_artifact
type_scouting_artifact
type_bottom_view_window
type_combat_sub_window
type_normal_dialog_frame
type_skeleton_window
type_transformer_slot
type_sacrifice_window
type_army_slot_widget
type_artifact_offering_widget
type_backpack_slot_widget
type_doll_slot_widget
type_belong_to_player_quest
type_quest
type_be_hero_quest
type_resource_quest
type_creature_quest
type_artifact_quest
type_monster_quest
type_defeat_hero_quest
type_skill_quest
type_experience_quest
type_map_creation_bar
type_progress_bar
type_garrison_base_window
type_monster_join_window
type_university_skill_button
type_random_map_generator
type_key_tent_def
type_treasure_def
type_spell_scroll_def
type_quest_gold_def
type_quest_experience_def
type_quest_creature_def
type_black_box_creature_def
type_witch_hut_def
type_shrine_def
type_scholar_def
type_prison_def
type_resource_lump_def
type_map_dwelling_def
type_flaggable_def
type_black_box_spells_def
type_black_box_gold_def
type_black_box_experience_def
type_artifact_def
type_witch_hut
type_object
type_spell_scroll
type_shrine
type_scholar
type_hero
type_seer_hut
type_random_artifact
type_key_tent
type_black_box
type_resource_lump
type_flaggable
type_town
type_monster
type_river_map
type_road_map
type_random_map
type_progress_bar
type_text_scroller




А кроме как названиями типов эта база никакой полезной нагрузки не несет.

Another nice find, I'd tried to extract the macos version myself but not knowing anything about those formats couldn't manage to do it. All the _def types were already available in the mapeditor though.