Nope, not at all :P in fact it has nothing to do with this program. It's something completely different of the tunnel.
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.
I can't blit a bunch of aligned images, I need to transform and blit separately each pixel of themAnd 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 ;)
And I'm way too lazy to design all the tiles and re-design (again) all the maps :P (jk, I'll certainly do that, but later)OK.
QuoteI can't blit a bunch of aligned images, I need to transform and blit separately each pixel of themAnd 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 ;)
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).So you mean like a different image for every track? won't that be a lot of wasted space? And you'll need an additional array/structure that overlays the track on the image, which could go wrong if there's some misplacing of the overlapping.
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 ?QuoteI can't blit a bunch of aligned images, I need to transform and blit separately each pixel of themAnd 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).
I also want users to be able to create, load and play with their own maps, so hard-coding maps isn't a solution.Hard-coded, but editable, maps in external files ?
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.QuoteBut 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.
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).Are you concerned about file size or RAM usage? The buffer could be dynamically allocated if the former.
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 D: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.
So I'll recode the display engine. Updates coming soon ;)
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.
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..
I'll just go with pixel testing, I want to have a respectable accurance with collisions.I'm not sure if that's a good idea, as pixel operations are never (on any platform) very fast; it could give quite a blow to performance. But what do I know, doing mode7 already involves a lot of per-pixel stuff and it doesn't seem to be that slow.
setPixel(screen,x,y, getPixel(bitmap, textureX % IMG_W, textureY % IMG_H));... Plus some more calculations 14325 times. I don't think that testing 44*16 additional pixels will change anything to the speed :P (moreover, the Mode7 engine uses floats - I'll optimise it later, and the detection engine will be restricted to ints).
Except in some cases on the 83+ (in Axe and TI-BASIC). In TI-BASIC there isn't much difference over using matrices, but in Axe if you need accuracy it's the fastest way.I'll just go with pixel testing, I want to have a respectable accurance with collisions.I'm not sure if that's a good idea, as pixel operations are never (on any platform) very fast
Yes, but when you have a massive 96x64 resolution... :ninja:Except in some cases on the 83+ (in Axe and TI-BASIC). In TI-BASIC there isn't much difference over using matrices, but in Axe if you need accuracy it's the fastest way.I'll just go with pixel testing, I want to have a respectable accurance with collisions.I'm not sure if that's a good idea, as pixel operations are never (on any platform) very fast
uint8 muteCityTileMap[mapHeight][mapWidth] = {
{ first row of tiles },
{ second row },
...
{last row}
};
Ok, but I think there's a background image (the city ?) for the paralax effect, so how will you handle this ? Do you want to use a transparent tile right now (if so, which one ?), or include the city in the map image (if so, I'll have to add its tiles in the tileset) ?Nah that was implemented in the GBA versions of F-Zero. The SNES game had no parralax effect for the city background image.
Programme de démo de F-Zero TrackSpire, clone du F-Zero de 1992 sur SNES pour TI-Nspire ! Au menu, affichage pseudo-3D, courses externes avec éditeur de maps, toussa ! Pour l'instant, l'affichage 3D fonctionne très bien, les collisions avec les murs et l'éditeur de maps aussi, sauf que les deux ne gèrent que des maps 32*24 tiles pour l'instant. Et une seule map, toujours la même, F-Zero.tilemap.tns.
Can the mode7 be taken out from the F-Zero in an independant lib?Yeah sure, I'm writing the game with that in mind. It also offers 24.8 fixed-points routines and tilemap loading from files.
I don't believe this game is using it, but I made a mode 7 engine a while ago, and Hoffa added nSDL and color support.The reason why I didn't use it is that it requires fixed-size tilemaps (too small for my needs) and is very rigid. Mine allows for custom width and height and dynamic tilesets and tilemaps.
http://ourl.ca/18123;msg=282877
No, it' not for me, or more, not for the moment.What background are you talking about ?
Hmmm, what if I redo this background thing here?
That looks amazing :OThanks ;D
Maybe the converter could include some sort of table that would assign a tile among the 16 ones you support to every 256 original tiles ?Rather the contrary I think :P assign several of the 256 tiles to one if the 16 tiles. And I don't do that because I've never found any real aligned map nor the real tileset.
Can you animate the vehicle's floating animation as well as the afterburners?Yep, that's planned.
Ok but why adding much more tiles would make it harder to code ? You could just check the tile on which is the player and compare it to a list of "walkable tiles" (or "non-walkable" if they are fewer), and then check if it's a special tile (acceleration, brake, finish line...).
Rather the contrary I think :P assign several of the 256 tiles to one if the 16 tiles. And I don't do that because I've never found any real aligned map nor the real tileset.
It's mainly because I'm lazy to draw them and that it would be very complicated to make a map on my editor with many many tiles.
I use them, but I meant, they are not perfectly aligned (IIRC their size isn't even a multiple of 8 ).Rather the contrary I think :P assign several of the 256 tiles to one if the 16 tiles. And I don't do that because I've never found any real aligned map nor the real tileset.
I can do that but there will be some things useless after the conversion, for example originally the borders of the tracks are made of 4 tiles... And by the way, the original tileset is already included with the converter and the maps are available here : http://www.snesmaps.com/maps/F-Zero/F-ZeroMapSelect.html .
Well that's the same as what I said: to each of the 256, you assign one of the 16. I just thought it was more logical that way because you basically needed a LUT but assigning several tiles to one can't be done with a LUT.Maybe the converter could include some sort of table that would assign a tile among the 16 ones you support to every 256 original tiles ?Rather the contrary I think :P assign several of the 256 tiles to one if the 16 tiles.
And I don't do that because I've never found any real aligned map nor the real tileset.Ah yeah, that's more of a problem :P.