Mon premier jet en C... Ce n'est pas brillant mais faut ben commencer...
On peut juste bouger le personnage à l'aide des flèches. Les collisions sont gérée et je travaille sur "comment rentrer dans la petite maisons ??"
L'arbre est issu d'une banque de sprite que j'ai trouvé sur ce site. Et la maisons est constituées de tileset que j'ai faite grâce à un tuto (sur ce site également)
Le premier fichier (*.g1a) est le "jeu" le deuxième correspond au sources.
Mon personnage est animé lors des déplacements
Améliorations à venir
peut-être...
-Possibilité d'entrer dans le bâtiment.⇒Fait
-Gestion de la course par la pression d'une touche du Replay et de Shift.
-gestion de l'intérieur du bâtiment
-nouveau style de maisons en brique
-système d'énigme, interrupteur, histoire,...
-armes, et système de combat
-map plus évoluées : herbes, cailloux, d'autres arbres et artéfacts
J'essayerai d'en mettre une
Mais sincèrement ce n'est pas un jeu c'est tout juste un début de commencement de gestion de graphismes avec le C...
Cela ne vaut pas la peine d'être téléchargé... Par contre toute aide sur le code sera la bienvenue : gestion des chocs, affichages,...etc
Ce petit bout de code marche parce que le bon dieux l'veut bien... et je crains qu'une map plus complexe ne soit pas aussi fluide...
merci
Pour les graphismes je n'ai pas fait grand-choses. Pour les capacités, c'est... énormes j'en suis rester sur le cul quand j'ai vu la vitesse d'exécution !!
En BASIC Casio un boucle For (vide) qui va de 0 à 75 à un impact visible en C il faut pousser la boule For (vide) de 0 à 20 000 pour avoir un truc visible
Eh bien ! J'ai pas pu m'empêcher de le télécharger quand j'ai vu l'image
Tu voulais des commentaires sur le code, eh bien en voilà !
-
Quand tu as des variables qui vont dans la mémoire, il y a deux destinations possibles : la ROM (mémoire de stockage) et la RAM (mémoire de calcul). La ROM, tu peux lire ce qui est dedans mais tu ne peux pas modifier les valeurs. La RAM, tu peux lire et écrire à volonté dedans.
Pour les gros paquets de données qui ne changent jamais, comme les sprites, on préfère utiliser la ROM parce que la RAM est petite et précieuse. En déclarant le sprite avec const char truc[] = { ... } au lieu de char truc[] = { ... } (note le const), on indique au compilateur que les données ne vont jamais changer, et cela l'incite à mettre le tableau dans la ROM. C'est mieux.
-
Quand tu dessines à l'écran dans un add-in, la technique c'est :
1. Tu dessines tout dans la VRAM sans changer ce qu'il y a à l'écran
2. Tu envoies la VRAM à l'écran (quasi-instantané)
La VRAM, c'est juste une zone de RAM assez grande pour qu'on puisse représenter tous les pixels de l'écran dedans.
Cette technique s'appelle double-buffering (parce qu'il y a deux "écrans" ou "buffers" : le vrai et la VRAM), et son intérêt c'est que ton utilisateur ne voit pas ce que tu es en train de dessiner, puisque tu le fais dans la VRAM. Il ne voit que le résultat final, et le résultat est plus fluide.
Tout ça pour dire qu'en général, on n'utilise jamais de fonctions pour dessiner directement à l'écran, en particulier par de ML_clear_screen(). Car au tout début de ton programme, à cause de cet appel de fonction, l'écran est blanc pendant une petite fraction de seconde. Si tu fais ça trop souvent, ça va donner l'impression de clignoter.
Morale : tu n'as pas besoin d'appeler ML_clear_screen() quand tu veux commencer à dessiner sur du blanc. ML_clear_vram() suffit.
-
À un endroit, tu as écrit ML_display_vram;, ce qui n'a aucun effet ! :o
Pour appeler la fonction, n'oublie pas les parenthèses, même s'il n'y a pas d'arguments : ML_display_vram().
Comment ça se fait que les contenus de la VRAM étaient quand même affichés à l'écran, alors ? Eh bien, c'est GetKey(), qui fait automatiquement un ML_display_vram (en gros) quand tu l'appelles
-
Le dernier point est un peu compliqué... je ne vais pas m'étendre trop dessus.
Tu as mélangé GetKey() et IsKeyDown(), c'est « mal ». On voit que tu as essayé, avec des Sleep(), de faire en sorte que le personnage continue de se déplacer tant que la touche reste appuyée.
Eh bien, en fait, tu n'as pas besoin ! GetKey() répète les touches directionnelles, c'est-à-dire que si tu restes appuyé sur une touche GetKey() va renvoyer plusieurs fois son numéro.
Voilà comment tu peux améliorer ta boucle while : en-dessous de chaque case, tu déplaces le personnage dans la direction indiquée, mais juste une fois. Tu ne cherches pas à savoir si la touche reste appuyée. Si tu fais ça, alors dans chaque case, il ne doit plus y avoir de IsKeyDown(), plus de Sleep, et plus de boucle while. C'est bon ?
Dans ce cas, quand j'appuierai sur [↓], GetKey() va renvoyer KEY_CTRL_DOWN et tu vas rentrer dans le switch. Mon personnage va descendre un peu, et hop, fini le switch. Ton programme va re-rentrer dans la boucle while et ré-appeler GetKey().
Et comme GetKey() répète les touches directionnelles, eh bien au bout d'un petit délai si la touche est toujours appuyée GetKey() va re-renvoyer KEY_CTRL_DOWN, et donc je vais continuer à descendre !
Je t'invite vraiment à faire cette modification que j'ai expliquée parce qu'actuellement la façon dont tu utilises le clavier est très bizarre et pas vraiment recommandable.
-
Voilà, j'en ai dit pas mal ! J'espère que ça te servira. Tu t'en sors très bien pour tes débuts, alors ne t'arrête surtout pas !
Je suis ravi effectivement
@Lephé : Merci des conseils et des encouragement
J'ai réussi à le faire entrer dans la maison !! via la touche alpha.
Je couche sur le papier un projet de Tomagoshi... Sans grand-espoir c'est juste pour le fun en plus y en a déjà un...
Pour toutes tes idées je rêverais mon code : parce que les commentaires constructifs c'est sympa mais si j'en fait rien c'est complètement con je te demanderais sans dote de petites précision le C me parait bien technique tout à coup...
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
A cause du changement de processeur des nouvelles Graph 35+ USB, 75 et 95 SD, de nombreux addins sont incompatibles avec ces calculatrices.
je te demanderais sans dote de petites précision le C me parait bien technique tout à coup...