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
fsouchu@2DArray did you get anywhere with SIMD rasterization?
@fsouchu nope, lol. i still haven't tried the thing i was talking about at first, but i goofed around a bit with some related-but-less-drastic simd usage, and failed to get any actual speedup (which is what has always happened whenever i've tried to use simd in general)
@fsouchu i did get a nice speedup on the rasterizer by doing that "splat a slice of the dither pattern into an 8-or-32 bit scanline-strip all at once, instead of iterating individual pixels" thing (i already had start/end sub-indices inside each strip, so i did some bitwise shenanigans to create a mask with leading and trailing zeroes, then used that to splat the pattern)
unfortunately, i need per-pixel iteration for wall occlusion, so i can't actually use that 🙃
Alistair Hutton@twitonatrain the dither pattern is storing u8 thresholds (to compare against a pixel's intended brightness), so it's not currently a blittable sprite! I could convert it into several ready-to-go sprites for different grey levels, but I imagine it'd lose some smoothness (especially in the sky, where it's a lot of smooth fades)...but maybe that'll become necessary at some point
@2DArray Ah, see I told you I wasn't paying enough attention. It's all looking lovely though.
@twitonatrain thanks! and honestly your idea is a good one which i've been trying to find ways to incorporate...i might have an avenue to use it in the mesh rasterizer (which does use blittable patterns!), if it can detect that a certain 32-bit slice of a scanline has no chance of being occluded by a wall (which means the per-pixel checks aren't needed there)