Introduced also a small Unit test project to prove it.
- Separated caching capabilities from PathFinder class to increase cohesion and maintainability.
Refactored the pathfinding algorithm by extracting methods based on responsibilities like
calculating costs and reordering functions. These changes should provide a in average a small increase in
pathfinding performance and maintainability.
- Optimized the pathfinder algorithm to reuse calculations like the
MovementCost and heuristics.
- Introduced base classes, IPathSearch and IPriorityQueue interfaces,
and restructured code to ease readability and testability
- Renamed the PathFinder related classes to more appropriate names. Made the
traits rely on the interface IPathfinder instead of concrete PathFinder
implementation.
- Massive performance improvements
- Solved error with harvesters' Heuristic
- Updated the heuristic to ease redability and adjustability. D can be
adjusted to offer best paths by decreasing and more performance by
increasing it
- Refactored the CellLayer<CellInfo> creation in its own Singleton class
- Extracted the graph abstraction onto an IGraph interface, making the
Pathfinder agnostic to the definition of world and terrain. This
abstraction can help in the future to be able to cache graphs for similar
classes and their costs, speeding up the pathfinder and being able to feed
the A* algorithm with different types of graphs like Hierarchical graphs
- 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.
To resolve the ambiguity introduced when the introduction of isometric maps meant that cell and map coordinates were no longer equivalent, a new type has been introduced so they can each be represented separately.
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.
This enables the map importer to map the .ini video definitions to ours.
The mapping generally is as follows:
Intro => BackgroundInfo
Brief => Briefing
Action => GameStart
Win => GameWon
Lose => GameLost
An issue in some Red Alert maps means that this mapping is not always
quite correct. In those maps that do not have a 'Brief' video defined
(scg03a is an example), Westwood has assigned the video that should
probaby have been the 'Action' video to the 'Intro' slot instead. I can
only assume that that was done due to some limitation in the original
game code. Mappers will have to correct that assignment manually in
those cases.
Reinitializing the initial cell info layer for the path search took a fair bit of time. We cache this initial setup so it only has to be done each time the map size changes. A CopyValuesFrom method in CellLayer is provided which copies values between layers by just copying the internal arrays for super speed.
This speeds up InitCellInfo 10x.
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.
