HRP in Sfall

[FakelsHub]

В связи с недоступностью исходных кодов HRP, и его частичного устаревания, необходимо полностью перенести функционал HRP (или его наиболее важные компоненты) в отдельный модуль в sfall, чтобы весь контроль над движком осуществлялся из одного контролируемого проекта.

При этом основная библиотека HRP может использоваться как доступ к некоторым особо большим функциям (как к экспортируемым).

[FakelsHub]

На сегодня 200 функций приобрели имена в дизассемблированном коде HRP, осталось разобрать 800.

Все же наверное это будет новый проект объеденный одном решении с sfall.
На выходе будет получатся две библиотеки ddraw.dll и новая f2_res.dll

[NovaRain]

It will be like recreate a new HRP from the disassembled code, except the new one depends on sfall instead of working standalone?

[FakelsHub]

Not from disassembled code, I just study what is done and how to repeat it.
Probably Yes, it will not work separately from sfall, simply because there will be no functions for creating a game window and other DirectX functions, only everything that is necessary to increase the map scale and other HRP capabilities.
Why run a game without sfall? there are a lot of bugs.

[burner1024]

Don't know if useful, but just in case - noticed some offsets in mapper's HRP: res_m2.ini.txt

[FakelsHub]

На данный момент осталось реализовать опции ALTERNATE_AMMO_METRE и NumPathNodes.
На этом интеграция будет считаться законченной.
Реализация HRP меню будет отложено (нужно будет подготовить новый интерфейс к нему).

At the moment, it remains to implement the 'ALTERNATE_AMMO_METRE' and `NumPathNodes' options.
At this point, the integration will be considered completed.
The implementation of the HRP menu will be postponed (will need to prepare a new art interface for it).

[NovaRain]

Currently the main menu button text seems misaligned with the background.

[FakelsHub]

show an example.
There will be differences because the implementations are completely different.

[NovaRain]

show an example. There will be differences because the implementations are completely different.

Here's the comparison. I use graphics mode 5 and 1280x720 for GraphicsWidth/Height and SCR_WIDTH/HEIGHT, and all main menu related options are default in ddraw.ini/f2_res.ini.

With the external HRP:

With sfall built-in:

[FakelsHub]

I'm fine with this, there is no shift.
what happened there?

[NovaRain]

I'm fine with this, there is no shift. what happened there?

Ah, I got it. In f2_res.ini HRP enables its USE_HIRES_IMAGES by default so MENU_BG_OFFSET_X/Y values have effect.
Disabling USE_HIRES_IMAGES and the menu position is now normal with sfall built-in.

EDIT: Oh, SCALE_BUTTONS_AND_TEXT_MENU also affects this.

[FakelsHub]

here with the English version

[FakelsHub]

Ah, I got it. In f2_res.ini HRP enables its USE_HIRES_IMAGES by default so MENU_BG_OFFSET_X/Y values have effect.
Disabling USE_HIRES_IMAGES and the menu position is now normal with sfall built-in.

Show the settings
Everything should work the same without any disables.

[NovaRain]

Show the settings

Well, it's due to I enabled SCALE_BUTTONS_AND_TEXT_MENU.

[MAINMENU]
MAIN_MENU_SIZE=1

USE_HIRES_IMAGES=1

; With default 0 it's OK, enabling both USE_HIRES_IMAGES and this will cause the shift
SCALE_BUTTONS_AND_TEXT_MENU=1

MENU_BG_OFFSET_X=-14
MENU_BG_OFFSET_Y=-4

[FakelsHub]

Well, it's due to I enabled SCALE_BUTTONS_AND_TEXT_MENU.

the last time I rewrote the main menu code, this option worked correctly. apparently something broke.

[FakelsHub]

I think it's time to merge the HRP integration branch with the main one. Only I forgot how to do it correctly :)