Log In  


Cart [#20068#] | Copy | Code | 2016-04-29 | Link


Here's my first game for Pico-8 and it's a Pole Position/Enduro/OutRun derivative. You might have already played it on my itch.io page.


  • Day and night
  • Three landscapes
  • Obstacles and jumps
  • A strict time limit
  • See how well you did in the course map overview
  • Really messy source code
  • Terrible sound

I wrote something about it in my blog and if you have something to ask about it I will gladly answer here.

Edit: I'd like to mention I used the ord() function found here, it was a lifesaver.

Update: Now saves high score only when returning to title screen, would continuously write on disk otherwise (due to changes in 0.1.6)

arcade racing
P#19673 2016-04-10 03:49


Oh, and I know there is a game called PicoRacer-2048, I only noticed that after I posted the game on itch.io and, well, at that point it was too late. So it's not an intentional ripoff, just lack of imagination.

P#19674 2016-04-10 03:50


clearly, I think it's one of the very best PICO-8 game ever released!

sorry, I have to play again! :D

P#19689 2016-04-10 17:45


I love it.. I had played it on itch.io originally and it's nice to see it on here. It's alot of fun, well done.

I really enjoyed reading the post on your blog, very nice write up and very informative.

P#19691 2016-04-10 17:51


Thanks! I think there is much room for improvement, though. At least for gameplay, the sprite bank is 95 % full already. :)

P#19705 2016-04-11 03:12


This is terrific! It's really polished and you packed in an impressive amount of visual variety. The little touches make a big difference, like the custom fonts and the scanline dithering. (And the football. Of course.)

Thanks too for the detailed writeup, those were great insights into the design. Interesting what you noted about pico-8 calculating sprite rendering time based on area, could you expand on that? Is that just a consequence of the internal scaling operations, or does there seem to be some arbitrary delay being applied there?

P#19707 2016-04-11 04:29


I'm glad that the article had some value. Thank you. :)

Well, I might be talking out of my ass here, but different API functions have different "execution time" and for sspr() it varies based on the draw area. IIRC spr() has a bit faster exec time for similarly sized sprites, not sure how much of that difference comes from having to use more Lua tokens for the extra arguments and so on and how much comes from the actual sspr() call itself.

I doubt sspr() and spr() do anything differently internally (i.e. an additional layer of Lua code doing the scaling and drawing), I would guess it's just one SDL_RenderCopy() call in both cases plus a delay based on how many pixels were drawn.

But that's just my guess, the truth might be more complex.

P#19710 2016-04-11 05:24


I'm just speculating here myself, but I'm doubtful that the pico-8 draw APIs use SDL operations directly - both because they need to handle index-based transparency and recoloring, and because pico-8 exposes the framebuffer as directly addressable memory in its own tightly-packed indexed format.

That would otherwise involve frequent translation to and from hardware texture formats - which seems like a lot of decidedly un-retro hassle for something that would have more 'authentic' performance quirks if it were handled in software, with a final translation from framebuffer memory into an SDL texture for rendering to the screen.

My own guess would be that pico-8 does API draws in software and imposes a delay on each framebuffer pixel write to make larger coverage take longer. There's bound to be more going on than just that though, since it's still slower to draw a 16x16 sprite than to draw a 16x16 color rect.

P#19711 2016-04-11 06:49


Hmm, that's a good point, you're probably quite correct. Didn't remember the whole memory map and 4-bit pixel thing going on.

P#19714 2016-04-11 07:22


PICO-8 does have arbitrary delays, it helps to the Fantasy Console idea and also would make sure that you don't get silliness like "This cart requires a 5GHz computer"

P#20072 2016-04-29 22:54


Yes I did play it on itch.io and thought it was very slick!

Actually the part I'm most curious about is the engine sound - how does it scale up and down dynamically with the speed of the car? I expected you to have a different sound effect for each pitch of the engine but I didn't find any such sound effects... so is it possible to send data directly to the Pico-8 sound device??

P#20077 2016-04-30 03:51


You can poke the memory at 0x3200-0x42ff to modify the parameter of a sound effect. You can see this in the following lines:


This modifies the sound effect at index 2 according to the speed of the car.

P#20085 2016-04-30 18:32


There are indeed 'artificial' costs assigned to the internal draw operations. For spr() it's around 1 Lua vm instruction per drawn pixel, and sspr() it's 2.

@kometbomb thanks for the excellent write-up. Apart from being an entertaining read, it also revealed a bug in the draw cost calculations that is now fixed in 0.1.6 -- as you pointed out, sspr() wasn't properly taking clipping into account, so drawing would cost the same even if they were mostly clipped.

P#20105 2016-05-01 18:51


@Zep: Nice to hear that I could help improving this awesome toy. :)

My frequency setting code actually overwrites data in the instrument (i.e. other than the frequency/note param) because the different parameters (frequency, waveform etc.) share the same bytes. I ended up just fiddling the numbers until it sounds at least somewhat like an engine.

I vary the frequency so that it's basically doing a really fast arpeggio, as you can see the above code. The 1.5 multiplier is there so that both notes don't change at the same time when tach goes up a notch, giving an illusion of more than 32(?) different frequencies.

P#20127 2016-05-03 11:43


<3 this game

P#20185 2016-05-05 04:13


Thanks for the engine sound explanation... that's mad!

P#20276 2016-05-07 07:19


Really good article, I enjoyed reading it :)

The only thing missing are small .p8 (like in the spaceman8 article), showing the techniques used.

Because it's one thing to understand a concept and another to be able to write it down. I think experienced coders won't have this problem, but this limits the reach of the audience who could learn from it.

P#41140 2017-05-30 16:54


Nice that you found it enjoyable, thanks. :)

I guess the article was more about the general ideas than execution. It's quite hard to explain something to someone who's not very familiar with e.g. basic 3D math and such, since you don't want to simultaneously explain how to translate points and also use some PICO-specific tricks to draw a road.

But maybe some very basic 3D tutorials might be fun to write! I know I enjoyed reading and playing with those back in the day.

P#41431 2017-06-09 03:04


Yeah! i loved to read about those pseudo 3d effect,

It's really close to the pico-8 philosophy to make the best with the limited resources you have ; "our hardware can't handle 3d? no problem let's simulate something that looks close to it!"

And even today those super scaler games looks nice (not sure it's nostalgia kicking in?).


An article about basic 3d would be awesome :D

I found really few ressources trying to understand how it worked, while trying to decode the 3d checkboard tweetcart of Morgan3d: https://www.lexaloffle.com/bbs/?tid=29061

and your post: http://kometbomb.net/2016/04/03/how-does-pico-racer-work/

P#41541 2017-06-11 05:26

Log in to post a comment


New User | Account Help
:: New User
About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2017-06-26 10:21 | 0.195s | 1835k | Q:32