Fan-made tech demo of Starfox on the Genesis

[old man]

Nobody ever mentions the eight general purpose registers the 68k has. Anyway....


http://nedroid.com/comics/2013-02-06...alled-copy.png

And what's the deal with people crapping on the SVP Virtual Racer port? Just because the 32x version is better doesn't mean that one didn't kick ass.

[ThugsRook]

And what's the deal with people crapping on the SVP Virtual Racer port? Just because the 32x version is better doesn't mean that one didn't kick ass.

SVP Virtual Racing = slide show
32X Virtual Racing = much better slideshow

[kool kitty89]

One thing that hasn't come up AFIK (even in the Nintedoage criticism) is the tearing from being single buffered in this demo.
Does that not bother anyone here much? Leaving it that way certainly frees up VRAM space and allows for more detail in the background (Virtua Racing could have had a BG closer to VR Deluxe if done that way), but SNES Star Fox was double buffered as it is to avoid screen tearing.

SVP Virtual Racing = slide show
32X Virtual Racing = much better slideshow

Neither are slideshows. SVP VR runs at a pretty solid 15 FPS and 32x at 20 FPS (both maybe with a little slowdown, but it's not obvious to me).

Stunt Race FX is a slideshow, Checkered Flag is a slide show, and Hard Drivin' is obviously a slide show, but those two aren't. (personally I'm not sure I'd call Star Fox a slideshow, but it's certainly choppier than SVP Virtua Racing)

Nobody ever mentions the eight general purpose registers the 68k has. Anyway....

Everyone who wants to poke fun at x86 does. (actually, it's more the 16, 32-bit wide registers, 8 of which are full general purpose and the other 8 are fixed/mixed purpose)

In the context of 650x CPUs though (not just compared to 68k, but Z80/8080 or x86 even), there's the issue of fast memory access and especially the use of zero page "registers" to make up for this. However, once those types of CPUs start getting fast enough, you run into issues with DRAM and ROM being too slow to allow the CPUs to run at full speed . . . external caching and/or scratchpads can be a huge help with this though, or using SRAM for main memory in general (impractical for home comuters, but OK for small chunks of RAM in consoles or -less cost constrained- arcade boards). NEC also got away with this since they offered very fast ROMs for the PC Engine, and relatively fast DRAM in the PCE-CD as well. (and SRAM in the Super CD and Duo)
The SNES was crippled with the slow RAM/ROM in the system, hence the 2.68 and 3.58 MHz limits. Even adding an 8kB scratchpad could have been a big help. (if it was stuck at 3.58 MHz, less so, but it should have allowed 5.37 or 7.16 MHz -again, for 1990, Ricoh should have been able to put out 7 MHz 65816s with reasonable yields)

Still, there should have been much better cost trade-offs to allow more fast RAM than just a small scratchpad. (and still keep the SNES's retail price of 1990/91)

[Armoured Priest]

One thing that hasn't come up AFIK (even in the Nintedoage criticism) is the tearing from being single buffered in this demo.
Does that not bother anyone here much? Leaving it that way certainly frees up VRAM space and allows for more detail in the background (Virtua Racing could have had a BG closer to VR Deluxe if done that way), but SNES Star Fox was double buffered as it is to avoid screen tearing.



Neither are slideshows. SVP VR runs at a pretty solid 15 FPS and 32x at 20 FPS (both maybe with a little slowdown, but it's not obvious to me).

Stunt Race FX is a slideshow, Checkered Flag is a slide show, and Hard Drivin' is obviously a slide show, but those two aren't. (personally I'm not sure I'd call Star Fox a slideshow, but it's certainly choppier than SVP Virtua Racing)



Everyone who wants to poke fun at x86 does. (actually, it's more the 16, 32-bit wide registers, 8 of which are full general purpose and the other 8 are fixed/mixed purpose)

In the context of 650x CPUs though (not just compared to 68k, but Z80/8080 or x86 even), there's the issue of fast memory access and especially the use of zero page "registers" to make up for this. However, once those types of CPUs start getting fast enough, you run into issues with DRAM and ROM being too slow to allow the CPUs to run at full speed . . . external caching and/or scratchpads can be a huge help with this though, or using SRAM for main memory in general (impractical for home comuters, but OK for small chunks of RAM in consoles or -less cost constrained- arcade boards). NEC also got away with this since they offered very fast ROMs for the PC Engine, and relatively fast DRAM in the PCE-CD as well. (and SRAM in the Super CD and Duo)
The SNES was crippled with the slow RAM/ROM in the system, hence the 2.68 and 3.58 MHz limits. Even adding an 8kB scratchpad could have been a big help. (if it was stuck at 3.58 MHz, less so, but it should have allowed 5.37 or 7.16 MHz -again, for 1990, Ricoh should have been able to put out 7 MHz 65816s with reasonable yields)

Still, there should have been much better cost trade-offs to allow more fast RAM than just a small scratchpad. (and still keep the SNES's retail price of 1990/91)

I don't know if anyone ever found out the licensing fee for the SCP700 (and what that cost at a per unit break-down)...that trade-off right there with a cheaper, virtually as good (if not better) sound module couldn't have made the difference by itself.

edit: I re-read what I wrote. I meant so write that I feel that the cost difference probably could have made the difference for some better components elsewhere...Just kind of wondering out loud how much could be gained.

[Barone]

That's an FMV game aside from the wireframe rendered stuff . . .

No, it's not. I think you missed this while you're off: http://www.sega-16.com/forum/showthr...gons-or-not-yo
Yes, it's a technique with limited use, but, still, you could render Starfox background's animated "objects" (not the enemies with AI, of course) using that to save a lot of processing resources IMO.

[Stef]

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)

Nope of course polygons are not all treated as textured I meant that textures in game were not simple scaled/rotated sprites (and so no possible perspective) but real quad textured polygon so texture can have perspective (needed for textured part on building). Actually the game has only very few textures in some part but the engine actually does support it.
Texture are encoded as a specific color. Color are encoded by polygon face and in byte form, depending the value of that byte you goes to a [type,value] table where color type can be one of lighted, solid, direct, animated, texture... and the value usually pointing to another table to find the final byte color (2 nibbles).

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 was how my old 3D rendering worked, double wide pixel but honestly there is not much use of that. The new engine work on real pixel for edge but still you specify a byte color do you keep the possible extra solid colors by dithered pairs. If you look closely at the demo posted, you will see i use it exactly as the original game use it. I swap pixel pairs each scanline so dithering looks better (as the original game does). I think this way of rendering offer the best result, of course, at some cost as you have to take care about nibble on edge.

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)

I agree with that, i think a future version may work in H40 mode, so aspect ratio will be better and the vertical scroll bug could be hidden

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.

Oh ok i probably saw a 16 Mhz version then
Anyway still very impressive !

One thing that hasn't come up AFIK (even in the Nintedoage criticism) is the tearing from being single buffered in this demo.
Does that not bother anyone here much? Leaving it that way certainly frees up VRAM space and allows for more detail in the background (Virtua Racing could have had a BG closer to VR Deluxe if done that way), but SNES Star Fox was double buffered as it is to avoid screen tearing.

Totally true, i was surprised no one pointed it before Actually my engine can support double buffering but i needed VRAM space for background tiles and i have to disable it only for 8 or 9 missing tiles :-/ A complete bitmap buffer flip take 3 frames on NTSC and 2 frames on PAL system, so indeed you have tearing (2 on NTSC, one on PAL) ans that is a bit annoying.
I guess i could probably optimize my VRAM table arrangement so i can re enable it but then later i will have problems when displaying sprites...
I guess they are very short on VRAM on SNES as they have the same quantity but just without sprites and scroll tables in.

[Barone]

Oh ok i probably saw a 16 Mhz version then
Anyway still very impressive !

This is footage from real hardware (X68000 SUPER-HD: 10 16 MHz CPU and 2MB RAM):

[Kamahl]

Geograph Seal is so much more fun than Starfox, even at 10 Mhz.

[Zebbe]

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.

I read interviews with Trip Hawkins and the CEO of Treasure, both stated the Mega Drive processor is more powerful than the SNES processor. I guess they are part of the "Sega fans hoax" and that this guy on Nintendo Age is right, seems legit.

[TmEE]

Kevin Seghetti in the most recent Sega-16 interview calls SNES CPU an abomination.
(I personally consider 65x and derivates garbage... they only saw use because they cost very little, there are no redeeming factors...to me)

[NeoVamp]

SVP Virtual Racer port?

SVP Virtual Racing = slide show
32X Virtual Racing = much better slideshow

Is Virtual Racer related to Virtua Racing by any chance?

[kool kitty89]

Nope of course polygons are not all treated as textured I meant that textures in game were not simple scaled/rotated sprites (and so no possible perspective) but real quad textured polygon so texture can have perspective (needed for textured part on building). Actually the game has only very few textures in some part but the engine actually does support it.
Texture are encoded as a specific color. Color are encoded by polygon face and in byte form, depending the value of that byte you goes to a [type,value] table where color type can be one of lighted, solid, direct, animated, texture... and the value usually pointing to another table to find the final byte color (2 nibbles).

I would have thought that the non-rotated/non-distorted objects would have been using a simpler scaling algorithm to save on computational overhead compared to the rotated objects and warped textures on actual 3D perspective polygons. (the asteroids, explosions, and 2D scaled projectiles would just need scaling, not actual affine texture rendering -or something similar- as rotated sprites and warped textures would require -hell, even the "sprite mode" of the Playstation only allows scaling without rotation to optimize for speed and max fillrate)

It was how my old 3D rendering worked, double wide pixel but honestly there is not much use of that. The new engine work on real pixel for edge but still you specify a byte color do you keep the possible extra solid colors by dithered pairs. If you look closely at the demo posted, you will see i use it exactly as the original game use it. I swap pixel pairs each scanline so dithering looks better (as the original game does). I think this way of rendering offer the best result, of course, at some cost as you have to take care about nibble on edge.

How much different is performance using full resolution like that rather than double wide pixels?

I agree with that, i think a future version may work in H40 mode, so aspect ratio will be better and the vertical scroll bug could be hidden

I was also thinking about the tearing issue and single buffering along with H40.
If you switched to 280x152, there should be enough vblank time to DMA the entire polygon framebuffer window in a single (NTSC) vblank period and avoid tearing even if single buffered. At 152 pixels, that should allow (in 60 Hz) 108 x 198 = 21384 bytes transferred within vblank, and 280x152x4bpp gives 21280.
Also, that's actually very slightly higher resolution than 256x160 and the exact number of pixels SNES Star Fox uses at 224x190. It also fills pretty much the exact same horizontal screen space (on the monitor or TV) as 224 pixels on the SNES (or H32 MD) but at higher resolution. (vertical boarder will be higher, obviously)

I'm also assuming you're rendering the entire polygon window in work RAM. If you modified the renderer to use less work RAM (like rendering smaller strips/chunks), you'd still get tearing without double buffering in VRAM.

Since the SNES already sacrificed VRAM space for double buffering, there's not much to gain in terms of added space for background detail unless you wanted to go beyond what the SNES game already did. (for that matter, that same resolution would have been interesting to see with SVP games, since you'd have a lot more space for BG detail than Virtua Racing did)

Kevin Seghetti in the most recent Sega-16 interview calls SNES CPU an abomination.
(I personally consider 65x and derivates garbage... they only saw use because they cost very little, there are no redeeming factors...to me)

Short instruction execution times for simple operations and very low latency memory access (and low latency interrupts). The programming methodology is very different from contemporary CISC processors though (8080/Z80 and derivatives) namely the issue of less powerful but very faster instructions less registers but fast memory access and lower clock speeds in general.
And in terms of sheer cost, the Z80 was right alongside the 6502 . . . hence both being pretty nearly equally popular for early home computers and game consoles. (including 6502 used in some relatively high profile designs and Z80 in some very low budget ones -like BBC Micro vs Sinclair's ZX series)

The 680x family was a lot more like the 650x family though, but the 6800 was obviously far more expensive than the 6502 at the time.

There's been tons of discussions on the trade-offs and overall performance between 650x and Z80, x86, or 68k, and on Sega-16 in particular, I remember Chilly Willy and Tomaitheous showing some example code that ended up turning out very similar performance on the PC Engine and MD CPUs with each optimized for.
I know some compare the 650x to the RISC architecture design philosophy (or the original, most fundamental RISC concept -which few "RISC" chips strictly conform to), though compared to actual RISC architectures the tiny number of registers is a huge contrast among some other things. (albeit if you consider Zero Page "registers" the situation is a little different)
And I know Chilly and Tomaitheous are both experienced at both 650x and 68k assembly . . . and I recall Tomaitheous mentioning he used to play around with 6809 coding too. (including some CoCo demos)

I also know that the performance advantages of 650x chips kind of get ruined when used with heavy bus contention and/or slow main memory, and that's directly related on the lack of internal registers and ability of fast external RAM access. (actually the TMS9900 relied on this as well) Including a local (not shared bus) fast SRAM scratchpad for a 650x (or 9900), that would also mitigate a large number of the trade-offs. (even just 256 bytes -to account for zero page- would offset the lack of registers at least)

The 6809 and 6309 is kind of a weird example with relatively low clock rates, high per-clock performance, more powerful instructions than 6502, more registers than 6502, and very low latency external memory access as well. (the transistor count was also way higher than the likes of the Z80, 6800, or 6502 . . . and higher than the 8086 as well iirc -less than the 68000)

I don't know if anyone ever found out the licensing fee for the SCP700 (and what that cost at a per unit break-down)...that trade-off right there with a cheaper, virtually as good (if not better) sound module couldn't have made the difference by itself.

I can't say exactly how much the SPC unit cost (be it licensing or buying components straight from Sony), but with the much simpler and older design (and in more common use) and the fact that Ricoh was already Nitnendo's primary chip vendor, there's a ton of supporting evidence for that being considerably cheaper in general.

And again, at worst, the trade-off of using 32 kB of SRAM vs 128 kB of slow DRAM would have been much better for the SNES and should have removed the main limiting factor on CPU speed. (assuming Ricoh wasn't having unusual problems getting the 65816 up to speed in general -the fact that it CAN run at 3.58 MHz but simply doesn't due to slow RAM/ROM is a good indication that clock speed and yields weren't the main issues -lack of higher speeds than 3.58 MHz also doesn't say much since it wasn't until fairly late in the SNES's mainstream life that 3.58 MHz ROM even became cost effective -at the same time, Atari was still using 2.68 MHz ROMs on the Jaguar) NEC was an exception with fast ROM on the PC Engine, but they could greatly deflate costs due to in-house manufacturing of the ROM chips.
-But, again, they probably could have made other trade-offs to allow 64 or 128 kB of SRAM too. (that's aside from just cutting costs more in general and allowing a more competitive retail price)

Edit: moved the Starblade discussion with Barone to here:
http://www.sega-16.com/forum/showthr...751#post562751

[TmEE]

The faster instructions holds no water because the "competition" runs at 2...4x speed, instructions take close amount of time, and memory access figures remain similiar. It is same deal as volume control, when it is quiet you turn things up. Instructions take less cycles but they are bare bones and manage almost nothing, you have to chain more of them and then you get some results that matter, and at that point you no longer have any advantage, only headache for the programmer. Being cheap is the only reason that CPU family exists.
The fast bus cycles that are stuck in one-another are harmful for many applications, there is a reason why nobody did that, not without bus request facilities. Most of 65x series never had any of that, you need extra hardware to achieve it which tends to null up the saving on CPU itself. Most computers used something else just because of it.

[old man]

Is Virtual Racer related to Virtua Racing by any chance?

I knew it didn't get an l. It's been too long since the 90's and my brain just automatically rejected their spelling conventions. Too much EXTREME!!!! from that decade will do that to you.

[Stef]

I would have thought that the non-rotated/non-distorted objects would have been using a simpler scaling algorithm to save on computational overhead compared to the rotated objects and warped textures on actual 3D perspective polygons. (the asteroids, explosions, and 2D scaled projectiles would just need scaling, not actual affine texture rendering -or something similar- as rotated sprites and warped textures would require -hell, even the "sprite mode" of the Playstation only allows scaling without rotation to optimize for speed and max fillrate)

What i can say is that asteroid object as represented as single face 3D object with a color value pointing to a texture. I don't have yet figured all object model encoding scheme so maybe some specific values imply a simpler render method (only scale without perspective nor rotation). Of course that would make sense as it would be a lot faster for that type of object.

How much different is performance using full resolution like that rather than double wide pixels?

I can't really say as my new render code was really faster than old one (can't compare). Anyway i guess it can become significant when you have many "edge rendering" (small polygons) but is completely hidden on large polygons by "content rendering".

I was also thinking about the tearing issue and single buffering along with H40.
If you switched to 280x152, there should be enough vblank time to DMA the entire polygon framebuffer window in a single (NTSC) vblank period and avoid tearing even if single buffered. At 152 pixels, that should allow (in 60 Hz) 108 x 198 = 21384 bytes transferred within vblank, and 280x152x4bpp gives 21280.
Also, that's actually very slightly higher resolution than 256x160 and the exact number of pixels SNES Star Fox uses at 224x190. It also fills pretty much the exact same horizontal screen space (on the monitor or TV) as 224 pixels on the SNES (or H32 MD) but at higher resolution. (vertical boarder will be higher, obviously)

One of the big problem is that i do need to convert my bitmap buffer to tiles and DMA cannot do that...
I spent sometime in trying to find a method to allow DMA for tile conversion but i didn't found anything viable. At best i need to transfer 2 times the amount of original data, not worth it.
Also i can't get use something as close to the maximum DMA capabilities because of the SGDK vblank overhead, I always have to count some wasted scanlines :-/

I'm also assuming you're rendering the entire polygon window in work RAM. If you modified the renderer to use less work RAM (like rendering smaller strips/chunks), you'd still get tearing without double buffering in VRAM.

Tearing is because of the main ram to vram buffer transfer which cannot be completed in a single frame, modifying the rendering in main ram does not change anything on that.
I actually use 2 buffer in main ram too as the active display period is used for rendering (write buffer work) while blank period is used to transfer in vram (read buffer work).