Quote from: Lionel Debroux on January 08, 2013, 10:55:03 am

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).

Can't you store maps as tilemaps, then, at the beginning of the game, draw the wjole map to a certain buffer and you'll only have to deal with one big image ?

Not that I can't do that, but I also want users to be able to create, load and play with their own maps, so hard-coding maps isn't a solution. But for the draw-to-a-buffer thing, I could do that but that takes even more space than a single image map (tilemap + tiles + buffer, instead of only map).

Quote

But for the draw-to-a-buffer thing, I could do that but that takes even more space than a single image map (tilemap + tiles + buffer, instead of only map).

Yup, it temporarily raises the peak RAM consumption, so as to permanently reduce the storage consumption.

And the little bit more RAM consumption shouldn't be a big issue, having less storage space for files/other games is much worse.

If you go for images and re-use F-Zero maps, was the color you talked about for collision detection the black surrounding roads? Because if it's the case, then you might want to change it from a different black tone than the one in the circle tiles along the road, so no collision detection weirdness such as getting stuck inside those balls occur.

In fact I'll go with tilemaps. The whole image can't even be entirely loaded, it's 800K in gif format but 42MB in raw format

So I'll recode the display engine. Updates coming soon

In fact I'll go with tilemaps. The whole image can't even be entirely loaded, it's 800K in gif format but 42MB in raw format

So I'll recode the display engine. Updates coming soon

That sucks, but yeah if you can go with tilemaps hopefully this should make things easier memory-wise in the end (and possibly allow a non-CX version). The only other solution is to only load needed parts of the image at a time but that would be decompressing every frame, which might be slow.

Is tile mapping when you have an array and you draw textures according to the array?

Yep, you have numbers in an array and each number corresponds to a specific tile. Generally the good way to do it is to group all wall tiles together and the floor tiles together, with the event tiles in the middle.

It depends. I doubt SNES collision detection was even this complex. If a tile is half floor and half wall (eg if the wall is left of the tile) it is probably treated as a floor tile on the SNES. Othwerwise they most likely use pixel-test detection, since road edges are black and black isn't used anywhere else in F-Zero maps.

If a half floor/half wall tile were treated like a floor tile then it would mean that half of the tile is treated incorrectly.

Wow, that is one clever remark..
The SNES was not a computing wonder, it is normal that things were as minimized as possible, it's that way, or none at all