A fairly small iteration, the main use cases I implemented in this PR was the SPlat::Timeline class. SPlat::Timeline is an interface with a single function, SPlat::Timeline::get_time(): time_t, which returns time in a computer-interpretatable form. This is abstract enough to represent real-time -- by default, SPlat is centered around the system time -- or some abstract time -- for instance, another timeline tracks what display loop iteration the main window is on.
Two important non-use-case steps were also taken this iteration. First, SPlat::Events::Event was separated into two classes. Now, SPlat::Events::Event is simply an interface, whereas SPlat::Events::Command contains the state that the event needs, such as type, args, and priority. Second, SPlat::Runtime provides an extensible Singleton location for the highest-level policies, such as global timelines, a flag for whether the game is running or not, and anything else with such broad scope that may be needed in the future.
We used our display SPlat::Timeline object to implement client-side pausing/unpausing that should transfer over well for our client-server protocol. The main idea is that, if the window is paused, then we simply will not raise the updates for the relevant SPlat::Model::Assets, but otherwise continue running as normal. This stops the relevant SPlat::Assets from moving so much.
Refactoring the SPlat::Eventscomponent was very useful, and ended up solving a myriad of other problems. Before implementing my networked features, I would like to do the same with SPlat::Assets; our SPlat::Model::AssetFactory<T> class is OK, but not a substitute for a real abstract factory pattern, which we will need to be able to scale appropriately in a networked scenario. SPlat::Model::Assets do not obey SOLID principles which is causing some pretty major issues, and on top of that, they are not well synchronized. Adding a mutex requires us to write our own copy constructor, which then causes a slew of other problems... I would like to separate SPlat::Asset into a Facade-style component which can be serialized and deserialized as SPlat::Model::Asset::Properties. So, I'll just do that one step at a time. Hopefully it will resolve some of my existing bugs, but until that point, it will still be OK. We'll call it "Iteration 2.5".
A fairly small iteration, the main use cases I implemented in this PR was the
SPlat::Timelineclass.SPlat::Timelineis an interface with a single function,SPlat::Timeline::get_time(): time_t, which returns time in a computer-interpretatable form. This is abstract enough to represent real-time -- by default,SPlatis centered around the system time -- or some abstract time -- for instance, another timeline tracks what display loop iteration the main window is on.Two important non-use-case steps were also taken this iteration. First,
SPlat::Events::Eventwas separated into two classes. Now,SPlat::Events::Eventis simply an interface, whereasSPlat::Events::Commandcontains the state that the event needs, such as type, args, and priority. Second,SPlat::Runtimeprovides an extensible Singleton location for the highest-level policies, such as global timelines, a flag for whether the game is running or not, and anything else with such broad scope that may be needed in the future.We used our display
SPlat::Timelineobject to implement client-side pausing/unpausing that should transfer over well for our client-server protocol. The main idea is that, if the window is paused, then we simply will not raise the updates for the relevantSPlat::Model::Assets, but otherwise continue running as normal. This stops the relevantSPlat::Assets from moving so much.Refactoring the
SPlat::Eventscomponent was very useful, and ended up solving a myriad of other problems. Before implementing my networked features, I would like to do the same withSPlat::Assets; ourSPlat::Model::AssetFactory<T>class is OK, but not a substitute for a real abstract factory pattern, which we will need to be able to scale appropriately in a networked scenario.SPlat::Model::Assets do not obey SOLID principles which is causing some pretty major issues, and on top of that, they are not well synchronized. Adding a mutex requires us to write our own copy constructor, which then causes a slew of other problems... I would like to separateSPlat::Assetinto a Facade-style component which can be serialized and deserialized asSPlat::Model::Asset::Properties. So, I'll just do that one step at a time. Hopefully it will resolve some of my existing bugs, but until that point, it will still be OK. We'll call it "Iteration 2.5".