Fan-made tech demo of Starfox on the Genesis

[marlowe221]

The NintendoAge thread was an interesting/entertaining read.

I don't pretend to understand all the technical stuff (I'm just a simple, country lawyer) but I will say this:

1. It's actually pretty cool that the SNES could use a variety of cheater chips in cartridges. It's actually kind of a cool design feature in a way. (I realize the Genesis could do it too)

2. It's awesome to see what the Genesis is capable of with no extra help at all. "Blast Processing" indeed.

[TmEE]

It is not really a design feature. There are no "designed to use addons" in the SNES cartslot, in fact, there's more of that "designed for addons" in MD cartslot. SMS beats all though, that cartslot is insane.

[marlowe221]

It is not really a design feature. There are no "designed to use addons" in the SNES cartslot, in fact, there's more of that "designed for addons" in MD cartslot. SMS beats all though, that cartslot is insane.

That's interesting. I had always understood that the whole "extra chip" in the cartridge set-up was an intentional design decision by Nintendo for the sake of versatility or some such crap. So it was more of an unintended evolution then?

[Barone]

That's interesting. I had always understood that the whole "extra chip" in the cartridge set-up was an intentional design decision by Nintendo for the sake of versatility or some such crap. So it was more of an unintended evolution then?

That's what Nintendon'ters want you to believe.
Nintendo just screwed up with such a slow processor and then they tried to cover their shit with a bunch of aid-chips.

[sheath]

Yeah, the reason the SNES uses so many chips is because it needed to thanks to the slow CPU. Yes the SNES CPU can do some things in fewer cycles than the 68k but I have yet to see that making up the difference of five Mhz between the two processors. This is the reason Race Drivin' is almost half the framerate of the Genesis game in the SNES version, why SNES beat-em ups only have 3-4 enemies on screen, why SNES shooters have fewer objects, bullets, enemies and explosions, and why SNES games slowdown more frequently and prominently than Genesis games do.

Well, to be completely fair some of the above is also due to poor programming and slower ROM running the CPU even lower in the 1-2Mhz range. If the SNES had come out with a 12Mhz 68000, or even 65c816, we wouldn't be having this discussion and the SNES would have far fewer helper cart chips.

[Barone]

Games like Flashback and Another World are also significantly slower on the SNES (to not talk about the loading times).

[marlowe221]

Well, learn something new every day I guess.

So would I be correct in assuming that Genesis games use add-on chips in cartridges a lot less often?

[sheath]

Only the SVP in Genesis Virtua Racing, there are no other add-on chips.

[marlowe221]

Wow. I become more and more impressed with the Genesis all the time.

[sheath]

Eh, apparently its limitation to only four 15 color palettes, and the DAC not having timing lines connected, negates almost anything positive we can say about the MD/Genesis design.

-edit-

Since the SNES game is already windowed at a lower resolution, I wonder how direct color DMA mode would work out for a Starfox port. 320 mode is only 160x224, that isn't great and with the low colors of the original it might not even benefit from 512 colors.

[Stef]

This is something I've wondered for a while, but:
Are all the objects in Star Fox rendered in realtime, or are some prerendered 2D vector animation that just gets rasterized? (and I don't mean the scaled/rotated sprite textures, since those are obviously 2D)

From what i can say, all is rendered in realtime. All objects you can see in cutscene are present in the rom.
What part of game make you though about prerendered ? About texture, they are actually textured polygon, texture is encoded as a specific color information.

Also, are the polygons being rasterized with any compensation for aspect ratio, ore are square pixels assumed? (I forget if the SNES game bothers with this either) Running in H40 might be interesting, though you'd have a bigger horizontal boarder then, but squarer higher-res pixels and more DMA bandwidth. (maybe get away with double wide pixels -bytes rather than nybbles- without being too jagged -if you tried doing that in H32, it would be more obvious, though you could blur things a bit using H-scroll -shifting 1 pixel left/right at 60 Hz to blur things horizontaly)

I guess they just assume square pixels. I'm using H32 as anyway i don't use the DMA at all, all rendering / bitmap buffer conversion is done by the 68000 so i don't have any loss in using H32 About the h scroll blur, that would affect polygon edges as they are not anymore double pixel wide (i improved the polygon rendering code for that).

Can you scroll the screen over to hide the cell scroll artifacts?

Nope if i stay with H32 mode, but using the H40 mode could fix the problem

It hits 7 FPS with a lot more going on than your demo though

I agree, 7 FPS is probably the worst you can get in original SNES game when screen is more loaded that what i display in the demo.

but again, we'll have to see how things go once the thing gets fully optimized. (I wouldn't be surprised with the MCD outdoing Super FX, but vanilla MD would be really interesting)

Yep, it can be optimized, hope to have time to work on that soon =)

The most impressive software rendering on 68k I can think of is Geograf Seal running on a 10 MHz x68k. (then again, you've got an 8bpp framebuffer to help there too, and a lot of RAM to help with some shortcuts)

Just watched a video, indeed it's very impressive, do the x68k has some hardware assistance as DMA or blitter ? the 8bpp help but still, the 3D engine is really smooth !

[Stef]

Since the SNES game is already windowed at a lower resolution, I wonder how direct color DMA mode would work out for a Starfox port. 320 mode is only 160x224, that isn't great and with the low colors of the original it might not even benefit from 512 colors.

using direct color DMA would eat precious 68000 cycles, and as you said, Starfox only use 16 colors for the 3D rendering so that is not really useful here :-/

[TrekkiesUnite118]

Out of curiosity what resolution are running at right now? Would you possibly get better performance if you windowed it on the sides as well like the SNES game does?

[kool kitty89]

From what i can say, all is rendered in realtime. All objects you can see in cutscene are present in the rom.
What part of game make you though about prerendered ? About texture, they are actually textured polygon, texture is encoded as a specific color information.

So all polygons are treated as textured? But most are just using very simple single color (or dithered) patterns? I wonder if that would actually make things easier to convert to an ASIC-assisted renderer on the Sega CD. (except you can't really render dithering properly with the ASIC unless you don't scale the textures . . . I guess that might still be faster than software filling with the sub-CPU since there'd be more overlap in execution then CPU rendering alone -the actual texture decals and scaled sprites would be a much bigger boost from ASIC rendering)

I guess they just assume square pixels. I'm using H32 as anyway i don't use the DMA at all, all rendering / bitmap buffer conversion is done by the 68000 so i don't have any loss in using H32 About the h scroll blur, that would affect polygon edges as they are not anymore double pixel wide (i improved the polygon rendering code for that).

Yes, the blur comments are mostly for a case where you'd be willing to use 1/2 res pixels. (doing a rasterizer with double wide "pixels" made out of 2 4-bit pixels -solid color or dithered pairs) It would look worse from lower res, but could be faster (lower res and 8-bit boundaries) plus it give pretty solid blended pseudo colors (dithered pairs). You'd have to compensate for the doubled pixel aspect ratio too.

It's kind of up to aesthetic trade-offs for speed, color smoothness, and resolution whether it's worth doing things that way.

Nope if i stay with H32 mode, but using the H40 mode could fix the problem

Personally, I wouldn't mind the same screen res at H40 (with a boarder around the 256 pixel window), but I'm sure some others would complain. Actually, I was already emulating it that way (fusion with raw plugin enabled -so unstretched H32) and I definitely prefer it. (you get closer to square pixels too, especially in PAL)

Just watched a video, indeed it's very impressive, do the x68k has some hardware assistance as DMA or blitter ? the 8bpp help but still, the 3D engine is really smooth !

Some videos may be emulated or running on 16 MHz models (maybe 68030, but less likely -kind of rare). 10 MHz slows down more than 16 MHz, but it's still surprisingly smooth. (not sure if there's any videos using 10 MHz)
You've got plenty of RAM and mass storage to work with on the x68k, so there might be more optimization with tables and other tricks.

Starblade says "hi!".

That's an FMV game aside from the wireframe rendered stuff . . . and that's not rasterized polygons. (wireframe 3D is a lot less intensive than filled polygons: no hidden line removal -computationally intensive- and no color filling -bandwidth intensive)
Same thing for Silpheed, except it uses scaled sprites instead of wireframe animation.

There are a few other games with polygon effects, most notably using ASIC-assisted texture mapped polygons (several of Core and Clockwork Tortoise's games did that, and F-1 Beyond the Limit), but it's still a relatively limited effect in those games . . . some more consistent than others, (Joe Montana NFL uses a gameplay/graphical style similar to 32-bit NFL games), but none really pushing polygons as the definitive feature. (texture mapping with perspective warped -and/or linescrolled- ground combined with scaled/rotated sprites was the main feature -on top of normal MD 2D- and actual 3D portions were more like added effects)

Actually, with what the Sega CD has to work with, you could probably have a game very similar to Star Fox in design, but using fully texture mapped polygons and perhaps a moderately lower polygon count on-screen (assuming you'd want a similar framerate). So kind of like Soulstar's rail shooter stages, but with textured polygons instead of scaled sprites.
Since you'd still be limited to 15 colors for the polygon layer, color optimization would be very important, but still probably doable. (Batman and Robin is one of the best examples of this IMO: doing the entire foreground layer -street, buildings, sidewalk, and all scaled sprites/objects using a single set of 15 colors -only far BG skyline and HUD use separate palettes) Also remember Star Fox itself used only 15 colors for all scaled sprites and polygons (including occasional texture mapping).

While I know that this is an issue and does slow down the 68k, it seems to be making a mountain out of a molehill if you ask me. It seems SNES fans have started throwing this around as a sort of catch all to any argument about the CPU in the Genesis.

Since we've got a mix of programmers on here with considerably experience optimizing for 650x and 68k, there's been some really nice and balanced comparison of the trade-offs involved comparing the PC engine, SNES, and MD. And it's pretty well established that if the SNES was clocked a bit higher (not even necessarily as fast as MD or PCE) that it could have been notably faster in most areas that mattered. (software rendered 3D would not be among those typical areas . . . and that's also an area the PCE falls short of the MD -not impossible, but much less favorable than comparing other CPU usage in games . . . chunky pixels also makes compression easier)

On another note, the 6809 would also have been a really interesting CPU to see in a console, or especially the Hitachi 6309. (even at 2.68/3.58 MHz it could have been really interesting to see . . . really powerful 8/16-bit CPU with some of the trade-offs of the 650x/816 but fewer disadvantages -aside from never going beyond 3.58 MHz, but that's moot in the SNES's case anyway) Granted, it wouldn't have been cheap to license like 650x/816 parts. (plus Nintendo had been banking on NES compatibility early on too . . . then again, the 680x is pretty compatible with the 650x bus interface too)

The SNES CPU is 30% slower than the Genesis one in most of the cases, to begin with.

That's somewhat true at 3.58 MHz, but not so much at 2.68 MHz. (which a large number of SNES games run at -and even late gen games had to deal with for accessing work RAM)

It is not really a design feature. There are no "designed to use addons" in the SNES cartslot, in fact, there's more of that "designed for addons" in MD cartslot. SMS beats all though, that cartslot is insane.

Too bad the SMS didn't add analog audio input lines like the Famicom, 7800, or MD (I think SNES too), then the YM2413 could have been done as a lock-on cart outside Japan (or a plug-in to the expansion port -without a passthrough AV cable). Then again, it sucked that Nintendo screwed that up with the NES as well. (added a bunch of cart pins too for expansion that never got used for anything, yet they didn't bother to reserve 1 line for mono audio input -and so many mappers had sound built in that went unused on NES releases)

Then again, the MD did have that and never took advantage of it . . . and the SMS didn't take advantage of its potential either (well, you may change that, but I meant back then). Granted, the SMS wasn't super popular like the SNES, MD, or Famicom, so there was less incentive to push embedded hardware on carts for later games. (why the MD didn't do it is anyone's guess though, and Sega even left cart manufacturing open to 3rd parties -if they wanted- so it would be even more straightforward for 3rd parties to put their own goodies in carts even if Sega didn't bother with it internally)

There's a lot of software workaround for the MD's limitations too, but some of those things obviously proved problematic on average (like certain sound issues), or in the case of 3D (or maybe texture effects), there's some things you can do in software (including this thread's main example) but a lot that could be helped with a little relatively inexpensive hardware . . . and less than what's needed to do the same thing on the SNES. (like a more primitive DSP to help with math coprocessing for 3D transformation -or possibly computation involved with scaling effects- while still relying on the 68k for actually drawing, and/or adding a little more RAM on-cart to give some decent space to render into without compromising work RAM) It wouldn't be SVP level 3D, but it would be cheaper (and could have been done earlier) and quite possibly similar or better than Super FX 3D. (might allow for certain cross-platform MCD and cart games too that otherwise wouldn't work well on the MD)

Well, to be completely fair some of the above is also due to poor programming and slower ROM running the CPU even lower in the 1-2Mhz range. If the SNES had come out with a 12Mhz 68000, or even 65c816, we wouldn't be having this discussion and the SNES would have far fewer helper cart chips.

Even running the RAM at 3.58 MHz would have made a big difference . . . but if they'd switched to SRAM (or maybe a different DRAM interface) faster should have been possible too. ROM speeds would be limited by cost though, and SNES carts at 2.68 MHz were already faster than early MD ROMs (not a problem for the 68k with its slow memory interface, but 650x chips need fast memory to work efficiently -8-bit bus combined with lack of registers). Even if cost concerns had knocked RAM down to 64 or 32 kB if using SRAM, the trade-offs would be well worth it. (as it is, the 128k DRAM is underutilized due to the speed limits . . . it would be great to decompress into and such, but the slow CPU/RAM made load times unattractive, so that's moot -and using 32 kB for fast code/data -and zero page "registers"- would help a ton even if you still had to slow down in ROM)

A 5.37 MHz version of the SNES CPU should have been a very good match for the 68k in the MD or PCE CPU for typical games (better at some things and worse at others).
But in 1990, I'd think that a 7.16 MHz 65816 should have been perfectly doable (and significantly faster than the MD or PCE) . . . 10.74 MHz would have been really nice but that would need somewhat more expensive 100 ns SRAM (or faster) and I'm not sure yields would be high enough for 10 MHz to be cost effective. (by 1994/95 it was certainly practical and cheap enough to include on-cart with SA1, but 1990 is the context that matters)
7.16 MHz with 32 or 64 kB of 120 ns SRAM should have been perfectly practical for the time . . . and if you're going to argue cost to performance ratio issues, going for a full 128 kB SRAM should have been a much better trade-off than wasting money on a complex (but bottlenecked and underutilized) sound subsystem. (Ricoh's own 8-channel PCM chip would have been fine for the time, and even better in some ways than the SPC700 module -at least as it was used in the SNES)

Eh, apparently its limitation to only four 15 color palettes, and the DAC not having timing lines connected, negates almost anything positive we can say about the MD/Genesis design.

The 9-bit RGB is limiting too . . . 8 palettes and 12-bit RGB would have gone a long way towards making the differences less noticeable. (PC Engine has the oddest set of trade-offs though . . . 9-bit RGB but 32 subpalettes; well, unless you consider the Atari Panther with 32 colors from 18-bit RGB and vriable color depth up to 8-bits per sprite/object -ie 1, 2, 4, or 8bpp and 1, 3, 15, or 32 colors with linear palette offset for lower color depths like the Jaguar and Saturn -so 4-bit sprites could use any set of consecutive 15 colors in CRAM)

Since the SNES game is already windowed at a lower resolution, I wonder how direct color DMA mode would work out for a Starfox port. 320 mode is only 160x224, that isn't great and with the low colors of the original it might not even benefit from 512 colors.

Not a good idea . . . even with the Sega CD, 9-bit RGB can be worse for that sort of shading/gradients than dithered/paletted RGB. You've got the 2D BGs to consider on top of the dithered shading. Plus you can't use the ASIC, and you need more CPU time to fill large areas of 16-bit pixels than psuedo 8-bit (using dithered pairs -same effective res as DMA color) or lower res in general compared to 4-bit pixel rendering. (DMA color is probably mostly good for certain ray casting and voxel engines and certain splash screens and FMV -especially if using flicker color)

On the MD itself, you've got the issue of massive CPU contention using DMA color like that, but again, using 1/2 res psuedo 8-bit pixels might be an interesting way to speed things up compared to full res rendering, plus there's more flexibility for dithering (assuming you're using the H-scroll blur/flicker blending method) and effectively have up to 120 pseudo colors from pseudo 12-bit RGB as well (on the 15 color bitmap layer alone). The trade-off for that speed and blending/color is lower effective resolution (though the blurring technique will soften things a bit -so blurry rather than just blocky) and if you use H40 the pixels won't quite be twice as wide as the SNES or MD H32.
OTOH, H40 would mess up the aspect ratio for the far BG . . . in NTSC at least. (it looks way wrong in PAL normally, and H40 would aspect correct things pretty well)

In terms of speed boost alone, dropping to half horizontal res would be 2 fold: 1 the lower res rasterization in general, 2 the advantage of working on byte boundaries rather than nybbles -very good for normal CPUs since they're optimized for byte/word/long/etc addressing and data manipulation and working on smaller chunks requires bit manipulation or look-up tables that eat up processing time.

[Stef]

Out of curiosity what resolution are running at right now? Would you possibly get better performance if you windowed it on the sides as well like the SNES game does?

Resolution is 256x160 (40960 pixels), of course reducing resolution can help but honestly i think that is already a quite low resolution, original game is 224x190 (42560 pixels). I'm almost on par (1600 pixels difference) and i really want to keep that resolution for the moment
Maybe later reducing horizontal resolution to 224 can be tested but that won't help that much, the 3D transformation almost use as much (if not more) time than rendering in complex scenes.