Posté le 03/07/2018 21:19
L'adresse du Gitea : https://gitea.planet-casio.com/Equipe_Odyssee/Odyssee le scénario : ici et là ainsi que sur le Git Mécanique de base et combats Fuite et sorts Les niveaux ils vont jusqu'ici Les objets Le système de matrice pour les maps
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 138 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
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
Citer : Posté le 30/10/2018 23:39 | #
Ah, sorry, je n'avais pas fait attention à cela !
Citer : Posté le 31/10/2018 13:56 | #
J'ai jeté un œil rapide, je t'ai pas ignoré mais en ce moment, j'ai vraiment beaucoup de difficultés à suivre le niveau de première S...
Edit : pour la technologie, je suis partagé : Gint est vraiment génial, mais l'installer sur une VM et devoir travailler sur VM, ça me gonfle... d'autant que les sprites trouvés sont en monochrome, alors que si on utilise Gint, on prendra des images avec nuances de gris
Citer : Posté le 04/11/2018 18:21 | #
En lisant la RDP je me suis rendu compte que je suis le seul à n'avoir rien à faire (ça ne me gène pas du tout au contraire
Si vous avez quelque chose à me demander...
16×16 c'est rendu Pokémon ?
Pour le gameplay vous pensez que ce serait mieux case par case ou "flottant" (plus précis), personnellement pour les RPG j'ai toujours préféré le case par case mais j'ai des goûts particuliers.
Il y a un casino dans le script ? J'adore les casinos dans les jeux.
Le code sera-t-il Libre ?
Bon, bonne soirée
Citer : Posté le 04/11/2018 18:45 | #
Alors...
Toutes les tâches n’en sont pas definies donc tu auras forcément un truc à faire
Je penche aussi pour du case par case mais on a pas choisit
Pour le casino c’est pas prévu : le jeu se déroule dans un endroit époque médiévale
Citer : Posté le 04/11/2018 19:02 | #
http://www.instrumentsmedievaux.org/loisirs-au-moyen-age-les-jeux-dargent/
Il y a bien un bourgeois qui nous proposerait une partie de dés ?
Comme l'a dit LePhénixNoir, 16×16 c'est un peu gros, et en plus l'écran fait 64×128 (de mémoire) donc ça fait des cases de 4×4 pixels...
8×8 c'est déjà mieux, mais ça laisse plein d'espace inutilisé.
Je propose 8×12.
Citer : Posté le 04/11/2018 19:25 | #
En lisant la RDP je me suis rendu compte que je suis le seul à n'avoir rien à faire
Tu n'es pas le seul crois-moi. Cela fait longtemps que je me suis engagé dans le projet et jusqu'à présent je n'ai pas servi à grand chose, si ce n'est pas pour dire rien du tout. Et le simple fait de voir mon nom dans la revue sans avoir fait quoi que ce soit me gêne énormément.
Pardonnez-moi de ne pas avoir été vraiment actif dans le projet. Je n'ai plus suivi l’avancement depuis la rentrée et j'ai été vraiment en galère ces derniers temps en cours. Je sais que tout est posté dans le gitlab mais j'ignore totalement comment il fonctionne.
J'espère qu'il n'est pas trop tard, j'aimerais être utile sur quoique ce soit dans le projet. J'ai pu acquérir quelques compétences de bases du C en prépa que je n'ai pas du tout encore utilisé sur calculatrice. Je me débrouillerai pour trouver du temps pour cela.
Citer : Posté le 04/11/2018 19:42 | #
Ne t'en fait pas !
Il n'est jamais trop tard ! On t'aideras à récupérer les connaissances si vraiment ça te manque
Pour les dimensions, des carrés multiples de 4 seraient les bienvenus : 4*4, 8*8, 12*12, 16*16
Citer : Posté le 04/11/2018 20:18 | #
Pour les dimensions, des carrés multiples de 4 seraient les bienvenus : 4*4, 8*8, 12*12, 16*16
Je pensais à un quadrillage 8×12 de carrés 8×8
Citer : Posté le 04/11/2018 20:21 | #
Personnellement, je sais que j'hésiterais entre du 8×8 et du 10×10, qui e semblent être de bons compromis taille de case / taille de l'écran
Citer : Posté le 04/11/2018 20:21 | #
Ça me paraît être une bonne idée ça, mieux que 16×16 en tous cas.
Citer : Posté le 04/11/2018 20:29 | #
Personnellement, je sais que j'hésiterais entre du 8×8 et du 10×10, qui e semblent être de bons compromis taille de case / taille de l'écran
Autant prendre le milieu dans ce cas: 9x9 (Comme ça on a un écran de dimension 7x14 puisque le pixel 64 et 128 ne sont pas pris par l'écran je crois)
Citer : Posté le 04/11/2018 20:38 | #
Choisissez attentivement votre taille en fonction des symétries aussi : quand vous dessinez un arbre, une fleur, etc. vous voulez que la tige fasse (souvent) 1 pixel de large, et donc pour que la chose soit symétrique il faut lui allouer un nombre impair de pixels.
Donc, si vous partez sur un tile impair et que vos objets sont de taille impair, vous n'aurez pas d'espacement entre les tiles, ie. deux arbres côte à côté vont se toucher. Ce n'est pas très très important, mais planifiez un peu.
Citer : Posté le 05/11/2018 18:52 | #
C'est pas con... mais tous notre (ma) reserve de sprites est en 16*16...
Citer : Posté le 05/11/2018 19:00 | #
donc on fait tous ce que vous voulez par par pitié ne changez pas la taille des sprites ou alors, en fonctions du numéro du tableau de sprite appelé on fait varier la commande ML_bmp_or_cl... Oui, je pensais faire un grand table qui récapitule tous les sprite du jeu sauf le personnage. Et selon le numéro que l'on appelle avec le moteur physique on fait varier les paramètres de la fonction qui dessine... c'est pas bête ? nan ?
Ai pas compris
Pour la minimap j'ai une idée !
On découpe tous les sprites en 4 (si 16x16 en 4 tiles de 8x8), déjà ça fait gagner de la place pour les doublons et ensuite on peut afficher la minimap plus efficacement... Enfin je pense.
Citer : Posté le 05/11/2018 19:15 | #
Alors que je t'explique un peu comment ça fonctionne, n'oublions pas que pour beaucoup (dont moi) c'est avant tout l'occasion rêvée d'apprendre le C
En C, les graphismes, (sprites, tiles,...) sont convertis du *.png initial à des *.txt contenant les code hexadécimal de l'image monochrome... Tu me suis ? Ces codes hexadécimaux sont présenté sous forme d'un tableau.
C'est pratique : tu oublies aucun code hexa...
Ces tableaux ont un petit nom (c'est le petit plus du C) et si on met ces petits noms dans un autre tableau, on va obtenir un gros tableau qui va contenir tous les autres tableaux qui contiennent les codes hexa des images...
On sait que les sprites font (c'est un exemple) 8*8 pixel, ça fait un écran qui est composé de 12 cases par 8
Maintenant on créer une matrice de 12*8 qui contient "l'intérieur" de la case, ça va ? Donc on va avoir un "1" pour un bout de mur, un "2" pour une fenêtre, un "3" pour une porte,... etc
Maintenant passons au moteur graphique (la base)
On va construire deux boucles For qui vont balayer la matrice et à chaque tour de boucle on regarde le chiffre stocké dans la matrice. On regarde aussi le numéro de la grosse liste qui correspond à numéro stocké dans la matrice...
Là je t'ai perdu ? Bon en fait c'est super-simple mais je sais pas expliqué...
Dans une grosse liste tu as plusieurs petites listes, la première correspond à un bout de mur, la deuxième petite liste contient les codes hexa d'une fenêtre,...
Donc plutôt de faire ML_bmp_or_cl(grosseListe[0],...) pour afficher un bout de mur, tu regarde ce qu'il y a dans ta matrice à cet emplacement (puisque que ta matrice est une sorte de carte de la map à afficher) on va avoir un truc qui ressemble à ML_bmp_or_cl(grosseListe[matrice[x][y]],...)
Exemple :
const unsigned char mur[]={0x0ff,0x0aa,...}; /*Aux lignes 1, 2, et 3 je déclare mes tableaux qui contiennent les codes hexadécimaux de mes images, pour plus de simplicité, j'ai donné le nom de l'image dessinée par le tableau au tableau...*/
const unsigned char fenetre[]={0x...};
const unsigned char porte[]={...};
// maintenant on va faire une grosse liste qui va récapituler tous ça on note *[i]nom[/i] car c'est un tableau de pointeur, ne t'occupe pas de ça on s'en fout:
const unsigned char *Sprites[]={mur , fenetre , porte}; // voila c'est tout !
// la matrice, là elle est "ouverte" pour que tu vois mieux (elle s'appelle "Map")
const char Map[12][8]=
{{0,0,0,0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0,0,0,0},
{0,1,2,3,0,0,0,0,0,0,0,0}};
// les valeurs entrées correspondent au dessin à faire : au niveau du 1 on aura du mur, sur le deux on aura une fenêtre, sur le trois une porte.
// Le moteur physique
ML_clear_vram(); // on nettoie la VRAM
For (x=0 ; x!=12 ; x++)
{
For (y=0 ; y!=8 ; y++)
{
ML_bmp_or_cl (Sprite[ Map [x] [y] -1 ] , coordx*8+x , coordy*8+y , 8 , 8 ); // là c'est un peu compliqué, on affiche sur la VRAM le contenu (l'image en quelque sorte) du tableau Sprite à la case Map[x][y]-1, oui, -1 car les tableaux en C débutent avec 0, donc le chiffre 0 affiche un mur, le 1 une fenêtre, tout est décalé donc il faut tout bien remettre en ordre ici ! ensuite on utilise "coordx" et "coordy" ce sont des variables qui déterminent la position du sprite dessiné le 8 parce que les sprites son 8*8 pixels...
}
}
ML_display_vram(); // on affiche la VRAM
Et voila !
Citer : Posté le 05/11/2018 20:53 | #
C'est super bien expliqué merci
Je connais les pointeurs (et les déteste
J'ai fait du C++ donc j'ai "les bases de la base"...
Je me demande ce que provoque le [-1] comme indice dans un tableau.
Car cette ligne
fonctionne même avec rien à dessiner ?
J'ai tout compris sauf ça en fait
Citer : Posté le 05/11/2018 20:57 | #
Ah c'est malin tiens, j'étais en train de rédiger une explication plus détaillée.
Citer : Posté le 05/11/2018 21:06 | #
Ah c'est malin tiens, j'étais en train de rédiger une explication plus détaillée.
Ah ^^'
Je veux bien voir si elle n'est pas morte...
Citer : Posté le 05/11/2018 21:46 | #
Le "-1" très bonne remarque il suffit d'insérer une conditionnelle subrepticement
Citer : Posté le 05/11/2018 21:49 | #
Ah c'est plus logique d'un coup !
Alors pourquoi faire ça ? Autant mettre la map avec -1 pour les cases vides (parce que la calto n'aura jamais à afficher 256 tuiles différentes j'espère) et retirer cette soustraction.
Citer : Posté le 05/11/2018 21:51 | #
Heureusement mon navigateur est plus fort que ça. Je vous ai peut-être sous-estimé dans cette explication, désolé si c'est le cas.
Je me permets de faire une version légèrement revisitée de tout ça, d'abord pour contribuer à expliquer, et aussi parce que gint vous simplifie la vie sur ce point...
C'est pratique : tu oublies aucun code hexa...
En fait, peu importe le langage dans lequel tu travailles, ce qui importe c'est que tu aies les données de l'image. C'est-à-dire, des informations te permettant de savoir, d'une façon ou d'une autres, quels pixels sont blancs et lesquels sont noirs.
Comme en C, on peut faire à peu près tout ce qu'on veut (et même plus), on décide d'utiliser un bit de mémoire pour chaque pixel : 0 pour blanc et 1 pour noir. Ça nous prend autant de bits qu'il y a de pixels dans l'image, disons N.
Du coup il nous reste à trouver un moyen de mettre ces N bits dans le programme. La méthode classique consiste à créer un tableau de char avec des données en hexa, mais c'est pas obligé. gint fait ça bien plus joliment par exemple.
Ensuite, pour les afficher, eh bien on appelle une fonction de MonochromeLib, par exemple ML_bmp_or_cl() en lui disant où les bits de ton image où été mis, et elle se débrouille pour afficher.
Dans un programme C, toutes les données ont un nom, ça fait partie du jeu. Donc en fait ce qu'on a une variable qui représente les données de l'image. Par exemple logo_du_jeu.
Donc ça c'est bien pour afficher une seule image. Attention à ne pas confondre avec ce qui suit.
Quand tu vas afficher ta map, tu auras tes tiles, et si tu y vas naïvement, une image par tile. Donc tile_arbre, tile_maison_1, tile_maison_2, tile_puits... bref, tout un paquet. C'est pas terrible, tu vois venir le désastre au momen d'afficher un tile :
ML_bmp_or_cl(tile_arbre ...)
Sinon, si le tile est la partie gauche d'une maison
ML_bmp_or_cl(tile_maison_1 ...)
Sinon, si le tile est la partie droite d'une maison
ML_bmp_or_cl(tile_maison_2 ...)
Sinon, si le tile est un puits
ML_bmp_or_cl(tile_puits ...)
C'est la galère complète ! Chaque fois que tu veux ajouter un tile, tu es obligé de modifier le code. Hors de question de faire ça.
En fait tu n'as pas vraiment envie d'avoir un nom pour chaque tile. Tu as plutôt envie d'avoir un nombre pour chaque tile, c'est-à-dire de mettre tes tiles dans un tableau. Comme je suis flemmard, je l'appelle tiles[] (les crochets c'est juste pour rappeler que c'est un tableau). Bien sûr, on va vouloir écrire des trucs comme tiles[i] avec i une valeur entière bien choisie. Ce qui donne :
ML_bmp_or_cl(tiles[i] ...)
Hop, plus besoin de travailler. Il te suffit de regarder le numéro du tile que tu veux afficher (ça, c'est marqué quelque part dans la map) et tu affiches. Plus besoin de te poser de questions inutiles comme « est-ce un arbre ? » ou bien « est-ce que j'ai pensé à ajouter mon tile fleur au code ? ».
Maintenant on créer une matrice de 12*8 qui contient "l'intérieur" de la case, ça va ? Donc on va avoir un "1" pour un bout de mur, un "2" pour une fenêtre, un "3" pour une porte,... etc
Ici, il s'agit simplement de décider d'un numéro pour chaque tile. Il faut que ça corresponde à l'ordre des tiles dans le tableau, donc ne le change pas trop souvent. Ajouter des nouveaux numéros est safe, renuméroter ce qui existe veut dire que tu dois modifier toutes tes maps (et ça t'as pas envie !).
On va construire deux boucles For qui vont balayer la matrice et à chaque tour de boucle on regarde le chiffre stocké dans la matrice. On regarde aussi le numéro de la grosse liste qui correspond à numéro stocké dans la matrice...
Ça c'est bien clair, tu lis les données dans la matrice, tu vas chercher les sprites, tu dessines. Pouf.
Btw Shadow, le moteur d'affichage... c'est le graphique. Le moteur physique, c'est les collisions, les mouvements des personnages, tout ça tout ça.
Ajouté le 05/11/2018 à 21:52 :
Ahrem