Modern SNES Games and Demos

There’s nowhere near enough happening in the SNES indie/homebrew development scene right now imo, especially when compared to how active the Genesis scene is in comparison, but there is some new stuff out there, and I just thought I’d showcase some of it here.

Note: Some of these examples may be a few years old, but they’re still new games for SNES that came out decades after it was no longer officially on the market. And some of them may be barely more than simple concept tests, or possibly just glorified ROM hacks, but I still think they’re worth covering here.

Without further ado, let’s begin:

Multi-jointed Enemies in SNES Games

Because it’s often been asserted by certain people that the SNES can’t really handle multi-jointed enemies, I figured I post a few examples of the SNES doing just fine in this department.

Here’s a couple from Turrican 2:

At 1:06 and 24:04

Idea for cool 3D effect on SNES

​So, I’ve just considered that Mode 7 also uses 8bpp 256-colours like Mode 3, which means you could create all kinds of pseudo-3D effects alongside the 8bpp 256-colour palette cycling I’ve mentioned previously for some amazing results.

My first idea is a 3D waterfall effect that combines the kind of thing Kulor is doing below along with the palette cycling to have the water animated and actually streaming down the 3D scene too:

Note: I sent Kulor a wee message about potentially adding in additional shading to the wall sections of his scene that aren’t flat, where there would be less light hitting them (assuming the light source in the scene is somewhere above and in the distance), which would sell the 3D effect even more, and I would definitely apply that to the waterfall scene too.

So, imagine a multi-level waterfall plus some landscape sections that’s rendered similarly to Kulor’s scene, which could be in a shump level where you either fly up the scene over the waterfall like in Kulor’s example or horizontally across the scene as in most shmups.

Here’s a simple scribble of the idea I had that I jotted down a while back:

And here’s a very basic example of moving across a Mode 7 water background, just to hint at how the side-scrolling version might start, but it would be a lot more visually appealing and sophisticated as I imagine it:

Now, the Mode 7 tilemap would consist of what looks like some patches of brown ground or rocky areas broken up by water sections that are drawn as if they are flowing down parts of the scene, so it’s not all just water. Everything is technically static outside of the actual entire scene scrolling relative to the player, but the water is animated as flowing using the palette cycling. This way, you can have the pseudo-3D scene scrolling entirely in whatever direction or even completely static, and the water would still flow correctly irrespective.

Super Off Road: The Baja comes to mind for the general effect, where the road there would be replaced by the flowing water in my example, and the height difference between each flat and vertical section of the scene would be larger and more pronounced like Kulor’s example, to really emphasize the 3D effect of it being a waterfall flowing over land areas and cascading down walls and the like:

Also, as seen in Mark Ferrari’s examples, you could even bake in the animated mist at the bottom of the waterfall sections using the palette cycling too, and maybe even a few sections with some swaying tufts of grass here and there (7:30):

And, because this is all currently done entirely with backgrounds, there would also be plenty of sprites left to use some of them for little scaling rocks and tufts of grass at points, so the whole scene has a little more 3D height and depth too. A bit like scene in Panorama Cotton on Genesis, but maybe a bit more subtle and taking up less sprites overall, so there’s plenty left for the actual player and ships and so on (from 6:24):

In fact, that Panorama Cotton level above with the water is kinda a much more simplified-looking version of what I’m thinking about actually (at least for the vertically scrolling version), where the water would look much nicer and the landscape would both be able to be fully textured and have big sections where it drops down before going flat again and so on, all because of how Mode 7 works.

On top of that, any part of the scene above the Mode 7 waterfall would be a background mode switch and could use say the full three layers of Mode 1 for some overlapping mountains and clouds in the distance and have lots of line/row scrolling applied to really sell the whole 3D effect of the scene even more. And, because I think it’s possible to do this based on chat in SNESdev and also this, it could even be that the main sky and clouds are done with their own Mode 7 section too, and made to scale towards the view much like this lovely effect (at 22:48):

I think that would create an amazing 3D effect on SNES. And, because it’s ultimately just a “relatively simple” Mode 7 effect plus palette cycling (and the palette cycling really doesn’t cost much at all), it could be done alongside a hectic shump or whatever and just really make the SNES look like it’s doing something very impressive visually.

So, there it is, it’s out there. If I could program for SNES then I would implement this into my own shump tests, but I can’t, and I can’t do most of this in Game Maker 8.1 mockups either, so I leave it in the ether for someone else to try if it so takes their fancy.

Note: If anyone wants to talk to me more on this, give me a shout. And I’d be up for doing the art too.

And here are my own tests again, just in case you’re wondering if I have a clue what I’m talking about and/or any artistic skills whatsoever:

“Blast Processing”, the reality. . . .

As it turns out, “Blast Processing” really was just total marketing spiel back in the day, even if the Genesis could technically do some stuff under the hood that can now be sort of linked to it decades later.

“The fact is that Blast Processing is such a hardcore, low-level application of the Mega Drive hardware that, astonishingly, it was never used in any shipping games and only in recent years has the technique been successfully mastered. And even then, its actual application in games is severely limited, with some interesting, but not exactly game-changing results … But secondly, and perhaps more pressingly, Blast Processing essentially uses the entirety of the 68000’s CPU time. You can run Blast Processing on a Mega Drive game, but you’d be unable to run anything with it … So it’s useless for standard cartridge games [other than for static high-colour images] … Throughout the machine’s lifetime, clever coding produced an almost generational leap in the effects seen in Mega Drive titles – but Blast Processing, unfortunately, wasn’t one of them.” – Eurogamer

Here’s a Digital Foundry video of what real “Blast Processing” is: 

There are also some other additional limitations and drawbacks to this mode that aren’t metioned in the video above, such as a lower horizontal resolution with double-wide pixels, some glitchy pixels, a stalled CPU and out of action sound processor, the disabling of scroll planes and an inability to display sprites, etc, which I’ve not seen/heard anyone mention in the past when talking about “Blast Processing” on the Genesis, especially when using it to suggest the console is capable of something the SNES isn’t, but they are covered nicely in this video:

So, it’s definitely interesting that Genesis can even do higher colour images in the first place, but some random hacker pulling off some random hack decades down that line, a hack that clearly wasn’t what Sega was trying to convince all the Genesis and indeed SNES fans of when it marketed “Blast Processing” to them as some kind of Genesis secret sauce that makes its games run faster than those on SNES, is nothing more than straight-up lying.

But, hey, the high-colour images do looks half-decent for what they are, at least based on the clips in the video footage above. Although, it would be nice if I could find some examples of clean full-screen images of “Blast Processing” in action somewhere online to check out.

Edit: I managed to get the images from the demo that’s linked in the Digital Foundry video:

Not sure what the big bars of solid colour at the bottom of each image are though.

Here’s some standard SNES 256-colour images for comparison:

Note: Any black bars or borders in the SNES images are just me being lazy and not finding images that fit its aspect ratio properly before converting them to display in the SNES’ specifications.

Nintendoes . . .

Note: This article exists because I think we’ve seen the spreading of a false narrative around the SNES/Super Famicom and Genesis/Mega Drive consoles in recent times, which basically conveys that the SNES really only has more colours than Genesis but is otherwise just very slow, and that the Genesis basically does everything else better and/or can simply duplicate anything SNES does anyway through pretty much sheer CPU power alone, which simply isn’t the objective truth at all.

So, this a list full of things the stock SNES does better than the stock Genesis in terms of technical specs, plus some things it does that Genesis simply can’t, as well as some ways it just measurably beat the Genesis based on official numbers like sales and such–and all of them are facts:

Can display four times as many colours onscreen total (256 vs 64, before any standard HDMA, colour math or special raster tricks).

Has a master palette of colours to choose from that is 64 times larger (32,768 vs 512).

Can use up to twice as many full-screen, fully overlapping background layers (4 vs 2).

SNES’ max tilemap size is 64×64 tiles at 16×16 pixels per tile (1024×1024 or 1,048,576 total pixels) vs Genesis’ 64×64 or 128×32/32×128 tiles at 8×8 pixels per tile (512×512 or 1024×256/256×1024 or 262,144 total pixels).

SNES’ max number of unique background tiles is 4096 (in Mode 0) vs Genesis’ 2048 (in its only mode). This is not accounting for the likes of tilemaps and sprites, which take up memory and would reduce available tiles on both systems similarly.

Can process a max 128 sprites vs Genesis’ max of 80.

Its largest in-built sprite size is 64×64 vs Genesis 32×32.

Can display a max 32 sprites per scanline vs Genesis’ max of 20.

Can do column scrolling down to every 8 pixels vs every 16 on Genesis (lower is better here).

Can use two window/shape masks to either visibly draw shapes on top of or cut shapes out of one/some/all layers, which is used to create various effects like spotlights or beams of light (when combined with colour math), interesting shapes when fading in/out the screen, hiding certain objects or parts of the level from view, faking simple additional layer/sprite elements, etc.

Can do proper colour math for the likes of transparency effects on both sprites and backgrounds.

Has built-in mosaicing.

Has built-in HDMA that can be used to change the main background colours every single scanline, change scroll speeds on up to four layers at once on every scanline, can be used for afine transforations of a background layer to create all the Mode 7 effects the SNES is known for, can adjust the two window/layer maskes on a per-scanline basis, and much more besides.

Has a higher maximum resolution of 512×448 vs Genesis 320×448.

Can actually use the 448 interlaced mode to properly double the vertical resolution at no extra VRAM or processing cost when in Modes 5 and 6, which is done by allowing the use of built-in double-height background tiles that take the vertical resolution doubling into account (at the cost of the usual third background layer). This works similarly in horizontal 512 mode too.

Can have up to eight channels of PCM sampled sound, and can output audio at a max of 32KHz and 16-bit depth in stereo, which is more than Genesis when playing like for like.

Can do Dobly Surround Sound.

It has eight times as much audio RAM, at 64KB vs 8KB.

Has twice as much work RAM at 128KB vs Genesis’ 64KB.

Can apparently compute roughly 1.7 million CPU instructions per second vs Genesis’ roughly 900,000 (min I’ve read) to 1.4 million (max I’ve read), due the fact the SNES can execute instructions in fewer clock cycles than Genesis (I’ve read 2-3 cycles on SNES and 4-8 cycles on Genesis). And this seems like it’s along the same lines: “every time the m68000 accessed memory, it’s 4 clock cycles wait per 16 bits, whereas the 65816 [is] 1 clock cycle per byte [a byte is 8 bits]. So for instance doing 8-bit operations (very common then), 65816 would have an advantage over the m68000 and be roughly equal for 16-bit operations, just by memory wait time.” Basically, even though the Genesis has a faster CPU, it typically takes more clock cycles to perform instructions.

The standard controller that comes free in the box has nine main inputs, four more than Genesis’ 3-button pad and one more even that Genesis 6-button pad (which over half of Genesis systems didn’t ship with and owners had to pay extra for), with a far more versatile design.

SNES’ total library of official games is roughly 1757 vs Genesis’ at roughly 878.

SNES sold 49.1 million units worldwide. Genesis sold around 35 million (including the bargain-bin $50 Genesis 3 and the various Brazilian models).

SNES has 49 games that sold over one millions copies vs 18 on Genesis.

SNES’ top selling game sold 20.6 million copies. Genesis’ top selling game sold 15 million.

More SNES games still appear in pretty much every Top 100 Games of All Time list than Genesis. For example, IGN’s latest list has seven for SNES and zero for Genesis.

Genesis is very cool and all, and it does indeed have quite a few advantages over SNES, just as SNES clearly has quite a few notable advantages over Genesis, which I think more people should be aware of in modern times, just to make sure the narrative and indeed the facts around these two classsic systems aren’t being constantly distorted and history re-written by certain bad actors.

Now, anyone from the Genesis camp is free to post their own similar list of facts.

Note: I have tried to be as accurate as possible with all the data here, but, if you spot any mistakes, please let me know. If you’re being honest, I’ll update the details accordingly.

What I’d like to see in a SNES Mini 2

So, if Nintendo was to make a SNES Mini 2, I’d like it to be pretty much the same as before with a bunch of classic SNES digital titles pre-installed, although maybe with the SNES Jr. model this time to easily differentiate it from the first one (I guess):

Along with one major addition, which would be a working [mini] cartridge slot that actually takes [mini] compilation carts of classic SNES games in a similar vain to the Evercade VS: https://evercade.co.uk/vs/

This would mean publishers like Nintendo, Capcom, Konami, Square-Enix, Namco, Atari, etc, could release their own compilation carts of classic SNES games in modern times and possibly even make some brand new games for it too.

And, in an ideal world, Nintendo would actually release proper development documentation, finally, and maybe even some kind of simple and very user-friendly software developement tools to go along with this, so indie developers could also build their own SNES Mini titles relatively easily too, which could be via a website or even built into the system directly in a similar vain to the Pico-8: https://www.lexaloffle.com/pico-8.php

At the bare minimun though, just having a working [mini] cartridge slot allowing additional physical [mini] games to be plugged in could be a game-changer in the Mini category imo.

I think that could take a new SNES Mini 2 from being another cool little stocking filler to something potentially very special, and maybe even give birth to a modern SNES Mini console/game market category in its own right.

Note: An important caveat here is that I think any new games made for the SNES Mini 2 would have to be designed to work to/within the original SNES’ technical limitations, purely so these new SNES Mini 2 games could also be released in large cartridge size for the normal SNES as well. That way there’s an instant larger potential market base without any need to design and create totally different versions of the game (outside of the different cartridges).

SNES Mode 3 images can look gorgeous

The images below are doing nothing other than using what is possible in Mode 3 on SNES with its 8bpp and 256-colours total onscreen from the 32,768 colour palette. And this is even before any HDMA or colour math or any raster tricks and the like are applied. There’s even enough VRAM spare to maybe have a little scrolling and stuff too, along with a simple second background layer for some parallax and maybe even some sprites in there also. But, even just as static images and nothing else, they can look beautiful, and far beyond anything I’ve ever seen in any commercial SNES titles or even modern SNES indie games to date:

Impressive SNES Graphics

It’s just a bunch of cool examples of the stock SNES doing some rather impressive stuff graphically, be it purely visual/aesthetic or maybe how much it’s pushing around onscreen without slowdown, and so on.

So, here we go. . . .

A great use of SNES’ background Mode 3 for 8bpp, 256-colour, palette cycled visuals, which would be perfect in some kind of Choose Your Own Adventure graphic novel type of game experience.

The Super Mario Bros. Movie!

I am loving what I’ve seen and indeed heard so far. Really looking forward to this now. Hype!

My Honest Bonelabs Review

I don’t know what low bar most of the VR players out there have set for this medium, particularly on standalone, but I’m not drinking the Kool Aid here.

The controls and interaction in this game are simply terrible, just like Boneworks before it, and it’s immediately getting returned as a result.

When I can’t just jump and climb without getting stuck on scenery, can’t just grab and push/pull things around without it being a clumsy mess, can’t just swing a weapon/item without it getting stuck on my avatar’s body, when I have to overthink every motion/movement just to try to avoid horrible collision and motion-sickness-inducing clankiness, it’s just not good enough.

And, by the way, while the “realistic” physics might be celebrated by many in this game, it’s shocking to me that it still looks worse graphically than RE4 VR, which is a game originally released on GameCube in 2001 that’s been updated brilliantly for Quest 2 and actually looks and plays great on it. And, note, I just played RE4 VR literally mins before trying this to specifically compare the visuals and level of polish, so I’m saying with 100% confidence that RE4 VR simply looks better (less blurry overall, better texture detail, no noticeable foveated rendering, sharper in general, no janky legs and arms on the player, some basic shadows under the characters, etc), and it controls and plays leagues better too. There may be some technical level where Bonelab is beyond RE4 VR graphically (certainly in terms of the physics engine), but if it all just looks a bit uglier across the board, it ultimately means nothing to me. It’s the end visual result that counts and nothing more when it comes to the graphics.

Look, I can live with the visuals, which aren’t the best the Quest 2 is capable of (although are totally fine), but the fundamental controls and interactions simply are not good enough–they’re not even close to passable imo–and, for me, they utterly ruin what other potential might be there in the game.

That’s it.

If you want another similarly brutally honest review, you can check out this one too: