Best card for 31k only

[cools]

Having had such great success with Groovy and fake scanlines on a Rodotron, I thought I'd grab a faster card and see if that provided any benefit. One HD 4350 installed later, and I'm wondering why Groovy 148 looks so blurry. Since I'm trying out a "stock" configuration I try switching back to my 147 config, but the results are the same. I try upping the prescale value but with no effect.

Curious, I swap the previous HD 2400 back in. And bingo! Everything's pixel perfect again.

Should I be seeing this variation? With the 4350 it looked like prescale was at 1 whatever I did (blurry), but with the 2400 the scaling is pixel perfect at stock settings and the 31k resolution looks exactly like a 15k screen.

[wesbrown18]

Different ATI cards and different vendors have different degrees of quality when it comes to DAC encoders -- you're probably running into this.  While digital circuitry is very similar, the DAC that turns digital into analog makes a huge difference.

[cools]

If it was the end bit of the circuit I'd expect the scanlines to be nasty as well, but they're fine.

I'll have more of an experiment in the future if I get time.

[Calamity]

Hi Cools,

In Windows, GroovyMAME relies on the resolutions it finds in the system. So if you are using different versions of the drivers in any case, that might be the reason. In other words, provided it picks the same resolution in both cases, the results must be the same.

Make sure to get some logs the next time you test and post them here, they'll point us in the right direction.

[cools]

Using CRT_Emudriver 9.3 for both and letting GroovyMAME do it's thing - that's what's confusing.

I'll try when I get a chance - may be a fortnight away though

[cools]

*smacks forehead* I had half an hour spare and I've figured out what was going on.

When I was messing around with modeline disabled and working out my own scaling ratios I'd at some point put the custom resolution 1600x480 into the registry for the HD 2400. Turns out GroovyMAME was selecting this resolution every time. Of course, when I changed card this resolution was no longer available and Groovy was picking 640x480.

I'd love to be educated as to what's going on internally in Groovy when it picks one or the other resolutions. At 640x480 it's a blurry mess (with or without fake scanlines), but at 1600x480 it's incredible. I remember you mentioning you'd like to experiment with super wide horizontal resolutions - well at 5 x 320 width the picture is flawless. I'd like to try some slightly lower resolutions just to see where the sweet spot is, if there are any recommendations I'll give them a go.

The cool part about this is that as long as your GPU can handle a custom resolution of quite big on the horizontal, you should be able to use ANY card for Groovy in 31k and achieve a great result, not just an ATI - am I correct?

[lettuce]

What about games running at there native refresh rate cools, are you just using the 1 res (1600x480) in GM for all games? In yourset up would Mortal Kombat be running a 54hz with smooth scrolling?

[cools]

I'm working on a full set of modes @480 lines as by always having an integer multiple on the horizontal available means the screen is filled width, but refresh will always be 60. MK would be emulated quicker than the original game, but thats okay because I'm never going to play it. R-Type at 60 is good fun.

[Calamity]

I'd love to be educated as to what's going on internally in Groovy when it picks one or the other resolutions. At 640x480 it's a blurry mess (with or without fake scanlines), but at 1600x480 it's incredible. I remember you mentioning you'd like to experiment with super wide horizontal resolutions - well at 5 x 320 width the picture is flawless. I'd like to try some slightly lower resolutions just to see where the sweet spot is, if there are any recommendations I'll give them a go.

That makes sense now you see?

Well, let's say GroovyMAME has been programmed to hate fractional stretching, it will always try to solve things with integer scaling, and only use fractional as a last resource.

So say you have only 640x480 available. Now you lauch a Capcom game, 384x224. GM tries fitting the vertical size before. The vertical is always our priority with CRTs. So it turns out that 224 x 2 = 448, wich leaves reasonable borders inside a 480 lines mode. So it passes the filter.

Now let's try on the horizontal. You have to choices:

 a) 384 in 640, which leaves 128 pixels wide black borders on each side, ruining aspect 
 b) 384 x 2 = 768, which doesn't fit

That's why GM decides there's no possible compromise with this situation and switches to fractional scaling.

The new thing that will be implemented is, considering the above situation, that GM would use a mixed mode: integer on the vertical and fractional on the horizontal.

The cool part about this is that as long as your GPU can handle a custom resolution of quite big on the horizontal, you should be able to use ANY card for Groovy in 31k and achieve a great result, not just an ATI - am I correct?

Yes, indeed. It's just that for most of us running all games at 60 Hz is not exactly what we call a "great result". Especially when you have the power to use native refresh rates in your hands. But that's a different story

So I'm glad that using "super resolutions" (ultra wide resoltions) works so good. You'll be noticing a slight difference in the size of the borders as the scaling can't result in full resolution for all original modes. I believe that provided the horizontal resolution used is high enough, one could scale any resolution to fill the screen horizontally without any visible blur, as long as the vertical is integer scaled. The CRT should hide the effect. This will come handy if we ever move to Windows 7 in a future, as magic resolutions won't work for Windows 7, and we need to keep the amount of modes low due to HS tyranny.

[cools]

I've stuck with 1600 width, the border sizes in this are pretty low for the games I want to run and it fits the screen without adjustments from 640x480. I

I will try the 100% recommended setup at some point, but solely with a 31k monitor available in the INI files - the Rodotron is very heavily scanlined in true 15k and I really can't stand the picture.