Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic resolution support #328

Merged
merged 506 commits into from
Jan 21, 2024
Merged

Dynamic resolution support #328

merged 506 commits into from
Jan 21, 2024

Conversation

ds-sloth
Copy link
Collaborator

@ds-sloth ds-sloth commented May 8, 2022

I've had these features backported for a while. Now is a good time to begin testing and discussing, since they're now based on the main branch rather than another PR.

Some areas I think may have things to discuss:

  • Which NPCs should activate when they are visible, and which should activate when they are within 800x600 of the player? (Should the answer depend on whether the screen is bigger or smaller than 800x600?) Answer: we have a good set of defaults for now, future cases can be raised in Issues.
  • How should section resizes be animated? During 2P mode?
  • Should gameplay field resolutions above 1728x720 (2.4 aspect ratio 720p) be supported? Answer: probably not -- too far above the original game's 600p.
  • Correct handling to force at least 800x600 during Mode 2/3, and in multiplayer.
  • Finish the fog-of-war effect. Answer: still too many things to discuss, instead limit the world map view by default.
  • Ensure that the ini files for the new world map border and backdrop assets are correctly loaded.
  • How does this work on Vita? Other non-desktop platforms? Answer: @suicvne says there are a few issues with rendering that are more obvious here, but also occur in 2P mode on the non-multires version.
  • Resolve minor gameplay recording divergences recently discovered by @ds-sloth
  • Resolve 2P object spawn issues discovered by Sapphire Bullet Bill
  • Improve rendering for AutoCode HUDs that target 800x600. >800x600 done, <800x600 isn't possible in most cases. I now agree with @0lhi that it's up to the user's discretion if they're playing content designed for SMBX64/AutoCode.
  • Fix an issue where part of the menu information display became offscreen. Make menu logo transparent at low resolutions when it overlaps with text.

I'm sure there are also other suggestions or bugs that I haven't mentioned here. I'm looking forward to hearing lots of feedback.

@ds-sloth
Copy link
Collaborator Author

ds-sloth commented May 8, 2022

There may be some frame-count compatibility issues with the qScreen code during 2 player mode. Need to investigate further. This code is really tricky to debug. However, we now have animations like this:

@ChristianSilvermoon
Copy link

ChristianSilvermoon commented May 11, 2022

I do personally think higher resolutions should be supported, since 4K and 8K displays are a thing now days and it's always nice to be able to take advantage of the hardware you have.

Though admittedly I have a 4K screen I run at 1080p because that's just asking a bit too much of my poor 1050ti when it comes to gaming.

I unfortunately don't have any exotic resolution hardware to test the game on.
My Pine64 Pinephone has a 720p screen and my PiBoy DMG has a 480p screen

@ds-sloth
Copy link
Collaborator Author

I do personally think higher resolutions should be supported, since 4K and 8K displays are a thing now days and it's always nice to be able to take advantage of the hardware you have.

So, @Wohlstand built good scaling code and I've added integer scaling as an option. You'll certainly be able to run the game at 4K display resolution. (Even with integer scaling! It's 3x720p.) The question is whether the game's internal resolution should be able to be set above 1728x720. You can experiment by setting InternalW and InternalH in config.ini to something like 1920 and 1080 (or even 3840 and 2160) and seeing what things look like.

@0lhi
Copy link
Collaborator

0lhi commented May 12, 2022

Could we have an option to have the window size fixed (except for dynamic), and automatically adjust to the res selection?

EDIT: Also, some codes to change resolutions on the fly would be convenient:

  • gbaview and 480x320
  • snesview [...]
  • ndsview [...]
  • vgaview [...]
  • 3dsview [...]
  • smbxview [...]
  • hdview [...]
  • dynview
  • dyn{integer}x{integer}go

@LoveBodhi
Copy link
Collaborator

Also widescreen.

@ds-sloth
Copy link
Collaborator Author

@0lhi, I like your suggestion to resize the window automatically, but maybe with the following conditions: (1) the game is windowed, (2) the player has requested 0.5x, 1x, or 2x scaling, and (3) the player changes the playable field resolution to a non-dynamic setting. I had previously set it up to always resize the window, but certain strange issues kicked in on my Linux desktop, especially in fullscreen mode. I'll try to implement this feature again because I agree it's a lot more user friendly in certain contexts.

Separately, do you think we'll still need the cheat codes for changing resolution once there's an in-game options menu?

@ds-sloth
Copy link
Collaborator Author

The window should now resize when changing settings -- thanks @0lhi for the suggestion!

@0lhi
Copy link
Collaborator

0lhi commented May 22, 2022

(1) the game is windowed, (2) the player has requested 0.5x, 1x, or 2x scaling, and (3) the player changes the playable field resolution to a non-dynamic setting.

I agree with all of these conditions. Though the third one doesn't seem to apply? The window still resizes, but the resolution isn't dynamic. If this is intentional, I suggest to hide the dynamic setting while an x-scale is selected and vice versa.

I also suggest to group the x-scalings together (like "0,5x - 1x - 2x), and navigate through them with the select button. This prevents the window from becoming oversized when hitting 2x while having the 1280x720 resolution.

Separately, do you think we'll still need the cheat codes for changing resolution once there's an in-game options menu?

Yep! Commands will always be quicker to access than menu settings. The easier to access they are, the more people will be encouraged to test levels.

@ds-sloth
Copy link
Collaborator Author

Ah, I see. Yes, I'll make it not resize the window in this case. There are definitely use cases for mixing dynamic resolutions with fixed scaling, so I won't eliminate those combinations.

I understand that it's bad for the window to become resized, but the grouping mechanism with a new control key you mentioned seems a little overcomplicated. Maybe I'll try to figure out if SDL has any helpful methods for detecting the desktop size and use those to limit the requested window size.

Do you think the cheats should also resize the window when they are typed?

@0lhi
Copy link
Collaborator

0lhi commented May 23, 2022

Maybe I'll try to figure out if SDL has any helpful methods for detecting the desktop size and use those to limit the requested window size.

Oh yeah, that would be ideal!

Do you think the cheats should also resize the window when they are typed?

Can also depend on the scale option I think. (EDIT: So yes for 1x etc.)

@ds-sloth
Copy link
Collaborator Author

Is resizing during the game a cheat (should block save, etc)? (I really think not since this will be available from the in-game options menu, but wanted to check.)

@0lhi
Copy link
Collaborator

0lhi commented May 23, 2022

Is resizing during the game a cheat (should block save, etc)? (I really think not since this will be available from the in-game options menu, but wanted to check.)

Nah, this is a Debug Code :P

@ds-sloth
Copy link
Collaborator Author

Alright, feel free to check these out whenever you have time!

@0lhi
Copy link
Collaborator

0lhi commented May 23, 2022

I am very confused about the resize-ability of the window. Sometimes, I can't get it below 1280x720p. Sometimes, this occurs:
TinySMBX

Is it intended for the dynamic setting to not be able to go beneath 1280x720p?

Smallest Size at Integer Scale for GBA isn't supposed to be this big, is it?

IntegerScaleGBA

Idk. There is some pattern that can break the settings and some pattern that can fix them again. At least, scale1x + codes are reliable. I also like using the codes on nearest when the Window Size is fixed to 1280x720. It's convenient for the OBS Streaming software.

I like that the keyboard pops up when typing debugview, but the last letter finds it's way onto the keyboard:

Keyboard

Could you block out every non-number in that instance? // EDIT: Like this?

KeyboardFixed

@LoveBodhi
Copy link
Collaborator

Will be configable via gameinfo.ini?

@ds-sloth
Copy link
Collaborator Author

@LoveBodhi, gameinfo.ini will be extended to set default settings and compat values that apply everywhere (unless overriden) but I think this will be implemented during the upcoming settings rewrite. At that point, we will be able to set the default internal dimensions game-wide, and also restrict the game from using larger play fields. Does this answer your question?

@ds-sloth
Copy link
Collaborator Author

@0lhi, I think the weird resizability bug might have to do with the fact that we set the minimum window size whenever we set the window size. I don't know why we are doing this, but it's code I inherited from Wohlstand. I'll try removing it, and we can see if it breaks anything (maybe on Windows).

For the keyboard, this is a cheat -- it's not going to be all polished. I'll allow the user to type anything, even if it's invalid. But it's completely a bug that the last letter of the cheat shows up in the keyboard, and I'll try to fix that.

@LoveBodhi
Copy link
Collaborator

@LoveBodhi, gameinfo.ini will be extended to set default settings and compat values that apply everywhere (unless overriden) but I think this will be implemented during the upcoming settings rewrite. At that point, we will be able to set the default internal dimensions game-wide, and also restrict the game from using larger play fields. Does this answer your question?

I understand now, so Thanks❤

@0lhi
Copy link
Collaborator

0lhi commented May 24, 2022

I would keep the SDL_SetWindowMinimumSize() once to set the smallest size of the window (something ultra-small), just to avoid the user applying the impossibly small size.

240x170 seems reasonable.

240x170

@0lhi
Copy link
Collaborator

0lhi commented May 25, 2022

@ds-sloth Are you gonna do #190 before merge?

@LoveBodhi
Copy link
Collaborator

LoveBodhi commented May 25, 2022

768x432 (384x216, like Hello's fangames) or 424x240 will be added?

@0lhi
Copy link
Collaborator

0lhi commented May 27, 2022

Noticed a few issues:

  • Battery is shown even when battery-status = "off" is set.

Battery

  • Episode Title is not displayed anymore:
show-episode-title-small = 2
show-episode-title = 1

New
Old

@ds-sloth
Copy link
Collaborator Author

That is not the system battery status, but the controller battery status. They're shown in different locations, controller next to the controls preview, and system in the upper right. (The reported controller battery status is the same as system battery status for keyboard and touchscreen.) I don't think controller battery status is on by default but I can check. Can you verify that disabling battery status in the controller profile settings resolves this?

Ah, yes. I'll backport the episode title code soon.

@0lhi
Copy link
Collaborator

0lhi commented May 27, 2022

I don't think controller battery status is on by default but I can check. Can you verify that disabling battery status in the controller profile settings resolves this?

Ah yeah, I missed that. It is on by default but disabling in the profile fixes it 👍

@LoveBodhi
Copy link
Collaborator

But also:

  • 640x360
  • 848x480

@ds-sloth
Copy link
Collaborator Author

Hmm. Those can be set using the custom resolution setting in the ini. I tried to include the resolutions of the systems that the source games were on (3DS is included because it's a target platform of TheXTech). If a sizable user base also wants Hello resolution (768 x 432) I can also add that as a default resolution.

Why are 640x360 and 848x480 interesting to you?

@LoveBodhi
Copy link
Collaborator

These are modern 16:9 ratio!

@ds-sloth
Copy link
Collaborator Author

Ah, I see. I wonder... one option would be to have all the preset settings, but have a separate setting called "auto screen width" or something like that. This would turn any vertical resolution into a dynamic resolution like the "600p dynamic" setting. Then, we would not have the 600p dynamic, only the fully dynamic. But any fixed resolution could become horizontally dynamic.

@ds-sloth
Copy link
Collaborator Author

Thanks for the suggestions earlier, @0lhi!

Battery is shown even when battery-status = "off" is set.

New profiles now read the main config.ini setting for joysticks to determine the default value. (That setting is off by default.)

Episode Title is not displayed anymore:

I backported this feature now, but I use the same setting for the small-screen and big-screen cases. (Even though the location is still different -- screen top in big-screen, screen bottom in small-screen. Maybe we think about whether that's desirable.) I decided that, generally, users don't switch screen sizes frequently enough that it merits making one setting into either a complicated setting or a pair of settings. Also, the format has changed. It'll read the old numerical settings fine, but it'll also read "on"/"off"/"transparent" as strings.

Both of these have been updated both at the main branch and here.

ds-sloth and others added 23 commits January 2, 2024 18:00
For new files are wasn't at the branch "`main`".
@Wohlstand
Copy link
Collaborator

As a little exception to our internal rule (i.e. review each other before merge), let's merge this without of my complete review and test it out soon?

Why? Because of freaking Dezember (I was ill, had a strong cold, and was almost unavailable: I staid in my bed and was asleep the rest of time), and because of that a lot of stuff around got a strong delay. That's not good. Totally.

@Wohlstand
Copy link
Collaborator

Anyway, I did a partial review of the thing, and seems fine for me. I think, other parts I'll review in hot during experiments at the Main branch.

P.S. Do Squish merge.

Copy link
Collaborator

@Wohlstand Wohlstand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving this quickly, so, if anything I'll find, I'll fix that it being already merged to Main.

@ds-sloth ds-sloth merged commit a267ac2 into main Jan 21, 2024
27 checks passed
@ds-sloth ds-sloth deleted the wip-multires-backport branch February 19, 2024 17:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New quality-of-life feature or request (does not change gameplay) gameplay enh. New gameplay feature or request multires Issues regarding the Multi-Resolution feature.
Projects
None yet
9 participants