Testing LÖVE / OpenAL Soft audio effects, for which I don’t have a good in-game screenshot to demonstrate, so here’s a pic of an XMPlay spectrum visualization of the output. I uploaded some audio to SoundCloud here.
I am a bit under the weather as I finish this post. Hopefully it makes sense. I might edit it a bit once I’m feeling better.
Work Since Last Devlog
Added a debug feature to print LÖVE GPU stats and frame render times in the corner of the screen. It looks like automatic sprite batching is being used quite a bit.
I got BGM fade-out and fade-in working. I had planned on supporting music cross-fading, but for now I’m just going to stick to one active track at a time.
I hooked up lowpass and highpass filters for source objects and their effects independently, and added per-frame gain/volume deltas for both. This should squeeze some more life out of small samples and short music loops. As far as I can tell by watching the LÖVE process in System Monitor, these effects don’t have much impact on CPU usage, so that’s good. I’m running all of the supported effects simultaneously, but limiting each source to one effect, just to make the SoundParam tables easier to manage. The effects are:
- Ring Modulator
I added configuration items so that every effect can be manually disabled, and every parameter can be tweaked by the end-user in the config file. I believe it’s possible to continuously adjust effects at run-time as the game context changes, but I don’t think going any further down this road is a good idea if I ever want to actually finish a game.
Independent of the OpenAL filters and effects, I added some simple, per-frame, delta-timed ADSR envelopes to help manage the volume of sound effects. Here is a diagram of an ADSR envelope that I drew, and then realized was unnecessary since I could have just linked the Wikipedia article on musical envelopes instead:
These envelopes will conflict with manually setting channel volume, and also with BGM fade-out / fade-in. I’ll need to work on resolving these issues, eventually, but again, I think it’ll be OK for just one game. I’m just glad this stuff is basically all working now.
I moved all WAV sound effects to a work-in-progress folder, and added an extra step to the build process to convert them to Ogg Vorbis via ffmpeg. They’ll probably use the same amount of memory once decoded in RAM, but this should make the final release package a bit leaner.
After some tests, I decided to to use XM music for the soundtrack directly, without converting to Ogg Vorbis as part of the build process. This shouldn’t be a big problem as long as I keep the total size of the soundtrack down. I’m aware of a few differences in terms of playback between MilkyTracker (the tool I’m using to write the XMs) and libmodplug (the library LÖVE uses to play tracker music):
- EFX fine-tune settings can differ.
- Note cut-off sometimes doesn’t trigger in libmodplug, and I haven’t determined why yet. But setting volume to 0x00 works fine.
- For seamless looped music, use the BXX command to jump back to an earlier part of the track, or else there will be some silence.
The folks on the LÖVE Discord shared an interesting Gamasutra article about 2D scrolling systems.
I’ve noticed some occasional phantom player movement while testing. I’m pretty sure it’s a faulty directional pad on one of the controllers I have connected. I wonder if I can do anything to fix it.
I’ve sketched out a roadmap of monthly goals below, mostly focusing on technical hurdles and not necessarily game design. Maybe I’ll make a public-facing roadmap on my wiki and chip away at it. For now, here’s a rough draft.
I’ve dumped most of the tasks into September until I get a better idea of how to spread the work out. Also, I’m not sure how quickly I can get these things done, as I struggled in June and July, but then made great progress in August. So, we’ll see.
- ✅ [Planning]Get this roadmap started 🙂
- ✅ [GFX/Windowing] The engine has rudimentary support for multiple per-scene viewports with their own scrolling rules, but I don’t think I can fully flesh that out right now and also get a game finished. So turn that stuff off.
- [Scenes/Actors] Finish generic actor collision and platform movement handling
- [Scenes/Actors] Fix issues with sloped terrain
- [Scenes/Actors] Get the spinnyboys rolling up and down the hills
- [Scenes/Actors] Build up method calls for actors to simplify programming them.
- [Scenes/Actors] I need some way to cache or memoize handles to other actors. Hibernator had this hilarious performance issue where it would slow to a crawl if the player actor was near the end of the array, but run fine when closer to the start, because hundreds of other actors would do a linear search through the array to find the player, 256 times per second. Maybe have a service that hands out tickets which can expire if the far-end actor is removed.
- [Scenes/Actors] Make a camera / scrolling / scene transition manager. Target-to-follow, scroll boundaries, fade-outs, etc. Most of this already exists, but it’s jammed into the player actor instead of being properly separated.
- [Scenes/Actors] Revisit actor creation and removal functions, with respect to how they affect Lua garbage collection, and how the order of actors in the array can cause subtle bugs. Another fun Hibernator issue: the player could never attach to the first floating platform in the actor array. The player would constantly go into a mid-air state, land on the platform, go mid-air again, over and over. I never figured it out, and ended up hiding the first platform in an inaccessible test room in the upper-right corner of the map.
- [I/O+Conf] Need to ensure that Unicode is handled correctly in all calls to the Lua string library.
- [I/O+Conf] Debug: Save / Load game state
- [Widgets] Full options menu tree. Need to improve the widget system in order to do this. Selection boxes, “OK/apply/cancel” buttons, scroll boxes, etc.
- [GFX/Window] Functional fullscreen (canvas needs centering IIRC)
- (Pending further planning)
- (Pending further planning)
- [Planning] All engine components necessary to finish the game should be operational
- [Planning] Get some kind of engine demo out for feedback
- I’m really interested in sound synthesis through queueable sources. Maybe next time.
- Music / ambiance cross-fading, same as above.
- Asset editors for animations, terrains, envelopes and other engine constructs. They would be nice to have, but I can get by with defining them in code for now.
- The multiple viewport stuff, as mentioned above. Though, it would be fun to give each viewport its own canvas and do zooms / rotations / stuff like that.
- The drawing code should probably use love.graphics.translate() to position draw calls, but the game seems to be running well enough right now. Revisit if this is determined to be a performance bottleneck or causing some other problem.
- Shaders. Not sure if I need them right now, or if I should completely hold off. Will revisit when I have more work done.
Plans For Next Post
- Refine roadmap, put it on the wiki to track progress
(e 9/Sept/2019: Add checkmark, change formatting)