I’m getting some odd behavior when trying to load RetroArch through a frontend (Attract-mode). The game loads, but the resolution switching doesn’t seem to function. It will output to whatever resolution the desktop is set to.
I’ve not done any testing from different front ends. Does it work if you load Retroarch normally? I know with frontends you have the options to load a config file, is attract-mode loading the retroarch.cfg? this is were the settings are for the switching. Frontends load Retroarch in CLI mode so you will have to make sure the correct arguments are being added.
Once you’ve loaded a game in attract-mode can you press F1 and check in the menu if crt switching is enabled.
I’ve got it working now. It seems Attract-mode handles formatting the commands kinda strangely and was reverting to an earlier working config? I really don’t know why it was partially working to be honest, but putting quotations around the RetroArch path (it was working without them before) seems to have fixed it up nicely. I’ll chalk it up to user error.
Attract Mode is a launcher, not a frontend. Retroarch is still the frontend in this scenario
It is now merged. So if you download the latest nightly it will all be there.
There’s a wiki post here on the forum where we can make some documentation for the feature. We need some text explaining what it is and how it works (layman’s terms is good enough; doesn’t need to be very technical) and then some steps explaining how to set it up on a new blank-slate system:
I’m working on this now
OK guys, big update for Linux here. I have now included a modeline generator into RetroArch. So there will be no need to create custom resolution for Linux. Also with this modeline generator it set the exact hz needed for the core. In turn there is now no need for VSYN making in put lag non-existent.
Currently switching is a bit jarring, but I need to clean the method and move some of the method around which will help smooth this out.
@markwkidd any news from the devs?
That linux switching is looking awesome!
The Windows switching is merged and Twinaphex has been going through cleaning up the little quibbles. That was really the biggest hurdle, and the linux switching should get merged pretty quickly.
Has the linux switching been tested outside of X (DRM/KMS), or is it still dependent on xrandr?
ATM I am not sure how you can setup a custom resolutions as low as 192, 224 or 240p outside of xrandr. If any one has some knowledge in this and what’s to help out I’ll add other methods.
I think it should be just like normal DRM/KMS but you’ll use the functions from here: https://01.org/linuxgraphics/gfx-docs/drm/drm-mode-setting.html to create the modelines using the CVT algorithm, then add them and atomically switch to them as needed.
I am not using CVT, this is because it does not acuratly set the refresh rate. So instead I have created my own modeline generator within RA. This guarantees that the correct hz will be set, matching the core and no need for VSYNC.
If I can I would be happy to use my generated lines with drm. I have a lot going on at the moment but if some one wants to create a barebones drm fuction for switching I’ll add it in.
With drm can we add and remove resolutions on the fly, this is need as some cores are in the same resolution but a different hz. Hence the need to continuously add and remove them.
I’ve read that xrandr works with kms as long as you are on or above kernal 3.2
Oh, ok. I didn’t think xrandr was usable without an X server running. If it is, I don’t suppose there’s any issue. I guess we can test it out soon enough
This Is what I have read. You should be able to link the display to xrandr in terminal using the following command.
After this xrandr should be able to control and see your dislay outputs.
I was surprised I hadn’t checked back on this for a moment and ended up downloading the newest nightly for a totally unrelated reason and saw this was implemented. It’s working perfectly now in every scenario! Great work again @Alphanu this is awesome to finally have
Is this 15khz CRT support supposed to work with any video driver (gl, d3d9, d3d11, vulkan…) or is specific driver oriented? I’m asking this because I can’t get it working other than gl driver.
It uses RAs back-end video driver so should work with all. However, having said that windows does have issues with D3D and interlaced resolutions. Myself and @Retrorepair have had it working with D3D but you need to install the latest Directx run-time/SDK. However having said that GL has always given the best results.
There will be Wiki updated soon with all the relevant information for setting things up.
Ok guys this is it. I still need to tidy the code and put it in the correct places before I submit the next PR.
I have super fast Linux switching. Modlines to match and sync odd hz like Mortal Kombat. All this working without the need for VSYNC.
During my lag test I managed to get a huge result of 0.2 frames. This is shown at the end of the video.
@Twinaphex to generate and install these modlines that corretly mimic the original hardware I am having to use the system(); function. This can be changes to say execlp(); if preferred? Let me know so I can ammend anything before submision. Or if these are not allowed I’ll need to go back to the drawing board.