dhostin [Lexaloffle Blog Feed]

Benchmarking virtual sprite with lru cache

Sun, 01 May 2022 22:21:19 UTC

Hey !

You may have already heard about virtual sprite from Poom devlog ( @freds72) and one high memory implementation from @pancelor. Here is my take.

vsprbench

by dhostin

[Click to Play]

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 :

n is the name of benchmark,
f the 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.
d is the data preset. I use 4 presets, randomly populated 32767 sprite index at boot time.
ben8 and ben8f are for 8x8 sprite. ben8 can have sprite with index 0 to 1023, which imply a ~25% hit ratio as it is pure random. ben8f only have 0 to 255 sprite index, which implies 100% hit ratio.
ben16 and ben16f are the same for 16x16 sprite. ben16 has ~25% hit ratio and ben16f ~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 :)

Race no sun - Tweettweetjam 3

Sun, 17 Nov 2019 14:50:08 UTC

racenosun_560

by dhostin

[Click to Play]

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 !

Voxelspace experiments

Sun, 13 Oct 2019 19:50:29 UTC

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

voxelspace_ykk

by dhostin

[Click to Play]

first release

voxelspace_ykk

by dhostin

[Click to Play]

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

Pico Cyberbank

Sun, 21 Apr 2019 21:58:39 UTC

picocyberbank_100

by dhostin

[Click to Play]

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

Sun, 08 Jul 2018 04:53:35 UTC

Brutal Pico Race 1.0.4

by dhostin

[Click to Play]

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

Brutal Pico Race 1.0.3

by dhostin

[Click to Play]

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

Brutal Pico Race 1.0.2

by dhostin

[Click to Play]

1.0.1 :

first public
Changed rasterizer for @p01

Brutal Pico Race 1.0.1

by dhostin

[Click to Play]

1.0 :

Initial version