OLives Dev Blog

– 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

Resolves #91

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.

Either way, until soon. Byeee!

– 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

Resolves #91

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 🙂

– Implement rudimentary (down) scaling to the Bitmap class
– Take a screenshot and add it to the save files

Resolves #97

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 🙂

Add support for using Bitmaps as textures

Resolves #103

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!

– Add feature that allows to take screenshot
– Refactor code that provides incrementing filenames for save games to be more generic

Resolves #102

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 🙂

– Add a timestamp to save games
– Keep the scenario name in the game state so that it can be applied to save games

Resolves #99

Hello! I’m trying to go for smaller, but more frequent commits again. So just in that spirit, this commit once again does exactly as it says:

Obviously still missing and also the next topic is actually taking screenshot and using them as thumbnails. So until that is done, byeee!

Store both the wall and portal data in save files

Resolves #98

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!

– Implement storing objects in save files
– Implement storing tile type data in save files
– Fix value for ObjectCategory::All

Relates to #98

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:

So the obvious next two steps are supporting walls and portals. 🙂

– Activate the “Save Game” button in the in-game menu
– Determine a name for the new .zip file to be stored
– Provide enough basic information into the new newly created snapshot to make it load from the menu

Relates to #98

Hi! As I had had previously hoped, self-motivation is a much smaller problem when there is less debugging and more actual development.
This commit actually contains much of the meat of the whole save game milestone: it creates the actual save file (.zip), makes sure its name is in the correct format and finally writes data from the current game state into it.

As for now, this is weird up directly to the “save game” button in the in-game menu. There isn’t much in term of user feedback happening, but an astute observer looking at the log will see something like

These files are “good enough” to be actually loaded already, however for now the snap shots basically only contain the very basic necessary information for that.

To keep things interesting there are some caveats:

• Actually seeing saved games will require a restart of OLives for now
• Save games do not have a proper title yet
• No tile, wall or object information is currently stored
• There is now way to actually delete save games from within OLives

So the next few tasks are basically already cut out for me, I will put a special emphasis on adding the missing fields to the save games. Anyway, it was good to be back to actually creating, nut just debugging Code.

Byeee! 🙂