« previous next »
Pages: 1 2 3 [4] 5 6 ... 9   Go Down

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

0 Members and 1 Guest are viewing this topic.

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 #45 on: January 09, 2013, 05:04:41 pm »
I'll just go with pixel testing, I want to have a respectable accurance with collisions.
Logged

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #46 on: January 09, 2013, 05:08:16 pm »
Yeah that's what I mean NIck. The SNES processor isn't even as fast as the TI-83+, let alone the 84+. Collision detection checks are even scrapped sometimes to gain speed, such as when Mario jumps backwards in a corner just below ceiling blocks when crouching, which, as a result, can let you go through walls.

And in most RPGs on the NES/SNES, if you see a tree or bush, you can't even walk right next to it sometimes if the tree doesn't take the entire tile size. Add to that the games where you can't walk behind walls such as Final Fantasy IV. Of course on a Nspire he has more processing power for a game like F-Zero but doing collision detection by tile as complex as it should be would be a shitload of work, with about 128+ if/then/else blocks.

What I suggest is pixel-test for walls, but tile collision for dashes, finish line and jumps.
« Last Edit: January 09, 2013, 05:09:10 pm by DJ_O »
Logged

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 #47 on: January 09, 2013, 05:13:46 pm »
Yeah, I think that's the best way to do this because walls can be one or a half of a tile, when the finish line, dashes, jumps and power regenerators are always a full single tile.
Logged

Offline hoffa

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 322
  • Rating: +131/-13
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #48 on: January 09, 2013, 05:15:28 pm »
Quote from: Matrefeytontias on January 09, 2013, 05:04:41 pm
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.
Logged

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 #49 on: January 09, 2013, 05:25:41 pm »
To render the scene, my Mode7 engine does
Code: [Select]
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).
Logged

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #50 on: January 09, 2013, 05:33:23 pm »
Quote from: hoffa on January 09, 2013, 05:15:28 pm
Quote from: Matrefeytontias on January 09, 2013, 05:04:41 pm
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
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.
« Last Edit: January 09, 2013, 05:33:59 pm by DJ_O »
Logged

Offline hoffa

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 322
  • Rating: +131/-13
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #51 on: January 09, 2013, 05:43:54 pm »
Quote from: Matrefeytontias on January 09, 2013, 05:25:41 pm
To render the scene, my Mode7 engine does
Code: [Select]
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).
Alrighty then. In the next nSDL release there'll be optimized versions of get/setpixel functions (as much as they can be optimized) included. You should definitely tell every single one of the floats to fuck off, as IIRC the CPU doesn't even handle floating point operations, so it's all done using integers, meaning slow as hell.

Quote from: DJ_O on January 09, 2013, 05:33:23 pm
Quote from: hoffa on January 09, 2013, 05:15:28 pm
Quote from: Matrefeytontias on January 09, 2013, 05:04:41 pm
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
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.
Yes, but when you have a massive 96x64 resolution...  :ninja:
« Last Edit: January 09, 2013, 05:47:52 pm by hoffa »
Logged

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #52 on: January 09, 2013, 08:30:21 pm »
Why not have a separate collision texture? The Nspire has the RAM to do it. With that you could even have multiple types of surfaces, for example normal track, off-track but still traversable regions that slow you down, and speed boosting surfaces.
Logged

Offline tr1p1ea

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 647
  • Rating: +110/-0
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #53 on: January 09, 2013, 08:49:47 pm »
If you wanted to save space you could still use a 'tilemap' for the collision component of the track. Its never drawn but each component of the track (each 16x16 segment or whatever size you want to use) would correspond to a 'tile' in the tilemap that you can index to see if there is a collision or not.

You could save space even further by storing multiple 'collision tiles' per byte, 2-bits per collision tile would give you 4 possibilities (walkable, medium, slow, collision).

Then again i would still recommend a tilemap for the tracks especially if you have lots of repeating features. Otherwise you are going to be wasting a lot of space.
« Last Edit: January 09, 2013, 08:57:39 pm by tr1p1ea »
Logged
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

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 #54 on: January 13, 2013, 01:19:16 pm »
Update !

Thanks to hoffa for his help with the nSDL and the port of SDL_image to Nspire, now I can use the original tracks from the first F-Zero as gif files (so 800KB instead of 42MB !!!) !



As ever, new screenshot in the first post :) but this time I didn't attached the tns since it's so little progress.

Now I'll work on collision detection, I have enough of going through the walls :P

Also, do you think I should lower the camera a bit or is it ok like it is ?
« Last Edit: January 13, 2013, 02:32:38 pm by Matrefeytontias »
Logged

Offline ElementCoder

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 611
  • Rating: +42/-2
    • View Profile
Re: [C] F-Zero : trackSpire
« Reply #55 on: January 13, 2013, 01:26:44 pm »
Where's the screenshot? I only see the 3 I've already seen :p? I think the camera is fine like this, maybe a tiny little bit lower.
Logged

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

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 #56 on: January 13, 2013, 01:33:36 pm »
Do you know the time it takes to shoot a 4MB-large screenshot, convert it from avi to gif and then upload it ? :P

Anyway, you can see it now :)
« Last Edit: January 13, 2013, 01:34:08 pm by Matrefeytontias »
Logged

Offline deeph

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 138
  • Rating: +6/-0
    • View Profile
    • deeph.servhome.org
Re: [C] F-Zero : trackSpire
« Reply #57 on: January 13, 2013, 02:12:09 pm »
I agree with tr1p1ea, tile-based maps would much more efficient (overall size and ease to check collision/recovery area/starting line/etc...).

And if you only want to handle a big image for your mode 7 engine, you can still generate it before starting races.
Logged

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55943
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: [C] F-Zero : trackSpire
« Reply #58 on: January 14, 2013, 01:55:16 pm »
Will you get rid of the huge black area on the left side of the road when the race starts?
Logged

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 #59 on: February 02, 2013, 12:02:33 pm »
Bump,

Since I've got some free time recently, I dig in this project again : it's not dead, be sure of that, but I'm having a really hard time trying to make the engine work with integers instead of floats. The accuracy is the main problem I think, so I came to the conclusion that I needed somewhat fixed-point calculations routines. Since I'm bad at maths in fact (experience I don't have), I only can search on the web or ask for it. So if someone wants to help me with that ...
Logged
Pages: 1 2 3 [4] 5 6 ... 9   Go Up
« previous next »