Weekly Dev Log 6:
10/1/15
University is back in full swing and so is the homework that goes along with it. Not complaining mind you, it is nice to get back to learning new things.
Not much to report other than I’ve been looking into better methods of constructing an undo / redo system. The one currently in use basically creates a backup of your project right after an action of some kind is made, and stores this in a list. When the user hits “Undo” it simply reloads the entire project as it was before the last change. As you can imagine, this is not a very efficient design. It is, however, easy to implement, and works quite well.
My current idea for a new undo system involves say, an “id” for each action. When an action is performed, a ds_map is created to store the relevant “before and after” data for the action and added to the list of undo events.
For example: when you begin to move a bubble, a ds_map is created with data for an “event_id”, “bubble_id”, “x”, and “y”. where
- “event_id” holds BUBBLE_MOVE_EVENT,
- “bubble_id” is the unique identifier for the bubble being moved
- “x” & “y” are the starting location of the bubble before it is moved.
The cool thing about this method is that I can display to the user unique information about each undo event. Like, hovering the mouse over the undo button will show a list of available undo / redo actions. Hovering over a specific action will highlight what was done so you can compare the difference.
This means a lot more work on my end, but I feel the memory and efficiency savings will be worth it.
Another thing regarding the undo system, is that I would like to store the data in the project save file. This way, when you quit Chronicler and fire it back up again, you will still have the ability to undo / redo actions. I feel this is an important feature that nearly all applications lack.
Of course there will be an option in the settings menu to change the maximum number of undo / redo events to store in memory. (or unlimited, but this could cause Chronicler to crash if your PC runs out of memory!). Now that I think about it, I can simply store the last 20 undo events in memory and the rest in the save file. That will enable true unlimited undo’s. (as unlimited as your hard drive anyway haha). It will however increase the size of your .chron files. I may add a popup that asks if you wish to remove undo’s beyond, say, 1000.
I also need to find a way to determine whether the the user clicked the close button on the window and ask if they wish to save their project before exiting.
That’s all for this week. I’ll work on the undo system in my free time. This is a core feature that needs to be implemented immediately rather than tacked on later.