nesdev.com

I think you can start by making an RLE decoder, and then work backwards.

On the SNES vs the Genesis doing 3D rendering, the graphics format probably is the most limiting factor. Of course, you can use Mode 7, but then your rendering area is very limited. Really though, a size much bigger than this will lead to garbage framerates regardless of the graphics format. The SNES port of Wolfenstein is really underwhelming for the hardware, but so were 90% of games in the console's early lifetime.


Donkey Kong Country 2 actually does it better than 90% of games though, as it doesn't just shear the layer horizontally, but also stretches/shrinks the layer vertically. I've noticed that while it's fairly rare for SNES games to do this, you almost never see it for the Genesis, likely do to having the line scroll table instead of HDMA.


I don't think I've ever seen Sonic with blue arms. However, they did decide to give him blue legs.


What the actual fuck Stef.

Using Mode-7 as the buffer, there's probably ways of recycling blank or solid colored tiles, but it I would need to think a lot about it.

I have also thought about representing 2 colors per 8x8 tile, and shrinking the mode 7 layer down to a 256x128 area, and using the tile map as a pattern map, but a 256x128 window doesn't look that good. Now that I think about it, you can take the 256x128 area, stretch it to 192 and put it into interlace mode.

Dude, this is the SNES we're talking about. I wasn't even aware that size was possible using Mode 7, because if it is, the graphics format basically isn't a problem.

Not normally, but if every 8x8 tile consists of 2 solid colored halves, then you can pull off a 4bpp packed pixel 256x128 window.

Oh...

Star Fox only uses 16 colors for polygons.

In other words, you can use the S-CPU to render into what is essentially an untiled version of Mega Drive VDP format, and use the result as your tilemap. Only catch is, you don't have any space left over for any other colours in CGRAM. Unless you use direct colour mode for the Mode 7 layer, and since you're rendering to the map and not the tiles, there's no reason you couldn't do this. It just limits you to 8-bit RGB, which is kinda bad, but eh... EDIT: see below.

Furthermore, 256x128 is the absolute limit of what you can cover with 16x16 sprites, meaning you can't do seamless backdrop tilting or even scroll unless you use 32x32 - or possibly 16x32...? The non-square PAR might let you get away with more vertical skew than horizontal, but then it wouldn't match the rendered layer unless you applied a transform to one of the axes every time you computed a projection, which would be expensive, and hidden penalties like that are best avoided if you're trying to prove something about CPU power... maybe the Corneria background wouldn't be all that bad; it doesn't have much in the way of verticality...

...just thought of something: I believe the MD Star Fox mockup uses column scroll to tilt the rendered layer, in order to avoid the extra rotation transform. Technically tilting a Mode 7 layer should be trivial, but if you're already at 256x128 there's no wiggle room...

One final issue is that if you're rendering into Mode 7, you can't use the PPU multiplier during the display period. This could be a serious obstacle to doing decent 3D on a stock SNES. I haven't looked into this much, but I think there are a bunch of tricks that have been used in the past to do fast bitplane rendering of polygons on a 65xx. If you can render more than one or two pixels at a time, because most polygons are untextured, the bitplane format isn't such a crushing disadvantage. Plus you can set up the VRAM gate to take linear bitplane and distribute it into tiles in VRAM, so you don't need to worry about tiled rendering either way...

...

I actually used this same packed-tile Mode 7 idea for a background for my port, except I used it as a compression technique. With a brute force optimizer in Matlab, plus a bit of hand-tuning, I managed to get a 128x128 image with over a hundred colours into 24 KB of VRAM (well, 12 KB of tile data and 8 KB for the map). The result is virtually indistinguishable from the uncompressed image, and as a bonus, rotation is a lot smoother at the same zoom level, because it's basically doing sub-texel positioning.

Unfortunately, the success of this compression method seems to be highly material-dependent. I tried it again on a different image (a larger one - 128x192) and had to back it all the way down to 14 colours to fit it in 192 tiles with acceptable levels of artifacting.

Why is CGRAM a problem? Only the first 16 colors are needed, so the rest can be used for sprites. You're right that I might need the Mode-7 multiplication registers.

It's not. I must have been thinking of my other scheme, which was to draw the tiles themselves in packed-pixel format and blend the 16 colours into 256 combinations so it would still work. The result would be blurry but potentially serviceable.

Your way's better.

I once heard of a trick called XOR filling, which is to just draw dots at the top and bottoms of polygons, and XOR each group of pixels with the group above them. I think it can aim for 256x192 at 20fps.

Yeah, I seem to recall something about that from a discussion about polynes.

Also, I found this: http://codebase64.org/doku.php?id=base:6502_6510_maths
in which is found this: http://codebase64.org/doku.php?id=base: ... he_vectors

I don't know if it's the fastest way, but it appears to claim to do something similar to your goal in a reasonable amount of time.

One might also want to take a look at what Overdrive 2 is doing in that polygonal section near the end. I think there's a video; they've got some shenanigans going on that might be conceptually useful...

those demos were helped a lot by the chunky display that the MD has,but i agree a 2.68mhz 65816 cannot do a 3D game like the 7.6 mhz 68k can do .

Wolfenstein on Apple 2 gs trounce the MD version, and this computer has no hardware acceleration at all like sprites,DMA,background layers.
But The 2gs has a 8/10 mhz 65816 accelerator ,however he accesses to his "video RAM" @1mhz (apple 2 compatibility) .

https://www.youtube.com/watch?v=E3uHip1Qr-4&t=263s

But with a planar format, even (IMO) a 10mhz 65816 cannot do some miracles .

Toy Story on SNES did a much better job with ray casting, although they were helped by Mode-7's packed pixel format, and vertical mirroring. Too bad they had to make the screen smaller to fit within 256 tiles.

https://www.youtube.com/watch?v=AuvcCvRMbU8