modify ChooseInitialMap to throw NoAvailalbeMaps exception if no maps were loaded.
implement Utilities.TryWithPrompt - safe execution of a provided action with ability to prompt user on error.
Previously ReleaseBuffer did not immediately null out the buffer, instead the releaseBufferOnCommit flag allows it to be nulled when the texture is next access and the pending changes from the buffer are committed to it. Now the texture is committed immediately, thus the buffer is null once ReleaseBuffer returns.
Once loaded, we force a GC to reclaim temporary memory used during loading. Previously the buffer would not be null as it was pending commit to the texture and thus could not be reclaimed. As soon as we rendered the first frame, the buffer is nulled but we are now in a low GC state - and the buffer will not be reclaimed until the next gen 2 GC which may be dozens of minutes away.
This change ensures the buffer is null in time for the post-load GC, and thus can be reclaimed before we start rendering.
This avoids a crash that stops the maps from being updated
when the base mod ruleset is not valid (e.g. a trait is missing a
FieldLoader.Required property). This also significantly improves the
upgrade performance.
If the mapserver returned an unusable minimap blob, we'd end up dropping
the resulting exceptions on the floor, and committing a completely broken
MapPreview, which would then blow up the tail end of the map change
process, and all future ValidateClient calls after players join (which
itself was handled by kicking the player and logging some noise of dubious
value).
Adjusts exception handling in a number of places to log the exception
rather than dropping it on the floor, and makes the mapserver response
parsing tolerant of bogus minimap blobs -- in this case, we'd rather just
have no minimap.
Candidate for stable, as it fixes a bug present in the current release and
the current playtest series.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
The Download class cancels asynchronously, which means callers must handle cancellation inside the completion event, and not after requesting cancellation.
This was previously trying to use values that had
not yet been initialised, which meant that *all*
maps were treated as unsuitable. This would cause
the mod to always fall back to the first installed
map.
Not doing this can occasionally this can result in a cross thread call to the backing texture which leads to bad things. This stops trying to be clever regarding the thread safety invariants exposed by SheetBuilder and does things simply and safely: All updates happen on the main thread.
- Made Array.IndexOf available via extension method.
- Made ToHashSet extension method.
- Change collections queried often via Contains into sets.
- Avoid Count() extension if Count or Length property exist.
- Made Count() > 0 checks and variations calls to Any() instead.
- Don't call ToList/ToArray if there is no benefit to materializing the sequence.
- If the sequence does benefit from materialization, follow this general pattern:
- Collection queried often via Contains use ToHashSet to speed up lookups.
- Short lived variables use ToList. This is because ToArray requires an extra copy to output the final size.
- Collections persisted into fields or for a long time use ToArray to minimize memory overhead.
Textures, FrameBuffers and VertexBuffers allocated by the Sdl2 Renderer were only being released via finalizers. This could lead to OpenGL out of memory errors since resources may not be cleaned up in a timely manner. To avoid this, IDisposable has been implemented and transitively applied to classes that use these resources.
As a side-effect some static state is no longer static, particularly in Renderer, in order to facilitate this change and just for nicer design in general.
Also dispose some bitmaps.
The buffers in SequenceProvider can be freed if Preload is called, since we know everything is loaded. A SequenceProvider is created for each TileSet is use so this saves memory for however many tilesets had been used in the game. This will be at least one for the shellmap, and often more.
The MapCache loading thread is kept alive for 5 seconds after it last generated a map (in anticipation of more requests). Once this time expires the thread is allowed to die, as it is unlikely there will be more requests in the short term. At this time it is ideal to force the changes to be committed to the texture so we can release the buffer. As well as marking the buffer for release, we must access the texture to force the changes stored in the buffer to be written to the texture, after which the buffer can be reclaimed.
Additionally, when starting the MapCache loading thread we must ensure the buffer is created from the main thread since it may query the texture object which has thread affinity. After that the buffer may be modified freely on the loading thread until released.
