Improving the framerate to 60pfs

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Improving the framerate to 60pfs

Post by D3thAdd3r » 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
Attachments
square_to_nonsquare_pixels.png
square_to_nonsquare_pixels.png (2.57 KiB) Viewed 2072 times

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Improving the framerate to 60pfs

Post by CunningFellow » Thu Sep 24, 2015 12:48 am

Could UZEM detect what graphics mode (or be told in command line switches) so it then made the surface it rendered too exact same pixels as the video mode.

Then SDL plus the magic of modern video cards could scale this to screen with all modern bicubic interpolation and even that 4xBRZ thing I was shown this morning.

I am sure you could even paint to a surface that was 1440x224 and then let the video hardware scale it nicely with no extra CPU usage.

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Improving the framerate to 60pfs

Post by uze6666 » Thu Sep 24, 2015 1:21 am

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.
Standard NTSC ratio is 4:3 (1.333...) and 720x480 with square pixels is 1.5 so the original uzem resulted in a image that was too wide compared to a TV. I didn't like that and sneaked in at some point a simple scaling to try to get closer to 4:3. In order to avoid using a division, I used this:

Code: Select all

current_scanline[(current_cycle*7)>>4] = pixel;
Which results in a ratio of about 1.31. Naturally it's always the same regardless of the video mode. And it causes the artifacts Lee points out though this is an extreme example and it's not usually that noticeable.

As CunningFellow mentioned, hardware scaling could be a better approach. But I prefer sharp pixels, so bicubic could look too soft. But in any cases, I think SDL2 could help with this and offer different scaling options to satisfy different tastes. I have started porting the code to SDL2 a while ago, will try to merge that in the uzem140 branch.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Improving the framerate to 60pfs

Post by D3thAdd3r » Thu Sep 24, 2015 2:50 am

CunningFellow wrote:I am sure you could even paint to a surface that was 1440x224 and then let the video hardware scale it nicely with no extra CPU usage.
HW graphics would have to be OpenGL, and you can render to a texture then display that to a couple camera aligned triangles easy. It would probably look nice downsampled, I don't think filtering would be necessary in that case. 4XBRZ is cool, probably really slow?

HQ3X would be a candidate. I like how it looks for SNES games, for some reason not so much for NES stuff.

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Improving the framerate to 60pfs

Post by Artcfox » Thu Sep 24, 2015 4:12 am

D3thAdd3r wrote:
CunningFellow wrote:I am sure you could even paint to a surface that was 1440x224 and then let the video hardware scale it nicely with no extra CPU usage.
HW graphics would have to be OpenGL, and you can render to a texture then display that to a couple camera aligned triangles easy. It would probably look nice downsampled, I don't think filtering would be necessary in that case. 4XBRZ is cool, probably really slow?

HQ3X would be a candidate. I like how it looks for SNES games, for some reason not so much for NES stuff.
I wonder if anyone's written a shader program that can do 4xBRZ on the GPU. I just discovered today that ffmpeg can do hqx or xbr scaling, so if anyone wants to see how it looks (my version of avconv doesn't support either), you can try my video recording patch and add a filter that will apply those scaling methods. You'd probably have to first scale the video down using nearest neighbor so that each pixel is actually a single pixel in order for those pixel-graphic scaling algorithms to work properly.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest