Why isn't the sprite manager created as its own class similar to Sprite ?
A1:
Although the sprite manager code has been created in a class of its own, its tight integration with the game engine made it simpler to just place the sprite management code directly in the engine. If the code resided in a separate class, you'd have to do a fair amount of work making sure that the game engine could communicate with the sprite manager, and vice versa. This is a situation in which it's easier to forego a strict OOP approach of sticking everything in its own class, with the benefit being a more simplistic design.
Q2:
I'm still having trouble understanding how the AddSprite() function affects the order of sprites in the sprite list according to their Z-order. What gives?
A2:
It works like this: The Z-order of a sprite determines its depth on the screen, with higher Z-order values resulting in sprites that are more visible. In other words, a sprite with a Z-order of 3 would appear to be sitting on top of a sprite with a Z-order of 2 . The practical way to achieve this effect is to draw the topmost sprite last. Or to put it another way, you draw all the sprites in order of increasing Z-order, which naturally means that the higher Z-order sprites appear to be on top of the others. The AddSprite() function enforces this system by making sure that the sprite list remains sorted by increasing Z-order as new sprites are added. The Z-order of the sprites is then automatically factored in when drawing the sprites because the sprite list is already sorted accordingly .
