Fix spaghetti init

[egornovivan]

https://github.com/sfall-team/sfall/issues/504 It’s no longer possible to do it better in the case where the game exe loads f2_res.dll

[egornovivan]

Can return the condition if (SCR_WIDTH == 0 || SCR_HEIGHT == 0) but it seems to me that this makes little sense

[egornovivan]

As I understand it, f2_res.dll reads settings from f2_res.ini and therefore if we store zeros in the screen resolution there, we will get unpleasant results like 640x480 in some modes. If you don't fix it with hacks, then it's better to leave the current version.

---

Right now I’ll do a sadomaso version

[NovaRain]

1. No plan to remove HiResMode switch yet.
2. Does this "fix" your game scaling problem?

I don't really understand what you mean by "spaghetti init". From your PR the whole Graphics::mode setup is even more like spaghetti than sfall current method IMO.

• With external HRP, its init runs before sfall init and already sets up the settings for itself. The only sfall thing it reads for graphics is Mode. In sfall, Graphics::mode will be only 0, 4, 5, 6 as set in Graphics.cpp, Setting::init() does nothing to change/set it.
• With built-in HRP, after Setting::init(), Graphics::mode will be 1-6 depending on the combination of GRAPHICS_MODE, WINDOWED, and WINDOWED_FULLSCREEN in f2_res.ini. The mode will be overridden later in Graphics.cpp only if player sets using DX9 mode in ddraw.ini (emulate the behavior of external HRP). Graphics::init() also initialize which graphics renderer to use, be it DX9 or DD7 based on the final Graphics::mode value in Graphics.cpp.

As for the whole "resolution" settings, the basic principle is:

• SCR_WIDTH/SCR_HEIGHT in f2_res.ini set the viewport size (how much of the area you see in the game).
• GraphicsWidth/GraphicsHeight in ddraw.ini set the window/screen size (how the game screen should be stretched to fit).

And using cnc-ddraw takes over the role of GraphicsWidth/GraphicsHeight with its own width/height/fullscreen settings.