Taller resolution support for Linux port?

kerohazel · Post by **kerohazel** » Sun Jun 19, 2005 8:40 pm

Is there a way -- or if not, can we MAKE there a way -- to allow the window to stretch for games that use the 256x240 resolution? The only game I play regularly that uses it is Dragon Quest 5, but I know there are others. The top and bottom of the screen get lopped off no matter what resolution I choose, and I had to check the Windows ZSNES to make sure that it was a port-specific problem.

Post by **grinvader** » Tue Jun 21, 2005 4:48 pm

You mean the SDL port doesn't switch to PAL resolution ?

kerohazel · Post by **kerohazel** » Sat Jun 25, 2005 8:03 am

Actually, 256x240 is NTSC, if all the pixels are doubled. (If you used enhanced resolution you'd get the standard 480 lines for NTSC.) PAL has 576 visible lines. </wikipedia>

But yeah, it's not working.

Screen captures give you the whole image, but the window itself while playing the game does not change.

Post by **grinvader** » Sun Jun 26, 2005 9:41 pm

kerohazel wrote:</wikipedia>

That's a load of ignorance.

The NTSC SNES outputs a picture of 256x224 (the first line being always empty) in lowres mode. All pixels are *not* doubled, that's when analog comes in and helps the scaling - also causing overscan.

The PAL SNES outputs a picture of 256x239 (same empty line thing) and fills in a PAL tv with the same magic analog stuff.

Anyway, I can see the trouble with DQ5, but fyi it's not an increase in resolution at all - the GL code is just ass and slides the whole image down several lines in this game. You can check yourself by not using an 'O' mode.
Main issue being that the GL code is similar to radioactive waste in several ways (ugly, dies hard and can't touch it without losing limbs and/or brain parts), and no one in the current dev team can do anything to fix it... hell, I have the knowledge on how to handle nuke waste (honest), but not this.

kerohazel · Post by **kerohazel** » Tue Jul 05, 2005 10:16 pm

Would the unmanageability of the OGL code have to do with ZSNES's assembly base? Cause that's really too bad... it seems like such a trivial problem, but I know that even trivial problems can have agonizing solutions when the code is sufficiently yucky.

Post by **grinvader** » Tue Jul 05, 2005 11:35 pm

kerohazel wrote:Would the unmanageability of the OGL code have to do with ZSNES's assembly base? Cause that's really too bad...

No, not at all. It has to do with the stupidity of whoever wrote the GL code with such a wierd method.
Read that to get nice and shiny mind-scars. Especially with the 2-part vertically split 512x224 buffer.

I know that even trivial problems can have agonizing solutions when the code is sufficiently yucky.

You know much more than a lot of people who come here and complain.
Thank you for that.

-_pentium5.1_- · Post by **-_pentium5.1_-** » Sat Jul 09, 2005 8:15 pm

Hmmm... I seem to have an issue where ZSNES doesn't correctly change to a 256x239 resolution when loading a savestate, but it's in the Windows port. I'll post a formal bug report on this when I get a chance.