This query is sort of a follow up to a previous query I had submitted about 10 days ago regarding the ability to create a form of hidden-buffer as we used do when programming games for the DOS operating systems. Jjagg kindly responded to providing some sample source code as well, which he demonstrated with the use of a RenderTarget2D object.
At this point I am nearly done implementing his suggestions into my own strategy war game. I hope to begin testing the results in the next day or so.
However, in a strategy game the user is constantly making unit movements with the game’s AI responding in kind. This would mean that new unit placements have to always be redrawn to the mapboard.
Is it a correct assumption then that in these cases the mapboard is then redrawn to the RenderTarget2D, making all the unit\sprite drawings to their new positions and then sending the RenderTarget2D object to the event that draws the map to the actual display?
As a result, the only time the RenderTarget2D object will not be redrawn is when the user is merely scrolling an existing instance of the mapboard\RenderTarget2D object…
Is this a correct understanding on how to use a RenderTarget2D object in this case?
Yes, your assumptions are correct. It is possible however to keep the render target contents when setting it as a target by passing RenderTargetUsage.PreserveContents to the RT constructor. If you do that you only need to redraw the parts of the map that changed instead of redrawing the entire map. Preserving contents can be quite an expensive operation on some hardware, so you may want to profile it if you care enough about performance.
I spent over 42 years as a software engineer in the corporate environments both as an employee and as a consultant before retiring in 2014. I have produced two commercial products of relative complexity (neither of which sold due to the nature of the professional aspect of the field currently) However, my deepest interest in all those years was to create a military simulation, which thanks to people like you and others on the MonoGame forum, has been made possible,
Though the work is progressing slowly, the articles I publish regarding it appear to be appreciated by those developers with similar interests in such development.
