RetroArch - Native CRT Support


Currently this is in early stages and does not detect multiple displays, It will only set device 0 ATM. This will be where I will have to build in some options to set which display you want to use.

Its not a big code change to recompile, so if you know whether your CRT is plunged into device 1 , 2 or 3 let me know I’ll make the change so you can test.


Sorry if I didn’t answer all your question this evening, I’m not ignoring them. I have a fair amount going on ATM.

@Abwezi @SkyHighGam3r @radius


No worries, I’ll try testing it tonight with just the CRT hooked up and see what happens. I just wanted to make sure it wasn’t my setup since I’m testing with CRU instead of CRTEmuDriver.


Does CRU add modelines into windows registry?


Sorry if I didn’t answer all your question this evening, I’m not ignoring them. I have a fair amount going on ATM.

You are certainly alright I’m more than appreciative of what you’ve done already.


I’m not sure - I know you open the program - create a resolution - use a restart file and it resets the graphics drivers. Then those resolutions show up in the Windows display settings options.

Seems to stay with it after a restart - so possibly? I’m not sure where I’d look in the registry for that to confirm.


It doesn’t look like beetle psx has geometry switching based on the current display mode.

I just reviewed the code and the only thing that triggers a geometry change is changing the rendering resolution which is not the same.

   if (environ_cb(RETRO_ENVIRONMENT_GET_VARIABLE_UPDATE, &updated) && updated)
      struct retro_system_av_info new_av_info;

      /* Max width/height changed, need to call SET_SYSTEM_AV_INFO */
      if (GPU_get_upscale_shift() != psx_gpu_upscale_shift)
         if (environ_cb(RETRO_ENVIRONMENT_SET_SYSTEM_AV_INFO, &new_av_info))
            // We successfully changed the frontend's resolution, we can
            // apply the change immediately
            has_new_geometry = false;
            // Failed, we have to postpone the upscaling change
            psx_gpu_upscale_shift = GPU_get_upscale_shift();

      /* Widescreen hack changed, need to call SET_GEOMETRY to change aspect ratio */
      if (has_new_geometry)
         if (environ_cb(RETRO_ENVIRONMENT_SET_GEOMETRY, &new_av_info))
            has_new_geometry = false;

I mean, feel free to prove me wrong but this code indicates that beetle psx doesn’t react to internal mode changes.


Well if you seem them in the display options they will be an available resolution switch :+1:


Hmm OK if thats the case then some other part of beetle must be reporting back resolution changes.

This output text is what I receive from the video callback and retro_timing functions running Crash bandicoot.

This is then uses to set windows resolution and frequency if available. and set aspect ratios on the fly. Aspect ration changing is not Incorporated yet.


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.


Unfortunately, there is no current bounty. The issue was closed a while back. I will still work on it, but yeah its defiantly worth a big bounty!

Come on all you guys that are after this. Help me out, make a new issue and open a new bounty :heart_eyes:


I’ve got $25 I’ll throw down on it, either in a bounty or just sending it through Paypal or whatever. This is indeed a big deal.


In terms of the bounty itself, I just created a new github issue here:

Folks can paste that URL into bountysource to build the bounty back up again:

Edit: Direct link to add to the bounty:


I’ve got $25 down to get the ball rolling, lets make this happen!


I threw $25 on it, as well.

@radius, for the core needing to support it, do you mean having retro_set_geometry in retro_run() so it gets called on each frame??



Direct link to add to the bounty:


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 :sunglasses:


I’d love to test but I don’t have a CRT. So you’re changing res based on the width / height from video_cb?

I guess that’s one way to do it, although it seems a bit wasteful? it would be better if it happened on set_geometry, but maybe this is the correct way for a CRT, I wouldn’t know.


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!