03J05 - I also figured out how to render text using the SDL ttf library. The exact calls are much easier than I expected. Previously I had been using a monospaced image of the alphabet and strategically slicing portions of the image to display. Presumably that is what the ttf processing does in principle, but in a very digestible way. I can now set and display a unique line of text for each Scene.
As I was figuring out how to use the SDL ttf library, I came across some decade's old comments mentioning the importance of "destroying textures". Up until this point, I had not explicitly thought about the memory management requirements of SDL. In the past I had worked with a dynamic linked list of entities that would constantly be updated with chunks of memory freed or allocated as entities were removed/added to the struct. But I don't recall destroying any textures. As I understand it now, when a texture is rendered, a new portion of memory is allocated. A texture can correspond to a Scene image, the rendered Text, or any number of things. Perhaps erroneously, my game loop renders these textures once per frame. My not strategically destroying the textures, vindauga's memory footprint grows every frame. Indeed, when looking at the RAM usage, vindauga was adding about 10MB of required RAM every second, even on an idle Scene. I was very happy to discover that I could easily mangage this leak by clearing the SDL renderer at the beginning of every game loop. Now the RAM usage holds constant!
At this point, I call the core functionality of vindauga complete.
03I10 - After several failed attempts at creating a dynamically modified linked list, I gave up. I understand the concept well enough but I was running into compilation errors that I failed to understand fully including dreaded segfaults. This was a disheartening experience and I took a few days to reorient myself. In the process, I came across an OpenGL header-only game framework called gunslinger which seems really interesting. I'd like tomake a falling-sands game next using this framework, more on this later. Coming back to vindauga, I came to realize that for my immediate purposes I was greatly overcomplicating things. All I needed was to be able to preserve and reference back to the sceneID state as I navigate from one Scene to another. All this really requires is a simple array. Each time I navigate to a new Scene, append its ID to the array. To determine which scene to render/interpret, simply read the final element of the array. When the user navigates backwards from a Scene, pop the last element from the array. Simple! I had to tweak a few things like adding a delay when right-clicking to go back so that the game loop does not pick up the right-click button being down for more than 1 frame as then mulitple Scenes will be navigated.
03I05 - Next up: a data tree for the Scenes! I think having one central point of truth for Scene navigation will be nice, though it could also be possible to have a single dynamic list, which does not need to know about a central point of Scene organization. I don't think either one of these is the right way of doing this, merely a matter of preference at this point. I guess a central navigation map would be more efficient computationally. Secondly, I'd like to make a hover effect for when you are over a clickable item. This should be easy, just move the check Left-Click logic into the mouse position block for each Scene, and then call a draw() before checking for clicks.
03I03 - I have the basic structure and flow of the game established now. It will be a point-and-click style exploration game where scences can be discovered and observed. Each scene will be a low-res 1bit image (currently 128x128) with two states to give an sense of movement and life.
There's a few things I know will have to be developed quickly and soon to make the game fully functional. At the moment, right-clicking sends the player back to the starting Scene (0) regardless of what Scene they are in. Once the Storyboard gets anything more than one level deep, I will need to be able to keep track of the player's path, which Scenes they have been to and in which order in order to navigate backwards. The easiest thing I can think of is a simple array that I append each Scene ID to and pop Scene IDs off whenever the user navigates backwards, that way the tail of the array is always the current Scene. I say "simple array" but of course when working with C there are complications. I'll have to program my own append() and pop() functions from scratch. Maybe there's an easier way to do this? For now, I will try this and learn along the way. There's some other considerations nesteled within this effort as well: what if I want to keep track of Scene-based player states? Say the player talks to a character and that action changes something about the Scene (requiring a render of a distinct image file), how do I keep track of that once the user navigates away? Sounds like the job for a Scene struct. But, before I get too carried away and frozen by the mountains of new things to learn, let's keep things basic.
Another thing I am thinking about is the music and how it is handled. Right now, the music is loaded and called to play once, during the game initialization. If I want to play Scene-specific music, I'll need a way to call music loads and plays from within the game loop without repeatedly calling them every frame. Not sure how to do this, but I suspect I will be able to monitor the music Channels to see if anything is currently playing and choose not to reinitialize. Actually since I only trigger the change of Scene at most once per loop and only if the mouse click conditions are met, I think I can simply embed this directly within the game loop. The music would just restart each time a new scene is loaded though.
Finally (for now) I want to add a transition between Scenes, something like a fade out/in to/from black. Again, no idea how to do this but my assumption is that something to this effect already exists within SDL.
