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:
In my experience, I've found it is better to optimize the game as if
the whole screen was being updated at the same time. The effect
being, I never bother with dirty updates. It seems that many games
will have moments of brief full or near full screen updates, and time
spent optimizing the screen updates is effectively wasted.
On Tue, Mar 28, 2017 at 7:19 AM, Jason Marshall
<jasonmarshall...@gmail.com <mailto:jasonmarshall...@gmail.com>> wrote:
I tested the effect of my optimize_dirty_rects script that René
mentioned, and I found that the time spent in my optimization
algorithm exceeded the time saved by blitting fewer pixels. :-(
I've thought about reimplementing it in Cython to see if that
would make the algorithm run fast enough that its overall effect
is to save time, but I haven't gotten around to doing that.
Jason
On Mar 26, 2017 2:50 PM, "René Dudfield" <ren...@gmail.com
<mailto:ren...@gmail.com>> wrote:
Because rectangles can overlap, it's possible to reduce the
amount drawing done when using them for dirty rect updating.
If there's two rectangles overlapping, then we don't need to
over draw the overlapping area twice. Normally the dirty rect
update algorithm used just makes a bigger rectangle which
contains two of the smaller rectangles. But that's not optimal.
But, as with all over draw algorithms, can it be done fast
enough to be worth it?
Here's an article on the topic:
http://gandraxa.com/detect_overlapping_subrectangles.xml
<http://gandraxa.com/detect_overlapping_subrectangles.xml>
jmm0 made some code here:
https://bitbucket.org/jmm0/optimize_dirty_rects/src/c2affd5450b57fc142c919de10e530e367306222/optimize_dirty_rects.py?at=default&fileviewer=file-view-default
<https://bitbucket.org/jmm0/optimize_dirty_rects/src/c2affd5450b57fc142c919de10e530e367306222/optimize_dirty_rects.py?at=default&fileviewer=file-view-default>
DR0ID, also did some with tests and faster code...
https://bitbucket.org/dr0id/pyweek-games/src/1a9943ebadc6e2102db0457d17ca3e6025f6ca60/pyweek19-2014-10/practice/dirtyrects/?at=default
<https://bitbucket.org/dr0id/pyweek-games/src/1a9943ebadc6e2102db0457d17ca3e6025f6ca60/pyweek19-2014-10/practice/dirtyrects/?at=default>
So far DR0ID says it's not really fast enough to be worth it.
However, there are opportunities to improve it. Perhaps a more
optimal algorithm, or one which uses C or Cython.
"worst case szenario with 2000 rects it takes ~0.31299996376
seconds"
If it's 20x faster in C, then that gets down to 0.016666.
Still too slow perhaps.
It's not an embarrassingly parallel problem... I think. But I
haven't thought on it much at all. Maybe there is a use for
multi core here.
Anyone done any other work like this? Or know of some good
algos for this?
cheers,
