Well if you seem them in the display options they will be an available resolution switch
Currently super resolutions was a quick implementation. I did not get round to setting an ignore function in the horizontal detection if the resolution is correctly scalable.
In terms of the bounty itself, I just created a new github issue here: https://github.com/libretro/RetroArch/issues/6368
Folks can paste that URL into bountysource to build the bounty back up again: https://www.bountysource.com/
Edit: Direct link to add to the bounty: https://www.bountysource.com/issues/55920730-native-15khz-crt-support-in-retroarch
I’ve got $25 down to get the ball rolling, lets make this happen!
I threw $25 on it, as well.
@anon24419061, for the core needing to support it, do you mean having retro_set_geometry in retro_run() so it gets called on each frame??
Awesome!
Direct link to add to the bounty: https://www.bountysource.com/issues/55920730-native-15khz-crt-support-in-retroarch
Thank for the support guys, Its very much appreciated. @markwkidd @hunterk @Abwezi
beta testers will be needed soon, so if you know any others interested? The more results on different systems tested, the quicker things may go and the quicker the end result
I don’t have any Windows machines hooked up to my CRTs, so I can’t do any testing at the moment, either. Are you planning for linux support, as well? I haven’t looked to see how GroovyMAME handles it, whether it’s xrandr or something else.
I’m sure groovymame uses xrandr, I have had a good look over the source code for it. If there is enough interest then yes I will look into porting for linux.
My personal opinion it that Windows has to many overheads for an emulation machine. However, linux does not see to run emulators as fast. I’ve only tested this on ubuntu to be fair. Arch others maybe faster.
Although I do remember using groovyarcade back a while back and if I remember that was running on Arch linux.
I’ve ranted on here but the answer in short is yes. Once this Windows version matures there will deffo be a linux release!
I just want to re-iterate this statement. There is a 4:1 which is suitable for 1920x480, but not an 8:1 for 1920x240. Let alone higher resolutions like 3840x240, etc, etc.
As far as I know, the only way to get proper visuals is to set the aspect ratio correctly and set integer scale to “on”. Setting it to ‘config’ requires you to manually input the x/y resolution numbers; which are going to differ between each system (and in our case multiple times per game).
You can manually set 8:1 or 16:1 aspect ratio by changing the “Config Aspect Ratio” to 8.0 or 16.0 and setting the Aspect Ratio mode index to “Config”, and this automatically scales horizontally without needing to change anything per-game. The custom viewport x/y stuff is only used if the Aspect Ratio index is set to “Custom”
In the config file, it would look like this:
aspect_ratio_index = 19
video_aspect_ratio = 8.0
With 3840x480 fullscreen resolution, this will automatically stretch all games to the full width of the screen.
With 3840x480 fullscreen resolution, this will automatically stretch all games to the full width of the screen.
Is there any way to accomplish this regarding the height of the screen? My problem currently trying to use the fork for supee resolutions is that 240 and 480 high modes don’t stretch to the height of the screen when switching from one to the other
If you wanted to try using kernel mode setting, I believe the relevant section would be here:
If you have Integer Scale turned on, it should automatically scale and center the game vertically to your output resolution. However, it’s probably not updating the scaling when mode changing between 240 and 480 because the aspect ratio is not being reinitialized with the new dimensions yet.
I have a crt connected all the time, so feel free to use me for testing.
Foxhole was kind enough to send me his retroarch config and that helped me figure out my configuration issues so a big thank you to him! With this I have everything working properly with all platforms and games tested so far. Does anyone have a few good examples of games to test?
The game mentioned by @anon24419061 Seiken Densetsu 3 would be a good one. I’ve not incorporated aspect scaling and width ignore yet. It will be interesting to know how it functions. With your config.
Games that i know about that switches from 240p to 480i in gameplay to menu’s.
Ps1
Chrono Cross (Between gameplay to menu)
Einhander (between gameplay and config/gallery/ending credits)
Tobal No. 1 (between gameplay and FMV)
Tobal 2 (between gameplay and FMV)
Silent Hill (switches to 480i for the inventory screen)
Toaplan Shooting Battle
Dance Dance Revolution 4th, 5th, and Extra Mix
Thunder Force V
Omega Boost
N64
Killer Instinct Gold
Which emulator is everyone using for n64 and which plugins/settings? I’m having trouble getting anything (N64) to run with this build and feel like it must be down to a modeline misconfiguration.
EDIT - With parallel core d3d isn’t working at all and gl crashes on interlaced gfx if you choose 320x240.
@Retrorepair If your CPU is fast enough, try using angrylion gfx plugin with cxd4 RSP.
@Alphanu Re: switching too much, I was thinking about how we would ultimately handle this functionality in the config/menus and I figured a good solution could be to have 1 overall option (call it CRT Switch Res or something like that) that has 2 modes of behavior: super-res (horizontal res is locked to 2560 or whatever, vertical res changes when the game changes it [could be represented as a mask in the video_fullscreen_y config option, such as -1 since 0 is already taken]) and “original” (both horizontal and vertical res change when the game changes them; both video_fullscreen_x and video_fullscreen_y would be -1 in this case). So, the option would have OFF, Super-Res, and Original to choose from.
This would solve the issue @anon24419061 described without needing to change how you’re doing it or dig into each core and add core options to enable res-switching capability (i.e., adding set_geometry to run on every frame).
I think it would also be good to have a “double scan” toggle that just doubles the refresh rate values it matches against, for people using 31 khz PC monitors.