Aller au menu - Aller au contenu
Inscris-toi au e-camp "Héberge ton jeu Facebook sur Azure" de Microsoft vendredi 25 mai à 13h30 !

Creation d'un rpg sur nds

Initialiser un tableau d'objet en ROM

Pour accéder à cette section
Connectez-vous !
connexion_rpx

Résolu Le problème de ce sujet a été résolu

Page 1 
Auteur Message
1 visiteur sur ce sujet (1 Anonyme)
Page 1 
Hors ligne Tannis Dragon # Posté le 19/01/2012 à 16:32:38

Bonjour,

Programmateur novice en C++ (voir même en C) je suis à la base un électronicien.
J’ai malgrès tout des connaissances de bases (pointeur, fonction, class…).
Ma question porte sur une console portable la NDS. J’utilise la palib pour programmer, même si j’ai touché un peu la libnds (mais pourquoi réinventer la roue quand celle-ci à déjà été inventé :) )

J’expose les paramètres logiques d’un jeu genre RPG :
Admettons que dans mon jeu j’ai 100 objets (2 à 3 objets par Map), chaque objet (faite par une class) contient un nombre de variable.
Mes objets ont des valeurs de base d’initialisation (comme la position sur la Map et à qu’elle Map ils appartiennent). Il me faut donc les mettre en ROM.

Là est mon problème :

Au début je comptais le mettre dans un fichier à part, et d’aller lire ce fichier pour récupérer mes valeurs d’initialisation, mais en compilant, le fichier ne sera pas intégré dans le .nds, il faudra donc copier le .nds du jeux et un fichier d’exploitation de donnée d’initialisation. Hors la plus part des jeux RPG n’ont pas ce fichier à part. Cela revient a dire qu’il y a un moyen d’intégrer ces données.


Je pourrais aussi initialiser toute mes variables en début de programme main(), mais cela reviens a mettre en début de programme tout mes objets en variable locale et donc mettre celle-ci dans la RAM. A 100 objets multiplier par 7 ou 8 variables… on monte entre 700 et 800 variables en mémoire RAM dont la plupart (soit 99 %) ne seront pas exploité sur la Map affiché à l’instant présent reviendrais à saturer la mémoire.

Si j’admet que l’instruction « const » permet de mettre m’a valeur d’initialisation dans la ROM (ou la cartouche de jeux) et non dans la RAM (interne pour les variables).
« pour cela il me faudrait la confirmation, car la plus part des forums que j’ai vu parle toujours de programmation PC et donc malgrès le faite que sa soit une constante celle-ci est mise en RAM. La nds étant une console portable, la RAM est beaucoup plus petite qu’un PC. »


Donc dans l’hypothèse que « const » me permet de mettre en ROM, un autre point pose problème. Il me faut initialiser à la création de l’objet dans le programme par l’intermédiaire par exemple du constructeur de class.

J’ai voulu créer un tableau d’objet constant, cela m’aurait permis de mettre mes objets initialisés, rangées et placées en ROM. En effet sa serait beaucoup plus pratique que de créer chaque objet à la main avec un nom : coffre1, coffre2, coffre3 etc… Et beaucoup plus simple a retrouver sur qu’elle Map ils appartiennent avec une boucle dans un tableau et un test, que de regarder chaque variable avec un nom différent

Ma surprise fut (et après avoir fouiller le net) que les valeurs passées au constructeur ne pouvait être exploitées dans un tableau d’objet. Il me faut donc initialiser mon tableau avec mon nombre d’objet (ici 100) et remplir le tableau.
De toute façon obligatoire puisque chaque coffre contient des objets différents sur des cartes différentes, a des emplacement différents, il m’est impossible de mettre une valeur par défaut à l’aide du constructeur.

Mais en faisant cela et le mettre dans un fichier en tête .hpp celui-ci sera alors copié dans mon fichier .cpp par le compilateur et mon tableau et l’initialisation de mes données s’en trouveront être des variables globales mis dans la RAM. (Saturation de la RAM)

En résumé :
comment je peu initialiser mes objets (de type class) dans un tableau d’objet et que ce tableau soit placé en ROM (ou dans la cartouche de jeu).

Ainsi quand j’afficherai ma carte, je sonderais le tableau sur ma variable NumMap qui me permettra de copier cette donnée dans un tableau d’objet plus petit en locale (donc en RAM).

Désolé pour la longueur, je ne suis pas très bon en synthèse. Merci d’avoir lu entièrement ce paragraphe. Je continue de mon côté à chercher une solution. J’ai aussi tenté d’exploiter le Tas, mais ou rangent ils la donnée ? (je suppose dans une partie de la RAM allouer au Tas).

J’ai recherché sur le net par mots clef sur chaque parti de mon problème sans succès.

Merci d’avance ^^
Publicité # Posté le 19/01/2012 à 16:32:38

Hors ligne Aire-One # Posté le 20/01/2012 à 20:47:52
<(¤v¤)>
Salut !

Alors déja, qu'appels-tu une ROM, je pense que tu à oublié un 'O' et donc que tu parle de ROOM.

Sinon, il est vrai que pour un RPG, toutes les variables ne sont pas utilisées en même temps. :p pour 'alléger' la RAM, plutôt que d'ouvrire/fermer/réouvrire en écriture... un fichier (ce qui risque de faire lager à mort le jeu), je te conseil d'utiliser des plusieure maps. Ainsi, seule les info d'une map sont utilisées en même temps et tu libére environs 98% des la RAM :D

Malgrés tout, je ne pense pas que tu ais à utiliser 800 variables ! :waw:
Et aprés, en se qui concerne le fait que la nDS lag, je te conseil de d'adord faire des testes... :-°

En ce qui concerne les tableaux de class, je t'avoux que je n'y avais pas pensé et que je ne sais pas du tout si c'est possible... :o désolé

PS: le mot cléf const ne sert pas à stoker une valeure dans la ROOM mais à la déclarer comme constante se qui signifie qu'elle ne changerat jamais et donc qu'elle prend autant de place dans la RAM que n'importe quelle autre variable.
Reflets d'acide, la saga MP3 culte !
N'hésitez pas à me contacter
C: SDL, FMOD, (PAlib)
C++: PAlib, Qt, OpenGL
Batch (Makefile)
(xHTML/CSS + (PHP, Javascipt) occasionnellement :-° )
 
Hors ligne Tannis Dragon # Posté le 21/01/2012 à 12:07:29

Salut Aire-One,

Merci de ta réponse.

En faite je défini ROM (Memory Only Access) comme la mémoire morte, ou plus précisément celle ou est contenu le programme en lui même. Pour ce référencer à la nds, c'est le .nds qui est stocké sur la micro SD.

Mon but étant de faire une copie de mes informations de ma Map sur lequelle le joueur ce trouve dans une variable pour n'avoir en RAM que les éléments nécessaire.

La carte en elle même (décors et sprite) sont placées actuellement dans un tableau de type const int par PAGFX (d'où une déduction sur le faire que const laisserai en ROM) que je place dans la VRAM (RAM Vidéo)

En faite quand je disais 800 variables c'est surtout dans le cas ou mon tableau de type const ne mettrait pas en ROM mais en RAM, car pour un coffre j'ai :

  • sa position (x,y)
  • le numéros de la carte ou il se trouve (NumCarte)
  • l'objet à l'intérieur (NumObjet)
  • la quantité de cette objet (QtObjet).


A partir de là mon objet coffre me prend 5 variables. Je dis variable car pour l'instant je ne connais pas l'instruction pour la stocker en ROM en C++ dans ce que j'appellerai un programme embarqué.

Donc au démarage de mon programme j'initialise tout mes coffres, ce qui revient à faire Code : C++
1
TableauCoffre [0].Position(5,3);

Je pense que le simple fait de faire cette ligne met mes informations en RAM.

Pour chacun de mes coffres. En admettant que je met une 100 ene de coffre j'arrive à 500 variables. Mais dans mon RPG il n'y a pas que des coffres comme objet, j'ai aussi des rochers, des PNJs, des intérrupteurs... Bref je pense atteindre les 800 facilement :-°

Les tableaux de class me permettront de ranger mes objets sans me soucier de leurs noms. Car créer 100 coffres reviendrais à créer un nom de variable pour chaque coffres. Faire une recherche sur un coffre précis dans le jeu deviendrait fastidieux. Avec un tableau d'objet, il suffit juste de connaitre le numéros du coffre qui appartient à la map.

ex : le numéros de coffre est le 8 sur cette map :
Code : C++
1
2
Positionx = TableauCoffre [8].LecturePosX();
Positiony = TableauCoffre [8].LecturePosY();


Les tableaux class fonctionne bien, mais d'après ce que j'ai lu sur le net, on ne peut pas les initialiser avec un constructeur... :(

Adieu :
Code : C++
1
Objet TableauCoffre [100] = {{5,4,...},{50,30,...},...}; // initialisation de mes coffres


Le code ci-dessus ne fonctionne pas !


Merci d'avoir confirmé que l'instruction const mettait en RAM et non en ROM. Mon problème reste donc entier.

Comment mettre mes tableaux d'objet en ROM et les initialiser ?


PS : tu confond le mots anglais ROOM qui veut dire salle (dans le sens d'une pièce de maison par exemple) et ROM qui est l'abréviation de Mémory Only Read (Accès en mémoire seulement en lecture). A comparer à RAM qui est Ramdom Access Mémory (Accés en mémoire en lecture et écriture (aléatoire)) ;)
Hors ligne Aire-One # Posté le 22/01/2012 à 14:03:37
<(¤v¤)>
Au niveau du ROM tu as raison (c'est une erreure de ma part je l'admet (petite confusion :D ))

Par contre, le fait que PAGfx 'construise' tes images avec des const c'est parsqu'elles ne changeront pas, le sol ne deviendrat mystérieusement rouge tout d'un coups (par exemple), donc on met const pour dire que ça ne changerat pas.

Petite erreure de ta part lorsque tu dit: la quantité de cette objet (QtObjet). (lorsque tu explique d'où sortent tes 800 variables)
Parsqu'avec PAlib, Qt ne fonctionne pas... ce sont deux bibliothéques différentes :( (et de toutes façon, je ne pense pas que le proceseur de la nDS soit assez puissant)

Ensuite, pour tes coffres, plustôt que de faire des Sprites, je te conseil de les inclures à ton backgrung et de simplement creer des variables si ils sont ouverts pour placer un sprite de coffre ouvret
Non, c'est innutile, ça prend autant de place en mémoire...

Je ne vois pas trop comment tu veux t'y prendre pour faire 'disparaitre' 800 variables. Surtout qu'à mon avis, la nds a serte un petit processeur, mais elle doit pouvoire survire à 800 variables stokées dans un tableau bien organisé.
Pour te le prouver, je fait appel à Noda, qui à réalisé un Warcraft sous nDS avec la PAlib et qu'à mon avis, il doit y avoir pas mal de variables en mémoire... lien sur son dev-blug à la page du Warcraft (bon, bien entendu, il y a des limites qui te sont donnés plus bas dns la page mais ça ne géne absolument pas le jeu ;) )
Reflets d'acide, la saga MP3 culte !
N'hésitez pas à me contacter
C: SDL, FMOD, (PAlib)
C++: PAlib, Qt, OpenGL
Batch (Makefile)
(xHTML/CSS + (PHP, Javascipt) occasionnellement :-° )
 
Hors ligne Tannis Dragon # Posté le 22/01/2012 à 16:58:30

Salut Aire-One,

Pour ce qui est de la définition de ROM ce n'est pas grâve, j'aurais peut être du préciser dans mon premier Post la signification de l'abréviation. :)


J'ai fais un tour sur le net en me basant sur programmation embarqué. J'ai pu trouver qu'en language c,c++ l'instruction ROM était utilisée pour signaler au compilateur que la donnée constante est en ROM. Je n'ai pas encore testé, mais je modifierais ce poste pour informer si le compilateur le prend ou pas. Après le moyen pour moi de vérifier si ma constante est bien mise en ROM et non en RAM... Je ne sais pas. :(
Comme promis je modifie dans le poste sur l'instruction ROM, finalement sa ne marche pas. Je pense que c'est liée à un sous programme du compilateur spécifique à l'embarqué qui force au point de vue de l'assembleur à laisser la variable en ROM.

Ci dessous le site ou j'ai trouvé l'information page 2 :
http://genelaix.free.fr/IMG/pdf/optimi [...] _embarque.pdf

Il dois surement avoir un lapsus en ce qui concerne QtObjet, Peut être est ce une instruction d'une bibliothèque (je ne savais pas que c'étais aussi une instruction dans une Lib). Mais de mon côté je l'ai noté comme étant un de mes noms de constante de mon coffre, Qt pour l'abréviation de quantité et Objet pour objet :lol:

Code : C++
1
const unsigned char QtObjet = 2;


Cette constante contient le nombre de fois que j'ai mon objet dedans. (comme 2, pour 2 potions si l'objet est une potion).

Merci pour le lien, j'ai déjà téléchargé les sources et je suis entrain de regarder. Le style du jeu n'est pas le même que le mien, mais il me sera profitable de regarder l'architecture et certaine façon d'aborder des points techniques du jeu. :)

Un point me gêne par rapport à ma question parcontre.

Il initialise bien les monstres et il a plusieurs monstres. L'initialisation de ces monstres ce fait à l'affichage dans un tableau de structure.
Mais comme les monstres sont typés, il identifit le type de monstre dans son tableau et lui adjoint des caractéristiques qui seront également les même pour tout ces types de monstres. En gros il a mis dans un #Define que les squelettes avaient autant de vie et de forces et tout les sprites de type squelette sont identiques (même vie et même force). Principe que j'utiliserai dans mon jeu d'ailleurs. Mes coffres ne peuvent pas avoir tous le même contenus.

Ne soyons pas défaitiste, il a beaucoup de variable et de variable globale en effet dans son programme, ce qui n'a pas l'air de déranger ou niveau fonctionnement du jeu. :)

Je vais continuer à regarder son programme. Car il y a une histoire de fichier aussi qu'il charge (sauvegarde ou fichier de donné ???) .

Deplus il a mis les dialogues en #Define. J'avais lu ,il me semble quelques part , qu'il valait mieux ne pas trop utiliser cette instruction car le compilateur ne peu pas vérifier le type de donnée si celui ci est mis dans une variable.

Mon jeu n'étant qu'au début, je créer des fonctions et les tests au fur et à mesure que j'avance. La actuellement j'ai que 2 coffres qui me permette de tester mes fonctions. Mais je m'avance pour le futur en prévision de tout ce que je vais mettre :D

Merci pour ta réponse.
Édité le 23/01/2012 à 10:57:17 par Tannis Dragon
Hors ligne Aire-One # Posté le 22/01/2012 à 18:19:45
<(¤v¤)>
Ok pour le Qt object c'est bien trouvé, tu m'as eu :lol:
(sauf que pour entrer une quantité, j'utiliserais plutôt un int... :-° (tu utilise plus de place en RAm pour rien puisque tu utilise un char pour retenir un chiffre :o ))

Parcontre, je t'avais juste donné le Warcraft de Noda comme exemple, parsqu'il utilise tout un tas de variables en même temps et que ça ne géne pas du tout le jeu. Regarde les source si ça t'intéresse mais les déclaration globals et le texte dans des defines, moi aussi j'aime pas trop ;) ...

Pour tes coffres, pourquoi ne pas créer tout simplement un variable 'contenue' de type int qui est géré par un switch ?
Faire un truck un peu comme ça:
Code : C++
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
typedef struct{
    int x, y;
    bool ouver; // fasl=fermé, true=ouvert
    unsigned int QtObjet; // le nombre de d'objet du coffre
    int contenue[QtObjet]; /* Suivant la valeure tu 'check' le contenue
                              par exemple: 1=epee, 2=piece, 3=cape....*/
// PS: faut que te gére autrement de tableau d'int contenue parsque c'est pas possible comme ça  :p 
} coffretype;

coffretype coffre[nombreDeCoffre]; // sauf que là c'est déclaré en global ;)
Reflets d'acide, la saga MP3 culte !
N'hésitez pas à me contacter
C: SDL, FMOD, (PAlib)
C++: PAlib, Qt, OpenGL
Batch (Makefile)
(xHTML/CSS + (PHP, Javascipt) occasionnellement :-° )
 
Hors ligne Tannis Dragon # Posté le 23/01/2012 à 00:11:21

Petite réponse vite fait sur ton dernier message Aire-One :)
J'espère que sa ne sera pas pris pour du flood, mais il est tard :lol:

Ton code est ce que j'avais écris la première fois avant que je ne passe par des class mais c'est quasi la même chose. J'ai juste ajouté mes variables en privé et fait des fonctions membres pour y accéder. Sauf que je ne stockais qu'un type d'objet et non un tableau. En effet normalement la place alloué par le tableau d'objet se base sur un contenu fixe, le tableau pouvant varier de dimension rend l'allocation impossible d'après moi.

Après j'ai vue qu'il y avait possibilité avec un pointeur de créer un tableau dynamique...

J'ai même poussé un peu plus (mais je me doute que ton code sert juste d'exemple) j'ai utilisé enum sur l'état du coffre.
Code : C++
1
2
3
4
5
6
Enum E_Coffre = {ouvert, fermer};

typedef struct {
etc...
E_Coffre EtatCoffre;
etc...


Mis aussi en variable global ;)

Juste pour te dire que j'ai choisi un unsigned char car tu va de 0 a 256 valeurs donc 8 bits (ou 1 octet) pris en mémoire. Il ne m'en faut pas plus car je n'irais jamais au de-là de 256 objets dans un coffre o_O
Si tu met un Int, tu va de -32767 à +32768 en valeurs soit 2 octet. Et la capacité de mettre dans ton coffre 32768 objets.

Maintenant je me trompe peut être mais il vaut mieux utiliser une variable adapté aux nombres maximum que tu peu mettre que de mettre un int qui sera peut être géré plus vite par un processeur 16 bits, mais qui sera stocké dans 2 octets dont 1 octet que je ne me servirais jamais.

Après dans l'idée tu a peut être pensé que je parlais de coffre de rangement d'objets. Le genre ou le personnage ouvre et met tout les objets qu'il a droppé sur des monstres. Là je te dirais ok pour le Int :)

Les coffres dont je parle sont plutot ceux que tu trouve un peu partout sur les maps ou dans les donjons et qui ne contiennent que 1 voir 5 ou 6 objets pas plus.

Sa peu paraitre tatillons de chipoter sur quelques octets, mais autant prendre de bonne habitude en programmation (d'ou le faite que les #Define je n'en fais pas non plus :D )

Pour le perso j'ai prévu un objet de type sac à dos et un coffre fixe dans une maison qui sera du même objet que le sac ;)
Hors ligne Aire-One # Posté le 23/01/2012 à 17:49:21
<(¤v¤)>
En ce qui concerne les coffres, j'avais bien compris ton idée. C'est juste que tu as parlé de metre plusieures objets dedans, je me suis juste dit: "Si on met plusieures objets, pourquoi metre le même en plusieures exemplaire ?"Donc j'ais fait un tableau :p ...
Pourquoi ne pas en faire un dynamiquement ? Dans le constructeur directement ? (n'oublie pas de détruire dans le déstructeur (bien que je croix que la nDS vide sa RAM à chaques exteiction))

Pour les int ou char... Ce que tu dit est vrais, mais je trouve plus logique d'utiliser des int pour manipuler des chiffres. D'autant que pour une différence de quelques octets... :o
Enfin aprés c'est toi qui vois :D

En ce qui concerne le "gros coffre à objet privé du perso" je pense que ça n'as tout simplement rien n'à voir... ;) . En fait, je pense que ce serrait un objet unique à lui tout seul qui se gére totalement différament de tout autre type de coffres ou "sac à objets". En effet, dans ce coffre, le joueur pourrat socker tout un tas d'objet (enfin au moins plus que dans son sac :p ). Il pourrait aussi garder de grandes quantitées de "piéces d'Or" et avoir une géstion sur plusieures "cassiers" (soyons fous :D ).
Et en se qui concerne le côté prog, ça n'aura rien à voir... :-°

Secret (cliquez pour afficher)
J'aurrais juste une petite question à te posser: (un peu hor sujet mais tu peux toujoure me répondre par MP si tu ne veux pas "dériver")

Tu code en C++ avec la PAlib. J'ais des problèmes là dessus: en gros, tout mes codes C++ ne compillent pas, le compillo me dit toujours que mes class ou structures ou enum (enfin tout se que fait quoi) sont déja déclarés et il me donne des liens vers des fichiers de la lib. Or, ces fichiers ne contienent absolument pas les mêmes nom de variables que je déclare (il m'envois même parfois vers des lignes vide :waw: )
Si tu pouvais me dire comment tu compille ça m'aiderait beaucoup ;)
Merci
Reflets d'acide, la saga MP3 culte !
N'hésitez pas à me contacter
C: SDL, FMOD, (PAlib)
C++: PAlib, Qt, OpenGL
Batch (Makefile)
(xHTML/CSS + (PHP, Javascipt) occasionnellement :-° )
 
Hors ligne Tannis Dragon # Posté le 24/01/2012 à 12:28:07

Salut Aire-One,

Ok, c'étais pour éviter qu'il y est un doute sur le sujet :)

J'ai songé à faire en dynamique, mais je n'en ai encore jamais fait, je progresse lentement, il y a peu j'étais encore sur des structures, il n'y a que quelques semaines ou je suis passé en class (après avoir relus le chapitre pour en créer). Donc oui si mon besoin s'en fait sentir j'en ferais.

Par contre il me semble tout de même que je ne pourrais pas faire de tableau d'objet avec un type d'objet contenant un tableau dynamique. Car chaque objet aura donc une taille différente à cause du tableau dynamique ce qui est contraire au contenu d'un tableau ou chaque variables ou objets doivent avoir le même poids pour que le tableau puisse allouer en mémoire la place qu'il faut.


Oui, à chaque extinction de la console la RAM est forcément vidé (dû à la technologie même de la RAM), Mais rien n'empêche de prendre de bonne habitude sur la façon de coder et si au besoin il faut le détruire par un destructeur de le faire proprement. :)

Pour ce qui est du coffre privé je suis d'accord avec toi, c'est un type d'objet différent qui n'a rien à voir avec les coffres commun dans le jeu.
Je dois dire qu'on a tendance a dévier un peu du sujet de départ :lol:

En résumé par rapport à mon sujet et pour recentrer un peu :

Pour ce qui est de mettre en ROM une donnée :
  • Const ne permet pas de mettre en ROM
  • l'instruction ROM n'est pas une vrai instruction du C++ (donc inutilisable)
  • Que les programmateurs de jeu utilise beaucoup de variable ce qui apparement ne pose pas problème
  • Je pense aussi qu'ils utilisent les #DEFINE comme moyen de mettre en ROM...

Pour ce qui est des Tableaux d'objets afin de les initialiser directement à la création :
  • Aire-One comme tu me l'a signalé dans un post tu ne connais pas trop les tableaux d'objets (ce n'est pas un reproche Aire-One, juste un fait :) ).

Je garde le sujet ouvert encore un peu.
Peut être que quelqu'un connait une instruction pour laisser les données en ROM et par exemple utiliser un pointeur pour aller les lires (enfin pour moi c'était le tableau en lui même qui servait d'entrée pointeur pour aller les lires en ROM).

L'initialisation du tableau étant une demande qui découlait du problème de mise en ROM. Tant que le premier n'est pas vraiment résolus la question se posera donc toujours. Car si une instruction existe pour mettre en rom, il ne faut pas que mon initialisation de tableau soit alors en RAM car il n'y aurait plus d'intérêt à avoir des données en ROM et les mêmes initialisés en RAM.

Actuellement : j'initialise mon tableau d'objet en globale et donc en RAM afin de pouvoir continuer a avancer sur d'autre aspect de mon jeu :)


Sinon je vais devoir changer le sujet du topics en "Aide et astuce dans la conception d'un RPG" :lol:

Secret (cliquez pour afficher)
Aire-One je t'ai répondu en privé ;)

Hors ligne Aire-One # Posté le 24/01/2012 à 14:29:36
<(¤v¤)>
Ok je croix que toutes tes questions possée en ouvreture de topic ont eu une juste réponse dans ton message précédent... :D

En ce qui concerne l'allocation dynamique des tableaux, je peux pas trop le cacher, on ne peut apprendre quand pratiquant et j'avoux ne pas en avoir beaucoup utilisé :p

Par contre, une erreure: les #define en servent pas à mettre quoi que ce soit dans la ROM !
Ce sont en réalité des instructions suplémentaire pour le compillateur.
En gros ça veut dire que quand tu utilise des defines, il ne sont pas pris en compte dans le programme mais pas le compillo
(un p'tit exemple doit être plus parlant:)
Code : C
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
#define NOMBRE_MAX  10 // Là tu dit au compillateur:
      // "partout où tu verrat écrit NOMBRE_MAX tu remplace par la valeur 10"

int main(){
    int vieMax = NOMBRE_MAX; // du coups, ici au moment de la compillation,
// c'est exactement parraille que si tu avais écris:
// int vieMax = 10;

...

    return 0;
}


Et lorsque tu utilise des instructions commencent par # (comme pour les #define) tu parle au compillo et pas au programme. Par exemple avec les include...

Donc, en gros, lorsque tu utilise des #define, tu n'alloue aucune mémoire, pas même en ROM ou en RAM.

Pour la suite, construire un RPG est extrémement compliqué et je ne peux donc que te souhaiter une bonne chance sur çe long chemin sinueux (j'ais déja vus mieux comme métaphore sur la construction d'RPG :p )
Reflets d'acide, la saga MP3 culte !
N'hésitez pas à me contacter
C: SDL, FMOD, (PAlib)
C++: PAlib, Qt, OpenGL
Batch (Makefile)
(xHTML/CSS + (PHP, Javascipt) occasionnellement :-° )
 
Hors ligne Tannis Dragon # Posté le 03/02/2012 à 15:09:55

bonjour,

Il est temps de cloturer mon sujet. Merci a Aire-One pour son aide.

A ceux qui chercheront une solution, voilà ce que j'ai pu faire de mieux.

A la question de la mise en ROM :
J'ai contourné l'idée, j'initialise mes informations que lorsque le programme en a besoin. donc mes informations sont dans la ROM et j'initialise sur les même variables (des variables commune).

Pour le tableau d'objet :
Pour mes coffres sur la Map, j'utilise un tableau dans le Tas que j'initialise avec les coffres de la carte. Bien entendu attention a bien supprimer lors de l'ouverture d'une nouvelle Map l'ancien pointeur avec la fonction delete [] avant de recréer un tableau (fuite de la mémoire). Mais on ne peu pas les initialiser à la création, à moins que les données de départ soit les même pour tous les objets, dans ce cas vous pouvez les initialiser dans le constructeur.

Merci
Cordialement

Retour au forum "Jeux vidéo" ou à la liste des forums

Pour accéder à cette section
Connectez-vous !
connexion_rpx


Lire aussi