Re: Improving the framerate to 60pfs
Posted: Thu Sep 24, 2015 12:17 am
I think it would look better if it did fill more of the screen in full screen, and I can't imagine why the performance wouldn't be a little better as well.
I have been wondering forever how was this 630 horizontal resolution is calculated. 240*2 is much less, 240*3 is much more...clearly there is an attempt to emulate the non-square pixels that SD NTSC televisions have, but I can't for the life of me figure out how it matches up. It's pretty confusing as I am reading different ratios of 1.1 or 1.2 even 0.9(the pixel is narrower than it is tall, whereas PAL is wider?). So I don't know the ratio of width to height on the theoretical emulated pixels, but none of the numbers I find match up. Personally in any emulator I have the choice, I use integer-scaled video modes even if it doesn't exactly match what is shown on an old television.
The reason I think it matters is that Uzem definitely distorts the images, and probably does so differently depending on the video mode at play(based on resolution, just a guess). Any time you "sample" something to a different resolution you have artifacts unless it is a direct 1:1, 2:1, 3:1, etc integer scale. The effect looks like "ripples" kind of, and I see it in non-integer modes on other emulators. Displaying any "checkerboard" type pattern in mode 3 demonstrates it:
In this picture the top is the actual 1:1 pixel graphics resources, the bottom left is a direct Uzem screen capture, and the right is the graphics resources scaled by 4 with no interpolation; the closest size I could bring it to Uzem without distortion.
As far as I know the only possible way to be perfect is integer scaling. Problem there is most things are at 240x224, so resolutions of 480 or 720 make sense. But that is going to still ripple at mode 2's 144x224, or video players 170, or mode 8's 120x96, mode 12, etc. I don't think you can find any number that was a perfect integer to every possible video mode existing or those to come, except if you went 1 pixel per cycle or 1440.
1440 is pretty unwieldy as a window and a lot of computers probably wont do 1600x1200 or whatever is closest still. 720 is a nice number for all video modes that take an even amount of cycles per pixel, the only common modes that would suffer were 7, 9(80 columns is 3 cycles, 60 columns version should be perfect at 4 though), and 12.
Edit-well the game draws the cards by repeating the top,side,bottom and middle tiles, so that might be confusing...but still you see what I mean..3 pixels wide, 2 pixels wide, 3 pixels wide, 2 pixels wide,etc.
Edit 2-fixed graphics/fact check: I was wrong mode 2 is 10 cycles/pixel so should work perfect with 720 resolution. I'm pretty sure every video mode suffers the distortion at the current 630. I also wonder if that small shimmer effect the 60 fps rendering introduced has something to do with this? It would make sense since the edges of something 1 frame are 2 pixels wide, then next frame they are 3
I have been wondering forever how was this 630 horizontal resolution is calculated. 240*2 is much less, 240*3 is much more...clearly there is an attempt to emulate the non-square pixels that SD NTSC televisions have, but I can't for the life of me figure out how it matches up. It's pretty confusing as I am reading different ratios of 1.1 or 1.2 even 0.9(the pixel is narrower than it is tall, whereas PAL is wider?). So I don't know the ratio of width to height on the theoretical emulated pixels, but none of the numbers I find match up. Personally in any emulator I have the choice, I use integer-scaled video modes even if it doesn't exactly match what is shown on an old television.
The reason I think it matters is that Uzem definitely distorts the images, and probably does so differently depending on the video mode at play(based on resolution, just a guess). Any time you "sample" something to a different resolution you have artifacts unless it is a direct 1:1, 2:1, 3:1, etc integer scale. The effect looks like "ripples" kind of, and I see it in non-integer modes on other emulators. Displaying any "checkerboard" type pattern in mode 3 demonstrates it:
In this picture the top is the actual 1:1 pixel graphics resources, the bottom left is a direct Uzem screen capture, and the right is the graphics resources scaled by 4 with no interpolation; the closest size I could bring it to Uzem without distortion.
As far as I know the only possible way to be perfect is integer scaling. Problem there is most things are at 240x224, so resolutions of 480 or 720 make sense. But that is going to still ripple at mode 2's 144x224, or video players 170, or mode 8's 120x96, mode 12, etc. I don't think you can find any number that was a perfect integer to every possible video mode existing or those to come, except if you went 1 pixel per cycle or 1440.
1440 is pretty unwieldy as a window and a lot of computers probably wont do 1600x1200 or whatever is closest still. 720 is a nice number for all video modes that take an even amount of cycles per pixel, the only common modes that would suffer were 7, 9(80 columns is 3 cycles, 60 columns version should be perfect at 4 though), and 12.
Edit-well the game draws the cards by repeating the top,side,bottom and middle tiles, so that might be confusing...but still you see what I mean..3 pixels wide, 2 pixels wide, 3 pixels wide, 2 pixels wide,etc.
Edit 2-fixed graphics/fact check: I was wrong mode 2 is 10 cycles/pixel so should work perfect with 720 resolution. I'm pretty sure every video mode suffers the distortion at the current 630. I also wonder if that small shimmer effect the 60 fps rendering introduced has something to do with this? It would make sense since the edges of something 1 frame are 2 pixels wide, then next frame they are 3