Sorry your browser is not supported!

I've been reflecting on comparative performance for particle type effects where I can't use the built in particle system.
If you want to use particles in your own system, then these results will be interesting.. I compared the performance because I was interested to see the difference between the 3 methods and was somewhat surprised - here are the results on a low spec laptop.

Test 1:
2048 sprites (5x5) from image, with alpha on and no shape = ~210fps

Test 2:
2048 sprites from no image (5x5), with alpha on and no shape = ~258fps

Test 3:
2048 5x5 blocks drawn using the drawline command. No transparency or shape overheads = ~127fps

using a loop:



and expanded loop gave a eyebrow raising increase, but still nowhere near sprites: - ~158fps



Conclusion: I am somewhat surprised that this is the case. Obviously drawline is not as fast as I thought and in reality, you'd be better off drawing lines with sprites still for performance.

This example also indicates how expensive for/next loops can be in extremis (2048 hits to the loop per frame) so consider expanding your loops in this way for performance.

Reminds me of the old assembler days on the amiga where you had compiler commands such as REPT where you could repeat the same code n times to gain much needed frames.

This isn't all that surprising as the draw command is having to work 5 times, compared to a sprite which has the y depth covered by it's initial size, which can do it all in one pass. The draw command is better used for one off operations rather than all the time. It also makes the process of diagonal lines easier than using sprites. It is still faster to work out the maths (Not good I know for us dyslexic maths types, and I am sure that is a viable condition ), and use rotated/scaled sprites in AppGameKit than to use the draw command.
The question is, if you use a single draw command, rather than 5, and compare that to a 1 pixel sprite stretch/scale, which is the faster? I would guess the sprite, but it could be a lot closer when compared directly, and the draw command may be faster. I haven't tried this so am guessing.
For next loops are always a slow down factor, especially when using multiple loops. The smaller you can make them the better.

How do you think the pixels are drawn otherwise?
A sprite has to be drawn, as does a line.

i think this is where DrawLine should have a duplicate function by its core




if this new command will apear that basicly the line drawing command will be faster.

Yes, but in the actual AppGameKit code you are having to call draw line 5 times, compared to a sprite, which would require just one operation. I'm pretty sure the drawing commands are slower also, so that would exasperate things. The draw commands were put in to make things easier, not faster, unless they have been improved since first introduced.

I wasn't trying to be overly critical, I'm only a hobbyist programmer, just suggesting why the draw command could be slower in your test.

I was under the impression that the drawline command was relatively fast (sure I read that somewhere). However, it's not the case.

Without knowing how the retrospective commands are handled "inside" agk, we can only gauge the effects by experimentation.