Crt_Emudriver and Retroarch - Interlaced resolution issue

Hi. I am using retroarch on a win7 x64 machine with crt emudriver and a 15Khz crt. The issue i am facing is that when starting retroarch from an interlaced resolution such as 640x480i and retroarch is configured to use a progressive resolution such as 640x240p, it will not change the resolution but just display retroarch on the upper half of the screen. From what i’ve read this is due to a win7 bug that causes problems when changing resolution from interlaced to progressive. As far as i know this is possible to fix, though i am not a developer so i’m not sure how. Is there a chance of seeing a fix to this problem implemented in retroarch? Thanks.

Not likely. RetroArch just spits out framebuffers and doesn’t have any concept of interlaced fields, etc. Your best bet is to either use 480 res with the interlacing.cg shader to draw black over half of the lines or switch to an actual 240p signal before launching RA.

Currently switching to progressive before launching is what i do to get around this problem, i was just hoping there would be a way to completely fix that issue. And i do recall not having that issue wih a very old version of retroarch. I will have to look for it though since i can’t remember the version.

Just checked it, and versions 1.2.0/1.2.1/1.2.2 switch the resolutions just fine, it’s the later versions that exhibit this problem. So it is possible to fix this, the only questions is how?

English isn’t my native language so i may have been not too clear as to what i mean. If windows is set to an interlaced resolution like 640x480i and retroarch is configured to a progressive resolution such as 640x240p, what should happen when launching retroarch is the resolution should have change to 640x240p, but what actually happens is that the resolution stays 640x480i while retroarch itself is squashed to the upper half of the screen. I hope my message is clear now, if not i can take some pictures to show what i mean. Thanks.

We would have to find which commit actually caused the change in behavior. The whole program has basically been rewritten multiple times since 1.2.2, so it’s sort of a needle-in-a-haystack situation without that information.

I have some free time on my hands so i should be able to track the version pretty quickly.

Hmm, seems like i spoke too soon. I was hoping i could find the nightly from 1.2.2-1.3.0 that caused this but it seems that the only nightlies available are for the new version. Is there an archive maybe for the old nightlies?

No archive, no. If you can build it yourself, you can use git bisect to fetch and build snapshots until you find the one that broke it.

Unfortunately, that’s beyond my knowledge for the time being. For now i’ll have to use version 1.2.2.