|
La programmation des sprites sera ce qu’il y a de plus long à programmer. En effet le moteur de TDXSpriteEngine anime bien tous les sprites qui lui sont liés met il ne fait qu’appeler les procédures qui sont dans les
sprites ou TimageSprite.
Pour commencer il faut quelques règles pour respecter un codage simple et facile à manipuler.
Tout d’abord, un sprite ne doit être appelé que par son composant TDXSpriteEngine. Si il devait être appelé autrement, ce serait par l’intelligence artificielle ou parce que c’est un joueur et encore.
En effet à partir du moment où une sprite est créé, il doit être entièrement autonome jusqu’à sa mort. Normalement le seul moment où vous le manipulez est quand vous le déclarez :
with TImageSprite.Create(DXSpriteEngine.Engine) do
begin
X:=30;Y:=40;
End;
Destruction de tous les sprites pour changement de niveaux : SpriteEngine.Engine.Clear;
La façon dont vous ferez vos sprites sera hiérarchique : Un sprite quelconque aura la possibilité d’être descendant du sprite principal. Cela permet d’introduire des données supplémentaires dans vos sprites. Par
exemple, le sprite TSpriteJoueur1 est descendant de TSpriteJoueur. Celui là est descendant de TSpritePrincipal qui lui est un TImageSprite.
Un sprite bouge par la méthode domove :
TSpriteEnnemi = class(TSpritePrincipal)
private
procedure DoMove(MoveCount: Integer); override;
end;
C’est une procédure propre à delphi x qui est appelée par TDXSpriteEngine.Move ou par Move du sprite.
C’est la procédure DoMove qui anime le sprite. Il est préférable de la mettre dans le sprite hérité qui sera créé. C’est pareil pour les méthodes DoCollision et Create. Ce que vous devez faire par contre pour éviter
de saturer la mémoire, c’est de mettre les procédures de mouvement qui concernent tous les sprites ‘par exemple les détections de dépassement de l’écran) dans le TSpritePrincipal. Tout ce qui concerne les ennemis
tels l’intelligence artificielle et ses pointeurs doivent être dans TSpriteEnnemi.
Voici par exemple le code d’une déclaration de balle :
type
TSpritePrincipal = class(TImageSprite)
Procedure CreePrincipal; // procédure
d’initialisation appelée par la méthode create située à la fin de la hiérarchie de sprites
end;
TBalle = class(TSpritePrincipal)
procedure DoMove(MoveCount: Integer); override; // A mettre à la fin de la hiérarchie
procedure IntelligenceBalle; // Je l’ai ajoutée mais une balle n’en a que très peu
procedure BallePlombNormal(Choix:integer);
Procedure BalleFolle(Joueur : TSpriteJoueur);
// Gestion des collisions
procedure DoCollision(Sprite: TSprite; var Done: Boolean); override; // A mettre à la fin de la hiérarchie
procedure Destruction; // procédure qui joue un son avant d’appeler le
destructeur dead.
public
constructor Create(AParent: TSprite ); override; // A mettre à la fin de la hiérarchie
end;
Les procédures Balle folle et balle plomb sont appelée par l’intelligence artificielle qui est appelée par DoMove.
La procédure DoCollision sère à détecter quels sprites ont été touchés. Il est préférable d’appeler DoCollision par la méthode Collision dans DoMove des
sprites les moins nombreux à l’écran. Dans mon casse - briques, l’animation devenait trop lente quand les collisions étaient gérées par les briques. DoMove gère par ailleurs certaines des collisions. Par exemple les
murs indélibiles.
La procédure Create sert à tout sauf à positionner le sprite sur l’écran. En effet le sprite n’étant pas tout seul, il faut pour chaque sprite créé le
positionner après la méthode create. Par contre la méthode create gère le plan (propriété Z) dans lequel se trouve chaque type de sprite. D’ailleurs vous pouvez pour cette propriété décalerer des constantes qui
serviront à identifier tous les plans de votre animation. La méthode contient l’initialisation du sprite : si il est visible (propriété visible), si il bouge (propriété Moved), si il est indépendant (propriété
Collisioned) . Ou d’autres variables à intialiser : le compteur d’existence du sprite si c’est une simple animation supplémentaire par exemple.
|
