Now, after two months of work, it is time to show progress and describe the architecture of events recorder. This is a class diagramm, which can give some understanding of how does events recorder relates with other classes of scummvm.
Lets describe it particulary by means of subsistems, which it records.
Hi. This week I’ve add new features to events recorder. Now it can replay game without display it on screen: it initialize memory buffer instead of initializing of SDL context. Next feature: user can switch recording mode to normal game play. I. e.while user is recording his gameplay he may interrupt it and continue playig in normal mode. You may see on this diagram how it works:
On this week I’ve finished savefiles embedding. Following the fuzzie’s idea, I created class which inherits DefaultSaveFileManager and implements listFiles and openForLoading functions. During the recording or playback it calls functions of events recorder. This functions read hold or read save files from recording file.
Also, I’ve begin work on onsreen recording dialog. This dialog will show during the recording and playback and allow to control the recording process. You may see very first version of this dialog on following video:
So, I’m still working on integration of save files into recording file. On last week I did alot of things to this. After code studying, I saw that every engine supporting states loading, have some kind of fucntion which generates file name by slot’s number. Some engines have this function as is a class static method, others like public method, few engines have this function inlined to code of saves-related functions. In other words, we have same behavior and different interface. So after discussion with mentor we decided to unificete interface of save files name generation and make all engines compatible with this interface. Then we produced some requirements to name generation function:
It’s needed to make a recording self-sufficient and independent from save files. At the moment, user should make following sequence of actions to playback loaded game:
This week I’ve just did little code refactoring and moved all playback file related issues to separate class. Also, following my mentor’s advice, I implemented cache for recording dialog. Now It reads every file header before adds it to list, store file’s header to array and every time when user update selected record, it doesn’t need to reopen the file.
What I want to implement now it’s to keep the game save in playback file, i.e. if we load file before recording, it shouldn’t ask what record you want to load. It should load it automatically. I’m not sure is it possible, but it may be great feature.
Last week I’ve added opportunity to view playback file screenshots directly from GUI. How it works you may see on the following video:
https://www.youtube.com/watch?v=trqPXKsAaCs
Also I’ve added dialog window to edit info about author, visible name and description of playback file.
https://www.youtube.com/watch?v=trqPXKsAaCs
During the work by GUI we’ve desided to move all operation with file to separate class. It should provide high flexibility and make possible to simple access to playback file. So I’ve added class PlaybackFile which works with file and provide higher level of abstraction.
It’s time to make gameplay recording more user friendly, cause rewrite config time every time when we want to record or to playback isn’t very fun. So we’ve begun work on GUI for recording and replay. First of all, I once again changed initialization routine of recorder, totally removed it from engines and call it at same time when the user choose game, so it became even better and transparent.
This week I made easy integration of recorder to engine. Now, engines inherited of AdvancedMetaEngine initialize registrator automaticaly. Few other, inherited from MetaEngine (SKY, SCUMM, SWORD1, SWORD2, QUEEN) can be initialized by adding only two strings:
#include “common/eventrecorder.h” g_eventRec.init(gameName());
I’ve tried registrator on number of games and at first view it works well. So, seems like it almost works and will ready to testing soon.
On this week, I fixed architecture mistakes in event registrator. When I’ve enabled registering of all time events (when somebody whant to know about system ticks) there strange mistakes occurred and it didn’t work at all. So, I’ve enabled registering time events only in some places of engine. But even in comments to my gsoc proposal, LordHoto noticed that need something to do with it, because when different parts of VM see different time, this will cause problems. In addition, direct replacement of g_system->getMillis() by the g_eventRec.getMillis() is bad, untransparent, unflexible, etc. At last, after one of commits, my mentor _sev proposed me to liquidate this dirty hack, by getting rid of all g_eventRec calls and doing registration of all g_system->getMillis() calls.