It is currently Thu Oct 19, 2017 12:18 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: NMI vs IRQ
PostPosted: Wed Oct 19, 2016 11:58 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
An NTSC PSX in 320-wide mode has a 32:35 PAR, meaning the video should display with an aspect ratio of 1.66. An NTSC SNES in 256-wide mode has an 8:7 PAR, meaning the video as you've converted it shows up with an AR of 2.06. You could get an exact match with 256x176, but of course that wouldn't fit in VRAM without tearing; getting the correct aspect ratio at 8bpp would involve narrowing the image. Here's a reasonably good comparison; 240x160 apparently fits, and gives an aspect ratio of 1.71.

(If one were to make the assumption that the original video was prepared without taking the PAR into account, the SNES resolution closest to recovering the animation's natural aspect ratio with full screen width would be 256x161. But based on the shape of the sun in that first frame, I don't think this is true.)


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 5:07 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
You wouldn't need the bottom of the video to fit in VRAM twice. You can double buffer all but the last block and single buffer the last block, and you still won't get tearing.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 7:17 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
That's what I'm doing, it's the last block that's the limiting factor, since you need to upload it all in one frame. The larger your visible window, the more data you need to upload in the last frame, while at the same time having fewer lines to do it. I'm not sure how much more data I can pull off, if any (at least in terms of full lines of tiles).


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 10:33 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
256x152 (aspect ratio ~16% too wide)

38912 B + 64 B (black tile*) + 2x1344 B (168 high*) = 41664 B for a single frame, including two tilemaps
65536 B - 41664 B = 23872 B max buffer (roughly 8 KB per frame for 3 frames)
38912 B - 23872 B + 512 B = 15552 B to transfer on last frame
15552/165.5 = 93.97 scanlines of DMA, resulting in about 16 scanlines of wiggle room

*not necessary with precise IRQ timing
[...actually, it occurs to me that a blank line of the tilemap could be reused as a black tile...]

256x160 (aspect ratio 10% too wide)

40960 B + Nx1280 B (160 high) = 42240+1280(N=2) B for a single frame, including N tilemaps
65536 B - (42240+1280(N=2)) B = 23296-1280(N=2) B max buffer
(40960+1280(N=1)) B - (23296 B-1280(N=2)) B + 512 B = 19456 B to transfer on last frame
19456/165.5 = 117.56 scanlines of DMA, resulting in about 16 scanlines of overload

(also note that it does not matter whether the tilemap is duplicated and switched or overwritten during the final frame)

240x160 (aspect ratio ~3% too wide)

38400 B + 64 B (black tile**) + 2x1408 B (176 high*) = 41280 B for a single frame, including two tilemaps
65536 B - 41280 B = 24256 B max buffer
38400 B - 24256 B + 512 B = 14656 B to transfer on last frame
14656/165.5 = 88.56 scanlines of DMA, resulting in about 13 scanlines of wiggle room

**not necessary with window masking and precise IRQ timing

240x165 (aspect ratio exactly correct)

40320 B (240x168 data) + 2x1344 B = 43008 B for a single frame, including two tilemaps
65536 B - 43008 B = 22528 B max buffer
40320 B - 22528 B + 512 B = 18304 B to transfer on last frame
18304/165.5 = 110.60 scanlines of DMA, resulting in about 14 scanlines of overload


256x176 Quantomatic (aspect ratio exactly correct)

22528 B + 1408 B = 23936 B for a single frame, including one tilemap (Quantomatic requires a tilemap refresh every frame)
(22528 B + 704 B + 256 B)/4 = 5872 B per frame, resulting in about 50 scanlines of wiggle room (ie: it fits in normal VBlank)

with sprites

22528 B + 1408 B = 23936 B for a single frame
(22528 B + 1408 B + 512 B + 544 B)/4 = 6248 B per frame, resulting in about 48 scanlines of wiggle room (ie: it still might fit in normal VBlank if you're careful/clever)


Last edited by 93143 on Thu Oct 20, 2016 10:55 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 10:55 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
I really don't want to do 240x160, the side bars always looked weird to me in smkdan's original. However, I will definitely look into 256x152. I'll have to scroll BG1 to recenter it, but that's pretty straightforward, right?


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 11:05 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
Yes, scroll registers are single-byte dual write, accessible any time (even during active rendering, though the PPU won't notice for a couple of slivers). Just remember that neutral position is actually FFFFh (or 03FFh, since the underlying value is only 10-bit for non-Mode 7 layers) because line 0 is for sprite caching and isn't displayed.

To me, the aspect ratio is a bigger issue than the sidebars, but it's your project...

I just wish Quantomatic were at a more sophisticated stage of development; right now it doesn't use sprites and has issues with colour fidelity in certain situations. Mind you, it still wouldn't look quite as good as true 8bpp... I'm thinking that combining it with CGRAM HDMA would be a fun task for a quantum computer...


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Thu Oct 20, 2016 12:07 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
93143 wrote:
To me, the aspect ratio is a bigger issue than the sidebars, but it's your project...


Yes, I understand that objectively 240x160 is better, but in practice, aspect ratio isn't really that noticeable unless 1) it's an actual photograph where you can tell proportions of real objects are off, or 2) you are looking at it side-by-side with the original (or are very familiar with it) or 3) it's completely and horribly off

In this case, it's close enough, and the fact that it's animated lends considerable wiggle room before it starts to look visibly off without the original to compare to, and stretching to 256x152 will get us closer. On the other hand, the sidebars are just *there*, obviously visible by themselves, regardless of whether or not you're looking at the original, which, to me, is a larger issue when viewed on its own, as it will be by 99% of everybody who is playing the game normally. It's like watching a widescreen video on YouTube where the uploader hardcoded the letterboxing into the actual video file so now you can't properly watch that widescreen video on a widescreen monitor.

Quote:
I'm thinking that combining it with CGRAM HDMA would be a fun task for a quantum computer...


Then we'd have to rename it quantumatic, amirite? :P


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Fri Oct 21, 2016 7:50 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
Ok, 256x152 it is. It definitely looks better, so there was certainly a point to be made about the old AR not looking good, but at this point, I don't think you can really argue that the remaining AR correction would make up for the eyesore that is vertical pillarboxing.

Image

Image


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Fri Oct 21, 2016 8:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Fri Oct 21, 2016 8:57 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
qwertymodo wrote:
at this point, I don't think you can really argue that the remaining AR correction would make up for the eyesore that is vertical pillarboxing.

Well... they do look good, but the AR is still noticeably off. If the SNES had square pixels, simply correcting for the Playstation's non-square pixels would result in an ideal resolution of 256x154, which is why your screenshots look so good without aspect correction. But the SNES does not have square pixels, as is popularly demonstrated by the famous pic of the full moon over Magus' castle (the developer really lived up to their name with this game). Scaled horizontally by 8:7, those screens look like this:

Attachment:
Yukud5jPAR.png
Yukud5jPAR.png [ 49.79 KiB | Viewed 888 times ]

Attachment:
VzKgDlhPAR.png
VzKgDlhPAR.png [ 170.45 KiB | Viewed 888 times ]

And would the sidebars really be all that noticeable in a real use case? On an HDTV, or even a widescreen monitor, a SNES game running fullscreen will have sidebars anyway, and on a CRT the screen typically has a dark or black border that can even cover up some of the picture. And anyway lots of games with FMV and/or software rendering (Out Of This World, Star Fox, etc.) had black borders on all four sides.

Nevertheless I respect your decision. Full width does have its own appeal, and it does look basically perfect in an emulator with square pixels...

...

Also, why is the first image (the sky/sun) only 151 high? It seems to be missing a line off the bottom. The second one is 152 as expected...

qwertymodo wrote:
Then we'd have to rename it quantumatic, amirite? :P

I wasn't going to say that, but I suppose somebody had to...

tepples wrote:
Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.

Yeah, but then you need two tilemaps, and they both need updating. Worst-case bandwidth is actually higher than with straight 8bpp. Unless you got really lucky with the material, the only reason to do that would be to save some space, and this hack is nowhere near the limits of the MSU1.


Top
 Profile  
 
 Post subject: Re: NMI vs IRQ
PostPosted: Fri Oct 21, 2016 10:25 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
93143 wrote:
tepples wrote:
Would it be hard to make some tiles 8-bit and others 4-bit using BG1 and BG2 of mode 3? If you can recognize which tiles in each frame don't need the extra bit depth, that can save you some bandwidth.

Yeah, but then you need two tilemaps, and they both need updating. Worst-case bandwidth is actually higher than with straight 8bpp. Unless you got really lucky with the material, the only reason to do that would be to save some space, and this hack is nowhere near the limits of the MSU1.

The hard part is that right now every frame's tilemap is identical, so I can upload frame n, then upload tilemap n+1 and switch to it in the middle of uploading frame n+1, so I can overwrite tilemap n when I get to it and have that much less data to upload in the final frame. If I were to try and optimize with 2 different BG layers, not only is that 2 tilemaps to upload, it's 2 tilemaps worth of space I can't touch until the end of the frame, which is exactly when the bandwidth timing is already the tightest. Not to mention the vast increase in complexity converting the data.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group