hq3x, hq4x on SDL build
Moderator: ZSNES Mods
hq3x, hq4x on SDL build
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.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
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.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
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.
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm