Audio Visualizer Python is now working great on Windows 11 and Ubuntu 22.04. Instead of worrying about the creation of packages, I've decided to focus solely on stability, code quality, and documentation. If the project is working, active, and stable then we will surely get pull requests to add convenient packages at some point. 😅

My next goal is adding automated tests to prevent regression of features in the next next goal, which is to improve code quality by refactoring. There are classes in the program which have too many concerns, and several methods that are way too long and procedural. This is because I wrote most of the code 5 years ago. It will be much easier for others to understand the codebase once I've completed these two goals -- but it's a long-term thing.

One section of code I'm not certain about is the Component class that every component inherits from. This class has a metaclass which decorates each method to wrap it with error-checking and automatically call super() and whatnot. This makes creating a new component pretty easy -- you just subclass and define the methods you need -- but metaclasses are quite Python-specific and this decreases maintainability of the code for others. I'm not sold on removing it entirely, however, because it does fulfill its goal of making the actual components simple and providing nice error messages to the user if something goes wrong. If I do refactor that code, it will be a future goal. It's not actually badly-written like the aforementioned huge classes, just a bit unusual.

For this program I decided to make `pytest` a dependency for users even though it is normally a development dependency. The program has a `--test` option at the commandline which runs pytest and generates a text file that users can submit with an issue on GitHub. This is currently a rough idea that isn't fully fleshed out, but it sounds good in theory. The program is very complex, so having a proper crashlog that users know how to access could be really useful, once I write more tests!
#blog #python #qt #avp

This old program I'm trying to resurrect (Audio Visualizer) crashes on Windows because I'm sending SIGINT to a pipe. Apparently Windows only implements a few signals like SIGTERM, and if I change to that signal then it works fine on Windows.

SIGTERM is just politely asking the program to stop, right? I doubt this will have any negative consequences 🤔

I got burnt years ago trying to package this app for Linux, so my goal is to get it working with py2exe so at least it has *some* package even if it's not my preferred platform.

Another problem: The app crashes instantly without an exception in Windows 11 if I try to create a QImage with a linear gradient, something which doesn't happen on Ubuntu 22.04 (with the same Qt version). That's probably going to be much harder to fix, but I'm okay with the program being 99% working anyway. If I have to remove gradients then I will, but I'm trying to avoid that compromise.

Video of the program in question: https://www.youtube.com/watch?v=EVt2ckQs1Yg
#blog #qt #python

Resizeable menu scene in Muffin Game Engine! It's flickery because the buttons are being destroyed and recreated when resized, but that's only because I didn't originally write this scene to be responsive. If I separate positioning from creation in the code then it'll be smoother looking.

Rapid resizing of the window isn't a high concern anyway. The goal is mobile responsiveness if someone rotates their device occasionally. I want my next game to be fullscreen so it feels less like a box inside a website.

Since I already have "scene mounting" separate from "scene creation", doing a resize is typically as easy as un-mounting and re-mounting the stage. I just have to do all positioning inside mount instead of at creation.

The main "world scene" would probably need special behaviour in real games, but this works for simple scenes like menus, pausing, modals, etc.

TypeScript is great. It makes writing code a lot more fun. I don't have to worry about something potentially being undefined because I forgot an argument, and it encourages me to think about the relationship between different parts of the program. In just a few days I've caught at least 5 errors before runtime which I'm sure would've wasted 5 minutes each if I were using JavaScript. I have wasted *more* time writing interfaces and thinking about type relationships, but I think it'll be worth it in the long-term if I keep using this game engine.

The git repo is here now: https://github.com/tassaron/muffin-game

It's also published on npm despite being very alpha software. I wanted to learn how to publish there. I'm also tagging versions in Git; this way if I need to compile an old game someday in the future when the engine has evolved, I'll have a version number to reference.

I have a new game Pipe Puzzle using v0.0.7 of Muffin Game Engine.