hq3x, hq4x on SDL build

[fearpi]

I'm curious - is there any particular reason why hq3x and hq4x are not available in the SDL port? Is it more difficult to implement than hq2x for some reason? All of the filters look inexplicably terrible (especially with resolutions that are not 8:7 - and they never looked bad at all under Windows) and I wish I could try out hq3x.

[Deathlike2]

IIRC, the internal tests show they are simply massively slow via SDL. You have to create multiple huge textures and that's just not very performance viable.

[DancemasterGlenn]

Is that performance hit something that is potentially "fixable" at some point in the future? I don't need to use those video modes (my precious....), I'm just curious.

[Nightcrawler]

I'd be interested the methods being used here. The Hqxx algorithms shouldn't be limited to anything inherent to SDL/OpenGL. I'd speculate the performance problem could be fixed with a change in implementation.

[paulguy]

i find hq2x+bilinear filter looks better than hq3x or hq4x at most resolutions. I usually run it at 1280x1024

[grinvader]

For those who wonder about the real reasons behind no hq3/4x in SDL:

Short answer:
The SDL port's graphic code is awful compared to the windows port's. Too awful to fix.


Long answer:
Back when zsnes got its SDL port, someone (name lost to history) whipped up something that would make the current stuff work fine. However that code is on the far side of flexibility. So it works fine for what we had back then (DOS resolutions), and nothing else, and adding new things in is not easy at all.

So what happens in the win port ? After emulation is done, the video buffer (max 640x480) is sent to directdraw. For hq3x, we simply tell directdraw that the end buffer will have to be thrice as big, and it allocates the thing, the filter is ran and output into that new end buffer, and it's displayed when necessary.
For SDL, there's no code like that. So it cannot exceed the max size, 640x480. Which is fine for 2x (from lowres), but not for anything above. We'd have to create the buffer ourselves, and stuff.
For GL, there's a minimal difference, but the same underlying crap that prevents stuff.
When displaying the final image, we can ask for any resolution supported by GL. So you can have 1024x768 using it, but it's actually just the smaller buffer scaled to that res. The scale being applied at the last moment, we still don't have any buffer big enough to actually store filtered output.
Pagefault added specific code to allocate a buffer for the NTSC filter, and it doesn't work under GL... anyway we could bring the SDL port up to snuff, but at the moment noone wants to deal with the current rigid mess of code in there. And at least 4 of us tried at it in the past, with various amounts of brain bleach used to survive the experience.

[DancemasterGlenn]

That's too bad... oh well. Hopefully that will happen someday.

[fearpi]

Very informative answer; thank you! It's a shame about the state of things in the SDL port, though.

[pagefault]

It's coming, but I have other stuff to do.