qui peux me donner quelques cours pour la création de jeux

[G-Rom]

en asm , c'est tout de suite plus clair , je me demande dès fois pourquoi on à inventé le basic...

[Fig]

Code : Tout sélectionner

  CALL  _PB_SpritePixelCollision@24

Ce n'est pas mieux optimisé en asm que la double comparaison... Sauf si tu sais ce qui se trouve dans cet appel...
Mais tu as raison, c'est plus simple pour un débutant

[Backup]

ben c'est surtout le nombre de ligne asm qui me fait dire que moins il y en a mieux c'est ..
plus de directives , implique ,plus de manipulations mémoire, et plus de temps de traitement ... enfin...j'imagine


@G-rom : oui , effectivement, mais tu vois ç'etait juste pour voir ce que le purebasic pondait
et comparer le nombre de ligne de traitement ....

comme je le soupçonnais , les fonctions toutes faites de Purebasic , sont quand meme relativement optimisées

certes, il y a moyen de faire mieux a la main , mais pour un compilateur, il faut qu'il génère un code
qui soit le plus "Standard" possible pour pouvoir tourner quelque soit la config

mais ça tu le sais déja

[Reedit]
@Fig : ha oui effectivement, il appel la librairie.. j'avais zappé le truc !!!

[blendman]

Dobro : c'est vrai que c'est plus simple pour un débutant. Et même spritecollision().
En fait, j'ai mis ça par habitude, car je fais mes tests de collision comme ça, avec des bounding box spécifique ^^'.

Tiens, sinon, une question que je me posais :
spritewidth() : purebasic stocke la taille au début du jeu ou il recalcule la taille à chaque fois qu'on utilise cette fonction ?
Edit : en testant, j'ai l'impression que le spritewidth() est un peu moins rapide que de stocker la taille du sprite (bon, sur 100 000 interrogations on commence à voir une très légère différence)

[Backup]

Dobro : c'est vrai que c'est plus simple pour un débutant. Et même spritecollision().
En fait, j'ai mis ça par habitude, car je fais mes tests de collision comme ça, avec des bounding box spécifique ^^'.

Tiens, sinon, une question que je me posais :
spritewidth() : purebasic stocke la taille au début du jeu ou il recalcule la taille à chaque fois qu'on utilise cette fonction ?

ben a mon avis , il le calcul a chaque fois !!

l'assembleur de la fonction :
sur la ligne :

Code : Tout sélectionner

a=spritewidth(1)

Code : Tout sélectionner

; a=spritewidth(1)
  PUSH   dword 1
  CALL  _PB_SpriteWidth@4
  MOV    dword [v_a],eax

on vois qu'il fait appel a la fonction qui renvoie le résultat dans le registre Eax
et que Eax est récupré par la variable a

cela signifie que si tu utilise

Code : Tout sélectionner

a=spritewidth(1)

tu fais appel une seule fois a la fonction , ensuite si tu utilise "a" l'appel ne se fera plus

par contre si dans une fonction , tu utilise la fonction "spritewidth(1)"
genre :

Code : Tout sélectionner

Resultat = GrabSprite(#Sprite, x, y, spritewidth(#Sprite), Hauteur [, Mode])

l'appel aura lieu a ce moment
et si ça se trouve dans une boucle, ce sera a chaque fois !

mieux vaut utiliser une variable en debut de routine
et utiliser cette variable par la suite

donc :

Code : Tout sélectionner

largeur=spritewidth(1)


;; puis ensuite :
Resultat = GrabSprite(#Sprite, x, y, largeur, Hauteur [, Mode])

[blendman]

Merci pour ta réponse détaillée, Dobro

[Fig]

Je dirai que cette valeur est pré calculée. Parce que l'esprit de Purebasic c'est de garder ce genre de valeur, pour ne pas perdre du temps. Comme pour listsize()

Renvoie le nombre d'éléments contenus dans la liste spécifiée. Cette fonction ne modifie pas l'élément courant. Elle est très rapide (elle utilise une valeur précalculée) et peut être utilisée sereinement pour savoir si une liste est vide ou non.

La fonction appellée contiendrait juste la lecture de cette valeur pour le sprite donné.

A vérifier, mais je ne vois pas trop pourquoi le sous programme calculerai la largeur du sprite a chaque fois...

[Backup]

A vérifier, mais je ne vois pas trop pourquoi le sous programme calculerai la largeur du sprite a chaque fois...

ben en fait on transmet le numero du sprite sur la pile

la fonction calcul en temp reel la largeur du sprite , puis renvoi le resultat dans Eax !

comment la fonction pourrai garder la valeur ?
il suffit de voir l'appel en Assembleur que j'ai posté pour se rendre compte qu'il n'y a rien d'autre de sauvé !
pourquoi faire ? , garder une valeur de largeur , qui ne servira peut etre plus ...
vu que l'utilisation standard c'est de récuperer cette valeur dans une variable ..

code assembleur commenté

Code : Tout sélectionner

; a=spritewidth(1)
  PUSH   dword 1 ; on pose le numero de sprite sur la pile
  CALL  _PB_SpriteWidth@4 ; on appel la fonction qui calcul la largeur du Sprite ( cette fonction recupere surement le DC)
  MOV    dword [v_a],eax ; on pose le retour de la fonction dans la Variable A

[Fig]

Le contenu de la fonction CALL _PB_SpriteWidth@4 est probablement très courte en fait.
Calcul de l'adresse de la largeur du sprite en fonction de son numéro puis un simple mov aex,[adresse largeur du sprite]

Par exemple pour un sprite chargé en bmp, PB créé directement les valeurs de l'image, largeur, hauteur, profondeur de couleur, à partir de l'en tête du fichier.

[Kwai chang caine]

Et ben mon vieux..je regarderais plus jamais une BMP de la même manière
Quand on explique en détail c'est comme pour l'ASM..comme dirait notre militaire....c'est beaucoup plus compréhensif
Mais l'important c'est que JB, puisse faire son jeux grâce à toutes ces explications

Quoi qu'il en soit merci de l'explication FIG

[Backup]

@Fig :
oui ben tu explique que LoadSprite() se sert de l'entete de l'image ,pour fabriquer un sprite et alors ?

ça ne signifie nullement qu'il garde ces infos quelque part !

d'ailleurs si c'etait le cas , les fonctions comme "SpriteWidth(#Sprite)" n'aurai aucun sens !
puisque PB saurai deja le format du sprite XX

ce que tu decris serai valable dans un interpréteur , mais là on est dans un compilo
et je ne vois pas pourquoi PB garderai cette info ! (et ou la garderai t'il ????? )

c'est pourquoi il existe un parametre de retour , c'est pour que toi, le codeur tu garde cette info dans une variable !

[Fig]

Voyons, comment est stocké un sprite en mémoire et comment l'affiche t'on ?

Un sprite en mémoire c'est une suite d'octets. Il n'y a pas de bord qui indiquent la fin d'une ligne et le passage à la suivante.
Pour l'afficher dans la zone mémoire vidéo, il faut bien connaitre la longueur d'une ligne et le nombre de ligne (largeur et hauteur du sprite)

Quant à savoir où ces infos sont stockés... Fred le sait

Enfin si je devais deviner, je ferais une table faisant correspondre le numéro de sprite avec l'adresse de ce sprite en mémoire et j'y placerai aussi ces informations.

[Backup]

alors SpriteWidth(#Sprite) ne sert a rien !

un sprite est un conteneur
qui se formate a la creation ou au chargement d'une image

du coup , il est probable qu'il soit stocké lineairement dans un espace memoire
dont le numero de sprite est une information de position dans la ram

a partir de la effectivement pb connais la taille du sprite !

mais cela ne signifie pas qu'il la connait sous la forme x=10 y=50

mais que la fonction SpriteWidth(#Sprite)
regarde a l'emplacement memoire de ce sprite , et calcul la taille qu'il a
(il y a peut etre effectivement des infos de format dans cette memoire)

tu as raison

[G-Rom]

le plus simple pour savoir est de faire :

*ptr = LoadSprite(#pb_any,"...")

et de poké le pointeur

[Fig]

Je viens de le faire, visiblement peekW(*ptr) c'est la hauteur et *ptr+11 c'est la largeur... *ptr+8 c'est la profondeur de couleur (32bits)

Quelqu'un pourrait confirmer ?