Handle Videomodes better #211
Closed
alufolie91 wants to merge 28 commits from
vidmodestuff into Saturn-Next
pull from: vidmodestuff
merge into: saturn:Saturn-Next
saturn:Saturn-Next
saturn:lugstuff
saturn:retrySOCK
saturn:polyholes
saturn:dynskins
saturn:Saturn
saturn:mobjcheck
saturn:waterrefract
saturn:bluaopti3
saturn:lua-no-zzone
saturn:mac-ci-test
saturn:luaprofile
saturn:introsfxshit
saturn:mointerpfix
saturn:maperrors2
saturn:maperrors
saturn:testintermissionfix
saturn:optifindvar
saturn:holeywallcolumns
saturn:Saturn-Testing
saturn:addon-download-info
saturn:hwbspupdate
saturn:bluaopti2
saturn:optimizewadlumps
saturn:netstuff
saturn:bluaopti
saturn:newfpscap
saturn:fixedclamp
saturn:threadstuff
saturn:servaddonsonly
saturn:timestuff
saturn:fixcmake2
saturn:crashissuereports
saturn:mipmaplistopti
saturn:menumodels
saturn:fixceemake
saturn:sdl3
saturn:remove-unused-mobj-interp-vars
saturn:revertsdl
saturn:updatesdl2again
saturn:controllerfixes
saturn:fakeseed
saturn:gammastuff
saturn:fastcmpstuff
saturn:luacvarfixes
saturn:SOCKma
saturn:lua-check-local-addon
saturn:updatemixer
saturn:dsdacol
saturn:transposesoft
saturn:updatelibbacktrace
saturn:deletglseg
saturn:curl-cli-args
saturn:refactorfbo
saturn:servericonpack
saturn:fastfilesearch
saturn:ljtest2
saturn:optional-freeslot-test
saturn:updatemd5
saturn:texhash
saturn:winzlib-ng
saturn:mmenucleanup
saturn:fixgnu23
saturn:unnestmothink
saturn:fixupnet
saturn:fixuphwbsp
saturn:updatewinlibs
saturn:emotes
saturn:softwarecrap
saturn:newmakefiles
saturn:luamusicdef
saturn:votebgstuff
saturn:netshit3
saturn:directionallight
saturn:ljtest
saturn:splitscreendirector
saturn:shaderspriteclip
saturn:refactorportals
saturn:nomobjshadows
saturn:sfc32rand
saturn:nettest2
saturn:nettest1
saturn:neo-kart
saturn:addfilelocal-load-animdefs
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
"Unhardcodes" the videolist
instead it will now fetch the availble displaymodes for the current screen
This allows any wonky display and display setup to get their supported screen resolutions
Custom resolutions will now also be put into the list, which makes them appear in the video setup and are reselectable aslong as the resolution cvars dont change
All the games "green" resolutions are in a seperate list which will make sure they are ALWAYS avalible on any setup
Should the gamewindow move to a different display, the resolution list will be automatically rebuilt and when in the display setup that will be refreshed to reflect the new list
Not completely sure which max would be the best, but currently this allows to hold 33 video modes (apparently the menu is desinged to hold a max of 36, so this could be raised to the menu limit if needed)
needs a bit of testing to see if anything breaks
tested on a 2560x1440 16:9 screen, a 1920x1080 screen in vertical orientation, and a 2160x1440 3:2 screen in a linux wayland setup
If someone could check on a different setup (ultrawide displays, different os; x11) would be greatly appreciated
much thanks to dsda-Doom for most of the code (saved me almost all the work lul)
Tested on Windows, everything broke since it returned a gazillion video modes, but should be fine now
Not sure how mac behaves, and idk how to test since i dont know how xcode works or if it even still runs on my 15 year old imac
Would like to test this on macOS, but unfortunately the CMake build has broken since the last time I tried it in June because of the new source files and cpp files, which the CMake build wasn't updated for. (macOS uses CMake, not Xcode. The Xcode project for SRB2 is ancient, and should probably just be removed.)
Edit: I made a branch that partially fixes this, but it isn't complete: https://github.com/P-AS/SRB2Kart-Saturn/tree/fixcmake
Also worth mentioning that this on X11 works fine.
Oof somehow still assumed macos relied purely on xcode.
fixing up the cmake build has been on the todo list for a good while now, but never gotten around due to the assumption its not strictly needed and all the mess with the c++ stuff during v9
if you could make a pr of the fixes would be really really appreciated X)
Perhaps with that knowledge might be also worth looking into providing a mac build aswell which would be awesome
good to hear its working on x11 too though
Ok this is pushed back a bit, since it should be tested a little more just in case.
I´ve made a new branch looking into it now aswell, it mostly ported everything over from blankart.
Not everything is fully working and implemented yet, but it produces a functional executable on nix (arch btw) for me
https://github.com/Indev450/SRB2Kart-Saturn/tree/fixceemake
If you could try it out on macOS would be super helpful! c:
Got it to build successfully with this, bit it needs a patch (https://github.com/P-AS/SRB2Kart-Saturn/commit/ee31cc1722519e4355eae935f683693df104f262) to correctly compile and link on macOS.
Edit: doesn't break CMake/make on linux either.
Used the command: (these last two should automatically turn off but they don't)
phew really glad this works with some tweaking, ty very much for testing and fixing things up c:
seeing that threads are disabled, so i removed the thread.h include (it wasnt needed anyways, not sure why it was there)
looking a bit around the net the thread_local keyword should be included with clang from xcode version 8, not entirely sure how new that is, but perhaps just removing the include might work ?
otherwise might consider looking into pthread or just seperating the software multithreading from the rest that uses sdl threads
definitely be sure to make a small pr for the ceemake branch so we can get on fixing up the rest of it!
Before/After(16:10 and 16:9) on macOS:
Turns out the modes in red can work correctly if you go into settings and completely disable HiDPI scaling (which I didn't realize was a thing Apple even allowed you to do). Changing the FBO option made no difference on macOS either. This isn't just a macOS specific problem either, it happens on Wayland too (at least when running SDL2 Classic, higher resolutions work correctly when running sdl2-compat on Wayland). Aside from that problem (which is out of scope anyway), I can confidently say this PR works fine on all the environments I've tested it on.
Same exact Linux build on Wayland with both SDL2 Classic/sdl2-compat:
Hm really weird, red marked resolutions are those that are checked to be higher than the current desktop resolution.
Yet they still get added to the list?
I assume you set your display at 3840x2160?
For me setting the desktop resolution below native will not even add any resolution above that here.
Maybe some discrepancies in how SDL reports display modes back in some cases, need to recheck how we get he desktop resolution again
Glad to hear that it works everywhere otherwise c:
Ok i think i see, desktop resolution gets checked with SDL_GetDesktopDisplayMode instead of SDL_GetCurrentDisplayMode, which might report something different if anything in the display settings/properties got changed during runtime
gonna close this for now since this is a huge mess and i dont have any means to check anything on mac
maybe ill revisit this sometime in a less messy way
Pull request closed