I don't know about the F1 game but I can take a guess on Gunstar Heroes.

I noticed the cubes are always aligned perfectly to the axis. And they have an isomorphic projection so the cube is always the same height (although that shouldn't be strictly necessary) as it's rotating. I also noticed the cubes never seem to get smaller if they are closer to the background.

Because of this you could just have a series of sprites each showing the cube in a different angle of rotation.

Now all you need to do is properly position a bunch of sprite (16 cubes + head) and it looks like a bunch of cubes that are actually drawn in 3-D. It wouldn't surprise me if they have some small table of the X/Y positions of the cubes precomputed so they don't have to do that in real time.

In fact since every cube is always rotated at the same angle you could just have one sprite in the system table and update it every frame.

That's my guess anyway. Clever sprite trickery.

It wouldn't surprise me if F1 uses something closer to what is described in the article (although much less capable).

sonic 2 https://youtu.be/9Q0NCY-zhGg?t=1540

The rotation of the character is just made of different sprites.

I've never had a Mega Drive before working on this, so I wasn't really familiar with a lot of its games.

I took a quick look at F1 just now though. The way it makes use of the nametable and patterns is very similar to what I do. There are precomputed fully solid patterns at a fixed location and the non-solid patterns seem to be bump allocated.

It makes use of both layers though, drawing the street on one and everything else on the other. I think it uses per scanline scrolling to apply correct perspective to the street.

I can't say anything about how it actually renders into the tile map for now. That would require a lot more than looking at the VDP (graphics chip) debugger in an emulator.

The Gunstar Heroes boss reminds me of an old demo effect called vectorballs or "bobs" https://youtu.be/Itv3f7o7Zac?t=167 combined with a Doom-style pre-rendered set of rotated sprites.

There weren't really any dead ends. Mostly because I started with a very simple naive way to draw polygons and improved it incrementally. I didn't implement all those steps, but convinced myself that they would work. I started with a generic plot-individual-pixels-into-tilemap routine. Going by tile-rows and columns with special casing solid tiles came next. That required "convexity" in x direction but at that point I was only thinking of triangles. Then I noticed that avoiding overdraw and working with a tesselation of the screen is probably faster. A that point I also extended it from triangles to polygons. While fleshing out the details of everything I noticed that I don't have to be exact for right-side edges if I draw the polygons in the right order.

There actually was an extension I did, that was scrapped because it just didn't look good. At some point there was support for dithering. That helps with the low color precision of the Mega Drive (3-bit/channel). It only supported 50% checkerboard dither though, which looked odd when animated. I toyed with some ideas on how to improve upon that and discussed them within our demo group, but in the end the decision was to not use dithering.

PAL vs NTSC perhaps?

For the Mega Drive/Genesis the framerate depends on the region, matching the local video standard. The European Mega Drive uses PAL with 50Hz.

As the biggest part (but not all) of the demoscene is based in Europe, most demos target PAL hardware. The same is true for our demo group. NTSC ports can be very difficult if not impossible as PAL often does have a slight advantage in CPU cycles per frame. This is also the case on the Mega Drive.

Porting the polygon renderer shouldn't be a problem as it renders in an off-screen CPU RAM buffer. In the worst case it would have to skip more frames, having a lower effective framerate.

A lot of the other effects have very critical timing though. I've been told that porting some of them to NTSC is just impossible.

There is a little more CPU time, but the extended vertical blanking interval means there is a huge difference in video memory bandwidth, which is critical for a long DMA transfer from 68000-bus memory to VRAM through the Mega Drive's VDP.

60Hz V-blank DMA: 7524 50Hz V-blank DMA: 17622

That's at 320x224 resolution for both. I don't know how much this affects this one demo in particular, but for other things it can be a little annoying sometimes to be bandwidth-starved.

For this project I don't really have to say much about the rust side of it. There were no surprises. The only thing special I can think of is the excellent cross-compiling support. That came in handy as I had to produce windows binaries for the 3D artists.