Monthly Archives: June 2019

Added optional cropping ( for drawing sub-widgets. When enabled, Text or other elements that are outside of the parent widget’s bounding box are only drawn up to its boundaries. This gets applied recursively to subwidgets.

This was a simple thing to implement, so I have no idea why it took so long to get the correct crop assignments down. Gah.

I spent entirely too much time today rewriting backup scripts. They were in need of updating, and it’s important to keep proper backups, but I feel like I got nothing substantial done.

Bookmarking some links on how to use the new queueable sound Sources in LÖVE 11. I’m interested in using them for simple sound effects generation.

  • A simple sine wave generator example from one of the developers, here.
  • Forum post about queueing one Source after another
  • There’s also an impressive-looking tracker module player, but I don’t quite understand how it works at a glance. The MOD loader code is an interesting read.

I rewrote the publishing / packaging script tonight. It was originally a shell script with a bunch of copy-pasted lines for each target. Now it’s a Python script broken up into a couple of functions and a list of target objects / structures that it iterates through. Overall this is a step in the right direction.


  • Run all build scripts (see last post), reprocessing all images and re-exporting all Tiled maps
  • Delete all previous contents of the packaging workspace
  • Remove “work” directories that held unprocessed images and maps
  • Zip this codebase into a .love file
  • Objects representing each target were declared and filled out earlier. For each target:
    • Make directory based on target’s name
    • If target needs the .love file, copy it
    • If the target has a path to LÖVE runtime binaries (ex: “love-11.2-win32”), copy all contents
      • If we’re copying the binaries, and the target needs the .love file to be concatenated to the Windows EXE file, do so now
        • If the target requires the Windows console EXE, concatenate to lovec.exe as well
    • Copy “pack-ins”, target-independent documents and resources that are part of the project but not part of the .love file (like readme files, walkthroughs, etc.)
    • If specified by target, format .txt files for Windows so that the newlines display correctly in Windows Notepad
    • Zip the directory

I currently have three targets:

  • “love-file”, which is just the .love file and the pack-ins.
  • “win32”, Windows 32-Bit.
  • “win64”, Windows 64-Bit.

Eventually, I also need to support Linux (I guess via AppImage or Flatpak, but haven’t really dug into it) and MacOS. In the meantime, if users on those platforms are interested in trying the game, I point them to “love-file”, along with downloading a matching version of LÖVE from I intend to update all of my LÖVE games whenever there is a new release of the framework, though I guess it depends on how big the changes are.

Rewrote the build script that handles spritesheet alpha transparency and exporting Tiled maps. Build times were creeping up to 3 seconds with only seven spritesheets or so. The new script is mostly Python, and checks the last-modified timestamps of files before it attempts to process them.

This is something I wanted to do earlier, and felt was going to bite me in the ass very soon, but I couldn’t figure out how to do it in a Bash script while also trying to get Hibernator out the door.

I also made a stew. Good day overall.

I’ve been drawing sprite and background mock ups, trying to keep things light and humorous. Wrote about 30 seconds of XM music just to see if I was capable of whipping up some upbeat tunes quickly, but it’s not coming naturally.

I’ve got a sort of anthropomorphic egg character that I’m liking, and I think it may end up being the protagonist for Bolero 2. Something along the lines of Humpty Dumpty, or the Codemasters Dizzy character, with an unreadable expression. For Bolero 2 in general, I think I want a 5-7 stage linear action game, with no real surprises or “twists”. Something to help round out the underlying engine, without pushing it beyond what it’s capable of, and which I can enjoy making content for and tweaking and playtesting.

Cleaning up the rat’s nest that is my widget definition source file (pretty much just used for the pause menu at this point). The “add widget” function’s argument list was getting ridiculously long and cryptic, so I changed it to take a Lua table with the arguments instead. I also made functions for each kind of item to be added (non-interactive label, command, checkbox, slider, etc).

Need to keep chipping away and fixing up messy things that I marked as “leave this, it’s OK for just this one game” on Hibernator.

Increased Bolero 2’s resolution from 384×216 to the more common 480×270. Both can be scaled up to 1920×1080.

I also increased the base tile resolution from 12×12 to 16×16, though I’m less decided about that. The former is cute, and makes for nicely shaped little goofball characters, but it’s really difficult to get them looking right at times due to the low resolution. It’s somewhere between the world of 8×8, where anything you draw will look about as equally good as anything else, and the land of 16×16, where changing one pixel can throw off the rest of the object.

Fixed the issue causing Bolero 2’s startup to fail.

Though I have a better idea of what to do with the sound manager, I’m not sure it’s a good idea to work on it while the main test area is so sparse. Will come back to it after I get some more actor objects doing things.

Sketched up some ideas for improving the sound manager in Bolero 2. Besides moving from just loading all Sources to using “channels”, I’d also like to support priority checking and prevention of doubled-up sounds.