... and everything built around them.
A GameSave would hold at least one but sometimes two representations of a save:
one serialized, and one "friendly", accessible for modification. Thus, a
GameSave would have three states:
- "Collapsed": only the serialized representation was present; this was the
initial state of GameSaves loaded from files;
- "Expanded With Data": both the serialized and the friendly representations
were present; this was the state of GameSaves loaded from files after a call
to Expand;
- "Expanded Without Data": only the friendly representation was present; this
was the initial state of GameSaves being prepared for being saved to files.
A GameSave would be able to go from Collapsed to Expanded With Data with a call
to Expand, and back with a call to Collapse. Of course, this latter transition
would discard any changes made to the friendly representation, for example with
Translate. A GameSave would however be unable to go from Expanded Without Data
to any other state; a call to Collapse in this state would have been a no-op.
There were two instances of Collapse being called, one in the GameSave
constructor taking the serialized representation, immediately after a call to
Expand, and another in SaveRenderer, which would Collapse a save "back down" if
it had originally been Collapsed. Now, consider that there reasons for
constructing a GameSave from the serialized representation are as follows:
- loading an online save at startup from the command line;
- loading a local save at startup from the command line;
- loading a local save when it is dropped into the window;
- loading a local save for placement of the most recently used stamp;
- loading a local save for stamp placement via Lua;
- loading an online save for preview generation while browsing;
- loading a local save in the stamp browser for thumbnail generation;
- loading a local save in the local save browser for thumbnail generation.
In some cases, the friendly representation is needed for thumbnail generation
by ThumbnailRendererTask. ThumbnailRendererTask operates on its own copy of the
GameSave, because it runs SaveRenderer on a thread different from the main one
and cannot be sure of the lifetime of the original GameSave. It destroys this
copy when it is done rendering, so the call SaveRenderer makes to Collapse is
pointless.
In all other cases, the friendly representation is needed immediately. In some
of these, SaveRenderer is used from the main thread, but since the friendly
representation of the GameSave will be needed for pasting anyway, the call
SaveRenderer makes to Collapse is pointless again.
So, Collapse goes away. This also means that it is pointless for GameSaves to
hold on to the serialized representation, since in all cases in which they have
access to it, the friendly representation is needed immediately, and with
Collapse gone, they will never need it again.
This made it possible to get rid of two GameSave constructors.
Also clean up Client::LoadSaveFile, Client::ReadFile, and Client::WriteFile in the process, and remove unused SaveRenderer::Render
Also clear SaveRenderer graphics cache along with the main Renderer's when needed, and revert to built-in element callbacks rather than nothing at all when assigning nil to a callback slot in Lua.
There are *no* more spacing issues. I used tabs exclusively.
Also, I made changes off of the develop branch.
Here's the Ruby regex that I used:
text.gsub!(/(( |\t)*)if ?\((.*)\) ?{?\n?( |\t)*(free ?\(|delete |delete\[\] )(.*)\)?;/, "\\1\\5\\6;")
I've left some of the less important items, like SearchView.cpp "'then' statement is equivalent to the 'else' statement", and RequestBroker::Request::~Request, because I don't feel like spending a few days entirely rewriting those files at the moment (which is what I'd end up doing if I started fixing minor problems and refactoring...)
GameSave::readOPS - not changed. At some point we may have to move to a larger type for element IDs (probably two or four bytes), but PT_NUM isn't likely to be raised to the maximum value of that type immediately, so this check will be needed then. There should be an elements[partsData[i]].Enabled check in there too, but it might be a bit difficult - I'm not sure how to access a Simulation object from GameSave::readOPS...
Notes on changes:
Graphics::textsize, Element_FRZW::Element_FRZW - typos
Button::Draw - the extra case was originally used to invert the icon (draw it in black instead of in white) when the button was clicked. However, the icon colour is now automatically set depending on the background colour. (Note similar conditions "if(Enabled) { if(isButtonDown || (isTogglable && toggle)) " near the start of the function - same logic but in a different place, setting icon colour indirectly).
Simulation::transform_save - unused redundant function, everything uses GameSave::Transform which does much the same thing.
PreviewView::NotifySaveChanged - should be height==YRES/2, it's checking whether the preview image is the correct size, and resizing it if it isn't.
Element_FWRK::update - no idea why that line was there, even though it was my commit that originally added it...