toujours sur mon jeu j’ai un petit problème d’affichage.
Je m’explique : dans ma boucle principale j’affiche le décor et des éléments mais dans une fonction, j’ai une autre boucle qui incremente la position pour déplacer les joueurs. Forcément pendant cette boucle le décor n’est pas affiché. J’ai pensé à peut être faire du threading qui incremente les variables de la structure du joueur pendant que l’affichage continu de boucler en mettant à jour (boucle principale).
Auriez vous une alternative à me proposer avec votre expérience où est ce la meilleure solution ?
Non pour ma part, le plus simple tu te fais des structures qui décrivent ton jeu (un tableau de structure sprite, une structure pour le fond, etc...)
Dans ta boucle principale, d'abord, tu vas dans une fonction "Evolue", qui regarde sur quoi tu appuies, déplace les sprites, mais en changeant juste leur coordonnée dans les structures, etc... Qui ne touche pas l'affichage du tout, mais les structures.
Puis tu te fais une fonction "Affiche", qui elle affiche tout, en lisant les structures. Cette fonction doit être courte, elle regarde les structure et affiche. Elle illustre, c'est tout. Et toutes les routines d'affichage sont dans la fonction "Affiche".
Non pour ma part, le plus simple tu te fais des structures qui décrivent ton jeu (un tableau de structure sprite, une structure pour le fond, etc...)
Dans ta boucle principale, d'abord, tu vas dans une fonction "Evolue", qui regarde sur quoi tu appuies, déplace les sprites, mais en changeant juste leur coordonnée dans les structures, etc... Qui ne touche pas l'affichage du tout, mais les structures.
Puis tu te fais une fonction "Affiche", qui elle affiche tout, en lisant les structures. Cette fonction doit être courte, elle regarde les structure et affiche. Elle illustre, c'est tout. Et toutes les routines d'affichage sont dans la fonction "Affiche".
Je vois ce que vous voulez dire mais du fait je vais devoir passer en argument tout ce que j’ai crée dans le main pour la fonction d’affichage ?
Si j'ai bien compris Fvirtman, tu ne passes qu'une structure à la fonction d'affichage (ou son pointeur). Tout ce dont tu as besoin pour afficher devrait s'y trouver.
- Edité par PierrotLeFou 23 mai 2022 à 18:53:36
Le Tout est souvent plus grand que la somme de ses parties.
Si j'ai bien compris Fvirtman, tu ne passes qu'une structure à la fonction d'affichage (....)
Et encore.... je sais, les variables globales c'est mal. Mais dans le cas présent, pourquoi se trimbaler une structure de fonction en fonction ? Autant la mettre en globale, elle n'est modifiée qu'à un seul endroit (si le programme est bien écrit): la gestion de évènements (et lors de l'init, bien sur).
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Si j'ai bien compris Fvirtman, tu ne passes qu'une structure à la fonction d'affichage (ou son pointeur). Tout ce dont tu as besoin pour afficher devrait s'y trouver.
- Edité par PierrotLeFou il y a environ 1 heure
je n’avoue que je vois pas bien comment vu que je n’ai pas un nombre déterminé d’elements. J’utilise déjà une liste chaînée pour le décor.
> Et encore.... je sais, les variables globales c'est mal. Mais dans le cas présent, pourquoi se trimbaler une structure de fonction en fonction ?
En fait la localité / globalité, c'est relatif. Si on programme dans un langage 00, les méthodes manipulent des attributs d'un objet, qui ne sont ni locaux à la méthode, ni transmis en paramètres. Ni globaux non plus. Et encore il y a des trucs "globaux" qui sont rangés dans un espace de noms (package ? module ?), ça pose pas de problème.
Si on revient à l'antiquité, les langages n'avaient souvent (typique fortran) que des variables globales et des variables locales à une fonction/procédure ou a un bloc. Comme la notion de fonction/sous programme était considérée comme "avancée" dans l'apprentissage, on ne faisait au début qu'un main, et on fourrait toute les variables au même endroit. Puis venait les procédures, et comme on avait la flemme de passer des tas de paramètres (pour les regrouper il aurait fallu avoir des structures) - toujours les mêmes - hop, des variables globales.
Quand on a commencé à apprendre comme ça, les enseignants devaient faire la guerre pour donner l'habitude de passer les trucs en paramètres. Donc principe dogmatique psycho-rigide, CEUX QUI METTENT DES VARIABLES GLOBALES IRONT EN ENFER.
On retrouve ces principes pas finauds (absence de discernement du pourquoi et du comment) sur différents sujets : les breaks dans les boucles, les return au milieu des fonctions, les gotos, etc. On baptise ça "norme de programmation de l'école machin", et comme l'école machin forme des génies, c'est surement bien, alors tout le monde doit faire pareil. OBEISSEZ, ESCLAVES PISSEURS DE CODE !
J'ai utilisé Allegro il y a quelques années, mais pas pour un jeu, c'était pour faire des affichages (animés) avec des éléments graphiques. Il me semble que le principe, c'était de matérialiser l'écran par un tableau, un « buffer », que l'on envoyait à l'écran tout à la fin des calculs avec la fonction 'blit'.
Du coup j'imagine que tous les éléments de ton jeu doivent d'abord être gérés dans le tableau (si un personnage se déplace, il se déplace sur le tableau) et, seulement à la fin, on envoie : « blit » !
(Je me souviens qu'au début − je débutais, hein ! − je n'utilisais pas de « buffer » et affichais directement : c'était moche, l'animation était hachée et clignotait. Puis j'ai lu qu'il fallait utiliser 'blit' et l'animation est devenue fluide. Et c'est logique.)
----
PS : est-ce que tu utilises le livre de F. Drouillon ?
Non pour ma part, le plus simple tu te fais des structures qui décrivent ton jeu (un tableau de structure sprite, une structure pour le fond, etc...)
Dans ta boucle principale, d'abord, tu vas dans une fonction "Evolue", qui regarde sur quoi tu appuies, déplace les sprites, mais en changeant juste leur coordonnée dans les structures, etc... Qui ne touche pas l'affichage du tout, mais les structures.
Puis tu te fais une fonction "Affiche", qui elle affiche tout, en lisant les structures. Cette fonction doit être courte, elle regarde les structure et affiche. Elle illustre, c'est tout. Et toutes les routines d'affichage sont dans la fonction "Affiche".
Je vois ce que vous voulez dire mais du fait je vais devoir passer en argument tout ce que j’ai crée dans le main pour la fonction d’affichage ?
Comment sont structurées tes données ?
Car normalement, si tu fais quelque chose de propre, tu devrais avoir une structure qui décrit ton monde (avec dedans un ou plusieurs tableaux de sprites, le décor, bref, tout bien structuré, bien rangé, hiérarchisé dans une structure mère, et c'est un pointeur vers la structure mère que tu passes).
Si tu étais en C++, je dirais même que tu passerais ta structure mère en const, car la fonction affiche n'a rien à modifier : elle consulte la structure pour afficher.
> je n’avoue que je vois pas bien comment vu que je n’ai pas un nombre déterminé d’elements. J’utilise déjà une liste chaînée pour le décor. Une liste chaînée? Des tableaux alloués dynamiquement ne seraient-ils pas possibles dans ton cas?
Le Tout est souvent plus grand que la somme de ses parties.
> Quand on a commencé à apprendre comme ça, les enseignants devaient faire la guerre pour donner l'habitude de passer les trucs en paramètres. Donc principe dogmatique psycho-rigide, CEUX QUI METTENT DES VARIABLES GLOBALES IRONT EN ENFER.
Je suis d'accord avec toi, faire comprendre l'intérêt est essentiel.
Pour un jeu, cela me semble facile : tu peux faire évoluer ton jeu pour qu'il devienne multijoueur ou que plusieurs parties avec des joueurs différents puissent être jouées en parallèle en réseau. Les apprentis programmeurs ont, la plupart du temps, tous déjà joué à des MMORG, ou rêvent d'en faire.
* en fonctionnant avec des variables globales, ou même avec variables statiques dans un module non exposées par un .h, le code de mes fonctions gérant la logique du jeu peut être consommé une fois par le programme (singleton) * en encapsulant les données propres à un jeu dans une struct, et en passant un pointeur sur struct à ces mêmes fonctions, je peux demain faire évoluer mon jeu pour lancer plusieurs parties simultanées avec le même code (j'ai créé un "objet" au sens C définissant les éléments d'un jeu et son état à un moment T).
Bien sûr, il y a plein d'autres vertus, mais celle-là est parlante.
On peut tenir un discours similaire pour convaincre de l'intérêt de découpler le traitement des éléments du jeu de leur affichage ou de l'interaction avec le joueur : on fait un jeu avec une idée révolutionnaire sur le terminal, qu'on peut faire évoluer en jeu graphique pour PC, pour console de jeux ou pour un navigateur, en changeant les parties gérant les entrées et sorties, et toute la planète joue à ton jeu ;-D
Après il faut tout de même faire le distinguo entre deux notions :
ce qui est imposé par des normes ; que ce soit professionnellement ou scolairement, ce ne sont que des directives plus ou moins rigides afin d'uniformiser le code produit. Cela peut aller du simple reformatage de code source pour respecter une esthétique précise, à l'utilisation de patterns/idiomes précis.
ce qui est appris durant un cursus ; quand on apprend (le C par exemple) on apprend quelques règles rigides comme pas de goto, pas de variables globales, pas de singletons, une fonction doit faire une chose uniquement, à chaque malloc son free unique, etc … Certaines s'appliquent toujours sans conteste : par exemple celle du malloc ; D'autres sont plus flexibles comme celle de la fonction ; parfois une fonction peut faire un peu plus ça dépend du contexte, de l'humeur, etc ; elle peut parfois même faire moins D'autres sont également flexibles mais contrairement au point précédent, il faut les contourner avec beaucoup de discernement et dans des conditions particulières. A priori, les débutants n'ont pas encore le discernement nécessaire et ne rencontrent en général pas les conditions particulières requises. Et s'ils ne dépassent jamais ce stade alors ces directives claires seront toujours utiles. Si on emploie beaucoup de novice alors on finit par retrouver ces règles rigides dans les documents normalisateurs …
Si tu as 2 boucles (presque) infinies, alors tu as mal pensé ton programme. Dans un jeu, il n'y en a qu'une, celle qui fait tourner le jeu. Traditionnellement elle boucle sur : lecture des entrées (pad, souris, clavier..), traitement (déplacements, collisions, animations..), livraison des sorties (l'affichage..). C'est résumé, mais ce sont les grandes lignes.
Il n'y a aucune raison d'avoir à boucler quoi que ce soit pour déplacer un personnage.
Un mouvement revient à parcourir une distance par unité de temps. Si je choisi la boucle principale (frame) comme unité de temps, alors le perso se déplace de X pxl/frame, je le fais avancer de X à chaque boucle de jeu, aucune nécessité de boucler spécifiquement sur le déplacement du perso pour faire ça.
En plus, il n'y a aucun sens à afficher tes backgrounds avant même de savoir où ils sont censé être puisque sur un scrolling, c'est la position du perso qui doit imposer la position d'affichage du background.
Le perso se déplace dans le monde, la caméra suit le perso, on prend la photo puis on l'affiche.
Petit conseil en général : si tu n'arrives pas à faire un truc qu'il a été possible de faire sur un Atari 2600 ou une NES, alors la solution n'est pas le thread, pas les listes chaînées, pas des calculs au 3ième degré pour faire sauter un bonhomme, ni aucune des autres atrocités absolument overkill que l'on peut voir ici où là..
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
Bonhomme !! | Jeu de plateforme : Prototype.