– Fix build in GCC 14 and newer Vulkan headers – Fix IDE warnings
Hello! This is purely a maintenance commit, as it became obvious the build environment would no longer work after an update. This is due to some restructuring in the C++ wrapper around the original C header files. Currently there are no new builds available, as the windows build is currently still failing and thus blocking the pipeline from finishing. This won’t require any further work on the main Olives code, but rather updating the windows build environment to use the 1.4.* style Vulkan headers as well.
– Fix hover states for the save menu – Fix overall hover logic (properly take z values into consideration) – Fix build – Let all widget (and inheriting classes) setters return the current instance
Hello! Obviously, this is the first commit in a very, very long time. This was both due to a lack of motivation, time and the overall thought of simply going back to bugs as opposed to actually getting to write something new (i.e. doing something fun!).
Be that as it may, finally the responsiveness of both clicking and the hover effect for the buttons in the save menu should be greatly improved. While doing so I noticed some things that were missing, but those fell mostly in the very broad category of housekeeping.
Next up, I will either have another look at the ongoing performance issue or go for some low-hanging fruit to hopefully get the motivation going again. Whichever it will be, I’ll hopefully be back soon!
– Add new buttons to the save list – Add an explicit “save new game” button to the top of the list – Change the way the current hover element detection works (WiP) – Add new type to distinguish between save list items
Hi! There are two big visible changes here: first and foremost obviously this potentially design award winning “new save” button, which gets added as the first element in the save menu now. This allows users to actually save their games again. Secondly, the overwrite and delete buttons actually hover now, at least mostly.
I hadn’t quite considered the fact that the entire hover mechanic wasn’t really build with overlapping UI widgets in mind, which caused all sorts of problems. The same was true for the click handler logic, making it impossible to hover and, more crucially, click the buttons. Now, the buttons themselves don’t actually do anything yet, except printing a message in the console, as I was quite focused on getting them to do anything at all first. The half-baked hovering is bothering me, but I will probably not spend too much time on this now, as fixing these types of issues are not great for my motivation. The approach was changed to actually take the z-index of a widget in mind, as opposed to blindly selecting whatever happens to at a screen coordinate first, which in this case were mostly the buttons of the menu behind the list. So if that isn’t quickly fully fixed quickly, I will concentrate on actually implementing the actions that are supposed to get triggered by these buttons first.
– Add new type to distinguish to different types of scenario/save game lists – Change dimensions of the list to make space for the additional buttons needed – Temporarily made it impossible to actually save due to lack of a button
Hello! The big ticket item in this commit is definitely the (visual) changes to the scenario/save game list. If drawn in “save game” mode it will now also include the “overwrite” and “delete” buttons.
The bad news here is that this also makes it impossible to actually save right now, as the save list itself is still very much work in progress. This will also make it necessary to finally implement runtime reloading of the file caches after adding/deleting save files, which is currently only happening once during start-up.
The next commit should come with a lot less of a delay. Until soon. Byeee 🙂
Hi! Once again, this is a pretty straight-forward topic in terms of functionality. I was struggling a bit with the scaling, doing so relatively late at night with less-than-ideal concentration certainly didn’t help. As things got a bit frustrating I now went for the age old “eh, good enough” approach for it and.. it is just that. The load/new game menu have been slightly adapted to support a more reasonable thumbnail size, which looks something like this:
Next up will either be some synchronisation regressions I noticed recently or I’ll move ahead with the next save game topic. Let’s see. Byeeee 🙂
Hello! Quick and to the point, this comes exactly as described. 🙂 No screenshot today as there is obviously no actual visual difference between textures loaded from either a PNG/JPG compared to a BMP.
While BMPs, or at least the relativiely simple variant OLives implements, do not support alpha transparency, that is not really a problem as the only planned use case for now will have them serve as thumbnails for saved games. I still have to work out some kinks for that, but overall the entire save game topic (including the Bitmap support) is progressing nicely. Byeee!
Hi! As a somewhat unexpected turn of events, I had to implement taking screenshots, so the picture below was actually taken by OLives 🙂
Besides the nice side-effect that this will taking screenshots of progress a lot easier, the actual reason for doing it was that I needed a screenshot functionality for save games, as the picture currently used is simply hardcoded. The next step will be adapting this to be used for exactly that purpose. Hopefully that won’t take too long, byeee 🙂
Hi! So, once again, this is exactly as described in the commit message. Probably the most interesting (and satisfying) thing for me while working on this was seeing the progression from “no walls at all” to “both walls and portals are rendered” correctly:
As can be seen there, now we’re seeing the exact same thing as before saving the game. 🙂 Next up will be fleshing out the actual save menu.. or maybe adding timestamp support to the save files, whichever will seem more appealing when it comes to actually working on it. Byeee!
Hello! This commit basically comes exactly as described, it implements storing the current object and tile state in the save games. Still lacking however are both walls and portal state, which leaves us with the following situation:
Left: state before saving Right: state after loading from a save file
So the obvious next two steps are supporting walls and portals. 🙂
