http://lazyfoo.net/tutorials/SDL/index.php
After about tutorial 10 or so he stops linking to pages describing his tutorials (because he hasn't completed his tuts for SDL 2.0 yet) and only links directly to the source zips.
I decided to proceed by simply reading his source and making sure I understand it as I go along.
In tutorial 14 we do the first bit of animation utilizing something called vsync (no clue what that is or how it works) and an array of SDL_Rects clipped off of an image, representing each frame in a sprite sheet.
I did something similar about a year ago in java, so the techniques he uses seem familiar to me up to this point:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
//Render current frame
gSpriteSheetTexture.render( ( SCREEN_WIDTH - gSpriteClips[ frame / 4 ].w ) / 2,
( SCREEN_HEIGHT - gSpriteClips[ frame / 4 ].h ) / 2, &gSpriteClips[ frame / 4 ] );
//Update screen
SDL_RenderPresent( gRenderer );
//Go to next frame
++frame;
//Cycle animation
if( frame / 4 >= WALKING_ANIMATION_FRAMES )
{
frame = 0;
}
|
At first I was like "Why in the blue blazes does he access the array frames with an iterated int, only to divide said int by 4. By this logic (AFAIK), we're getting things like "gSpriteClips[0.25]," etc.
Actually scratch that, the results will be even more bizarre because it's an int, not a double.
The first two arguments in the render function are supposed to be X and Y coordinates, but the third is supposed to be an SDL_Rect*.
His use of "frame / 4" is even more bizarre to me when he uses it in an if statement. It seems to me that the animation will loop four times (through 16 frames) before the frame/4 >= WALKING_ANIMATION_FRAMES condition is met.
I tried removing each of the divisions by 4 and it seems to speed the animation up unreasonably, so I know WHY he's using this technique, I just don't understand how it achieves that effect. To me it just seems like he's returning unusable array indexes.
No lie, I just finished typing all this and it dawned on me that he might just be looping through each frame four times before moving onto the next. Can anyone confirm this?
If that's the case, is there a more optimized way to do this that doesn't call render four times? I notice he hasn't gotten to timers yet.