Follow-up Comment #1, patch #863 (project wesnoth):
Seems like a nice design, and the use of map for z is cleaner that my
implicit stl-set sorting.
Just two small suggestions and a more ambitious one:
- since the enum tdrawing_layer will fix the order and number of layers, we
can use a simple vector instead of a map for these layers. That will spare
the search+insert in the map of layers done for each image. And also allow
some (maybe temporary) trick like: draw some layers (e.g. all terrains
layers), then call old un-adapted unit rendering code, then finaly draw the
last layers (linger etc..). Using iterator on map's keys(=layer) make it less
handy.
- I think that allowing tblit to store a vector of surface will ease your
life (as it did for me when I added the overload of tile_stack_append), a lot
of functions return a vector of surfaces (builder code, fog/shroud,
footsteps...) which will have the same x,y. With the one-surface tblit system
you will need to repeat the x,y and move all surfaces from one vector to the
vector of tblit. Also note that the builder function can return vector of
more than 10 surfaces, so creating a new tblit for each surface can even have
a performance cost.
- finally, if you like OOD, you can use an abstract tblit object supporting a
basic general draw(). Then layers can render something else that only
surfaces. Just create derived tblit classes, maybe some template tblit<T>
with T supporting a draw(x,y) operation. Example, for the previous proposal
about tblit having vector<surfaces> (=T), draw(x,y) will do an iterated blit.
So in short, abstract surface+blit to something+draw.
I think it can be very powerful and also ease the transition:
* it allow to simply implement a "unit layer", just use T=unit* and make
unit support draw(x,y) and that's it. A possibly useful trick could be to
allow the T object to interpret the x,y coordinates as hex location or pixel
coordinates, depending what it prefers to use.
* in general, for all our current little rendering functions (hp/xp
bars,
text in hex, etc..), you just need to store the parameters that we currently
use when calling it, and then the special T.draw(x,y) will do this call with
these parameters.
* Such T.draw(x,y) system also avoid that composite objects need to
build
and return a list of surfaces (+blit info). The layer system will tell it
where and when draw its things and it will do it itself. It can even reduce
the memory used by these layers (in those composite cases the parameters of
these rendering functions are often lighter that all the
[surfaces+offest+maybe clip_rect] that they draw)
* It also solve the problem of objects needing other SDL operations to
be
drawn (SDL_Rect or effects on the underlying image).
Mmmh sorry, I again go too far, anyways I hope that some of these ideas will
inspire you :-)
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?863>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
