Program Framework
- 7 Devlogs
- 25 Total hours
Framework built on top of SDL which will eventually be able to manage rendering, input, and more
Framework built on top of SDL which will eventually be able to manage rendering, input, and more
Today, I polished the library a bit more and expanded the demo.
First, I thought about how “game logic” would be executed and tied to the existing framework’s clock. I decided that the easiest way for me to implement this was to create a function pointer which is called every “tick” (a moment in which you want to execute updates, with an ideally constant step time).
Second, I removed my reporting/logging implementation. I don’t think it’s worth it to reinvent the wheel for this right now, but in the future, I might pull in libraries like spdlog.
I also updated the demo to show how input can result in movement.
Uhh, I also fixed a memory leak in which I never cleared the list of sprites to be rendered after each frame, so memory usage would slowly climb, and my fps would slowly drop. That’s an issue no more!
Yesterday, I worked on setting up a Linux build for BPF. SDL is largely designed to be compatible for a variety of different platforms, so I thought that not at least trying* to do so would be a bit of a waste. I spent way too long tracking down dependencies and setting up WSL, but I finally have a working binary for Linux (minor caveat: the audio wrapper which uses SDL_Mixer may or may not work; I can’t tell if there’s an issue with my virtual environment or with my code.
New functioning audio system
In the past few days, I have been working on implementing an audio system that relies on SDL_Mixer, a separate library from SDL.
I decided to use SDL_Mixer because I did not want to manually manage the mixing of sounds and management of the different audio streams, like that of which I would need to do if I used SDL’s built in audio tools.
I also dropped SDL_image from the library right now because it adds too many dependencies, and I don’t think the additional overhead is needed for my intended functionality right now. In the future, I was looking into incorporating WUFFS, which is a programming language that is built to guarantee memory safety when loading files. (link: https://github.com/google/wuffs)
I wasn’t really sure of what to put for my image, so I put an image of me stepping through and debugging my code to troubleshoot nothing being played. (Spoiler alert: I flipped an operator)
First, I worked a bit more on my observer system under the hood. Instead of relying on observer objects, the subject just takes a reference to a callback which is intended to be called on the subject’s notify(). The picture is a demo where anytime I press a key it prints “test.”
I also went through my code and tried to leave comments which clarify the functions and usage of certain things, which should help to make it more usable.
Also, my Git connection keeps breaking, which is enraging!
I finished wiring up a simple test render which uses the framework’s systems.
I also worked a bit on cleaning up some of the code and labelling my intentions/future plans. I also verified that my build configurations were ok, and made sure I had no more memory issues.
I cobbled together a component system which allows for the creation of two types of containers. One strictly contains data, while the other one is slower but can also contain references to other components and functions. I based quite a bit of this on some of the patterns I read in “Game Programming Patterns” by Robert Nystrom, and I really recommend it if you are interested.
In addition to that, I had a “small” (massive) memory leak which resulted from me misunderstanding the way SDL handles rendering, so I got it to render stuff and clear the command queue which fixed that.
I also started a little bit on a logging system which also uses SDL, but I want to make it more natural to use and more fitting with the way I designed this library.
Started basic window management, input systems, and texture rendering. More soon!