Projet ROLO : Baldur's Gate like - Page 5

119> tu fais un editeur de niveaux on-pc
ou alors, un editeur de niveaux on-calc, qui cree un fichier externe conforme au format de niveaux, et qui contienne tout (la map, les sprites, ...)

Tu peux faire un éditeur de persos qui rajoute ce qu'il faut là où il faut...

mouè

ms je v d'abord essayer la fonction ExtGraph correspondant à BitmapPut. Tt ce que vs dites c bien bô, ms c pa du gateau...
et ça modifierait une bonne partie de mon moteur de jeu auquel j'ai peur de toucher de peur de m'enfoncer à nouveau dans une mare de problemes...

oui mais tu gagnerait pas mal en place, en lisibilité et en rapidité aussi si tu n'as pas à chercher le fichier contenant le sprite à chaque fois pour lafficher...

Argh ! J'espère que tu ne cherches pas à chaque fois le fichier contenant le sprite pour l'afficher ! J'espère que tu fais ça juste une fois au début, et c'est tout !

Dans tout les cas, ton prgramme sera plus petit et plus rapide, comme l'a souligné Ximoon, si tu suis nos conseils.

ouè

ms si vous vlez je peux vs expliquer mon système en gros, ms c assez long...

Vas-y, ça pourra toujours être intéressant

alors:

bon déjà le paysage, c'est organisé sous formes de sprites 16x16, comme ts les programmeurs le font

ms le truc le plus dur, c'est les persos.
chaque perso sur une map est répertorié dans un espace mémoire que j'appele la table de GOs (game objects)
et avec lui y sont répertoriés sa vie, son mana, et certaines valeurs qui ont besoin d'être modifiés pendant le jeu.

ms toutes les autres valeurs fixes (nom de l'image PIC du perso, vie et mana par défaut, nom du perso, valeurs d'attaques et de défenses, nom du fichier script d'intelligence artificiele...) sont stockés dans un fichier à part que japel la template database.
et pour chaque type de GO y est réservé 100 octets en fait...

vs me suivez juske là ?

vas-y poste tout

ouè bon ok

alors dans son entrée dans la gotable, chaq GO possède le numéro de son template, pour qu'on puisse facilement y accéder...

en fait c'est ça la base mais après je vais pas trop rentrer dans les détails...

Donc dans ton fichier à part tu as les noms des PICs
Ces PICs, tu les utilises comment? Disons que tu doives affiche le sprite d'un perso... est-ce que tu trouves l'adresse du sprite une fois lors ed l'initialisation du prog ou alors tu la cherches à chaque affichage?

mouè...
ms c kan mèm assez rapide...

Rapide? sur ton screen ça se voit pas
Nan sans rire tu devrais remanier tout ça

Amosé a écrit :
mouè...

Mouè quoi ? Tu utilises la première ou la deuxième technique ?

bon je v essayer

ms admettons que j'optimise l'affichage des PICs, tous les autres trus je pourè pas plus les optimiser. Ya plein de calculs à chak affichage !

jackiechan> oops dsl
je la cherche à chak affichage

Tu veux mon avis? Tes fonctions de recherche des sprites et leur affichage prennent au moins 50% de ton temps de calcul. Je me trompe peut-être, mais en améliorant ça ça sera infiniment plus rapide, calculs d'IA ou pas

merci pr les conseils je v essayer...

Oui, le minimum à faire est d'optimiser la recherche des fichiers PIC pour avoir les pointeurs vers les structures BITMAP tous en même temps. Et ensuite, tu ferais bien d'utiliser les routines Sprite8X de ExtGraph à la place de BitmapPut. Attention, avec Sprite8X, tu dois lire les indicateurs de largeur et de hauteur au début de la structure toi-même, puis passer directement le pointeur vers les données. Et selon le mode d'affichage que tu utilises, il risque d'y avoir des problèmes avec des sprites dont la taille horizontale n'est pas multiple de 8.

j'ai un problème avec Sprite8X.

Lorsque je l'affiche, j'ai l'impression que le sprite affiché est correct, mais chaque ligne est décalée de pas mal de pixels...

Ton buffer fait quelle taille ?

?

Si c'est l'écran virtuel, il fait la taille normale : 3840 bytes. C'est en fait LCD_MEM.

C'est bizarre, si cette fonction était buggée, la TICT l'aurait déjà corrigée, je pense.
Est-ce que tu peux reporter ici la ligne où tu fais appel à la fonction ?

On suppose que j'ai déjà stocké l'adresse du début du fichier PIC dans la variable "adr", sans compter le word de taille du handle.
On suppose aussi que les coordonnées du sprite sont dans gox et goy :

short hei,wid;
hei = peek_w(adr);
wid = peek_w(adr+2)/8;
SpriteX8_OR( gox, goy, hei, adr+6, wid, LCD_MEM );

il faut que tu mettes adr+4, je pense, au lieu de adr+6

euh oui dsl g mal recopié javè mis adr + 4.

Les lignes sont décalées comment ?
Les unes par rapport aux autre (le sprite s'affiche en diagonale) ?
Décalées par rapport aux coordonnées auxquelles tu demandes d'afficher ?

Elles sont décalées les unes par rapport aux autres, sauf que à chaque ligne elles sont décalées d'environ 20 pixels...

Tu doit te tromper dans le paramètre bytewidth car il correspond à ceci:
((w-1)>>3)+1 ou w représente la taille de ton image en pixels. Donc tu lui soustrait 1 puis tu décale de 3 bits vers la droite et tu ajoute 1 et tu as la taille de l'image en longueur en octet.

On a pas besoin de la hauteur pour la calculer ?