Well forget all that from yesterday, wasted effort.
I've just finished a new workflow solely using the command-line!
this sprite has had no manual touch up - it is the best render result i've had without manual work.
i can now quickly iterate, tweaking the model to make sure elements render nicely in the final sprite.
The beauty of the command line!
If I run all the renders one after the other, maxing out a single CPU core (100% CPU usage): ~17 seconds
But with a simple & I can run them in parallel (well, one process each) using all 6 CPU cores (~450% CPU usage): 10 seconds
I hope you're safe and well and wish you a great 2021. I'm back at it, and am confident this year will be the year of Daily Driver and more besides!
Recent work on the game includes improvements to the physics of in-game objects and creation of yet more vehicles and levels.
"The car's the star", as they say, so I have sunk untold hours into both the physics and graphics of many different cars to ensure that the depth of control and animation is enough to hold a players interest for the time I hope they will spend with my game. There's no final vehicle line-up, as often some cars don't look unique enough after the first rough model is tested in the game. But these two are keepers!
Interestingly, both these vehicles show off one aspect of the game that I've not really talked about so far: reference and nods to classic games. Here we can see an RC car (whose antenna wobbles!) that is a nod to games like Re-volt, RC Revenge, Smash Cars, RC de Go!, Excite Truck, RC Pro-Am etc. And the forklift is a nod to Shenmue and the infamous New Yokosuka Harbor District.
BONUS
I forgot to post my logo tests from December in this thread. These actually aren't used in the game exactly like this but that's a post for another day.
English uses Futura Bold Oblique.
Japanese uses a custom typeface of my own.
Influenced by all the old Japanese PC magazines I've read and games I've played/swooned at over the years.
Do you have a new .pdx for the latest firmware?
Not quite yet, Brian. Very soon though!
I want to finish a couple of small bits. Then I'll build the latest code. Previously I've been lazy and recompiled the same old snapshot from end of July.
(and now for something completely different)
Sparrow-Solitaire.pdx.zip (231.6 KB)
This is how things looked with hastily ripped and converted placeholder graphics, before I drew my own graphics from scratch.
I'm (mis)using playdate.menu:addOptionsMenuItem to provide (kinda) sub-menu options:
Added some satisfying mahjong tile sounds
all with slightly randomised pitch so they don't sound repetitive
Board Games a-go-go!
Mancala (work-in-progress, before sprites and animations)
Following up on the ability to display a shade of grey by flashing pixels very quickly (click the reply arrow above to see message this one is replying to; and some chat on the Discord) here is a demo!
Shadow.pdx.zip (19.0 KB)
controls:
notes:
it looks like below, but ball shadow is flashing to make it look like grey (on device!)
ps: i didn't have time to create any new sprites so you have a small ball plus shadow, but the code will cope if you replace the 3 cell image table with something of a different dimension
From: Daily Driver: Pre-rendering Ranger ⌘I Get Info
I had a bit of a eureka moment with my car shadows in Daily Driver.
Since very early on shadows in Daily Driver have just been simple rectangles: one size fits all, rendered from a single 3D model, and post-processed to add dithering. MVP, you know? Over time I decided to do multiple shadows, one each for short cars and long cars.
Sometime later I threw caution to the wind and decided to render per-car shadows. However, the OpenSCAD projection() command that I was using was so slow! In fact it zapped my desire to finish implementing the feature. Instead, I let it sit for many months.
Recently, I picked things up again to get the a new trailer and demo out. And then it hit me, that if I flatten a car on the z-axis—as if Looney Tunes dropped a heavy weight on it—then that flat thing will be enough of an equivalent to a shadow for my use. So I did just that and the results were great, and more importantly very quick to render!
So I went all in and decided to not only render one shadow per-car but to render shadows for each individual frame. So now the direction of the front wheels and details of the body shape are reflected in the shadow. It might sound like a small thing but it really makes a big difference. You can see old vs new shadows in the image carousel below.
It’s in situations like these that I’m really proud I put a ton of early effort into the tooling and build process that generates my sprites.
Result!
From: Daily Driver: Makefile ⌘I Get Info
During the shadow rendering changes I was generating new sprites quite frequently, and I quickly realised that my mess of shell scripts just wasn’t a good enough system to be used in anger. I would have to call my scripts manually, with a variety of parameters, and remember a bunch of stuff unique to each script.
So I spent a day converting the script system into a Makefile, with rules for:
I also improved the scripts to make them touch all their output files with the last-modified timestamp of the original 3D model, meaning the scripts could become self-aware and know which output files are up-to-date and which need re-rendering.
With this system I can generate a full set of renders of all vehicles in ~minutes, or render just a single car in ~seconds. This is such a huge time saver and has enabled me to iterate on car designs more quickly and easily than ever before. I’m already seeing the gains in much better sprites.
Believe it or not this was the first Makefile I’ve ever needed to write from scratch. I knew enough about them to know that they would be a good fit for this task, and it was fun to learn more about something I only knew in passing.
I love this! Genius. 
From: Daily Driver: Pseudo-HDR ⌘I Get Info
I love OpenSCAD “the programmer’s solid 3D CAD modeller”, despite its idiosyncrasies. One of the quirks that causes me most pain are the lack of controls for scene lighting in the Preview render. Unfortunately, I use that very Preview render as my main output!
This lighting issue manifests as shadows cast on the model. As I rotate the car some white “highlight” elements become darker. At this point the model is made up of many more shades of grey than I’d like.
The problem escalated when I take the Preview renders and convert them to 1-bit monochrome (black and white) ready for display on Playdate . I use a simple threshold conversion where any pixels darker than the threshold value become black, and any lighter become white. The highlight elements that have been cast in shadow are now grey and in many cases after the threshold conversion they end up as black pixels when they should be white. The net visual result is a loss of detail and flashing elements as they disappearing from the model on certain frames.
My first attempt at solving this problem was to set model-specific threshold levels. This worked to a degree but there were still elements that would flash on and off as the car rotated, with headlights being the most noticeable. Whilst I lived with the issue for a long time it always bothered me as it did make the sprite feel buggy. Deep down I knew that the results could be better. However, looking at the OpenSCAD development roadmap made it clear that any improvements would have to come from me.
Eventually I realised that if black pixels are more reliably rendered then why don’t I take advantage of that and render the model in opposite colours so that the highlights are now black. After rendering I could simply negate the colours in the resulting image and the highlights would become white again. I tried a quick test and the results were good!
Of course this means an additional render stage is added to my workflow, but that’s of little consequence since the Makefile is doing all the hard work. I also had to make some changes to my render scripts so that the normal and negative images were composited together into the final image. The resulting sprites have no flashing elements, maintain more fine detail, and appear a lot more solid as a result. Excellent!
Afterwards it struck me that this process is similar to HDR photography where multiple photographs are combined to increase the dynamic range in the final image. So, just for kicks, I’m referring to this technique as HDR 1-bit rendering .
(Refresh the page so these are in sync)
Old rendering workflow: note the disappearing headlights
New rendering workflow: headlights are present and correct
Foot is back on the pedal!
I've introduced a third colour that can be isolated the same way as the highlights. It allows me to specify details that will be dithered in a pattern of my choice. Here I've used it for the rear/boot grille! Blog post soon.
A new post about how I render models in Red, Green & Blue ...and then split the image into Channels to make it easy to composite 1-bit sprites with a lot of detail and custom dither patterns from a single render.
https://blog.gingerbeardman.com/2021/06/05/channelling-rgb-into-1bit/
How about now? 
It's looking so good!
Yes! Today's the day.
I had tried to get something wrapped up (excluding and stripping out a bunch of stuff) for the update video day, but ran out of time.
Anyway! Here we go:
new build! 14 Aug 2021
Delete any old builds before installing.
Still not representative of where I am right now with the game, I’ve cut a bunch of things, but it shows my progress since the last demo (July/August 2020!). It also includes improvements that I’ve added since I sent my footage in for the update video:
Would love to know your thoughts! Especially regarding the Additional Collisions option.
Teaser Trailer
~60seconds, 462 KB
Controls
Gotchas
Menu
Notes
Debug Keys for game (simulator only):
Controls for editor (simulator only):
Debug Keys for editor (simulator only):
Love it! Is it crazy that I find myself wanting to drive on a larger track? That is, a track that takes up more area than the display.
Not at all, I know what you mean.
Lack of large stages will disappoint some people. Also the fact there are no CPU cars (though ghosts are still on my list).
I had dismissed scrolling levels, as I assumed it would destroy my high frame rate. Though I'm yet to test that hypothesis!
Though I had considered a sort-of Zelda-like transition when you reach the edge of the screen, but I find those annoying. This one I still want to do something with.
The stages in the proper game are more about testing driving skill with various waypoints and objectives that encouraging drifting and manoeuvrability. Rather than going full throttle for any prolonged period of time. Right now the levels in this demo build don't have any of this in so it probably feels a bit aimless (because it is!).
The closest I can think of is Trials where it's about finesse and control rather than full speed (unless you're really good and can do both).
Note to self, more representative levels in the next demo!
