Aftermarket SNES Cartridge Expansion Hardware

[Oziphantom]

realistic lighting and shadowing, reflective translucent water waves, rustling leaves

Frame rate would have been single digits for sure

yeah single digits FPM

[93143]

yeah single digits FPM

Not quite that bad, I think.

My reference point is that Doom managed double-digit fps with a renderer that (IIUC) could spend nearly 60 ms in the I/O-bottlenecked 80-cycle-per-pixel wall texture-mapping inner loop alone, and was so starved for RAM that it could only draw a third of a frame at a time and then had to wait for the SNES to download it to VRAM before it could start the next third. I haven't sketched out anything that seems radically slower than that.

...

This open-world engine brainstorm was what taught me that the Super FX can easily handle any pixel shader as long as the number of input bits is small enough that you can fit the lookup table(s) in the active ROM bank. Rustling sunlit leaves can be done inexpensively with a single-pass quasi-billboarded foliage shader with texture switching between frames. Even a translucent reflective wavy water surface would be much cheaper per pixel than wall texturing in Doom (though of course one has to take underwater scene rendering and reflection map rendering into account).

And not everything needs a fancy renderer. Affine texturing with tabulated Gouraud shading and nonlinear vertex fog can be done in something like 23 cycles per pixel with a linear bytemap target. Untextured Gouraud shading with fog can be done in 10.

There are ways to fake what I think should be halfway convincing dynamic shadows fairly cheaply on a sufficiently low-poly landscape. Stuff like terrain self-shadowing, and most of the weather engine for that matter, could be broken up and updated piecemeal over many frames, because they change so slowly that doing them every frame is overkill. Distant terrain and weather could be rendered at low LoD to a 360° partial-height buffer and updated much more slowly than the near field. The camera would normally be restricted to yaw, and perhaps a bit of software Y-shearing, to simplify the 3D transforms, and prebaked VSD with built-in LoD handling could simplify the frame data buildup.

One thing that bugged me was the trees. The tabulated foliage shader idea could have looked decent, and at 20 cycles per pixel for one notional version it was reasonably cheap. But forests absolutely murder your overdraw numbers, and it was looking like the transition from multi-element 3D trees to single-element trees to flat walls of fake trees might have had to happen nearer to the camera than I liked, especially on a clear, dry day with no fog to speak of. And I don't think I ever quite solved the dappled-sunlight-on-foliage problem...

...

I ran no tests. I didn't get nearly far enough for that. Maybe I'm overestimating the Super FX's ability to do everything other than the inner rendering loops in a timely fashion; certainly it wasn't the pixel plotting that slowed down Star Fox... but on the other hand, it certainly was the pixel plotting that slowed down Doom...

[creaothceann]

One thing that bugged me was the trees [...] forests absolutely murder your overdraw numbers

So you're saying it needs to be a sand/snow planet...

and it was looking like the transition from multi-element 3D trees to single-element trees to flat walls of fake trees might have had to happen nearer to the camera than I liked, especially on a clear, dry day with no fog to speak of.

Terra Nova SFC had clear, dry days with no fog and sparse trees.

[93143]

sand/snow

Unfortunately (well, I guess it doesn't matter), the setting was established before this game was anything more than a Zelda-like top-down action RPG (untethered feature creep ftw). It's full of forested hills and mountains.

Besides, a desert or snow open world wouldn't be nearly as interesting, either as a game or as a programming exercise.

(Also, that "4800 stars" scene is mirrored diagonally.)

planet

...I'm not thinking quite that big...

[SNES AYE]

(Also, that "4800 stars" scene is mirrored diagonally.)

Just a random thought. Would it be possible to fake the effect of thousands of stars moving towards the screen like that on SNES using an 8bpp background and palette cycling in a roughly similar method as seen here:

https://youtu.be/7LAY4ulp63Y?t=1221

Edit: The snowfall effect at 7:50 is possibly another good approach too, as it creates a nice illusion of hundreds of flakes falling:

https://youtu.be/7LAY4ulp63Y?t=469

[mannes]

To see how far you can push the hardware.

I was actually brainstorming such a game a while back. Not a port of BOTW itself, of course (I'd want at least an N64 to tackle that). But a huge 3D open-world game with realistic time-of-day, dynamic weather, seasons and agriculture, astronomically correct skies, realistic lighting and shadowing, reflective translucent water waves, rustling leaves, unlimited draw distance...

All of this was to run on the Super FX. Assisted by an MSU1, of course, but that's just storage and I don't consider that quite as hard a constraint. I was also considering the feasibility of using a period-accurate CD-ROM attachment instead...

...

Making something else on SNES would be much more practical...

Well I would hope you would want something more than a SFX2 for such a massive idea, but otherwise I can't wait to see your game. Are you taking pre-orders? Where can I buy?

Really tho, this kind of stuff is the future of the SNES for me, sounds very promising and exciting. I thought about doing a 4 swords thing with ALttP but with a higher difficulty level and a mild Friday 13th vibe - op dark knights that chase you around and make you team up with your cpu (or maybe 2p) allies to stand a chance of clearing a dungeon, competing for unique gear like the bow and arrow or hookshot. Not sure if that would be doable in vram since I know most of it is tied up but I like to think of how that might be possible.

In some ways botw would be easier than trying to mod alttp for 2 or 4p support plus some unique op mobs like a dark link or aghanim. I'd probably have to resort to the same tricks for displaying this like a snes botw

[93143]

Well I would hope you would want something more than a SFX2 for such a massive idea

Not really. The initial game concept doesn't technically need this level of 3D nature simulation; the main attraction of the idea at this point is seeing what can be done with the Super FX.

A lot of the stuff I've sketched out is a bit different from how things are done in modern 3D graphics, and I think that's interesting too.

but otherwise I can't wait to see your game. Are you taking pre-orders? Where can I buy?

Calm down - this game is way out of scope. If this becomes my job, I might eventually get to it, but it would require a team and the initiating concept was rather silly.

I've got a ton of plans for hardware-pushing games - ports, sequels/prequels, even the odd original game - but I will probably never get around to most of them unless my life changes radically or I get some sort of life-extension treatment.

The game I'm actually (intermittently) working on is a port of a vertical-scrolling bullet hell shmup (I won't say which one). This sort of game is tractable for one person, but since the original game is on a much more powerful platform, it's still an interesting challenge. It does use the Super FX to draw enemy bullets and handle collisions, and sometimes to assist with stage backgrounds. It also pushes the actual SNES fairly hard, using multiple hardware tricks to produce the illusion that it's doing things the S-PPU can't actually do.

But you shouldn't hold your breath for this one either. My first post on the topic was over 10 years ago, and I'm not particularly close to finishing...

I did finally finish a hack of Super Mario Bros. 3, though. It required a bit of in-place code and data hacking using a hex editor, but it's mostly an exercise in pixel art - all I was really doing was a role reversal where you play as the princess and rescue Mario; it's otherwise exactly the same game. I started that one in 2008, although to be fair it was untouched for most of that time...

In some ways botw would be easier than trying to mod alttp for 2 or 4p support plus some unique op mobs like a dark link or aghanim.

How do you figure? That sounds like a vastly easier challenge than a 3D open-world game regardless of coprocessor power, unless you're proposing a passthrough cartridge that serves as a dock for a Switch...

[Señor Ventura]

(Also, that "4800 stars" scene is mirrored diagonally.)

Just a random thought. Would it be possible to fake the effect of thousands of stars moving towards the screen like that on SNES using an 8bpp background and palette cycling in a roughly similar method as seen here:

https://youtu.be/7LAY4ulp63Y?t=1221

Edit: The snowfall effect at 7:50 is possibly another good approach too, as it creates a nice illusion of hundreds of flakes falling:

https://www.youtube.com/watch?v=7LAY4ulp63Y&t=637s

I was thinking about something similar, but sure it wasn't a new idea:

-A full grid of static background tiles with 16 2x2 pixels within it (4 per tile, per line), at 4bpp and 256x224. No scanlines disabled.
-It gives a simulated resolution of 128x112.
-896 4bpp tiles for 28.672 Bytes of VRAM to store background tiles.
-1.792 Bytes + 544 Bytes + 512 Bytes of background, OAM, and CGRAM attributes reserved in VRAM

You'll need only to update the cgram, until 30 Bytes per scanline at 15 grey degree colors wich outmatches any possibility (2 Bytes per pixel color, that here is iterated x2) but not even with v-blank except the first scanline (god bless hdma), to achieve half-full animated scenarios with tons of content, no big ROMS needed.

Maybe a coprocessor to figure out and translate to "pixel colors per scanline" what the cgram has to update.


It needs some thinking the matter over, it still doesn't fits.

[SNES AYE]

(Also, that "4800 stars" scene is mirrored diagonally.)

Just a random thought. Would it be possible to fake the effect of thousands of stars moving towards the screen like that on SNES using an 8bpp background and palette cycling in a roughly similar method as seen here:

https://youtu.be/7LAY4ulp63Y?t=1221

Edit: The snowfall effect at 7:50 is possibly another good approach too, as it creates a nice illusion of hundreds of flakes falling:

https://www.youtube.com/watch?v=7LAY4ulp63Y&t=637s

I was thinking about something similar, but sure it wasn't a new idea:

-A full grid of static background tiles with 16 2x2 pixels within it (4 per tile, per line), at 4bpp and 256x224. No scanlines disabled.
-It gives a simulated resolution of 128x112.
-896 4bpp tiles for 28.672 Bytes of VRAM to store background tiles.
-1.792 Bytes + 544 Bytes + 512 Bytes of background, OAM, and CGRAM attributes reserved in VRAM

You'll need only to update the cgram, until 30 Bytes per scanline at 15 grey degree colors wich outmatches any possibility (2 Bytes per pixel color, that here is iterated x2) but not even with v-blank except the first scanline (god bless hdma), to achieve half-full animated scenarios with tons of content, no big ROMS needed.

Maybe a coprocessor to figure out and translate to "pixel colors per scanline" what the cgram has to update.


It needs some thinking the matter over, it still doesn't fits.

I feel like this might have over designed the idea as I was thinking of it in relation to using specifically the 8bpp background.

I was honestly just thinking it would be as simple as creating a single 256 color background image with the different positions of each star's path assigned to one of the 256 entries in the palette that would be white and then cycling the single white palette entry to make it look like all the stars are moving towards the screen. Or something along those lines.

If you think of it as a single star for now, it would be drawn into the image in 256 or so positions in its line towards the screen, with each position being represented by a single entry in the single 256 palette and basically all of them black other than the current position that's white, and then the cycling of the white palette entry would take the star from the start to end of its path very smoothly. And in the full image you'd just put as many stars on there as you like in the same way, with different stars being white starting at different positions on their path, so the palette cycling loop would make them all animate towards the screen in an endless loop as such.

If that makes sense and would work as intended.

[Pokun]

I don't think "porting BOTW" to SNES means much as the result would differ so much depending who is doing the port. Ports of games of vastly different hardware has been very common historically and often with lots of liberties taken, especially when going from a more powerful system to a lesser one, sometimes the name of the game is about the only thing that remains the same.

I imagine a SNES port of BOTW would be some sort of demake with a look and feel similar to Zelda 3, but with many of the of the BOTW features such as the food system and the larger world added and freely interpreted by the porter. Not anything that would require a co-processor, it would just need lots of ROM space for the larger maps and large amount of side quests (though both would probably be toned down considerably).

[93143]

I imagine a SNES port of BOTW would be some sort of demake with a look and feel similar to Zelda 3

That really would be a completely different game. Looking into the distance is a fundamental part of BotW in terms of both feel and gameplay, and is what allows a nonlinear open-world with no hard limits on traversal to not confuse and overwhelm the player.

I know they tested some of the mechanics in a LoZ-style prototype, but aside from the nostalgia factor it really didn't look all that compelling by itself.

I think you might be able to stuff a recognizable approximation of BotW into a Nintendo 64 cartridge, but the SNES is probably a bridge too far if you're restricting yourself to the officially-available expansion coprocessors. That notional 3D open-world engine I was talking about upthread isn't really fast enough or flexible enough for BotW even with some of the fancier stuff nerfed; it saves a lot of effort by locking the camera to horizontal, using prerendered billboards for characters and objects, special-casing combat, and not having a bunch of interactable geometry with coupled physics and chemistry systems...

[Pokun]

I imagine a SNES port of BOTW would be some sort of demake with a look and feel similar to Zelda 3

That really would be a completely different game. Looking into the distance is a fundamental part of BotW in terms of both feel and gameplay, and is what allows a nonlinear open-world with no hard limits on traversal to not confuse and overwhelm the player.

Yes and that's exactly my point. Saying "a SNES port of BOTW" without mentioning any specifics could really mean about anything and every person reading the phrase may imagine something very different and be confused with the discussion.

Since the looking-into-the-distance-thing is basically not doable on SNES, something would have to be compromised and this something might be very different for different people.

I imagine a Zelda 3-style game but you can climb any wall and therefore pass any terrain (as long as you have the stamina) except the edges of Hyrule, and you can do things like chopping down trees, moving rocks, burning wood and hunting animals. Heh it starts to sound something more like Harvest Moon.

If we say a port of Tears of the Kingdom instead it becomes more complicated because the skyworld, the underworld and the interaction between the worlds are more fundamentally integrated into the game, so it is harder to simulate in just 2 dimensions. Mode 7 might help with the flying parts.

[93143]

Since the looking-into-the-distance-thing is basically not doable on SNES

...well, I wouldn't put it that way. I'm sure a simpler, faster open-world engine could work on Super FX, retaining the MSU1 for data and some of the speed hacks, while expanding in other directions to allow some of the key things BotW does but my game concept doesn't (looking into the distance is important in BotW, but looking up and down is important too so you'd have to support pitch transforms in camera space, which then expands the required dataset for prerendered sprites substantially...).

Using billboarded trees with no fancy shaders, fake (or no) water reflections, limited texture-mapping, a simplified weather system (no more complex than the real BotW, at least), no season system, and a stripped-down lighting system that doesn't bother with terrain-mapped blended shadows or normal mapping on sprites, and keeping the slowly-updated distant-scenery buffer so the Super FX doesn't have to draw all the way to the horizon every frame, I imagine it should be possible to keep a playable frame rate even with camera pitch permitted. If performance turns out to be good, maybe some low-impact stuff could be added back in - but I doubt blended wave-deflected environment mapping is going to make the cut...

Some of the larger enemies, such as Lynels and Guardians, could be problematic. They're too complex to be polygonal (an issue not shared by the Talus), but big enough that using prerendered sprites could look pretty bad. Perhaps a hybrid approach, if it doesn't end up looking even dumber...

Mowable grass is probably feasible on N64, but it might have to be severely curtailed or removed on Super FX.

It's arguable whether the end result would be a better experience than a top-down attempt in LttP's style, but I don't think it's impossible as such.

...

Whenever someone tells me something is impossible, I immediately start trying to figure out how to do it. This still happens even if I'm the one who said it was impossible in the first place and you're just agreeing with me...

[Pokun]

I don't believe in impossibility either, things are just more or less hard. I just can't imagine a 3-dimensional Super-FX Zelda for SNES that would work well so I would axe that idea right away and work on other, more interesting, aspects of the game that works with the hardware better. Weather systems, day-night systems, mowable grass and such things shouldn't be a problem in 2D of course.

[93143]

Weather systems, day-night systems, mowable grass and such things shouldn't be a problem in 2D of course.

And now I'm trying to figure out how to do realistic shadowcasting in a tile-based 2D game using an expansion chip. Normal-mapped lighting is easy by comparison...

Then again, doing a nice-looking fake dynamic lighting and shadow engine without a special chip would be far more impressive and more in line with the historic use of these chips, which was mostly to enable gameplay factors and not completely extraneous eye candy. Star Ocean had decent shadow handling for the SNES, and perhaps it could be expanded to allow time-of-day variation without looking too obviously fake...

Just changing the palette, and perhaps using colour math to darken the screen at night so lanterns work (it occurs to me that LttP actually did this in some dungeons), would be perfectly adequate for a SNES game, and players wouldn't generally expect more. The gameplay systems are more important anyway...