reserved texpos range

[shevernitskiy]

This PR add reserved range feature to dynamic texture module.

Reserved range is a buffer in the textures.raws vector right after static game textures. Game will never wipes items of this range from the vector.

Now loadTilset(), loadTexture(), createTile(), createTileset() can receive additional optional parameter bool reserved which define target range (false by default, dynamic range).

close #3709

[shevernitskiy]

I almost lost in logic branches:)

[myk002]

at program close, DF will attempt to free all these textures. Is the refcount incremented somewhere so that it doesn't end up doing a double free?

[shevernitskiy]

game will perform FreeSurface for entire textures.raws (i guess)... so every texture with refcount = 1 will be destroyed (here we destroy dummy)
our cached surfaces has refcount = 2 and it will be decrmented to 1..
then Texture::cleanup() will be called in Core shutdown sequence, there we will one more time call FreeSurface for our cached surfaces and finaly destroy it

[myk002]

I note that we currently double free on exit with current code in 50.09-r3, so this is a real issue. I'll test to make sure this PR fixes that issue before merging, but otherwise this is looking pretty good

[myk002]

sorry for the conflicting changes in Textures.cpp -- df::global::enabler is NULL if we don't have the symbol map populated for a version, and the current usage was causing crashes and preventing us from investigating the upcoming 50.10 release

[myk002]

There is still a double free going on here and DF is aborting when it frees the textures in its array. Could you double check the refcounting logic?

commenting out the for loop in reset_surface() avoids the double free

[shevernitskiy]

On a win there is no errors on close, they are visible only while debugging. That's why i missed that.
For me commenting out reset_surface() solves nothing, debugger still catches the exception.
Increasing refcount for dummy to equal size of reserved range eliminate the exception.

[myk002]

could you possibly update this branch with latest changes from develop?

[shevernitskiy]

rebased onto develop