I think it might actually slow it down a lot (about 4 times slower), but one thing he could do is have the first 1/3 of the screen show up at max vertical resolution and the rest remains pixelated as it is. Vertical resolution should remain the same, though.

However, from the 1 MB Mute City file, I think for mode 7 he's actually displaying a giant bitmap rather than a tilemap. I wonder if a real tilemap + map engine would be faster than displaying a giant tiled pic?

Do you plan to switch to tilemaps using 16x16 tiles to form it? Because that might make collision detection easier then.

Ah ok I see. If you can use the color you're talking about for collision that is fine, though. In case you are worried that cars going too fast might skip over that color, then you can maybe make that color a bit wider maybe if it doesn't destroy the map look.

Just make sure the game doesn't end up too big, though. Maybe a PNG -> BMP decompression routine or something?

the shape of the track doesn't seem to fit for a tilemap - it has too many curves and stuffs.

Actually one thing: the original SNES F-Zero used 8x8 tiles for the tracks. I doubt collision detection and curves were as complex as they look like, considering the limited SNES hardware. Basically any tile that is less than half a block/road side is flagged as road tile, while everything else is flagged as solid tile.



The above are the tiles for Mute City 1. To cut down on the amount of tiles you could also simply eliminate those complex curves entirely. I doubt they're really that necessary anyway when you already have 45° angle blocks.

But if you manage good compression from big images, then I guess they can be used as well. You could also easily modify them to have stuff not seen in the SNES F-Zero too.

Wow looking good there! Those were some good times Too bad I just upgraded to OS 3.2 so I can't test it atm

@ElementCoder : thanks I would recommend to wait a bit before test it though

@Lionel Debroux : I can't blit a bunch of aligned images, I need to transform and blit separately each pixel of them. And I'm way too lazy to design all the tiles and re-design (again) all the maps (jk, I'll certainly do that, but later)

Quote

I can't blit a bunch of aligned images, I need to transform and blit separately each pixel of them

And precisely, for generating each pixel of the large image (pixels which you will, indeed, later transform and draw separately), you could use tilemap definitions + tile images

Yeah I know that, but now that I think of it, using tiles is slower than parsing a whole map, because in addition of the initial operations that applies to a large map you'll have to find, load and apply calculations to pixels of different tiles (things that you don't have to do with a single image). Of course it saves size, but make the program slower. I think I'm better with a single image per map (that doesn't mean I can't change my mind tho, if I optimize my program to go fast enough maybe I'll have both speed and lightness).