Gestion des sprites sous ExtGraph - Page 1

Bonjour à tous,

Mon projet BB avançant à une vitesse raisonnable (les 101 niveaux sont codés), j'aimerais passer à la suite à savoir:
- Comment sont codés les sprites 8x8, 16x16 en 4 niveaux de gris? C'est le même codage que pour TileMap Engine?
- Comment afficher un sprite (animé) sur une map? (La map est au format TileMap Engine qui est dans ExtGraph)
- Comment gérer l'interactivité d'un sprite avec la map (collisions avec le décor)?
- Comment gérer les collisions avec les autres sprites?

D'avance merci pour vos explication.

Cordialement.

Fred.

Heu ça me semble un peu génerique comme question, donc je sais pas si je vais être totalement à coté de la plaque mais peu importe, allons-y :

- Aucune idée, mais il y a en gros deux formats (enfin pas seulement, mais disons deux formats très répendus) : entrelacé et non-entrelacé. Dans le premier cas, tu as une ligne du plan clair puis une ligne du plan foncé (ou l'inverse), autant de fois qu'il y a de lignes dans le sprite (sachant qu'une ligne fait un 1, 2 ou 4 octets respectivement pour les sprites de 8, 16 et 32 pixels de large). Le non-entrelacé stoque toutes les lignes du plan clair, puis toutes les lignes du plan foncé (ou inversement, mais dans Extgraph ou tigcclib, c'est cet ordre-là). Sachant que c'est Sasume qui a codé le TileMap Engine, il me semblerait logique que ça fonctionne avec un format entrelacé (plus rapide), mais peut-être que Kevin a fini par réussir à lui pourrir son projet en le convainquant d'utiliser l'autre format (qui n'a pour seul avantage que celui d'être "compatible" avec les fonctions lentissimes de tigcclib).

- En géneral, ou bien il y a quelque chose de spécial à faire avec le TileMap Engine ? (je ne l'ai jamais utilisé). En gros, il suffit d'afficher ton sprite (en mode "masque") par-dessus la map, je ne comprends pas trop la question; et pour animer il suffit d'une variable qui s'incrémente tous les N tours de jeu, et qui va servir à selectionner le bon sprite parmis tous ceux qui composent l'animation.

- Là encore je ne sais pas si il y a des fonctions spécifiques prévues dans le TileMap, mais sinon il te faut une matrice qui contient autant de lignes et de colones que ta map, et dans laquelle tu vas enregistrer "l'état" de chaque case (sol, mur, plate-forme, etc...). Il suffira de lire ces cases quand un objet actif sera en contact avec elles; ce n'est qu'une solution, il en existe bien d'autres.

- Pas graphiquement, en tout cas; c'est ton code qui doit gérer ça, en comparant les coordonnées et les tailles de tes sprites en mouvement pour voir si ils se "touchent" ou non (et si possible, quand tu as beaucoup de sprites, trouve une solution pour limiter le nombre de tests à ceux qui sont visibles actuellement sur l'écran, par exemple, ça peut éviter de demander trop de temps de calcul).

P.S : C'est quoi le "projet BB" ?

Je suis en train de coder Bubble Bobble (BB) pour la v200 (et la TI-89t quand j'aurais les moyens d'en acheter une).

Le TileMap Engine utilise un mode entrelacé. ça ne pose pas de problème. J'ai fais une série d'outils wysiwyg pour coder les tables de tiles et les tables de maps. L'encodeur marche comme il faut et sor aussi bien du code C (pour TIGCC et TileMap Engine) que des fichiers binaires

Visiblement, l'encodage des sprites fonctionne comme les tiles alors? Si c'est le cas, le même outil qui me fait les tables de tiles, peut aussi faire les tables de sprites!

J'ai une matrice qui contient les données de la map pour pouvoir l'afficher. Je comptais m'en servir pour l'interactivité entre les sprites et le décor. Je mets également cette même matrice à jour pour faire les scrollings circulaires (scrolls infini) horizontaux et je rafraichi l'affichage de la map lorsqu'il y a un scrolling en haut ou en bas. La map fait 30x32 tiles de 8x8.

fred.

boulifb
: Visiblement, l'encodage des sprites fonctionne comme les tiles alors?

Exactement oui, y'a que le format qui peut éventuellement changer, mais l'avantage d'utiliser la même lib pour tout c'est justement que tu peux n'utiliser qu'un seul et même format de sprites (Extgraph gère les deux modes à ma connaissance, entrelacé et non entrelacé)

Pour les grays, il y a en effet les GrayClipISprite.
> Sachant que c'est Sasume qui a codé le TileMap Engine, il me semblerait logique que ça fonctionne avec un format entrelacé (plus rapide),
En effet.
> mais peut-être que Kevin a fini par réussir à lui pourrir son projet en le convainquant d'utiliser l'autre format (qui n'a pour seul avantage que celui d'être "compatible" avec les fonctions lentissimes de tigcclib).
Kevin a déjà pourri la calling convention avec son patch à la con qui utilise a4. J'ai forké la routine de grays de TIGCCLIB, le fork est la routine de gris par défaut d'ExtGraph 2.00 Beta 5 (qui arrivera bientôt).

A part ça, mais non, c'est pas vrai qu'elles sont lentissimes.
On s'en fout de la vitesse (il a dit une fois qu'il pouvait forker ExtGraph pour faire des fonctions optimisées taille - il y en a, même s'il ne le sait pas toujours, mais ça coûte en vitesse).
Elles sont optimisées taille: si jamais quelqu'un utilise les trois modes OR, XOR et AND dans son programme, ça sera plus petit que d'utiliser les trois routines séparées d'ExtGraph - surtout que le vilain Lionel fait deux shiftings dans les "8" ! C'est ça qui compte.

Donc, à priori, je peux utiliser mon TileDesigner pour faire les sprites?
Ce dernier encode pour le TileMap Engine en mode entrelacé ou pour TIGCC en mode non entrelacé.
Si c'est le cas, j'ai juste à modifier le code pour donner la possibilité de faire des tables de tiles de 16x16 et 32x32 en plus du 8x8 actuellement géré.

Pour coder des images 8x8 j'utilise des unsigned char. Que faut-il utiliser pour du 16x16 et 32x32?

Je vais modifier le code de TileDesigner en conséquence

Fred.

boulifb
: Pour coder des images 8x8 j'utilise des unsigned char. Que faut-il utiliser pour du 16x16 et 32x32?

C'est la largeur qui compte. Puisqu'un pixel est représenté par un bit, il faut des chars (8 bits) pour faire des sprites d'une largeur de 8 pixels, et donc on utilise souvent des shorts pour 16 pixels et des longs pour 32 (tu peux utiliser 2 chars et 4 chars, mais quasiment aucune librairie ne fonctionne comme ça, à part XLib je crois).

ok c'est bon pour le codage
Mais j'arrive toujours pas à l'afficher avec ExtGraph

tu fais comment ?

ok, c'est bon... kevin et martial m'ont expliqué... ça tourne

Dans ExtGraph, il y a aussi des routines de test de collision

fred.