I’ve been neglecting the level editor a little bit. It didn’t get fully updated with IMGUI, mainly because it was a mess. It had gone through the entity system development with only quick updates here and there and it showed.
Last night I decided it was finally time to dig in. After an hour or two of cleanup and refactoring, things started looking much better. I wrote new entity & variant selection lists and fixed a few bugs related to Box2D. Overall line count went down, which is always a good sign. So much for custom UI components!
During a recent rewrite of the menu system, it occurred to me it would be nice to have a visual preview of the various animation easing curves available in the engine.
So I made a tool to do that. Pick an easing function, see the curve and an animation showing its effect on alpha, scale and position. 20 minutes, 150 lines of code.
This will make it much easier to pick the right function when creating new UI and in-game animations.
Luckily I’m done with the menus for now. If I ever need to add more polish, I might attach this new interface directly to the actual element being animated. That would make this a real WYSIWYG tool.
Tiny Loader version 1.2.3 is out now. Tiny Loader is the companion Mac app for Tiny Player. The app is now notarized with Apple. This makes it easier to launch the first time after downloading.
Tiny Player for Mac version 1.2.11 is out now. This update brings the following improvements:
- Notarized with Apple
- Improved UI for empty playlist
This was a big one. I switched to Box2D for collision detection & physics.
My old system was nothing fancy: axis-aligned bounding boxes, a “sliding” mechanism for collisions, sector based space subdivision. Worked well for Superforce. However there’s a lot more happening in Devastro 2. More bullets, more particles, more enemies, more complicated level design, player motion needs to be fluid around obstacles etc. Box2D seems like the right tool for that job.
First I had to rip out large amounts of old code both in the game and the editor. Everything was completely broken for over a week. Fortunately the Box2D integration went well and the game is now back up and running.
The Box2D API is nice and there’s plenty of documentation & example code.
To improve rendering performance the game builds a texture atlas from all the images. This process is quick enough to be done at load time. I wanted to have a clear idea about the atlas layout. Xcode does have some support for viewing OpenGL textures but it’s been crashing on me almost every time I used that feature. So I did what I usually do when a 3rd party tool fails me: I built my own inspection tool to look at the OpenGL textures directly in-game.
Even in its initial simple form it has already helped fix a few issues.
I’m planning to extend it with zoom & pan and a way to track usage of the individual images in the atlas.
Here is a list of development tools I’m using at the moment.
- iMac retina 27″ 2015, 32GB RAM
- iPhone SE
- iPad Mini 4
- XBox wireless controller
- Recent versions of Photoshop have been not so great. Pixelmator development has almost ceased. Considering switching to Affinity Photo.
- Starting to use Blender for 2D vector graphics as well (icons etc).
Number of commits is not a good metric for productivity, project health or anything else really. But let’s pretend! It may be OK as a simple activity indicator…
Here’s a Python script I made that graphs daily commit counts on a git repository by year.
Download the script here. Requires Python 3 and PIL/Pillow.
pip3 install pillow
python3 activity.py /path/to/imgui imgui
Example output for imgui:
As I keep adding assets to the game, the load time keeps increasing. Who would have thought? A 5 second startup may not sound like much but it quickly adds up during development.
One way to fix it would be to load assets on demand. This might cause stuttering, but that’s OK for development. However, improving the load time would benefit the final game as well. Let’s do that!
I added a job system that allows the preload to happen on multiple threads. Load time: 1.5 seconds. Nice! Now that I’ve “jobified” the tasks that need to run, further improvements can be made with relatively little effort.
The main menu of the game is going to have an animated background. Currently I’m thinking it could be the end of the original trailer put on loop:
As a temporary playback solution I used a series of JPEG files. Not very efficient. When looking for a decent video playback library, I found this one:
A brand new “single-header” library for decoding MPEG1 video, by Dominic Szablewski. Simple API, easy to integrate. It’s great!
In fact, I spent more time looking for my .blend source file than writing code to use the library. In Blender, I switched render output from image to video and set the codec to MPEG1. It all worked the first time I ran the game.