[Request] Multiples resolutions per system

General Development
#1

Hi guys, first of all, I’d like to say thanks for the great work you’ve done with this system, it’s such a nice fresh air in the emulator world!

I’d really love (and I’m clearly not the only one after having spoked with a lot of people about it) to be able to use multiple resolutions (and refresh) for each system that Retroarch has a port.

Because everyone having an arcade cabinet or CRT monitor will see a major improvement in using Retroarch with this.

NB: The all custom modelines and refresh trend came more or less from Calamity and he’s amazing groovymame that permit through his modified driver for old ATI to use up to 120 different resolutions to have each game on the exact original one.

It seems that Retroarch already permits to choose one custom resolution per system and that’s perfect for a system like the Nes who is using exclusively the 256 x 240 one. But then what about other systems like the Super Famicom who has 256 x 224, 256 x 239, 512 x 478 and 512 x 448 as possible resolutions for it’s games?

Please can someone add the support of multiple modelines under Windows, that will make Retroarch a must have for CRT owners!

Thanks a lot. Nocta

#2

I don’t think this one is likely, unfortunately. Per-game configs were considered and ultimately rejected when per-core configs were being implemented. Plus, none of the devs use CRTs, and trying to accommodate all of the CRT-friendly, native resolutions became a bottomless pit of feature-creep and frustration with the Wii port, so it’s sort of a sore point.

#3

Ok I understand. That’s really unfortunate though, it would have been the best thing that happened to CRT lovers since groovymame if it was implemented… :slight_smile:

#4

I’m also using Retroarch with the intention to run native resolutions on a CRT. And the option to use multiple resolutions per system would be really great. But since it’s not viable at the problem, I’m trying to find some workaround.

Is it possible to manually select which .cfg file you want to use? I’m using config files per-core, and when trying to load a new config file that I created in order to use a specific resolution, it’s not working because Retroarch is using the default settings of the core, and not the new cfg file that I created.

#5

retroarch.exe --config custom.cfg --menu --verbose should do it

#6

retroarch.exe --config custom.cfg --menu --verbose should do it[/quote]

It says it’s using the custom.cfg inside the GUI, but it’s still reading some settings, like the resolution, from the default per-core .cfg file. So, it’s not working.

#7

Any chance to finally get this integrated now that you have a CRT hunterk? :slight_smile:

That would change the all game for CRT owners and add great value to RA, please guys, give it a chance! :rolleyes:

#8

I haven’t had any problems using the current options, but I am in Linux and have just setup launch scripts for the various resolutions I’ll be using, which tbh isn’t very many (“240p” for consoles and then 384x224 CPS1/2/3; might set up some more this weekend), via xrandr.

Maister did just add resolution switching in KMS but it’s only among your available modelines (i.e., it can’t force totally new resolutions, based on, for example, a game you just loaded) and is, of course, linux-only. It should work with Calamity’s GroovyArcade, though, I would think.

As I use my monitor more, though, I’ll try to keep an open mind on ways to improve the experience. :slight_smile:

#9

Thank you so much for your answer hunterk. :slight_smile:

Using a horizontal resolution that’s a common multiple of all the system’s possible native horizontal resolutions seems to work quite perfectly with CRTs.

The main problem I can see left is the switch from progressive to interlaced. When games switches from 240p to 480i in-game you have a problem. If you’re running at a 240p mode they will be downscaled, and you will be obliged to use a shader to enable proper downscaling/interlacing. Not really nice.

But this addition by Maister could be the solution I was looking for, sadly not under Windows yet. Any chance we could have it one day?

#10

I think the only reason it works in linux is because KMS can exert direct control over the display. The closest I would think you can get in Windows would be fullscreen_resolution_x/y and windowed_fullscreen = false (or whatever those options are exactly).

For the “super” resolutions, I can’t get my monitor to accept any modelines with very large horizontal resolutions. That’s another thing I’d like to work on, since everyone speaks so highly of it.

For 240p/480i, I did just write an interlacing shader that will let you run in 480 all the time and put 100% scanlines on 240p content while interlacing the 480i stuff. I haven’t tried it myself yet, but GPDP and Monroe88 seemed satisfied with it.

#11

I saw it and it’s pretty amazing! Sadly this will not work for 15khz screens. =(

#12

hunterk, I just realized that the method used by Groovymame to allow automatic resolution and frequencies-switching (per game) is not made around hacks but around SwitchRes, which has it’s code available here!

Any chance that you could throw an eye in it and see if it could be possible to have it incorporated or at least facilitate the option to add it for 15khz CRT RA users?

Thank you. Nocta

#13

Oh, ok. Interesting. I’ll look into it. Thanks for the info/iink :slight_smile:

#14

Hi hunterk, any news concerning the possible integration of Switchres in Retroarch?

I have talk about it on some 15hzCRT-users forums and we are really looking forward to it! :wink:

#15

I’m not sure it’s feasible, unfortunately. However, it’s been awhile since I first looked at it and I’ve forgotten exactly why I was pessimistic about it. I’ll try to revisit it in a couple of days and post back.

#16

Thanks a lot Hunterk, I’m crossing fingers! :slight_smile:

#17

Just an update and some questions about switchres. I’ve been talking with maister about this and while I don’t think it’s feasible to incorporate SwitchRes’ code and functionality directly, we might be able to smooth using it with RetroArch.

SwitchRes has a standalone utility that can be used to generate modelines that are native to a game yet safe for your monitor, correct? Can this utility be used in a batch mode? That would allow users to set up all of their modelines ahead of time (in xorg.conf and/or EDID, for example) and then RetroArch could set fullscreen resolution based on those modes (particularly when running in KMS mode).

Approaching from another angle, I see that SwitchRes standalone has a commandline option for --emulator where you can specify emulators other than MAME for it to work with. What other emulators are supported by this? What would RetroArch need to expose to be supported in this way?

#18

What a great news, thanks a lot guys!

I contacted the guys behind Switchres, forwarding your questions and I’ll tell you right away when I’ll get an answer.

#19

Here is the answer by Calamity :wink: :

I think that for the specific task you’re requesting this feature (basically being able to perform resolution switching within a game for PSX and such platforms) there’s really no point in incorporating SwitchRes into RetroArch. As Hunterk is explaining it is a better idea to just assume that the modelines are already available to RetroArch in the first place.

So let’s consider the scenario where you have properly configured a system with two modelines such as 2560x240@60 and 2560x480i@60 (which is trivial to achieve in both Windows & Linux).

What you want the emulator to do is to be able to dynamically switch between both modelines, depending on the vertical resolution requested by the emulated hardware.

Without having the minimal knowledge of the internal details of RA, dynamic resolution switching may involve some refactoring of the DirectX full screen implementation. Basically you need to destroy the current device and create it again with the new resolution, with all the additional caution required if you’re running several threads for the video.

You also need to implement some logic for best mode picking, in case it’s not already included. This logic could operate on the whole mode list returned by the OS, or simply on an user defined mode list. I believe that like most emulators, RA only allows to specify a single resolution for full screen mode, by using the video_fullscreen_x & video_fullscreen_y options, so specifying an user mode list would involve implementing an array of these options.

A solution for not implementing that array would be using “resolution masks”, like this:

video_fullscreen_x = 2560 video_fullscreen_y = 0

Here “0” would be used like a wildcard. If “0” is already used to indicate the desktop resolution, another value could be used (“1”, or whatever).

Then, when the emulator detects a resolution switch request, it would decide which from the list of 2560x resolutions better fits the requested height.

As a note: a proper full screen configuration for any emulator should contain 3 values, not 2:

video_fullscreen_x = ? video_fullscreen_y = ? video_fullscreen_refresh = ?

That’s the only way to unambiguously target a certain video mode in the Windows OS.

Finally, answering Hunterk’s question, SwitchRes supports any emulator provided it takes command line options, it just launches the emulator with the specified options and performs a mode switch previously if specified, this is useful for emulators that are only capable of running at the desktop resolution. My understanding is that if the above or something similar was implemented then launching the games with SwitchRes wouldn’t be necessary.

RetroArch - Native CRT Support
#20

Cool. Thanks for the info and for being the go-between :slight_smile:

It indeed sounds like the way to go, then, is to see about setting up a mask that ties into a game’s reported resolution and refresh rate. I believe we indeed have the video_fullscreen_refresh option already and the logic for choosing proper dimensions/refresh, as maister mentioned in another thread. He pointed me in the direction of the file that likely needs editing, as well, so I’ll see if it’s within my reach. If not, I’ll try to goad someone into helping out.