2DArraymessing around with the playdate again
getting some perspective
getting fancier!
i'm a chronic bayer-hater so i replaced the structured dithering with blue noise, and to me it looks a lot nicer. runs at full speed on the real device, too!
starting on player-controls
the camera is following behind a car...but you can't really tell because the car isn't rendered yet
starting to draw a car and some tire tracks (the car is temp-art for now)
a floor
this drops my fps to 40 (max possible on playdate is 50) but i'm hoping/assuming i can find more stuff to optimize. worst case, locking the game to 30fps seems like it would be OKAY, and maybe even the more sane choice for a handheld (to save on battery power)
the real ideal thing would be if you could pick between 30fps (power-saver mode) and 50fps (try-hard mode)
better floor (now with ambient occlusion!)
back up to "usually 50fps" on the device, sometimes dips down to around 47
working on a drifting mechanic
it needs more tuning but i'm absolutely stoked about it already
starting to draw a proper car - i did this first version in a really basic way so i thought it'd tank my performance, but it turns out it still stays at like 45+ fps on the device. not bad!
i'm very bad at lowpoly modeling so the car accidentally looks like an old-timey beater, but i think that's sorta funny so i'll probably try to keep that vibe
night sky - drops me to about 40fps on the device, but i think i can still find more room to optimize
would be nice to add some clouds or something...
adding some presentation at the start of the race, and some basic timer/scoring stuff
all hail lobster font, lobster font will lead us to salvation
made a fancier finish-line and now i'm gonna need to write my own triangle-rasterizer instead of relying on the playdate sdk's fillTriangle() helper - i'd like to get rasterized meshes to use the same dithering as the walls/floors/sky, and also i need the meshes to get occluded by walls
custom rasterizer which allows the finish-line banner to be occluded by walls
working on replay recording/playback - yes, the clip looks the same as the others in the thread, but it's a pretty good run since i was retrying the map. if you think "i see places where the racing line could have been improved" then the game is working, lol
replay data is quite small: stores keyframes containing a bitmask of user-input states (one byte), along with how many frames you held that state for (one byte). a "normal" 30 second replay tends to be around 200 bytes
fsouchu@2DArray hu… that would assume perfect frame alignement between runs
@fsouchu yep! floating point is deterministic and the app is single-threaded, so (at least as far as i've seen...) the only thing that's unpredictable is the user-input. i wouldn't be surprised if the simulator and playdate produce replays which are incompatible with each other due to compiler differences...but i haven't serialized any replays, so i haven't seen that happen yet lol. if it turns out to be a problem, i can resort to a heftier format!
@fsouchu (and crucially, the app is using a fixed tick-rate, not a variable physics-step!)
@2DArray I suspect you have no lua? cause I find my game to be highly unpredictable in term of perf (eg not a flat line for a static scene)
@fsouchu correct, all C! but yeah even when the performance is variable, the game just moves slower instead of using a variable deltaTime (I'm now assuming I'm gonna lock to 30fps at some point because I can't stop adding visual stuff, so I just need to make sure it's always able to run faster than that - but even if it was a problem, the sim is WAY faster than the rendering, so it could do a multi-stepping fixed-tick for the physics whenever it was dropping frames)