HOME | DD

Description
Finally another menu test! I was dealing with some other stuff for a little while, but I've gotten back to it.

This time there are two nice new things I've been working on.

The first, and most obvious is the component on the left. That's a TextComponent. It allows the display of text in the menu. It needs a whole lot of work still before it gets to a point where you can just use it, and it functions internally just fine, but that's more work for later. At the moment I have a very simple bitmap-based representation going on. Every character (sans the space) is being represented by an image (the same image since it's tedious doing five dozen images individually). It also evens out the left-over space around the text to give a little room between the text and the edge of the component.

The second can't be seen, and honestly has nothing to do with menus, but is a very useful addition. It's code to capture the image on the display, and then save it. This is really useful since it means I can press a button and have a perfect image to show off, plus it can be easily integrated into the eventual game this menu system is for. The really interesting bit, however, is not just that it takes screen shots, but that I've implemented four different automatic naming schemes that should make file name collisions a non-issue.

NAME_MILLIS was the first method. Generally the way computers give timing information is by a "clock" that counts the number of milliseconds since some date (back in the 1970's I think, not really important). Details aside, it's essentially impossible to request two screen shots in the same millisecond, so you have no collision issues there. The problem with this method, however, is that it's pretty unintelligible to people. A file name example would be: screenshot 1396594962479.png

NAME_INCREMENT was the second method. How it works is that it takes a prefix, and adds a number on the end. It then checks if a file already exists with that name, and if it does, it increments the number, and checks again until it can save without over-writing previous files. This has the benefit of being much cleaner and easier to understand. It does run into the problem of having to go through checking through your files, but this is only an issue the first time you take a screenshot after loading, since it can just keep track of the last empty spot it used and go from there. One issue is that, if you delete any screenshots, it will then end up backfilling those. A file name example would be: screenshot 7.png

NAME_DATE_VERBOSE was the third method. What this one does is append the date to the prefix, in order of year, month, day, hour, minute, second, and finally millisecond. Since it goes down to the millisecond it avoids collision, and the date makes it very nice for Human interpretation, since you can look at the screenshots and find that one you took two weeks ago. Unfortunately, it's large and a bit hard to look at, which is why I came up with the last method. A file name example would be: screenshot (2014-3-4 3-1-51 360).png

NAME_DATE was the fourth, and (in my opinion) best method I've implemented. What it does is combine the approach from method 2, and 3. Rather than giving a precise date, it specifies year-month-day and then uses the increment counter. This means that you get the convenient date information, but avoid the clutter of hour/minute/second/ms precision. It also improves on the increment method because it minimizes the number of files it needs to check for since each date starts the counter back at 1. It has the same issue as increment in that it will backfill if you delete files between play-sessions, but since each day brings a new date prefix, it makes it much less likely. A file name example would be: screenshot (2014-3-4) 7.png

Description
Finally another menu test! I was dealing with some other stuff for a little while, but I've gotten back to it.

This time there are two nice new things I've been working on.

The first, and most obvious is the component on the left. That's a TextComponent. It allows the display of text in the menu. It needs a whole lot of work still before it gets to a point where you can just use it, and it functions internally just fine, but that's more work for later. At the moment I have a very simple bitmap-based representation going on. Every character (sans the space) is being represented by an image (the same image since it's tedious doing five dozen images individually). It also evens out the left-over space around the text to give a little room between the text and the edge of the component.

The second can't be seen, and honestly has nothing to do with menus, but is a very useful addition. It's code to capture the image on the display, and then save it. This is really useful since it means I can press a button and have a perfect image to show off, plus it can be easily integrated into the eventual game this menu system is for. The really interesting bit, however, is not just that it takes screen shots, but that I've implemented four different automatic naming schemes that should make file name collisions a non-issue.

NAME_MILLIS was the first method. Generally the way computers give timing information is by a "clock" that counts the number of milliseconds since some date (back in the 1970's I think, not really important). Details aside, it's essentially impossible to request two screen shots in the same millisecond, so you have no collision issues there. The problem with this method, however, is that it's pretty unintelligible to people. A file name example would be: screenshot 1396594962479.png

NAME_INCREMENT was the second method. How it works is that it takes a prefix, and adds a number on the end. It then checks if a file already exists with that name, and if it does, it increments the number, and checks again until it can save without over-writing previous files. This has the benefit of being much cleaner and easier to understand. It does run into the problem of having to go through checking through your files, but this is only an issue the first time you take a screenshot after loading, since it can just keep track of the last empty spot it used and go from there. One issue is that, if you delete any screenshots, it will then end up backfilling those. A file name example would be: screenshot 7.png

NAME_DATE_VERBOSE was the third method. What this one does is append the date to the prefix, in order of year, month, day, hour, minute, second, and finally millisecond. Since it goes down to the millisecond it avoids collision, and the date makes it very nice for Human interpretation, since you can look at the screenshots and find that one you took two weeks ago. Unfortunately, it's large and a bit hard to look at, which is why I came up with the last method. A file name example would be: screenshot (2014-3-4 3-1-51 360).png

NAME_DATE was the fourth, and (in my opinion) best method I've implemented. What it does is combine the approach from method 2, and 3. Rather than giving a precise date, it specifies year-month-day and then uses the increment counter. This means that you get the convenient date information, but avoid the clutter of hour/minute/second/ms precision. It also improves on the increment method because it minimizes the number of files it needs to check for since each date starts the counter back at 1. It has the same issue as increment in that it will backfill if you delete files between play-sessions, but since each day brings a new date prefix, it makes it much less likely. A file name example would be: screenshot (2014-3-4) 7.png