Unlock resolution

[pk-2000]

Modification to unlock window size & resolution.

Automatically determines the game's resolution. If it is lower than 800/600 it upscale's it to 800/600 (can be changed in lines 129 & 130 of eventhread.cpp) and if the game uses a higher resolution auto-adjusts the window.

note: on linux (at least on my machine) it cannot auto-adjust the initial window, if the default allowed resolution is equal or higher of the monitor resolution (the initial window size will be equal to the monitor resolution). Probably a bug of my linux drivers. Since I am not sure why it happens (linux drivers?/ SDL bug?/XFCE bug?), the workaround was to set the defScreenW and defScreenH in "mkxp.conf" to a smaller value than the monitor resolution. e.g. On a monitor 1920/1080 can be set to defScreenW=1910 defScreenH=1070 and then works correctly.

[Ancurio]

What happens to rgss1 tilemaps when a higher resolution is set? I was certain they were hard-coded for the original resolution.

Also, which games require these changes?

[pk-2000]

Correct they are hard-coded. Both the game window and it's tilemaps will retain their original size/resolution. The higher resolution is never enforced to the game. The resolution set in mkxp.conf, works now as an upper/max limit, that the mkxp will allow, and not as enforced resolution.

games shorted by resolution 800x600 various games that use Fullscreen++ script https://forums.rpgmakerweb.com/index.php?threads/fullscreen.14081/

960x640 Queen In Deficit (developer: BrokenTorpedo) Adult 18+ game (itch.io game store)

1280x720 Sometimes Always Monsters (developer: Vagabond Dog) https://store.steampowered.com/app/441440/Sometimes_Always_Monsters/

1280x960 Coming of Age (developer: CrazyBat) Adult 18+ game (ulmf.org forum)

[pk-2000]

Note: the only "problem" would be with rgss2 and rgss3 if you set a resolution lower than the resolution of the game. eg. if a game is made with 640x480 resolution and you set as default resolution 320x240 the size of the game and the tilemaps will be set to 320x240 overriding the game's native settings...

Applying a minimum hard limit by editing the lines 293 and 296 of config.cpp is enough to fix this if (conf.defScreenW < 640) if (conf.defScreenH < 480) ... but the "problem" will still exist for the games with higher resolutions...

[Ancurio]

So, I poured over the code changes multiple times now and I'm still not entirely sure what they're supposed to solve.

Could you state: 1) The initial problem 2) Your proposed solution 3) How you implemented said solution (optional if not clear from 2))

thanks!

[pk-2000]

I can understand the confusion

1. the initial problem is on graphics.cpp lines 929 & 930 and glstate.cpp line 123, that lock the size of the window to 640x480.
2. instead of using a fixed window size, to link the window dimensions to the mkxp.conf settings and the threaddata

3. that can be achieved by importing the modifications of graphics-binding.cpp, config.cpp, glstate.cpp and graphics.cpp. For the eventhread.cpp the necessary lines are 124-126...

   ... 108 & 127-130 are not needed, unless you want to define the minimum, initial and maximum sizes of the window... ... the purpose of the rest* is to query the SDL, about the size and position of the window before entering fullscreen mode and then restore it to the exact same position after leaving fullscreen mode.

*I added those lines for compatibility with some custom resize scripts when used with your WIN32API wrapper. Without them when exiting fullscreen mode, the window is always placed in the upper right corner of the monitor.

[Ancurio]

Sorry for the late reply.

the initial problem is on graphics.cpp lines 929 & 930 and glstate.cpp line 123, that lock the size of the window to 640x480.

I think we need to converge on a common vocabulary here. 640x480 is the game screen resolution, not the window size. If you set winResizable=true in the config you can manipulate it any way you want (though not from RGSS).

instead of using a fixed window size, to link the window dimensions to the mkxp.conf settings and the threaddata

so this means you want a variable screen resolution that is dependent on the current window size?

... the purpose of the rest* is to query the SDL, about the size and position of the window before entering fullscreen mode and then restore it to the exact same position after leaving fullscreen mode.

on Linux this always happened correctly for me already with no involvement from mkxp's side. Also, if it doesn't work that way, I think it's SDL's problem to solve; if they won't I can think about a workaround but I'd like to go the proper way first.

[pk-2000]

I think we need to converge on a common vocabulary here. 640x480 is the game screen resolution, not the window size. If you set winResizable=true in the config you can manipulate it any way you want (though not from RGSS).

Correct. As it is now 640x480 is the game screen resolution.

so this means you want a variable screen resolution that is dependent on the current window size?

Yes. Initially, I only wanted a variable game resolution. I had to link it to the window size, for compatibility with some games. They start/initialize with a game resolution set to 640x480, then resize the window and then use the new window size to re-adjust/update the game resolution.

on Linux this always happened correctly for me already with no involvement from mkxp's side. Also, if it doesn't work that way, I think it's SDL's problem to solve; if they won't I can think about a workaround but I'd like to go the proper way first.

For me on windows 7/10 always worked correctly. On linux on most machines worked correctly but on others did not... (more likely buggy gpu drivers)

[Ancurio]

I think this branch of mkxp-freebird should do what you want (alternatively, consider using mkxp-z which has a lot more features in general).

[pk-2000]

I think this branch of mkxp-freebird should do what you want (alternatively, consider using mkxp-z which has a lot more features in general).

Sorry for the late reply. About the freebird version: It resizes fine but has visual bugs. In games with resolution higher than 800/600, the text in messages and menus is not displayed at all or displayed partially. About mkxp-z: has many incompatibilities with lots of japanese games(scripts) and performance issues. v2.2.3 is somewhat better but still 60% slower than mkxp original and derivates. ps. feel free to close the pull request.