Kamilche schrieb:
I'm not seeing a speed increase on my machine. I get 449 with yours,
and 583 with Brian's version (more aggressive dirtyrect handling.)
You DID bump his square count down to 10 before testing, right?
Because he had added 80 squares in there, which made it test slower
until you set it back to 10 squares.
--Kamilche
Hi
Brians's version with 10 squares run at ~400 fps on my machine (
PentiumM 1.5GHz, 1GB ram, WinXP).
Your original runs with about ~400 fps.
(Just downloaded both to be sure I had made no changes)
I'm sure you will see differences with more object's moving or
static, because there the code becames more possibilities to
optimize. Try it with 100 moving rects and take a look at the dirty
rect's on screen.
Btw, I use also his code, because it is faster and more accurate as
any other I have tried, including mine. You also can see it in my
code pressing "d" and perhaps "f" (20 fps) or "s" to step trough frames.
Well I found out that one must use for all graphics the same
bitdepth, if not, it makes things a lot slower. All images should be
"converted". The other thing is, I use a background image to redo the
background (technically I could put there an image, no problem). That
is faster than filling areas I think. Your code can also be faster,
but it need some touches. I'm still amazed of the clarity and
simplicity of your code. ( mine is big an messy until now). If you
want I can take closer look to help make it faster.
Btw what are your fps of my code on your machine? Its for my statistic.
~DR0ID