Design guidance for 3D Engine on SuperFX

[secondsun]

This is a cool idea, but I'm not so sure about prototyping on Java...

I mean, it's way too easy to miss an important limitation and then *poof* just like that, you have to deal with new limitation you never knew about and are unprepared for.

Ha oh man! I'm counting on it. I've been writing Java for a long time, and I'm comfortable writing the math part of 3D in it at the moment. So far my biggest mistake is writing 192*256 as a resolution and now people are giving me advice on pillar boxing to get more DMA bandwidth on HBlank.

Do you expect to support the original SD2SNES, the one I have?

I don't know enough about the version differences of the SD2SNES to make promises, but I hope so. If it doesn't my code is all open source, and people can help me out there when that becomes a problem.

_{And yeah, I know it's weird thinking about LCD TVs when we're talking about a SNES homebrew concept, but yeah, people who play retro games on LCD TVs (when they don't have CRTs) exist and should be considered.}

I too thought of the great cosmic irony that I could double letterbox, get better performance, shoot out a signal to the tv and have it crop and give us full screen 16:9 LCD SNES games. If that is how things turn out it will look horrible and beautiful and I will love it.

[tepples]

If you want to use the GSU to target modern 16:9 60 Hz TVs, my best suggestion is a 240x160-pixel visible window. This is 38400 pixels, or 19200 bytes in 4bpp mode. The 8:7 pixel aspect ratio (on 60 Hz) will produce a 12:7 (1.71:1) display aspect ratio. You'll have (261 - 160)*165.5 = 16715 bytes of VRAM upload bandwidth per frame.

EDIT: Corrected scanline counts and resulting upload bandwidth

[93143]

You'll have (227 - 160)*165.5 = 11088 bytes of VRAM upload bandwidth per frame.

wat

An NTSC frame is 262 lines, no? That should give you nearly 16.5 KB per frame. More than adequate in the context of 248x160 (which is almost exactly 16:9) or even 256x168 (which is still closer than 240x160). Personally I'd go for 256x165, because while it does waste a bit of tile data, it fits even better than 248x160 and has full horizontal resolution.

Now, in the scenario where you're not replacing the whole screen every two frames, it might be worth it to go for 512x329i... if a modern "TV" could be convinced to display an interlaced picture at 60 fields per second, that is...

[tepples]

Fixed. My fault. I've been away from Super NES for way too long, and 240x160 reminded me too much of another platform whose video output does have 228 total lines (160 picture + 68 vblank).

In any case, I was trying to keep the best compromise among bandwidth, not spending time rendering pixels that would get cut off by side overscan on 4:3 CRT SDTVs, and minimizing residual windowboxing when displayed on a 16:9 modern TV.

And yes, in my experience, modern TVs at least try to deinterlace 480i signals to 60 frames per second. Otherwise, live sports would look even worse.

[93143]

I guess what I'm complaining about is that the "deinterlacing" part is completely unnecessary and for some reason tends to take forever, causing a huge increase in perceived input lag.

...I'm reading the Wikipedia article on deinterlacing and I can't see anything about filling in the blank lines in a field with interpolated values (anything from linear to CRT scanline emulation), while maintaining the intended position of the lines in each field to avoid bobbing. Has this been tried? What am I missing?

[lidnariq]

...I'm reading the Wikipedia article on deinterlacing and I can't see anything about filling in the blank lines in a field with interpolated values (anything from linear to CRT scanline emulation), while maintaining the intended position of the lines in each field to avoid bobbing. Has this been tried? What am I missing?

"Bob" deinterlacers do work and produce results that I find much less objectionable than a "weave" deinterlacer. Two decades ago CPUs weren't really fast enough for anything other than bob or weave. But I guess the half-wits in charge of modern TVs decided that the only 480i content that people care about is all from telecined masters, and there a weave deinterlacer really is the right choice.

[93143]

Okay, after a bit more searching elsewhere on the web, it appears Wikipedia was wrong (!!!) and decent modern bob deinterlacers do not in fact bob after all. Good to know...

[Bregalad]

Letterboxing does have the benefit of being able to zoom in to the screen on a 16:9 HDTV without losing any content whatsoever, if the content itself is further letterboxed into a 16:9 frame, but 16:9 HDTV users might be able to tolerate 192x224 pillarboxing if they can already tolerate 4:3 pillarboxing.

_{And yeah, I know it's weird thinking about LCD TVs when we're talking about a SNES homebrew concept, but yeah, people who play retro games on LCD TVs (when they don't have CRTs) exist and should be considered.}

I know our goals and why we are into retro game development could be very different. But IMO it's completely silly and anachronical to think about 16:9 HDTV when developing a game that is supposed to target the SNES platform. Sure, you could do letterboxing for SuperFX reasons and it would happen to increase the width/height ratio, like StarFox I think.

However you should either consider 16:9 HDTVs don't (yet) exist, or you should develop your game for the PC platform while retaining SNES-like graphics and forget about the SNES altogether. Developing a SNES homebrewgame and expecting it to be played on a 16:9 TV is silly by nature.

oh yeah NTSC is only 224 not 240..

If I'm not mistaken the SNES can output either 224 or 240 vertical lines depending on a register bit. But in practice there's few reasons to go for 240 with possible overscan of tha extra area anyway, except if you want exactly the same setup as the NES. Smooth scrolling with 240 visible lines is also difficult (just like on the NES). If you're planing to go for massive VRAM updates there's definitely no sense in using 240. I think it's common for games to purposely use forced blanking to have even less than 224 lines (via IRQ or HDMA), I'm fairly sure Chrono Trigger does this, as well as most SuperFX games.

[Nikku4211]

I know our goals and why we are into retro game development could be very different. But IMO it's completely silly and anachronical to think about 16:9 HDTV when developing a game that is supposed to target the SNES platform. Sure, you could do letterboxing for SuperFX reasons and it would happen to increase the width/height ratio, like StarFox I think.

However you should either consider 16:9 HDTVs don't (yet) exist, or you should develop your game for the PC platform while retaining SNES-like graphics and forget about the SNES altogether. Developing a SNES homebrewgame and expecting it to be played on a 16:9 TV is silly by nature.

16:9 HDTVs exist now in 2020. Regardless of what console the game is going to be on, it is currently being planned in 2020. It might be silly for most people, but when looking through the lens of that fact, I think it can work for people who like retro homebrew games but aren't going to go so far as to limit what TVs they use just to have a 99.99% accurate 1990s experience.

If I was making the game, I would not pretend that it's the 1990s just because I'm making a game for a 1990s console. If I was like that, I might as well just limit my tools to the same ones people used in the 1990s, and I think that would be silly.

Now, yes, I do personally prefer 4:3, as I usually do, and I am usually fine with it. However, if we need to letterbox for technical reasons, then I'm willing to at least look on the bright side of how modern technology can interact with old technology, rather than just pretending it doesn't exist entirely.

In one screen, do [all textures in PS1 FFT] all use the same 4BPP palette, or do they all use different 4BPP subpalettes?

A bunch of things use the same palette. If you have access to the CD, you can just snoop around. There's some palette swaps too.

I was only talking in terms of what's on the same screen at the same time.

I know 2BPP would be only 4 colours for the entire screen, effectively limiting it to a Super Game Boy palette or a Flipnote Studio palette, but how much of the screen can you do at 30fps with this method and a 2BPP framebuffer? How much can do you at 60fps? And would limiting the FPS to 25 instead of 30 even on NTSC screens help anything?

Non-integer divisions of the source frame rate may not look good. Perhaps 2.5 would be ok (24fps), just like conventional film telecining, but the judder may be perceptible.

In any case, the math I outlined before it still true, just with different constants:

Oh, that makes sense. I never thought I'd have to use my browser's zoom function, but this is some cool maths.

So far my biggest mistake is writing 192*256 as a resolution and now people are giving me advice on pillar boxing to get more DMA bandwidth on HBlank.

Yeah, that kind of stuff happens here. What could be dismissed as stupid, silly, or impossible can also provoke actual discussions, and even the stupidest of mistakes can inspire good ideas.

Do you expect to support the original SD2SNES, the one I have?

I don't know enough about the version differences of the SD2SNES to make promises, but I hope so. If it doesn't my code is all open source, and people can help me out there when that becomes a problem.

Oh, okay. Cool, thanks for the reply.

_{And yeah, I know it's weird thinking about LCD TVs when we're talking about a SNES homebrew concept, but yeah, people who play retro games on LCD TVs (when they don't have CRTs) exist and should be considered.}

I too thought of the great cosmic irony that I could double letterbox, get better performance, shoot out a signal to the tv and have it crop and give us full screen 16:9 LCD SNES games. If that is how things turn out it will look horrible and beautiful and I will love it.

Yeah, me too. If we're going to lose some resolution, we might as well make the best of said resolution.

In any case, I was trying to keep the best compromise among bandwidth, not spending time rendering pixels that would get cut off by side overscan on 4:3 CRT SDTVs, and minimizing residual windowboxing when displayed on a 16:9 modern TV.

Ah. Why do I keep forgetting about CRT overscan? I guess I just hate windowboxing that much.

[Hojo_Norem]

Just my 2p, but from my position in consumer electronics retail I notice very quickly when the manufactures start to mess around with long held traditions.

With the last couple or so of Panasonic TVs I have noticed a distinct lack of aspect ratio control on the remote. The control is instead buried inside the picture settings menu. I actually like this as I think I've noticed a slight trend to default to 4:3 for 4:3 content rather than zoom or whatnot. It seems that people these days are more accepting of being told that the TV is just showing you the picture in the way it was made. None of this "I want ALL my screen used" BS I got 15-20 years ago.

In fact I'm seeing more TV channels broadcasting 4:3 content as pillarboxed 16:9 that the OAR argument is slowly moving in the proper direction.

Personally, rather than worrying about filling the sides of a 16:9 image I'd be more concerned at the drop in perceived resolution that zooming in a already low resolution image will create. Being from PAL land I can live with a black border far easier than chunkier pixels.

[Nikku4211]

Personally, rather than worrying about filling the sides of a 16:9 image I'd be more concerned at the drop in perceived resolution that zooming in a already low resolution image will create. Being from PAL land I can live with a black border far easier than chunkier pixels.

Alright then. If you can handle a black border, good for you. I'm all for keeping proportions and keeping content on screen so I'm against the 'I want ALL my screen used' bollocks too.

I still find mixing retro tech with modern tech cool, though.

[Ryoga]

I've seen the video of the engine progress in JAVA and it's pretty cool. Hopefully we can see a similar result working on SNES.

Do you expect to support the original SD2SNES, the one I have?

As far as I know there are no significant differences between the two models. Where it seems that there is some difference is between revisions of the SD2SNES. It seems that the revisions below REV.H need some modification (not excessively complex) to replace the passive filter between the DAC and the SNES 'analog mixer with the better circuit from the Rev. H (and newer) that includes a unity gain opamp in order to fix the impedance mismatch that caused muffled and quiet audio in older revisions.

[93143]

IIRC the current version uses a new FPGA that's capable of running the SA-1 and MSU1 simultaneously. The original couldn't do that.

[Ryoga]

IIRC the current version uses a new FPGA that's capable of running the SA-1 and MSU1 simultaneously. The original couldn't do that.

And it also allows the SuperFX chip (GSU-1 / GSU-2) to be used simultaneously together with the MSU-1? Because if so, it does represent a substantial improvement.

[93143]

I believe the SA-1 was the only chip complex enough to not be compatible in the first place. Super FX + MSU1 worked on the old FPGA.