|
Hi
In my experience it depends on the kind of game you are making. If it is round based and only some parts need update then dirty updates might be worth. On the other hand, this is why the dirty sprite group kept it simple and just does union overlapping rects. But that is in no way optimal in all situations. Like here, more pixels would be updated instead of just the two rects and overdraw: +---+ +.+---+................................+ | | ' | | ' | | ' | | ' | | ' | | ' | | ' | | ' | | ==> ' | | ' | | ' | | ' +--------------------------------------+ +--------------------------------------+ | | | | +--------------------------------------+ +--------------------------------------+ | | ' | | ' +---+ +.+---+................................+ And at a certain point I think updating the entire screen is faster than the calculations needed to find out witch areas are dirty or not (maybe this could be a percentage of the screen area?). Also when using multiple layers of sprites and marking one sprite dirty, it should mark all overlapping sprites in all layers as dirty and re-draw them too (clipped to the dirty rect, in the right order). The fastest thing would probably be to have a dirty bit mask where you mark rectangles of bits that are dirty and just blit as many sprites you want, only the dirty pixels should then actually update on screen. There would still be overdraw (in memory) but clipped inside of the dirty areas and not on the screen. Not sure if single pixels can be updated and how fast it would be to just update certain pixels. I don't think that overdraw can be avoided in all cases (what if the sprites are half transparent on different layers? Or have holes in it? Then you need overdraw!). I think more important would be to have a nice and fast way to cull not visible sprites. This gets more difficult if parallax scrolling is used besides of scrolling in the world (then a world -> screen transformation and vice versa is needed (for mouse click to object conversion)). Culling enabled me (and my team) to write a game like as in the last pyweek [1] . It would not been possible otherwise (too many sprites to draw outside of the screen, probably the python part of handling those slowed it down too much, but with culling it was not such a problem). So at the end, it still depends on the kind of game. For fast graphics use dedicated hardware, on slower machines dirty update might still help. I still would like to try certain things out, but not sure how much time I will have in the next months. ~DR0ID [1] https://pyweek.org/e/codogupywk23/ On 28.03.2017 16:20, Leif Theden wrote:
|