Author Topic: [C] F-Zero : trackSpire  (Read 31140 times)

0 Members and 1 Guest are viewing this topic.

Offline squidgetx

  • Food.
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1881
  • Rating: +503/-17
  • rawr.
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #15 on: January 04, 2013, 10:43:00 pm »
That's looking pretty awesome! Is it possible to run it at a higher resolution, or does it slow down too much?

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55847
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #16 on: January 04, 2013, 10:54:01 pm »
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?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF



Official Website |T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: [C] F-Zero : trackSpire
« Reply #17 on: January 04, 2013, 11:08:34 pm »
@squidgetx in the screenshot I draw pixels 2 by 2, because drawing each pixel make the game so slow that it's unplayable (yeah DJ_O, 4 times slower).

For now I use a giant raw bitmap as a map, because I can just pick up a pixel and display it - the color has the exact good format.

What I planned is to encode each pixel of the map with 4 bits (instead of 3 bytes with the actual map). The main idea is that a pixel can either be a colour or a pixel of a texture. This difference is set using the actual value of the pixel. What I planned is :

If the 4-bits value of the pixel is lesser than 4, fill it with the corresponding colour of a 4 colours-palette.

If it's from 4 to 15 inclusive, then display it as a pixel of the corresponding texture loaded from a 12 textures array.


This should divide the size of the maps at least by 6 - and the original SNES Mute City map will still be more than 2Mb O.O
« Last Edit: January 04, 2013, 11:10:33 pm by Matrefeytontias »

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55847
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #18 on: January 04, 2013, 11:09:44 pm »
Do you plan to switch to tilemaps using 16x16 tiles to form it? Because that might make collision detection easier then.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF



Official Website |T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: [C] F-Zero : trackSpire
« Reply #19 on: January 04, 2013, 11:14:29 pm »
I don't think so, because the shape of the track doesn't seem to fit for a tilemap - it has too many curves and stuffs.

And for collision, I noticed that a colour that was in a certain part of the map (by part, understand the road, the plasma balls on each side etc) was not in any other. So to make collision detection, I can just test the area of the ship and see if it contains a certain colour or not. And I still can use the 4-bits identifier of the pixel to detect collision - faster than accessing the scren.
« Last Edit: January 04, 2013, 11:15:46 pm by Matrefeytontias »

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55847
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #20 on: January 04, 2013, 11:19:01 pm »
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?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF



Official Website |T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #21 on: January 07, 2013, 06:05:24 pm »
What method are you using to render the mode 7 effect? Also, you should consider implementing mipmaps, it will reduce the noise you see in the distance.

http://en.wikipedia.org/wiki/Mipmap
« Last Edit: January 07, 2013, 06:08:04 pm by t0xic_kitt3n »

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55847
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #22 on: January 07, 2013, 07:57:44 pm »
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.
« Last Edit: January 07, 2013, 08:55:23 pm by DJ_O »
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF



Official Website |T-Shirt store | Reverbnation | Facebook | Youtube | Twitter | Spotify

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: [C] F-Zero : trackSpire
« Reply #23 on: January 08, 2013, 09:25:55 am »
@t0xic_kitt3n since I want to save space, I prefer keep the display as it is (which I consider not that bad).

@DJ_O with hoffa's recent port of SDL_image, a map like the original SNES Mute City (14MB in raw bitmap) will only take 500KB once converted in gif and reduced from 6880*3488 to 3440*1744 (and I'll make it to keep a good display).

Offline ElementCoder

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 611
  • Rating: +42/-2
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #24 on: January 08, 2013, 10:25:37 am »
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 :(

Some people need a high five in the face... with a chair.
~EC

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: [C] F-Zero : trackSpire
« Reply #25 on: January 08, 2013, 10:36:50 am »
Matref: using tilemap definitions + tile images to encode tracks, as mentioned by DJ_O, could save a bit of space over pre-rendered images (and might help with collision detection) :)
It's just a slightly different tradeoff: the permanent memory consumption (space taken in the FS) would probably be lower; the runtime memory consumption would be roughly the same; the setup time (generating the track's image) would be a bit higher, though it's not very time-consuming to blit a bunch of aligned images.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: [C] F-Zero : trackSpire
« Reply #26 on: January 08, 2013, 10:39:00 am »
@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 :P (jk, I'll certainly do that, but later)
« Last Edit: January 08, 2013, 10:39:39 am by Matrefeytontias »

Offline Lionel Debroux

  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2135
  • Rating: +290/-45
    • View Profile
    • TI-Chess Team
Re: [C] F-Zero : trackSpire
« Reply #27 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 ;)

Quote
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.
« Last Edit: January 08, 2013, 10:55:41 am by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.
Co-admin of TI-Planet.

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: [C] F-Zero : trackSpire
« Reply #28 on: January 08, 2013, 11:00:16 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).

Offline Nick

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1166
  • Rating: +161/-3
  • You just got omnom'd
    • View Profile
    • Nick Steen
Re: [C] F-Zero : trackSpire
« Reply #29 on: January 08, 2013, 12:15:30 pm »
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.