02-10-2024, 10:20 PM
(02-10-2024, 09:44 PM)SMcNeill Wrote:(02-10-2024, 07:33 PM)TerryRitchie Wrote:(02-10-2024, 04:38 PM)Cobalt Wrote: 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.