Hey !
You may have already heard about virtual sprite from Poom devlog ( @freds72) and one high memory implementation from @pancelor. Here is my take.
As a reminder, the principle of virtual sprite is to have a kind of "palette of sprite" which allow to draw more sprite than the 256 native built-in ones.
The cartridge contains 4 PX9 compressed spritesheet that are unpacked when the cartridge boot. Then a bunch of benchmark are launched to test the LRU Cache with differents configurations.
Implementation overview
I implement two types of LRU cache and a benchmark to challenge implementations. With LRU cache, the oldest sprite are replaced by the new ones when cache is full. Easier to say than to do ! To keep track of sprite age, I use an queue, implemented with LUA tables.
I use a 2 implementations of the lru age queue, one with the native del, deli, add function, and one with customs ldel, laddlast function relying on queue/linkedlist principle. My goal with linked list is to avoid shifting all table elements and reduce cpu cost of del/deli function. These two additionnal functions costs 134 tokens, maybe it can be improved...
I also implement one type of cache that handle 8x8 sprites, (256 in spritesheet and 1024 virtuals) and another with 16x16 sprites (64 in spritesheet and 256 virtual).
8x8 sprites exactly match what pico8 can do with spr function but it has to deal with heavier table to handle sprite age in cache. 16x16 sprites are... bigger which can be a pros or a cons, but in both case they reduce the size of the cache and should reduce overhead to handle them. It is the choice that @freds72 has made in poom.
Finally, I added a FIFO policy to the cache, which has the advantage of being simple and needs low cpu. We can see if this is an interesting approach.
Results
To comment the results, I would say that 16x16 sprites are handled better, because even if pico8 draw less sprites per sec, each sprite is 4 times bigger. That said you can multiply the number of sprite per second and you will have more 8x8 sprites.
We can also see that with 16x16 sprites, the overhead of native del function is not to much of a problem.
With 8x8 sprites, you have a huge gain with linked list queue, because we never shift the whole 1023 elements in the age queue. So if can you afford the 134 tokens and have to deal with 8x8 sprites, this choice is interesting.
The worst choice to make is to deal with 8x8 sprites and native del function to handle lru cache. I think in this case the overhead simply discard the benefits of the cache.
EDIT: With the vspr function provided by @JadeLombax, we can see that LRU implementation overhead never provide better results. Even with high cache hit ratio, it barely reach the performance with cache. It means that sprite copy is already fast, so if we want to handle a kind of cache to avoid double copy for each sprite drawing, we need a low overhead cache mechanic. So I try a FIFO cache.
If you want to test your own functions
On tab 2, there is a table for benchmark declaration. The table benchs contain entries where :
nis the name of benchmark,fthe function to call to draw a sprite from high memory. The Function as 3 parameters, fun(sprite_nb,x,y). Sprite number is the absolute number of sprite among the 4 highmemory bank, with 8x8 sprite, it can be 0-1023.dis the data preset. I use 4 presets, randomly populated 32767 sprite index at boot time.
ben8andben8fare for 8x8 sprite. ben8 can have sprite with index 0 to 1023, which imply a ~25% hit ratio as it is pure random.ben8fonly have 0 to 255 sprite index, which implies 100% hit ratio.
ben16andben16fare the same for 16x16 sprite.ben16has ~25% hit ratio andben16f~100%
local benchs={
{n="jadelombax",f=vspr,d=ben8},
{n="vspr8memcpy",f=vspr8nc,d=ben8},
{n="vspr8lru ",f=vspr8,d=ben8},
{n="vspr8fifo",f=vspr8fifo,d=ben8},
{n="vspr8lru ",f=vspr8,d=ben8f},
{n="vspr8fifo",f=vspr8fifo,d=ben8f},
{n="vspr16lru",f=vspr16,d=ben16},
{n="vspr16fifo",f=vspr16fifo,d=ben16},
{n="vspr16lru",f=vspr16,d=ben16f},
{n="vspr16fifo",f=vspr16fifo,d=ben16f},
{n="vspr16nc ",f=vspr16nc,d=ben16},
} |
So you can add your function and declare it in the benchs, it should work :)
6 comments
Looks like I finally made something with voxelspace terrain recent studies https://www.lexaloffle.com/bbs/?tid=35654
This Race The Sun partial demake is my first entry to #TweetTweetJam N°3, in Pico8 with a 560 characters limit !
The Goal
You must go as far as possible, with no sun :D
Controls
Use < / > arrow to move your ship
Ctrl + R to restart after crashing
Good luck and have fun !
At first, I saw a demo where a student implement a voxelspace algorithm with compute shaders. Voxelspace is a tech invented in the '90s by Kyle Freeman at Novalogic to render landscape. Games like Comanche, Deltaforce used it. It was based on heightmap and voxels, not polygon. I don't know much about shaders, but I know it is better at rendering polygons. So... I try to understand how all this work and here is the result: my voxelspace implementation on Pico 8
With freds72 optimization
first release
Here is an implementation of voxelspace rendering algorithm, with a little perlin noise map generation. Features :
- Generate a 128x128 height map in memory,
- Generate a color map base on height with some noise (I could also use height difference to better show cliffs and flat grounds, maybe latter),
- colors fadding with distance
- We can move, with player one controls, zoom map with X (or M), strafe with player 2 left and right (s,f)
I don't know where it will go, or if it will become a game, but here is my work :D Have fun tweaking or exploring !
for a more advance experience, you can check electricgryphon work https://www.lexaloffle.com/bbs/?uid=10844
PicoCyberbank is a cyberpunk remake of West Bank / Bank Panic by Damien Hostin, on twitter yourykiki (The Lurking Engine)
Goal :
you must help the bank collect the credchips by shooting the baddies and survive 9 days ! Beware some people are not as they seem to be at first !
Controls - keyboard or gamepad :
Use arrows to shoot left center or right
Use button 1 (x) or 2 (c) to change the doors you are looking
Behind the scene
This project was less complicated than Brutal Pico Race, I designed it to work with my kids... But actually, it was way too complicated for my little beginners, and they gave up after coding the open/close system for the doors :D It is also why there is a lot of functions in french. They came back for beta testing !
I keep some interesting parts for myself, such as the plasma doors, using the PX8 compression and a coroutine queue to load people graphics at runtime, a bunch of sprite picked up randomly to build the people, and little hidden surprises on the intro scene to reflect how far you went in the game !
Once again, great thanks to the pico 8 community !
Have fun !
Brutal Pico Race is a fast and raw futurist racing game on Pico8 by me, Damien Hostin, on twitter yourykiki (The Lurking Engine)
I wrote a little insight on my blog in two parts, you can find it here and here
Choose one ship out of three class, choose a track and try to finish first ! You can also challenge a friend, alone or with AI, in split-screen mode !
Brutal Pico Race features :
Single player or two players in splitscreen
- 3 class of ships -heavy -normal -light with different speed curve
- 6 tracks
- 3 AI levels
Controls - keyboard or gamepad :
Menu
Use arrows to choose your ship / track / AI level
Z/C/N to start
When 2 players is selected, the second player can choose his own ship directly with S/F
Game
Player 1
- steering : arrow LEFT, arrow RIGHT
- accelerate Z/C/N, break V/X/M
- boost arrow UP
Player 2
- steering : S, F
- accelerate TAB/Z, brake Q
- boost E
after race
- up/down to see the other ships running
Great thanks to the pico 8 community (Zep, @p01, @FSouchu, @Felice_Enellen, Morgan...), all the followers who help me on the project ! And many thanks to my wife and children for the playtests and ships/tracks contribution !
If you like this game, don't hesitate to support it ! This will help me doing more ;)
Changelog
1.0.4 : (with pico8 0.2.1)
- @fsouchu subpixel polygon filling
- slightly better drawing distance in 2 players mode, 12 road blocks instead of 9
- drafting, stay long enough behind an opponent and get a boost
- Satisfying HUD design :
- formatting lap time correctly
- reduce health, boost and speed bar to center the pilot face :)
1.0.3 :
- We can finally die !
- Fix live rank
- Fix a bug where boost had not influence on centrifugal force, so now be carefull with boost spamming !
- Add chronometer and timeboard (best race time per track and per AI skill)​
- Add 3 tracks
- Add a 2 channels music for single player race
- Add controls helps
- Adaptive difficulty on boost, AI use less often boost when you're last or 3rd
- Change ship names
1.0.2 :
- Increase difficulty
- 3 kinds of bots
- Better end screen
- Changing camera after race
- Other ship progress on left
- Cooldown for ships collision damage
- Changing track loader, room for 3 new tracks
- Better boost visual fx
- Fix boost sound fx in splitscreen
- Change morgan3d heapsort with triplefox's shellsort
1.0.1 :
- first public
- Changed rasterizer for @p01
1.0 :
- Initial version
