Category: Game Design

In my last report, I was working on automating the Mac release builds for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

While I’ve made progress, it’s still not going well.

Sprint 2026-MJ_7: Release SDL3 update version

In progress:

• Ensure Mac version can still be built/deployed

Last time, I was trying to get SDL3_ttf to build properly, since it has a couple of dependencies and I was running into trouble getting it to build a Universal Binary properly.

It turned out that I had to do a few things.

First, I needed to have my build scripts call SDL3_ttf’s download.sh so that it would populate the Harfbuzz and Freetype dependencies.

Second, I needed to make sure I set SDLTTF_VENDORED to “ON” so it would use its internal projects that I just downloaded.

Finally, I needed to build out of source. Apparently this matters in this repo (and not in other SDl3_* projects) for some reason.

SET(SDL3_TTF_CONFIGURE_ARGS 
+	-DSDLTTF_VENDORED=ON
 	-DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR})
 
+EXECUTE_PROCESS(COMMAND ./external/download.sh WORKING_DIRECTORY "${PROJECT_BINARY_DIR}/${SDL3_ttf_EXTRACTED_DIR}")
+
+EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E make_directory build WORKING_DIRECTORY "${PROJECT_BINARY_DIR}/${SDL3_ttf_EXTRACTED_DIR}")
 ADD_CUSTOM_TARGET(SDL3_TTF_SHARED_LIBRARY 
 	ALL
-	${CMAKE_COMMAND} "${MULTI_ARCH_ARG}" ${SDL3_TTF_CONFIGURE_ARGS} WORKING_DIRECTORY 
+	${CMAKE_COMMAND} .. "${MULTI_ARCH_ARG}" ${SDL3_TTF_CONFIGURE_ARGS} WORKING_DIRECTORY 
 	COMMAND make
 	COMMAND make install
-	WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_ttf_EXTRACTED_DIR}
-	COMMENT "BUILDING libSDL3_ttf")
+	WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_ttf_EXTRACTED_DIR}/build
+	COMMENT "BUILDING libSDL3_ttf" VERBATIM)

At this point, I could create Universal Binaries for the SDL3 libraries. Whew!

Moving on to the Mac application, I had some work to do. When I last worked on creating a Mac port, all I did was use CMake to generate an Xcode project, then I built it manually in Xcode. As much as possible, I used CMake and a well-crafted Info.plist file to configure the project automatically. What’s nice is that a lot of things are handled already. I can bundle resources, have my “team” show up automatically in the code signing screen, and more.

So what do I need to do to create a Mac release? I need to archive the project, then notarize it through Xcode.

Unfortunately, I can’t seem to get it to archive properly. It seems to build my project just fine, but the main errors seem to be related to the code-signing step, and specifically when it comes to the dependencies on the SDL3 libraries.

When I read the logs, I see:

Command CodeSign failed with a nonzero exit code

And I see it for each of the libraries it failed to sign. For some reason, libSDL3.dylib was fine, but libSDL3_mixer.dylib, libSDL3_image.dylib, and libSDL3_ttf.dylib show “No such file or directory”.

That’s weird. If they didn’t exist, it makes sense that signing would fail for them, but they should exist!

So which directory is it looking in? Because those files are in the directory I installed them to.

The logs tell me that it is looking in an ArchiveIntermediates directory under ~/Library/Developer/Xcode/DerivedData/ and again, the files seem to exist there just fine.

But digging into it some more, I see that libSDL3.dylib is an actual file, while the other three are links to non-existent files.

So what’s going on?

Back to the logs. I noticed before the code signing activity that the libraries were copied from the directory I put them in and placed in the ArchiveIntermediates directory.

BUT! Only libSDL3.dylib had some special treatment to have strip called on it, which resulted in that file no longer being a symlink.

So I once again wished I had more hours to dedicate to this work, because I have questions to answer that probably just require some dedicated effort.

Why is libSDL3.dylib treated differently from the other libraries? I don’t see anything in my CMake configuration or in the resulting Xcode project settings to say why it is doing something special for that library and not the others.

Under “Frameworks, Libraries, and Embedded Content”, I see all of the libSDL3* libraries listed twice. For example, libSDL3_image.dylib is listed with the “Embed & Sign” option, while libSDL3_image.0.2.4.dylib, which is what the libSDL3_image.dylib symlink points to) is listed as “Do Not Embed”.

libSDL3.dylib pointed to libSDL3.0.dylib, yet somehow it seems to be doing the right thing when it comes to archiving and signing.

So what obscure Apple-specific thing changed that made something that used to work before suddenly not work, and what change do I need to make in order to make things behave the way they did before? I hope to figure it out this week.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was working on automating the release builds for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Due to other priorities taking up my time, this effort is still ongoing, and for much longer than I would like.

Sprints 2026-MJ_5 and 2026-MJ_6: Release SDL3 update version

In progress:

• Ensure Mac version can still be built/deployed

To recap, back in October, I started the work of updating Toytles: Leaf Raking from libSDL2 to libSDL3. I had expected that it might take me a week or two at most, assuming I could put in the hours.

It was mostly straightforward and quick to do except for when it came to dealing with libSDL3_mixer, which was significantly different enough from libSDL2_mixer in design that it required some rearchitecting of my own code.

I spent weeks of calendar time on that effort, even though it only represented a handful of hours of game development in all of December, and I finally finished at the end of January.

Next was putting out a new release on every platform that I support. Linux was easy, as I do my development there, and the scripts I use to make a release are mostly the same.

The Windows port took a couple of weeks, although it represented again only a handful of hours of effort, and most of this effort was trying to make sure that the next time I want to cut a release will be automatic and fast.

And here I am, still working on the Mac port, and the story is similar. In the last couple of weeks, I put in only a little more than 5 hours of game development time in. Which is too bad, because I really needed to put some time in to solve this one.

Warning: the following gets a bit technical.

Basically, to release a Mac build, I want to make sure my game supports both Intel-based Macs and the Apple Silicon-based Macs. Apple provides a way to do so with the so-called “fat” binary, or Universal Binary. Basically, it’s one application that can run on either one of the hardware options without the player needing to worry about it.

Of course, to build it that way, you need to explicitly configure the build to support both architectures.

Last time, I did so by manually building libSDL2 and my game on my Intel-based Mac Mini, then copying the binaries to my Mac in Cloud instance of an M1-based Mac, building new libraries there, then using lipo to combine the libraries into a Universal Binary version, then building the game with those libraries.

This time, I don’t want to do it manually, and I don’t want to depend on two different Macs. I want to make this part automated as well.

Now, SDL3’s documentation mentions how to build a Universal Binary for the Mac:

cmake .. "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" -DCMAKE_OSX_DEPLOYMENT_TARGET=10.13

And if I extract the SDL3 source code and use cmake manually, it works just fine.

However, because I wanted to automate this build as part of my own project’s build scripts, I wanted to have my project’s cmake scripts configure and build SDL3 and all of the other SDL3-based libraries.

And it felt like no matter how I tried to make things work, CMake was doing the most surprising wrong things and never the right thing in terms of passing the CMAKE_OSX_ARCHITECTURES variable to SDL3’s cmake scripts.

Now, I think CMake and CSS have something in common: it’s relatively easy to put together something that seems to work but might have fundamental flaws based on misunderstanding or ignorance of how it is supposed to work.

For CSS, things felt a lot less random once I put in time to understand the Box Model. I was no longer randomly trying different values for margins or padding to get things to line up.

CMake, on the other hand, continues to be a challenge for me to learn. The docs are great…once you know how everything works, but until then, they seem quite abstract and confusing.

Anyway, I spent a few hours trying to figure out why the following cmake script would not result in the cmake command above:

SET(SDL3_CONFIGURE_ARGS
    "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64"                                                                                           
    "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.15" 
        -DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR})                                                                                  
 
MAKE_DIRECTORY(${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}/build)                                                                      
ADD_CUSTOM_TARGET(SDL3_SHARED_LIBRARY                                                                                                  
                  ALL                                                                                                                  
                  ${CMAKE_COMMAND} ${SDL3_CONFIGURE_ARGS} ..
                  COMMAND make
                  COMMAND make install
                  WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}/build
                  COMMENT "BUILDING libSDL3")

As an explanation, I am creating the SDL3_SHARED_LIBRARY target as a custom command. It calls cmake with some arguments (SDL3_CONFIGURE_ARGS), then runs make and make install.

Now, you’ll notice that I have the arguments separate from the command. I have a few, including a target install directory that I want to specify. I don’t want to install to the Mac’s system. I want it to be in a known location for my own build.

And when I didn’t have the -DCMAKE_OSX_ARCHITECTURES argument specified, it would just build on the native architecture of the Mac I happened to be building on. It would specify the deployment target and the target install directory correctly.

That is, passing SDL3_CONFIGURE_ARGS to my custom target’s cmake command worked just fine.

But once I added the -DCMAKE_OSX_ARCHITECTURES argument with two values separated by a semicolon, it stopped interpreting things correctly.

In the above case (which wasn’t my first iteration, by the way), it would build the arm64 version. The semicolon seemed to get interpreted in a way that it was treating it as the end of the command, so x86_64 was seen as a new command.

That’s annoying. What about if we add VERBATIM to the invocation of ADD_CUSTOM_TARGET()?

Well, all that does is treat SDL3_CONFIGURE_ARGS as a single argument being passed to cmake. That is, instead of three separate arguments, it’s one big one…and completely wrong.

Also annoying.

I tried escaping quotes, quoting around escaped quotes, having no quotes, and using or not using VERBATIM for each case. I just kept getting the semicolon treated as the end of a command, leaving x86_64 as a completely separate command, or I got it to treat arm64;x86_64 as a list to expand (so it passed along “arm64 [space] x86_64”), or that one long argument.

I just couldn’t get it to do what I wanted, which was to pass along the arguments as I actually wrote them.

In the end, I found that the problem goes away when I don’t try to use a variable that represents multiple arguments, which makes CMake treat it as a list to sometimes expand or not based on some seemingly non-intuitive rules. I instead now use a separate argument:

SET(MULTI_ARCH_ARG
    "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64")

SET(SDL3_CONFIGURE_ARGS
    -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15
    -DCMAKE_INSTALL_PREFIX=${TARGET_INSTALL_DIR})
    
ADD_CUSTOM_TARGET(SDL3_SHARED_LIBRARY
          ALL
          ${CMAKE_COMMAND} "${MULTI_ARCH_ARG}" ${SDL3_CONFIGURE_ARGS} WORKING_DIRECTORY
          COMMAND make
          COMMAND make install
          WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${SDL3_EXTRACTED_DIR}
          COMMENT "BUILDING libSDL3")

Note that I pass along MULTI_ARCH_ARG by quoting in the cmake command, but I don’t quote the SDL3_CONFIGURE_ARGS.

The above worked, and I could move on.

I could have moved on earlier by not trying to do the above, but I was determined to figure out how to get CMake to do what I wanted, and in the process, I am now more familiar with how CMake variables and lists work. Next time I run into something similar, I have this experience under my belt, and I think the struggle was worth it for what I gained.

And now I’m fighting with SDL3_ttf dependencies not building with multiple architectures. SDL3_ttf depends on Freetype and Harfbuzz, and those are apparently building with the current architecture (arm64) and so when the x86_64 version of SDL3_ttf is trying to build, it can’t find the x86_64 version of those dependencies. Hopefully solving this one won’t take another week.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I was creating a new SDL3-based release for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Since SDL3 is so different and I’ve been unable to dedicate substantial time to it, the work to create release builds for each platform I support is still ongoing.

Sprints 2026-MJ_3 and 2026-MJ_4: Release SDL3 update version

Completed

• Ensure Windows version can still be built/deployed

In progress:

• Ensure Mac version can still be built/deployed

Since Toytles: Leaf Raking is in the No ICE in Minnesota Bundle on itch.io (which, by the way, at the time of this writing has raised over $500,000 for the Immigrant Law Center of Minnesota and is still going!), I’ve been focusing on updates for the desktop version of the game.

The Linux version was done right away, but when I last did the work to release a build for Windows, I apparently did a poor job documenting how I did so, so I had to reverse-engineer how I did it before with SDL2 in order to figure out how to do so for SDL3.

And this time, I’m writing scripts to do it for me so that next time I have executable documentation.

I run Ubuntu has my main development system, and one thing I love is that cross-compilers exist. Basically, I can build a Windows version of my game just by using the C++ compiler from MinGW, but I need to use the MinGW development libraries that SDL3 provides.

Next up is the Mac build, complicated by the fact that I don’t have a Silicon-based Mac. I do have access to Mac computers I can remote into thanks to a service I pay for.

Due to how they handle billing by the hour even if I only use one minute and my limited development time which sometimes finds me trying to squeeze in development minutes at a time, I feel pressured to make sure I have an entire hour at a time to dedicate to the effort.

I’m not sure how much I can iterate on trying to automate the Mac build, but I hope I’m most of the way there already and just need to adapt my scripts in minor ways.

Assuming I can knock out the Mac build soon, I’ll move on to the Android and iOS builds soon after.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I had finished the SDL3 migration for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

As soon as I get this release version built on all supported platforms and out the door, I can start focusing on the Major Update(tm).

Sprint 2026-MJ_2: Release SDL3 update version

Completed

• Ensure Linux version can still be built/deployed

In progress:

• Ensure Windows version can still be built/deployed

I try to automate what I can, partly to make sure it is repeatable. I don’t need to remember how to do something if I can just look at the script I wrote.

But I also like automation because it takes something that tends to be stressful and time-consuming and turns it into something that is routine and easy.

So as much as possible, I like to have scripts that build and package my games for release, and over the years, more and more things have been automated.

I even got my iOS build mostly automated, which has the bonus benefit of reducing my need to touch Xcode.

Anyway, the SDL3 migration has naturally thrown a wrench in my existing scripts, so I need to update them. They should more or less work as-is, and I just need to make sure I have new libraries and maybe potentially point the scripts towards them.

But deploying those versions to the various app stores is still a manual effort, and I want to change it.

For the Linux version, I created a script to take a finished build and upload it to itch.io’s servers using butler, itch’s app used for such purposes. And it works pretty well! I can just give the script the name of the project, the version number to release, and the channel (in this case Linux), and it does the right thing.

Well, mostly. I uploaded the tarball, when instead I should have uploaded a directory, which means someone with an older version of the game will not be able to cleanly update to the newer version. I need to fix that.

I am also working on the Windows version. Again, I have scripts that do the work for me, but in this case it requires me getting the SDL3 libraries for Windows first and ensuring the scripts know where to find them.

The Android build should be similarly very quick as most of the effort to build the bundle for the Google Play store is done, but the iOS and Mac builds are trickier, mainly because I don’t have a modern Mac to do development on so I work remotely on a cloud service provider. It’s not ideal, but it is cheaper than buying a new machine each time Apple decided an older one is obsolete.

But my goal with creating new deployment scripts as well as improving the build scripts is to make sure that such release events aren’t a big deal in the future.

Wish me luck!

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report from mid-December I was still in the middle of migrating my code from SDL2 to SDL3 in preparation for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I spent the beginning of January reviewing 2025 and planning 2026, but this past week I finally got back to game development and finished the migration work.

Sprint 2026-MJ_1: Preproduction

Completed

• Update SDL2 to SDL3

If you’ve been following along and are interested in the technical details, most of the upgrade was pretty straightforward and easy, especially since the SDL3 migration guide was fairly detailed and a lot of the changes were renames or small interface changes.

But I was struggling with migrating to libSDL3_mixer, which has completely changed, which meant my code also needed to change how it handled audio significantly.

Before, I just played sound effects at a certain volume on whatever free audio channel was available.

Now, SDL_mixer has tracks and mixers, and so now I needed to manage those as well as the sound effects.

Toytles: Leaf Raking doesn’t have music (yet!), which means I could worry about supporting audio looping later.

Once the SDL_mixer migration work was done, I then solved a problem involving mouse input and rendering scaling.

Basically, if you resize the window, such as maximizing it to be fullscreen, the game renders the screen to that new window as best it can. However, I found that the mouse cursor was still only getting recognized in the dimensions of the original window.

That is, if I was running the game at 1280×720, and I change the window to run on my 4k monitor at fullscreen, the mouse cursor and mouse button clicks were still acting like the game was still 1280×720. That is, only the top left of the window.

It turned out to be an easy fix. SDL3 has a function called SDL_ConvertEventToRenderCoordinates which takes an event, such as SDL_MouseMotionEvent, and converts the coordinates based on the current renderer. Well, actually, the docs show it takes in a lot of different things, but the point is that when I use this function, the input works as expected no matter what the window size and logical rendering settings are like.

Now I’m just checking to make sure the game works from beginning to end and on all platforms without any issues before producing a new release.

Oh, I also updated the copyright year, which reads “2016-2026” now. That’s right, this year marks the 10 year anniversary of Toytles: Leaf Raking‘s initial release! That’s why I am very interested in creating a Major Update(tm) to celebrate.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was making very slow progress on migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

It has been another slow couple of weeks since then.

Sprints 2025-MJ_8 and 2025-MJ_9: Preproduction
In progress:

• Update SDL2 to SDL3

I didn’t give an update last week because I didn’t have much to say. I don’t have terribly much to say this time either, as I once again hadn’t put in many hours, but I am sketching out ideas for how the game could be improved and enhanced.

One thing I might try to do is borrow some ideas from a game I’ve been obsessed with recently. Dice the Demiurge is an incremental dice game for one player by Sophie Houlden, the creator of Sophie’s Dice.

One thing that I love about Dice the Demiurge is that it sometimes encourages you to do things in the real world. For instance, if you choose to play as a Mage, you can gain a bonus level by spending time each day for a week learning a new language. I’m currently on my third world and have chosen to play as a Rogue, and I’m currently looking for opportunities to gain a bonus level doing…rogue-ish things.

Some of the real world things you can do are more intimidating than others. Early on, I also gained a permanent Notion 1d18 by singing in the shower after finding the Wandering Emporium, but I could also gain a dice pool by giving up on something unfulfilling, which is a surprisingly big thing to try to fulfill.

Anyway, this game has a lot of such mechanics based on you doing something in the real world, and as it is a single-player game, it’s obviously enforced by your own honor system.

But I wondered if there was something that Toytles: Leaf Raking could encourage the player to do in the real world that would fit the theme of the game, such as offering to help a neighbor with a chore, or saving money for a big purchase, or making plans for the week based on checking the weather forecast.

Would a single-player leaf-raking business simulation have enough players with an honor system to only give themselves a bonus in the game when they do the actual real-world action? It might be worth a try.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I was still migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Despite having time off from the day job, I got less done this week than normal.

Sprint 2025-MJ_7: Preproduction

In progress:

• Update SDL2 to SDL3

The holidays are always strange in terms of predicting how productive I will be.

Having time off from the day job doesn’t always translate into having more time to work on my business. Family activities and preparations for big visits naturally dominate.

Even when I do find myself with “idle” time, I might be exhausted. I think I napped more in the last week than I have in most months!

Some forward progress is better than none, of course, and I always manage to do something. I was updating code to use my new MixTrackManager that I mentioned last week, and a few more hours should be enough for me to finally finish this migration work.

And of course, last Friday kicked off the itch.io Black Friday sale which I am participating in, although I wish I had been more deliberate and prepared for it.

While I work on updating Toytles: Leaf Raking, you can get it now and ensure that you’ll get those updates for free in the future, when I will likely raise my prices!

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was still migrating my code to SDL3, specifically SDL3_mixer, for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

Alas, I am still, STILL working on it.

Sprint 2025-MJ_6: Preproduction

In progress:

• Update SDL2 to SDL3

Again, the main migration work that I have left is audio-related. To make things easier, I decided to create a MixTrackManager to manage my MIX_Track objects.

Basically, when I initialize my game, I will also configure a set of tracks, grouped by name.

For example, I might have one track for all user interface sound effects. Every button click and swooshing transition will likely play on its own. That is, if you clicked a button, you couldn’t have clicked a second button simultaneously, so won’t need a second track to play both sounds. One track will work just fine for “UI” sounds.

However, maybe there will be lightning crashes, the sound of rain hitting a roof, and the sound of wind. All of these might be “ambient” sounds that could play together, so I should have at least as many tracks available.

SDL_mixer lets you tag tracks, but the main use is to treat a bunch of tracks that are so-tagged as a collective group of tracks to play at once, for instance.

What I want is to be able to say “Play this sound effect on the first available track in the ‘ambient’ tracks”, and hence the MixTrackManager.

The old SDL_mixer just let me specify -1 as the channel to play on, and it would play on the first available channel rather than require me to specify a specific channel. I wanted to have something similar while also retaining the ability to have separate sets of tracks for different purposes.

So MixTrackManager allows me to create a set of tracks for a given tag, but I use my tags differently from how SDL_mixer is using them.

But maybe calling them “tags” even though the purpose is to just name a set of tracks (and even as I use that name to use SDL_mixer’s tagging functionality, too) is confusing things.

I might consider renaming things, but the functionality it will allow is the key: I will be able to play audio more or less the way I did before.

It’s taking me a long time to get to this point, and frankly I am not sure why exactly it has taken me so long, but I’m almost there.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

In my last report, I continued migrating my code to SDL3 for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

And once again, I continued the work.

Sprint 2025-MJ_5: Preproduction

In progress:

• Update SDL2 to SDL3

I realized at one point that my unit tests were not running after a build for GBLib, which is my non-game-specific infrastructure code that all of my games make use of. Framework might be too heavy and formal a word to describe it. Anyway, I must have disabled it in the past while attempting to change something unrelated.

I have tests for my game and for GBLib. Normally, after my code builds, the build system will run the tests automatically.

I probably should have thought this migration work was too easy when I noticed that I didn’t have to make changes to my unit tests to keep things passing.

Once I turned the tests back on, I saw a bunch of errors, so I spent time updating my unit tests to more closely match my updated SDL3-based code.

By the end of the week, I was starting to test-drive changes to my audio-related GBLib code. Like the previous week, a good chunk of this effort was spent figuring out what I wanted my code to do to manage audio. Again, SDL_mixer is completely different than it was. It’s not a matter of merely updating some function names or parameters.

I’m disappointed that I ended the week without finishing this migration work yet again, but the main work left in this effort is audio-related, and I did prove that I can now play audio with part of an update to GBLib when I did a one-off test on the main menu in which I played a piece of audio when I clicked on the screen.

Managing tracks isn’t something I had to worry about before, and I’m making sure my games have the tools available to manage them in a way that is flexible and easy.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Last time, I reported that I was still working on migrating my code to SDL3 for a Major Update(tm) for my strategic leaf-raking business simulation game, Toytles: Leaf Raking.

I continued the work this past week.

Sprint 2025-MJ_4: Preproduction

In progress:

• Update SDL2 to SDL3

At some point, I finally fixed the last compile error, and I was able to run the game, and I was surprised at how well it Just Worked(tm).

Well, I found an issue with the mouse cursor not being where I expect it to be if I change the size of the window. I’ll figure this issue out later, but I suspect it has to do with the game being at a “logical” set of dimensions but scaling the rendering without scaling the mouse cursor’s position.

And I also don’t have text and audio.

I am using the library NFont, and it hasn’t been updated in years, which means it doesn’t have an SDL3 update yet.

So I commented the use of the library out of my code, which explains why there is no text rendering to the screen.

And the audio is missing because SDL_mixer is so different from before that I have to figure out how to change my code to use it.

Within a day, though, I got text back. Originally I thought I would just remove NFont and try to use SDL_ttf directly, but instead I did the work to migrate NFont to SDL3 myself.

I even submitted a pull request for my changes to NFont in case the library does get updated one day.

Which just leaves SDL_mixer updates. So far I am initializing it with MIX_Init() and creating a Mixer object, but I am also no longer initializing it the way I did before with a frequency, number of channels, and chunk size.

I know I need to load sound effects and music into SDL_Audio objects, and I know that to play them that they should be set to Tracks.

What was nice about SDL_mixer v2 was that if I wanted to play on an open channel and not care about the particular channel I played a sound on, I could just use a channel ID of -1. It is possible to play and SDL_Audio file once, and it will be assigned to an internal track, but it doesn’t let me set the audio to loop or do any other effects I might want, so the fire-and-forget option isn’t ideal.

So I’m trying to figure out if there is a mechanism to do something similar with SDL_mixer v3, or if there is a better approach to playing sounds on tracks.

But I expect I’ll have sound effects implemented soon, and then I just have to fix a few issues like that mouse cursor issue I mentioned above, and then I’ll have Toytles: Leaf Raking running with SDL3.

And then the real update work can start.

Thanks for reading, and stay curious!

—

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!