Voir la version complète : Reset ou redémarrage d'un programme ?
SAlut,
j'ai un programme qui commence très classiquement par :
"int main(void){"
Comment je peux faire pour reseter ou relancer ce programme ? il faut refaire un appel à la fonction ?
Merci
le but du reset c'est de relancer le jeu n'est-ce pas?
Tu peux alors creer une fonction du genre "InitGame()" qi contient toute l'initialisation de ton jeu.
Dans ton main tu fais appel à cette fonction une permiere fois pour initialiser ton jeu et à chaque fois que tu désires reseter ton jeu, tu refais appel à cette fonction.
int main()
{
InitHardWare();
InitGame();
while (1)
{
...
}
}
bool InitGame()
{
m_iLevel = 0;
m_iScore = 0;
InitBackgrounds();
InitSprites();
...
}
C'est juste un exemple, mais c'est tout ce que tu peux faire.
Tu ne peux pas relancer le programme à proprement dit. Donc tu relances les phases de jeu avec une petite réinitialisation ^^
Oui, je pense que ton soucis est un faux problème, fait comme gwoin dit ça se passera sûrement très bien.
Aussi, grâce au bios tu peux faire un "soft reset", mais je doute que ce soit ce dont tu as besoin :lol:
asm volatile("swi 0x00");
EUh m'a l'air bien compliqué tout ca :lol:
En fait oui, c'est juste pour recommencer unepartie quand celle ci se termine. Comme au début du programme je déclare toutes mes varialbles ( et donc 0 pour le score, level...) ait je vraiment besoin d'une fonction init ?
Pour le soft reset, je pense pas que c'est dont j'ai besoin ;)
EUh m'a l'air bien compliqué tout ca :lol:
En fait oui, c'est juste pour recommencer unepartie quand celle ci se termine. Comme au début du programme je déclare toutes mes varialbles ( et donc 0 pour le score, level...) ait je vraiment besoin d'une fonction init ?
int main (void){
unsigned char jemesuisfaittuer=0 ;
rebelotte:
InitJeu();
while(1){
if(jemesuisfaittuer) goto rebelotte ;
updateJeu() ;
updateSprites() ;
updatenimportnawaktoutefaconcpourexpliquer();
}}
ps: (je sais meme pas si ca marche d'ailleur)
pss: me gueulez pas dessu je ne l'utilise pas Oo
ouais, moi j'utilise un truc similaire à l'exemple de Nes et ça marche bien.
EUh m'a l'air bien compliqué tout ca :lol:
En fait oui, c'est juste pour recommencer unepartie quand celle ci se termine. Comme au début du programme je déclare toutes mes varialbles ( et donc 0 pour le score, level...) ait je vraiment besoin d'une fonction init ?
Pour le soft reset, je pense pas que c'est dont j'ai besoin ;)
ho, y'a rien de bien compliqué la dedans ^^
Le fait de faire une fonction, ca te permet de l'appeler n'importe quand (quand le joueur appuie sur START en cours de jeu, quand le joueur perd la partie et en recommence une, au tout début du jeu, ...).
Il te suffit de déclarer tes variables en globale (en dehhors et au dessus du main).
Comme ça tu mets toute l'initialisation de tes variables dans cette fonction et tu es tranquille : tu réinitialises tout en un seul appel à une seule fonction :)
Le code de NesGBA doit très certainement fonctionner aussi, mais il connaît mon aversion pour les GOTO :lol:
Par contre tu ne peux pas appeler le GOTO en dehors du main.
Mais en dehors de ce probleme, tu vas devoir te familiariser avec les fonctions.
C'est tellement pratique de compartimenter son code. Ca permet de rappeler tout une partie de code en un seul appel et donc de le modifier aussi à un seul endroit...
Bonjour tout le monde ^^ ,
Ma façon de faire est dans le même ordre d'idée que celle de Nes et Gwoin sauf que j'utilise des pointeurs de fonctions ... ça donne quelque chose comme ça :
Déclaration du pointeur de fonctions :
void (*in_game)(void);
/** Dans cette exemple toutes les fonctions "pointée" ne retourne rien (le premier void) et n'ont aucun paramètre (deuxième void). **/
void initialisation_menu(){
/** on efface tout de la mémoire puis chargement en mémoire des maps , palettes ,sprites , ect ... **/
// une fois tout chargé en memoire on passe à la gestion des evenements/actions qui auront lieu dans le menu .
in_game = &dans_le_menu;
}
void dans_le_menu(){
/** ici on fait tout ce qu'on pourrait faire dans un menu , par exemple déplacer un curseur , choix d'un mode de jeu ... **
// si on appuie sur la touche A , on lance le niveau 0 .
if( appuie(TOUCHE_A) ){ in_game = &initialisation_niveau0; }
}
void initialisation_niveau0(){
/** on efface tout de la mémoire puis on charge les perso , les méchants , les maps , les palettes , ect ... **/
// une fois tout chargé en memoire on passe à la gestion des evenements/actions qui auront lieu dans le niveau0 .
in_game = &dans_le_niveau0;
void dans_le_niveau0(){
/** on fait bouger les méchants , on bouge le perso si on appuie sur les touches ... **/
// Si on appuie sur la touche SELECT , on retourn au menu :
if( appuie(TOUCHE_SELECT) ){ in_game = &initialisation_menu; }
//Autre exemple d'utilisation :
if( atteint_fin_du_niveau0 ){ in_game = &initialisation_niveau1 ; }
Bon j'arrete là pour les exemples , ca doit être assez lourd à lire en plus :whst: .
Pour ceux qui connaissent , ca ressemble assez à un automate ...
Sinon pour finir , l'inclusion de tout ça dans le main() :
int main(void){
ham_Init();
in_game = &initialisation_menu;
while(TRUE){
if( VBLANK ){
/** blabla **/
in_game();
/** blabla **/
} return 1;
}
Wala wala , j'espère que ca pas était trop long :-' et surtout que ca été compréhensible :ph34r: ... sinon j'essayerais des répondre aux questions :) .
Après pour un vrai reset il sauffit d'étendre l'exemple de initialisation_menu() ... mais j'pense que c'est largement faisable ... j'espère juste que ca sera pas trop compliqué à comrpendre :ange: .
Bon ok... je croyais être passé de developpeur débutant à développeur débutant confirmé, mais quand je lis vos posts, je me rends compte que je suis une sous merde de développeur... :hum: :| ^^
Voici mon code :
int main(void){
rebelotte:
Déclaration de toutes mes variables
Boucle principale
if...
if...
if...
if je me fais toucher alors goto rebelotte
}
Mais ca marche pas désolé...
J'sais pas trop comment marche le goto en C (peut etre pareil qu'en ARM ... faudra que je regarde :ph34r: ) ... mais on me l'a toujours déconseiller en cours :whst: ...sinon sans utiliser de pointeurs je dirais :
Déclaré une variable global reset :
u8 reset;
Fonction d'initialisation / de reset :
void initialisation_du_jeu(){
J'efface tout de la memoire;
J'affecte des valeurs à mes variables;
Je charge mes maps,tiles,sprites,palette en mémoire;
reset=0;
}
Ensuite pour le main :
int main(void){
reset=1 ; // pour initialiser une première fois le jeu .
while(TRUE){ //Boucle principale
if( reset==0 ){ // Gestion du jeu .
if...
if...
if...
if je me fais toucher alors reset = 1;
}else{ // On fait reset du jeu .
initialisation_du_jeu();
}
}
Juste une idée comme ça , ca me semble pas trop mal , j'ai pas testé donc j'suis pas sur que ca marche exactement comme tu le demande :-* .
Après relecture du sujet , j'crois bien que c'est la même chose que proposait Gwoin ... déclare tes variables avant le main pour les "rendre" globales (si j'ai bien suivi tu utilise qu'un seul fichier ... ) comme ca tu pourra accéder à ces variables depuis toutes tes fonctions ( alors que quand tu déclare une variable dans le main() , tu ne pourra pas y accéder depuis une autre fonction ... ) .
Bon j'sais pas si j'suis super clair quand meme :huh: , pas l'habitude de poster , et surtout pas l'habitude d'essayer d'aider ;) .
Pour info, le goto n'est pas une mauvaise chose.
Il faut juste l'utiliser là où il est necessaire.
Par exmple, si ya moyen de faire avec un for, un while ou un if, on utlise pas le goto pour faire des boucles, ou alors remonter de partout et faire des codes incomprehensibles.
Par contre, si on veut sortir d'une double double imbriqué, là, c'est bien.
For (blablabla)
For (blablabla)
if (machinchose == ça) goto LABA;
FINfor
FINFor
LABA:
parce que sans goto, ben sortir des deux boucles d'un coup, ça fait faire des trucs moches.
voilà, c'est un truc de base du CPU le goto et donc c'est pas forcement le diable, mais faut juste l'utiliser sans abuser.
enfin, c'est mon avis.
Ok je note ;) merci pour la réponse rapide Japi ^^ ... c'est vrai que dans cette situation , ca l'air d'être une bonne solution .
J'y penserais dorénavant :) .
Merci pour vos explications mais désolé c'est trop complexe pour moi... j'arrive a faire la boucle goto mais ca marche pas mieux...
Merci pour vos explications mais désolé c'est trop complexe pour moi... j'arrive a faire la boucle goto mais ca marche pas mieux...
Quand tu dis que ca ne marche pas, ca fait quoi exactement ?
Au pire poste cette partie de code, ca sera plus simple...
Alors comme j'ai dit plus haut :
nt main(void){
rebelotte:
Déclaration de toutes mes variables
Boucle principale
if...
if...
if...
if je me fais toucher alors fin du jeu et Si Stylus touche l'ecran alors goto rebelotte
}
Et quand je touche lecran avec le stylet, il ne se passe rien... PAr contre je ne fai saucun vidage de mémoire nul part...
Vue ton code , et j'ai tester vite fais goto ( et non GOTO il reconait pas , bref , note à moi même :lol: ) ... je dirais que ton code devrait plutot être :
Déclaration de toutes mes variables;
// u8 var_1; par exemple .
int main(void){
rebelotte:
Affectations de valeurs aux variables précédement déclarées .
// var_1 = 7; par exemple .
Boucle principale
if...
if...
if...
if je me fais toucher alors fin du jeu et Si Stylus touche l'ecran alors goto rebelotte
}
Pour le if je me fais toucher et tout , ca j'sais pas par contre si c'est juste ou pas .
Mais déjà j'pense qu'il y a un problème dans ton code car en utilisant goto vers le label rebelotte tu demande au programme de re-déclarer des variables ayant le même nom que celle déjà déclarées ( ... oula phrase bancal :whst: ... ) :
int main(void){
rebelotte:
u8 var_1=7;
goto rebelotte;
}
, me donne une erreur ( j'utilise le compilateur fourni avec HAM toujours :wub: , et dans ce cas là ça compile pas :lol: ) . Alors que :
u8 var_1;
int main(void){
rebelotte:
var_1=7;
goto rebelotte;
}
, est juste .
Cherche de ce coté là , c'est à dire , déclare tes variables avant le main() ... sinon pour ce soir , si c'est pas ça ... j'ai plus d'idée pour l'instant ;) .
J'espère que tu t'en sortiras ;) .
---
Mouais , après relecture du post de Nes , en fait t'es pas obligé de déclarer tes variables hors du main() , mais déclare les tout de même avant le rebelotte: et fais les affectations après (comme dans l'exemple de Nes , ni plus ni moins).
mastertop101
15/04/2006, 03h10
personnelement je fais qqch comme :
if(jemesuisfaittuer)
{
var1=0;
var2=0;
var3=0;
loadbg(...);
setspritexy(...);
}
tu code toujours kyros ? ca fesai un bail :) tu nous sort un ptit projet un de ces jours ? ;)
Merci pour vos propositions, j'essaierais ce soir ;)
ouais, le truc sur la declaration des valriables, c'est de les declarer de mettre ton label puis de les affecter comme ça quand tu fais ton goto, tu ne les redéclare pas, tu les reaffecte juste.
Ma fonction goto ne marche pas je crois...
j'ai juste ecris :
rebelotte:
...
...
...
goto rebelotte;
La synthaxe est elle bonne ?
rien d'autre à déclarer ?
la syntaxe est bonne, concernant la redeclaration d'une variable c'est pas un probleme si tu compille du c
exemple:
Start:
signed short hello =0;
goto Start ;
cette syntaxe cause une erreur lors de la compillation pour du c++ a moin que tu mette un test conditionnel.
Start:
if (initcompteur) signed short hello =0;
goto Start ;
on peut eviter l'utilisation du goto dans pas mal de cas (fin d'une double boucle anticipée par exemple) on peut le remplacer par un "return;" dans une fonction mais a mon sens si tu doit rajouter un test pour eviter le goto je prefere encore l'utiliser.
et y'en a vraiment marre des gens qui detestent le goto alors qu'ils savent meme pas a quoi il sert, dans le style : "a ben j'ai vu un gars qui avai l'air de pas mal toucher sa bille en c qui a dit que le goto c'est mal alors je vais dire pareil que lui j'ai moin de chance de me manquer" <- ca c'est bien une facon de penser a la con. utilise ce qui te sert, tu t'en fou de ce qu'en pensent les autres.
et y'en a vraiment marre des gens qui detestent le goto alors qu'ils savent meme pas a quoi il sert, dans le style : "a ben j'ai vu un gars qui avai l'air de pas mal toucher sa bille en c qui a dit que le goto c'est mal alors je vais dire pareil que lui j'ai moin de chance de me manquer" <- ca c'est bien une facon de penser a la con. utilise ce qui te sert, tu t'en fou de ce qu'en pensent les autres.
Reste zen Nesgba. Pour ma part, je n'utiliserai clairement jamais de goto car un programme bien structuré et bien compartimenté en fonctions (ou classes) reste pour moi la meilleur solution.
Je n'ai jamais attendu que quelqu'un me dise que le goto était mal ou bien.
Et sans vouloir ramener ta remarque à moi, au boulot je développe un logiciel en C++ qui contient plus de 250 fichiers sources et plus de 100 000 lignes de code, que je développe seul de A à Z et jamais je n'aurais pu faire un logiciel propre et qui ne plante pas avec des goto.
J'ai une architecture logiciel qui ne peut pas se permettre une fuite mémoire ou un mauvais adressage parce qu'un goto mal placé aura réinitialisé une variable ou utilisé un pointeur qui aura était libéré. On pe peut pas gérer un aussi gros programme sans savoir exactement ce qu'on fait.
Et cette facon de programmer me permet de faire des programmes qu'on peut rapidement et facilement mettre à jour (un simple appel à une fonction est quand même plus simple à écrire/comprendre/mettre en place que des retours en arrières ou en avant dans le code)
Mais bon, tu as raison, il faut que Sensei utilise ce qui lui sert et apprenne lui même ce qu'il prefere utiliser pour coder.
Apres tout, certains preferent passer plus de temps à debugguer et essayer de comprendre pourquoi leur code ne fonctionne pas plutot que de tout prévoir à l'avance.
C'est une question de point de vue... je ne pense pas que le mien soit plus con qu'un autre.
Si tu prevois bien en avance comme tu dis, ton goto ne provoquera ni erreur, ni reinit de variable ni rien d'autres puisque tout sera bien fait.
Enfin bon, on le prone pas, jusque des fois, ça evite 5 lignes de code de plus avec des conditions en plus et que derriere, ça sera transformer en asm avec des sauts to label de partout que t'en mettes ou pas.
Clair, parfois les gens s'embêtent avec des structures de boucles à la con (enfin c'est mon avis) alors qu'un goto, continue, exit ou return serait tellement plus adapté et compréhensible, mais non "un bon l33t de programmeur n'utilise jamais les goto"... <_<
Par contre un abus de goto dans tous les sens peut effectivement rendre le programme moins lisible et favoriser les bugs, mais c'est pareil pour les boucles imbriquées avec des conditions pas toujours claires du style l_bSuccess, l_bQuit et j'en passe.
Bien sur, chacun code comme il l'entend et ça me va tres bien.
C'est juste que la remarque de Nesgba m'a semblée assez agressive et que je l'ai en partie prise pour moi.
J'utilise volontiers les continue, break et return dans une boucle parce que le programme reste linéaire.
Mais je trouve vraiment risqué et dangereux d'utiliser des retours en arrière avec des goto.
Japi: Je suis d'accord avec toi que converti en ASM le code contient des tas de boucles. Mais à ce niveau là, c'est le compilateur qui les gère, pas le codeur. Le risque d'erreur n'est pas le même et surtout le compilateur s'en fout de lire une structure de programme bien faite et réutilisable ou un paquet de lignes illisibles. C'est pas la même chose.
Aussi, tout prévoir en avance sur un gros programme n'est pas aussi simple que dans un petit code de 2000 lignes. Dans mon exemple que j'ai cité plus haut, certain fichiers font plus de 3000 lignes (et il y en a plus de 250). Si tout n'est pas bien rangé dans des fonctions auxquelles je peux facilement faire appel (et là pas besoin de goto nul part), c'est très vite un beau bordel.
Pour moi le risque des gotos n'est pas de sortir d'une boucle, c'est d'utiliser le gotos pour passer d'un point à un autre du programme. Sur 200 lignes où il n'y a qu'un seul goto ou 2 c'est encore gérable, mais au delà (i.e. presque tous les programmes) ce n'est plus la même chose.
Essaie de modifier ton code 2 mois apres pour y reintégrer des nouvelles fonctions qui n'étaient pas prévu à la base et ce sera vite buggué.
Gwoin je te promet que je disai pas ca du tout pour toi, mais en regardant mieu je comprend que tu ai pu le prendre pour toi (puisque tu as été le seul a critiquer cette commande) donc j'ai pas été precis, je lisai en meme temp un tuto avancé sur le c fait par un prof et ca m'a mis sur les nerfs qu'il dise que l'utilisation du goto dans un programme prouve le faible niveau du codeur. (et ca se dit prof) :ranting:
Pour moi le risque des gotos n'est pas de sortir d'une boucle, c'est d'utiliser le gotos pour passer d'un point à un autre du programme. Sur 200 lignes où il n'y a qu'un seul goto ou 2 c'est encore gérable, mais au delà (i.e. presque tous les programmes) ce n'est plus la même chose.
Essaie de modifier ton code 2 mois apres pour y reintégrer des nouvelles fonctions qui n'étaient pas prévu à la base et ce sera vite buggué.
quand tu utilise le goto dans une fonction que tu connais par coeur le probleme ne se pose pas en c ou le programme est "deroulé" a contrario du c++ qui est plus orianté objet.
bien sur quand je parle de programmation je parle plutot de programmation dans le but de creer un jeu.
sinon question longeur de code ca n'a absolument rien a voir, la pluparts de mes programmes depassent deja les 10000 lignes le premier mois que je passe dessu et je les comprend parfaitements (encore heureux je veut pas une usine a gaz)
quand tu fait des fonctions qui se suffisent a elles memes je voit vraiment pas le probleme.
d'ailleur je me demande si on peut utiliser un goto d'une fonction vers une autre ? si c'est possible, c'est pas du tout pareil Oo
/mode polémique ON
int main (void){
unsigned char jemesuisfaittuer=0 ;
rebelotte:
InitJeu();
while(1){
if(jemesuisfaittuer) goto rebelotte ;
updateJeu() ;
updateSprites() ;
updatenimportnawaktoutefaconcpourexpliquer();
}}
Juste pour enflamer les esprits :devil: GOTO pas bien.
int main()
{
while(1)
{
InitJeu();
while(!jemesuisfaittuer)
{
updateJeu() ;
updateSprites() ;
updatenimportnawaktoutefaconcpourexpliquer();
}
}
}
/mode polémique OFF
Sinon c'est vrai que le GOTO a son utilité.
yopyop
j'adore le code bien rangé pour faire plus propre :D
Bah en indentant et en aérant c'est presque aussi beau que l'autre solution (même si dans ce cas précis l'autre solution est effectivement plus propre), et contrairement aux boucles imbriquées ça t'évite d'avoir à scroller ton écran horizontalement comme un con dès que ta fonction fait plus de 5 trucs :p
int main (void) {
bool bMort = 0;
gameReset:
InitJeu();
while (1)
{
updateJeu() ;
//Là c'est plus dur sans goto hein :p
if (bMort)
goto gameReset;
updateSprites() ;
updatenimportnawaktoutefaconcpourexpliquer();
}
}
Par contre dès que tu travailles avec la mémoire, utiliser des return, gotos et compagnie ça peut facilement être source de problèmes. Par exemple:
char *LoadSomething()
{
FILE *f, *g;
char *ptr;
f = fopen("1", "r");
if (!f)
return NULL;
g = fopen("2", "r");
if (!g) {
fclose(f);
return NULL;
}
[...]
ptr = something;
fclose(f);
fclose(g);
return ptr;
}
Ici, si t'as 10 fichiers à ouvrir, malloc ou instanciations à faire, ben au dixième return, tu devras libérer les 9 autres... Par contre en structurant avec des if...
FILE *LoadSomething()
{
FILE *f, *g;
char *ptr = NULL;
f = fopen("1", "r");
if (f) {
g = fopen("2", "r");
if (g) {
[...]
ptr = something;
fclose(g);
}
fclose(f);
}
return ptr;
}
Après la programmation orientée objet faut en avoir l'utilité dans un jeu (dans une app windows je dis pas)...
Bref tout dépend de ce que tu veux faire ^^
Aussi, tout prévoir en avance sur un gros programme n'est pas aussi simple que dans un petit code de 2000 lignes. Dans mon exemple que j'ai cité plus haut, certain fichiers font plus de 3000 lignes (et il y en a plus de 250). Si tout n'est pas bien rangé dans des fonctions auxquelles je peux facilement faire appel (et là pas besoin de goto nul part), c'est très vite un beau bordel.
Pour moi le risque des gotos n'est pas de sortir d'une boucle, c'est d'utiliser le gotos pour passer d'un point à un autre du programme. Sur 200 lignes où il n'y a qu'un seul goto ou 2 c'est encore gérable, mais au delà (i.e. presque tous les programmes) ce n'est plus la même chose.
Essaie de modifier ton code 2 mois apres pour y reintégrer des nouvelles fonctions qui n'étaient pas prévu à la base et ce sera vite buggué.
monsieur n'est pas le seul à ecrire des codes de plus de 2000 lignes. :rolleyes:
mais bon, je me sents pas visé, c'est juste desobligeant.
[hehe] je sents que je vais me faire allumer ^^
Gwoin je te promet que je disai pas ca du tout pour toi, mais en regardant mieu je comprend que tu ai pu le prendre pour toi (puisque tu as été le seul a critiquer cette commande) donc j'ai pas été precis, je lisai en meme temp un tuto avancé sur le c fait par un prof et ca m'a mis sur les nerfs qu'il dise que l'utilisation du goto dans un programme prouve le faible niveau du codeur. (et ca se dit prof) :ranting:
:)
C'est vrai que je l'avais un peu pris pour moi :-*
Chacun a ses méthodes de prog et l'important c'est que le programme tourne sans bug (c'est déjà pas mal :p ).
Japi: 2000 lignes c'était juste un exemple. Presque tous les homebrews ici doivent faire au moins ça ^^
Brunni: la programmation orientée objet à d'autant plus son interet dans un jeu que chaque perso ou item peut etre considéré comme un objet avec ses caractéristiques, ses variables et être hérité d'un objet mère qui contient des paramètres globaux...
Exemple d'un space invader: chaque type de vaisseaux ennemi (CVaisseauPetit, CVaiseauClingon, CVaisseauEnterprise, ...) herite d'une même classe "CVaisseauEnnemi" qui contient tous les paramètres et les méthodes communes à tous les types de vaisseau (niveau de vie, puissance de tir, position dans l'espace, direction, ...) et donc on peut avoir un tableau de CVaisseauEnnemi alors que tous les vaisseaux du tableau seront de types différents et on fait appel à une même fonction commune pour modifier leurs paramètres :)
EDIT [je retire mes dires, pas la peine de foutre la merde, ça à jamais fait avancer le monde]
Ben moi mon arkanoid fait 7000 lignes dans un seul main et pas un seul goto, bande d'amateurs !
Nan sérieux, je ne savais même pas que le goto était utilisable en C :-'
J'y penserai à l'ocaz, merci :)
lol la signature de Nes ^^
(comment ca mon post c'est du flood qui est la que pour faire croire que je sais coder ? ca se voit tant que ca ? :ph34r: )
Brunni: la programmation orientée objet à d'autant plus son interet dans un jeu que chaque perso ou item peut etre considéré comme un objet avec ses caractéristiques, ses variables et être hérité d'un objet mère qui contient des paramètres globaux...
Exemple d'un space invader: chaque type de vaisseaux ennemi (CVaisseauPetit, CVaiseauClingon, CVaisseauEnterprise, ...) herite d'une même classe "CVaisseauEnnemi" qui contient tous les paramètres et les méthodes communes à tous les types de vaisseau (niveau de vie, puissance de tir, position dans l'espace, direction, ...) et donc on peut avoir un tableau de CVaisseauEnnemi alors que tous les vaisseaux du tableau seront de types différents et on fait appel à une même fonction commune pour modifier leurs paramètres :)
Je suis d'accord, mais ça requiert de l'allocation dynamique ça? Donc je pense que tu oublies sur GBA, et probablement sur DS aussi.
Après tu peux faire un système similaire en C: une structure avec des membres de base (position du vaisseau) + un pointeur sur fonction pour le handler (la fonction commune pour modifier ses paramètres). Ensuite, quand on définit un objet, on lui associe une fonction et des données qui lui sont propres (on alloue un espace fixe par objet, et il en fait ce qu'il veut en le castant vers une structure de son choix). Dans ce cas, le code n'est pas vraiment plus compliqué à gérer, mais il est plus adapté à une console de jeu car très rapide et plus petit, et tu as un meilleur contrôle dessus. Enfin c'est mon avis hein ;), et je joue un peu l'avocat du diable aussi :ph34r:
Je suis d'accord, mais ça requiert de l'allocation dynamique ça?
Non, pas besoin d'allocation dynamique.
J'aime bien ton exemple, ca revient à faire un peu de l'objet avec des structures :). Sans l'héritage ni le polymorphisme, mais c'est déjà un peu de la phylosophie objet (programmation orientée objet, quand tu nous tient :wub: )
Heu je serais curieux de savoir comment tu fais ça sans allocation dynamique... :huh: vu que tous les types d'objets n'ont pas la même taille puisqu'ils ont des membres qui leur sont propres...
Et si le C++ le fait en interne, alors c'est ce que je voulais dire: c'est gros, lent et pas vraiment adapté à une GBA par exemple.
Oui, tu as raison si on utilise des pointeurs. Un new n'est rien d'autre qu'un malloc.
Surtout que l'héritage donne des objets provenant de la même clmasse mère, mais pas de même taille.
Mais une classe instanciée sans pointeur revient exactement à la même chose qu'une structure. L'héritage peut alors être remplacé par une série de structures sensiblement identique.
Mais ce que je dit est surement moins vrai en C qu'en C++.
Ca y est , je crois que j'ai réussi... :)
J'ai fait un simple goto avec Raz des variables level et score.
Vraiment simple mais vu mon niveau de prog , il ma fallu 4 jours :lol:
Tembargo
20/04/2006, 13h42
Ca y est , je crois que j'ai réussi... :)
J'ai fait un simple goto avec Raz des variables level et score.
Vraiment simple mais vu mon niveau de prog , il ma fallu 4 jours :lol:
Je suis justment en train de m'attaquer à ça dans mon jeu.. Pour réinitialiser des variables pas de soucis, il se trouve que j'ai fait la même chose que tout le monde ici. Mais j'ai un autre souci même si j'ai pas encore beaucoup cherché mais comment on efface de la mémoire et de l'écran des sprites, background... ?
Pour mon espèce de tétris, faut que j'efface toute les barres à l'écran.
Je suis justment en train de m'attaquer à ça dans mon jeu.. Pour réinitialiser des variables pas de soucis, il se trouve que j'ai fait la même chose que tout le monde ici. Mais j'ai un autre souci même si j'ai pas encore beaucoup cherché mais comment on efface de la mémoire et de l'écran des sprites, background... ?
Pour mon espèce de tétris, faut que j'efface toute les barres à l'écran.
tu ecrit des 0 dans les tiles que tu veut jarter. puis tu les defini comme 'disponibles' pour une eventuelle reutilisation. (mais tu n'est pas obligé de les vidanger tu met les 4 attributts a 0 ca marche aussi)
et comme il reste parfois des erzats de pixels, tu fout tes sprites hors ecran.
vBulletin® v.3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org