Game thing progress #9, more editor things

I'm not dead, yet. The past few months have been rather boring in terms of things made, since I had to work on my diploma a lot. Hopefully I'm done with that soon and can come back to doing things I actually like. I'm actually using this game as my diploma project without any modification, so that's something.

I was told my game wasn't that impressive, that's true, of course, though the game is not the focus of the diploma, the engine is. So, I made an arkanoid clone in one evening just to make a completely different thing. To make it I had to extend the modding API slightly, but now the walking mode pretty much is all moddable too, so you can basically make your own new game using it, if you for some reason wish to do it. The documentation is basically non-existant on it, but you can look at the code in resources/mods/example and go from there, probably. Maybe I'll add some comments there to explain everything that is happening in the future.

Some fun editor things were implemented, like adding and selecting entitites that don't have a collider. Some more were added, since I wanted to make at least one room completely or at least mostly in editor. Which I did, but only one for now. Hopefully more to come soon.

Here's how the editor looks now, fancy buttons:

The asset tab allows to add assets with the UI, too. It even has a fancy file selection window:

When the asset that is in use is edited, the system tries its best to find and replaced all the usages of the old asset with a new one. Plus, if a Drawable component is added to an object, it initially has a placeholder black-and-pink texture which cannot be saved and serves as a temporary value until the actual texture is selected.

Other than that, the callback system has been adjusted to allow including type requirements for callbacks, so the editor UI can actually check these requirements and draw the appropriate editor. Basically, after you create a callback you call a special function and pass the type data into it, and it saves it in a special place for later usage. Here is an example of how it looks in code:

debug_components.declare_callback_args(
   M.interaction_callbacks.look,
   { prefab = "string" }
)

The callback accepts a single string argument in a map, the argument name is prefab. The UI uses that to create an editor that shows the appropriate table. The types can even be nested if some argument is a table in the aforementioned declaration. Or it can be a freeform table if its type is declared as table.

Most recently, I've tried to replace the SFML audio module with SDL_mixer, which also made me add the entire SDL (though I've tried my best to disable unneeded things). The reason being that SDL_mixer can have sound libraries linked statically into it and I can select only those I want to have - namely OGG. All the sounds are in OGG anyway but SFML also requires FLAC, for example. And it links to everythng dynamically which is a pain. I've been doing the SDL thing in a separate branch for now, hopefully I will merge it into master soon and the next release on will only require you to have alsa/pulse on linux and nothing additional on other operating systems.

Did you know that building SDL is actually a huge pain in the ass? Their CMake file sucks and for some reason SDL_mixer's one has a check around everything that makes it only do something when building on android. I think I somewhat figured it out, but you can never know with these things.

Almost forgot.. I fixed an annoying bug I had with the TOML component saving. In TOML procesing code, the entity table itself is referred to as "self". So, the code tried to get the "self" node on every entity, even if one did not exist (such a node would have a path like "entities.entity name", with no component). If such a node does not exist in a file, but its source is retreived from code, it will point to some other node that actually exists which DOES NOT WORK and breaks things. So, now it only tries to use the "self" node in case there are no other nodes but the entity exists in the file: therefore it is guaranteed that the node will be pointing to an entity node with no components. Because of this bug, the saving was inconsistent: either the entity or the first component were selected at random, and when entity was selected things broke.

The shaders have been changed a bit, mostly moved to storing them in lua and C++ just sets them and then gets them from lua. With that, they can be edited more conveniently in the editor thing (which is basically the same as the callback or other table one, with types defined in C++ code and stored in lua).

That's about it, I think. Not much, but it's nice to write these things down sometimes. Hopefully someone actually reads them. And as usual, thank you for reading my blog post!