structure et optimisation

[blendman]

salut

Je me demandais ce qui était le mieux niveau performance :
- plusieurs petites structures
- une seule grosse structure

Par exemple, pour le personnage principal de mon jeu, j'ai ceci :

Code : Tout sélectionner

structure StPlayer
sprite.w
x.w
y.w
viemax.w
viecourrante.w
magiemax.w
magiecourante.w
xp.w
levelcourant.a
levelprochain.a
force.w
dexterite.w
sagesse.w
agilite.w
intelligence.w
humour.w
sympathie.w
chance.w
quete_etape.w
; etc.....
endstructure

Et encore environ 50 autres champs.

Je me demandais si c'était mieux de découper en plusieurs petites structures, lorsque je dois changer la valeur d'un champs, par exemple la viecourante, cela ira t-il plus vite si j'utilise des petites structures ?

par exemple, en faisant ce genre de chose :

Code : Tout sélectionner

structure StPlayer
sprite.w
x.w
y.w
endstructure

structure StPlayer_stat
viemax.w
viecourrante.w
magiemax.w
magiecourante.w
xp.w
levelcourant.a
levelprochain.a
force.w
dexterite.w
sagesse.w
agilite.w
intelligence.w
humour.w
sympathie.w
chance.w
endstructure

structure StPlayer_Quest
quete_etape.w
; etc.....
endstructure

Merci de vos réponses

[Guimauve]

Bonjour,

Pour répondre à ta question, le code n'ira pas plus vite ou moins vite du point de vue de l’exécution s'il y plein de petite structure imbriqué dans une grande. La seule différence se trouve dans l'organisation et le traitement des données. L'important est de bien regrouper les informations, par exemple mettre les informations en lien avec la physique (masse, vitesse, position, boîte de collision, etc) dans une structure, celle en lien avec l'intelligence dans une autre structure, celle en lien avec le niveau de jeu dans une autre, celle en lien avec le pointage dans une autre et ainsi de suite. De cette, il est plus facile faire la gestion de ce que veut faire le joueur (reprendre la partie, la sauvegarder en plein milieu, etc.)

Voilà c'est mon avis sur la question.

A+
Guimauve

[flaith]

En rejoignant Guimauve, tu peux utiliser aussi "Extend" pour tes structures
Une structure générale, et de nouvelles structures utilisant la structure de base

[Guimauve]

Re-Bonjour à tous,

Personnellement l'utilisation de "Extend" sur une structure, je proscrirais puisque cette pratique rend les structures trop inter-dépendante. Je préfère répéter les champs plutôt que de faire un "Extend" puisque de toute façon c'est qui se passe au niveau du compilateur. Mais bon, ça c'est mon point de vue.

A+
Guimauve

[Demivec]

Une autre variation:

Code : Tout sélectionner

Structure StPlayer_Quest
  quete_etape.w
  ; etc.....
EndStructure

Structure StPlayer_stat
  viemax.w
  viecourrante.w
  magiemax.w
  magiecourante.w
  xp.w
  levelcourant.a
  levelprochain.a
  force.w
  dexterite.w
  sagesse.w
  agilite.w
  intelligence.w
  humour.w
  sympathie.w
  chance.w
EndStructure

Structure StPlayer
  sprite.w
  x.w
  y.w
  stat.StPlayer_stat
  quest.StPlayer_Quest
EndStructure

[kelebrindae]

Perso, j'ai plutôt tendance à appliquer la solution de Demivec; elle me paraît plus intuitive (la donnée "joueur" est composée d'un sprite et d'une position, plus une donnée "stat" composée de plusieurs champs, etc...).
Mais:
- il faut faire attention à ne pas imbriquer trop de niveaux, parce qu'on obtient vite des trucs du genre "player\stat\body\health\poison = true", ce qui est un peu lourd...
- il y a un (très léger) coût en perfs, puisqu'au lieu d'accéder à une donnée via un pointeur, on la récupère via un pointeur lui-même récupéré par un autre pointeur, etc.. => autant d'accès mémoire que de niveaux d'imbrication. Ceci dit, c'est assez minime, car PB est plutôt bon en gestion de la mémoire.

[Le Soldat Inconnu]

Idem

C'est mieux pour la compréhension du code mais il faut éviter de trop imbriquer car ça devient pénible à coder ensuite.
Quand on arrive à 3 niveau, ça devient lourd

[blendman]

oki, merci pour vos explications, c'est un peu ce que je pensais.

Encore une question :
qu'est-ce qui est plus rapide :
les pointeurs ou les variables globales.
Imaginons que l'on doive appeler très souvent certaines variables, comme la position des ennemis sur une carte, est-ce identique ou y a t-il quelque chose de vraiment plus rapide ?

[Fig]

En fait je ne comprend pas la question
De toute façon, c'est la même chose, si on veut aller par là... Lors de la compilation, que tu te serves d'une adresse pour récupérer une variable ou du nom de la variable c'est kif kif. (le nom de la variable est finalement un substitut à l'adresse où elle est stockée pour le compilateur)

Voila comment je ferai... (une manière de faire parmi d'autres)

Code : Tout sélectionner

structure ennemis1
X.i
Y.i
selection.b ;si =1 selectionné, si=0 non selectionné
Vie.i
intelligence.i
sprite_courant.i ;contient le sprite en cours de l'animation
endstructure

global dim *carte_ennemis(100,100)
global newlist ennemis.ennemis1()

;Je créé 100 ennemis
For i=1 to 100
addelement(ennemis())
X.i=random(100)
Y.i=random(100)
ennemis()\X=X
ennemis()\Y=Y
ennemis()\vie=20
ennemis()\intelligence=50
;... on complète les autres caractéristiques
;on mets l'adresse de l’élément de la liste créée dans la carte des ennemis
*carte_ennemis(X,Y)=@ennemis()
next i

;boucle principale
repeat

;exemple on passe en revue tous les ennemis pour les faire avancer de 1 case
foreach ennemis()
X=ennemis()\X
Y=ennemis()\Y
*carte_ennemis(X,Y)=0 ;on efface l’élément de la case courante de la carte
ennemis()\X+1 ;on change sa coordonnée
*carte_ennemis(X+1,Y)=@ennemis() ;on rajoute l'adresse de l’élément
next

;exemple: on sélectionne un ennemi en coordonnée X_mouse et Y_mouse
*adresse=*carte_ennemis(X_mouse,Y_mouse)
changecurrentelement(ennemis(),*adresse)
ennemis()\selection=1 ;on met la sélection de l'ennemi à 1

;exemple: on affiche les ennemis
 for i=1 to 100
    for j=1 to 100
      *adresse=*carte_ennemis(i,j)
       changecurrentelement(ennemis(),*adresse)
       displaysprite(ennemis()\sprite_courant,ennemis()\X,ennemis()\Y)
    next j
 next i
forever

Code non testé mais bon, dans le principe ça doit être bon.
Je n'ai pas complété tout les champs: tempo animation, pathfinding ...etc