Most Efficient Sprites Question

[TerryRitchie]

One thing to keep in mind if you need to flip or change the size of your sprites it will really start to slow down your program doing it with _PUTIMAGE. IF possible you should have them already at the size and rotation you need or use _PUTIMAGE to do all that work to a _NEWIMAGE when your game first starts up to avoid any possible slow down while running.

I don't understand, you're already using _PUTIMAGE to display the sprite. I can see that maybe it takes a tiny bit more CPU power to resize an image using _PUTIMAGE but flipping should take nothing more. With flipping you're just changing the start and end x,y coordinates which controls the direction of flip you desire.

[SMcNeill]

One thing to keep in mind if you need to flip or change the size of your sprites it will really start to slow down your program doing it with _PUTIMAGE. IF possible you should have them already at the size and rotation you need or use _PUTIMAGE to do all that work to a _NEWIMAGE when your game first starts up to avoid any possible slow down while running.

I don't understand, you're already using _PUTIMAGE to display the sprite. I can see that maybe it takes a tiny bit more CPU power to resize an image using _PUTIMAGE but flipping should take nothing more. With flipping you're just changing the start and end x,y coordinates which controls the direction of flip you desire.

I think I can explain the overhead that *MIGHT* be going on with flipping for you, in a way that'll be quite easy to understand. 

Let's take a simple 3x3 sprite (as that's very easy to represent as pixels)

123
456
789


Now, to copy this sprite directly, we can read it and copy it row by row.  1 pass, we read (123), put it.  Then read (456), put it.  Then read (789), put it.   Read 3 blocks of memory, put them.

Now, if we want to rotate this image 90 degrees, what wouuld we do?  Read 7.  Read 4.  Read 1.  (These aren't adjoining regions of memory so reqire individual reads.)  Put (741) to the top row.  Read 8.  Read 5.  Read 2.  Put (821) on the 2nd row.   Read 9.  Read 6.  Read 3.   Put (963) on the last row.

Now, if both routines are set up to read every point, without any sort of optimization (such as reading a whole row at a time), then there wouldn't be any change in perfomance.  But, if PutImage does plain puts in a sensible manner (row by row instead of point by point), there'd be quite a bit of difference in how it'd perform.

---

Now, with that said, I *honestly* don't know if _PUTIMAGE was ever optomized for quick read/write on direct placement.  There may not be any difference in whether you flip or rotate an image, or not.  I just know that this type of method *could* explain why flipping/rotating would be slower than a direct copy from source A to dest B.

[TerryRitchie]

One thing to keep in mind if you need to flip or change the size of your sprites it will really start to slow down your program doing it with _PUTIMAGE. IF possible you should have them already at the size and rotation you need or use _PUTIMAGE to do all that work to a _NEWIMAGE when your game first starts up to avoid any possible slow down while running.

I don't understand, you're already using _PUTIMAGE to display the sprite. I can see that maybe it takes a tiny bit more CPU power to resize an image using _PUTIMAGE but flipping should take nothing more. With flipping you're just changing the start and end x,y coordinates which controls the direction of flip you desire.

I think I can explain the overhead that *MIGHT* be going on with flipping for you, in a way that'll be quite easy to understand. 

Let's take a simple 3x3 sprite (as that's very easy to represent as pixels)

123
456
789


Now, to copy this sprite directly, we can read it and copy it row by row.  1 pass, we read (123), put it.  Then read (456), put it.  Then read (789), put it.   Read 3 blocks of memory, put them.

Now, if we want to rotate this image 90 degrees, what wouuld we do?  Read 7.  Read 4.  Read 1.  (These aren't adjoining regions of memory so reqire individual reads.)  Put (741) to the top row.  Read 8.  Read 5.  Read 2.  Put (821) on the 2nd row.   Read 9.  Read 6.  Read 3.   Put (963) on the last row.

Now, if both routines are set up to read every point, without any sort of optimization (such as reading a whole row at a time), then there wouldn't be any change in perfomance.  But, if PutImage does plain puts in a sensible manner (row by row instead of point by point), there'd be quite a bit of difference in how it'd perform.

---

Now, with that said, I *honestly* don't know if _PUTIMAGE was ever optomized for quick read/write on direct placement.  There may not be any difference in whether you flip or rotate an image, or not.  I just know that this type of method *could* explain why flipping/rotating would be slower than a direct copy from source A to dest B.

Yep, I see that, thanks Steve. I was a assuming a byte for byte copy but that may not be case.

[SMcNeill]

Asking the other devs, and checking the source, it does seem as if QB64PE likes to do this type of efficient copying -- when it can.

When can it do this:
Always for 256 color screens, but it'll do flip/scale/mirror separately first for a performance hit.
For 32-bit screens when it's a direct copy and _DontBlend is set, and there's no flipping, mirroring going on.  
If it's got to scale or flip (in either mode), it'll do that first, and then do a direct copy as long as it doesn't have to do blending.

When can't it do this:
For certain if it's got to blend two colors together.  Note that this is when _BLEND is on, not when you just cross your toes and think, "Welp, this doesn't need to be blended."  Be certain to tell the machine when it doesn't need to blend colors (such as when all your images are 255 alpha), or else it's going to always assume that it's got to.

So flipping/rotating *is* going to affect the speed, but the overall amount depends on various factors such as blending or not taking place.

[johannhowitzer]

Flipping is also generally not a great idea for sprite art - a lot of things tend to look obviously flipped, shadows from the wrong angle, etc.  Whenever possible, create the flipped versions in the sprite sheet.