[AXE] Une sorte de mini-rpg

Non ne met pas des bloc noir autour de la map ca ne sert a rien, tu fais lors du dessinage de ta map :

If cordonnée depasse la map
dessin d'un carré noir
else
dessin du sprite de la map
end

Ok merci pour ce conseil sachiix, je vais pouvoir gagner 600 blocs

Dans les coordonnées, quand je dessine la map, j'utilise deux boucles qui vont respectivement de 0 à 7 et de 0 à 11. Donc en théorie je ne dessine que le blocs qui se trouvent sur la map, comment est-ce que je peux tester "If coordonnées dépassent la map" ?

La map est plus grande que l'écran donc il faudra gérer le déplacement de l'écran. C'est pour ça que la question se pose pour nous.

Si tu essais de dessiner quelque chose hors de la map, cela va au mieux dessiner n'importe quoi et au pire planter.
Si tu choisis des changements d'écran fixe, alors il suffira de refuser le changement d'écran ou placer des murs.

Mais si tu choisis un écran centré sur le personnage, alors soit la méthode de sachiix69 sera indispensable, soit tes routines de dessin évitent déjà le dessin extérieur.
En effet le personnage pourrait être au bord de la map et l'écran dépasserait de la map...

Pense aussi qu'il n'y a pas que le dessin de l'extérieur qui peut gêner, mais aussi l'état et les contrôles du personnage qui pourraient dépendre des tiles.

En fait moi ce que j'ai fait dans TinyCraft pour me simplifier la tâche, c'est en gros ne pas avoir de carrés noirs inutiles dans l'appvar lorsqu'elle est archivée (pour sauver de la place dans la calculatrice lorsque le programme ne tourne pas), mais au lieu de la désarchiver bêtement, en fait je la copie dans une autre appvar dans laquelle j'ajoute les blocs noirs. Du coup je traite la deuxième map plus simplement que s'il n'y avait pas les blocs noirs, et je ne perds pas de place dans la sauvegarde pour autant. Et ensuite évidemment pour sauvegarder je copie les octets utiles (sans les blocs noirs) dans l'appvar archivée (que j'aurais désarchivée au préalable et archivée ensuite).

Oui, sympa, mais je pense que c'est plus simple d'effectuer un test comme dit sachiix69, car on n'a pas forcément besoin de gagner en vitesse.
Si la vitesse joue, alors utiliser des murs, surtout dans une appvar temporaire comme tu fais, est préférable.

Oui, ma méthode fait gagner en virtesse, mais ce n'est pas pour ça que je l'ai présentée. C'est surtout parce que justement on n'a plus de "If" à écrire. Parce que des "If", il faut non seulement en mettre lors de l'affichage de la map, mais aussi lors des tests de collision comme tu l'as dit plus haut, ce qui alourdit le code  et multiplie aussi le risque d'oublis.

Mais bon, ça a aussi des inconvénients bien entendu : ça mange plus de RAM puisque la map "décompressée" est plus lourde que la map "compressée". Surtout si l'exécutable est une application (qui ne mange pas de RAM et qui prend toujours 16384 octets quelque soit le nombre de If qu'on met dedans (sauf si on en met trop et que ça rentre plus)).

En gros il ne faut pas mettre de If ca prendrais trop de cycle : 

Code:

:[]→pic0
:[FFFFFFFFFFFFFFFF et la tu met tout tes sprite...]

:Lbl Map
:0→r2→r1
:for(96)
:pt-on(r1,r2,1+XX*(r1>I or (r2>L))+pic0)
//ou XX est ton numero de map (oublie pas que tout est decalé a cause du premier sprite noir) I la largeur de la map et L la longueur
:!If r1++-11
:→r1
:r2++
:End
:End


Et la tu as une belle tilmap non optimiser mais qui fonctionne (je suppose) bien

Et que raconte tu pour la collision hayleia ???

Enfait ma tilemap fait déjà en sorte que l'on ne puisse pas voir ce qui se trouve en dehors de l'écran, d'ou led blocs noirs. Je vois ce que tu veux dire, mais ça ne peux pas s'appliquer pour l'instant à mon système.

Je pourrais le modifier par la suite

sachiix69 a écrit:En gros il ne faut pas mettre de If ca prendrais trop de cycle : 

Code:

:[]→pic0
:[FFFFFFFFFFFFFFFF et la tu met tout tes sprite...]

:Lbl Map
:0→r2→r1
:for(96)
:pt-on(r1,r2,1+XX*(r1>I or (r2>L))+pic0)
//ou XX est ton numero de map (oublie pas que tout est decalé a cause du premier sprite noir) I la largeur de la map et L la longueur
:!If r1++-11
:→r1
:r2++
:End
:End


Et la tu as une belle tilmap non optimiser mais qui fonctionne (je suppose) bien

Et que raconte tu pour la collision hayleia ???

Ben si tu mets un If dans ta routine de dessin, ça affichera des blocs noirs en dehors de la map, mais il faut aussi mettre un If dans la routine de déplacement pour éviter que tu ne te déplaces dans ces blocs noirs, parce que même si le dessin représente un bloc noir, aux alentours de ta map (dans la data que tu ne contrôles pas) tu as peut-être des octets qui ne correspondent pas à des murs.

(Et d'ailleurs, tu vois que t'es naze en optimisation, t'as quand même écrit 1+XX dans ton code précédent. Ok le code n'était pas censé être optimisé, c'est à dire que tu utilises des algorithmes pétés mais si t'es un optimiseur t'as quand même des automatismes (qui de plus ne gênent pas la compréhension)).

Ben bien sur que non il suffit de rajouter une conbditions au getkey, conditions qui est : 
(r1>I or (r2>L))

sachiix69 a écrit:Ben bien sur que non il suffit de rajouter une conbditions au getkey, conditions qui est : 
(r1>I or (r2>L))

Ben ok c'est pas un "If" à proprement parler lol mais ça reste du code à ajouter.

De toute maniere tu auras besoin d'un moteur de ce type : 

Code:

:.MiniRPG
:[]→Pic0
:[FF818181818181FF]
:[]→Pic1
:[FFFFFFFFFFFFFFFF ici tes decors]
:[]→GDB0
:[ici ta map disons qu'elle est le de longueur L et de largeur I]

:0→A→B

:While 1
:Sub(Map)
:pt-change(40,24,pic0)
:dispgraph
:pt-change(40,24,pic0)

:getkey(1) and ({B+4*L+5+A+GDB0}=numero tile de l'herbe) and (B<I)?B++
:getkey(2) and ({B+3*L+4+A+GDB0}=numero tile de l'herbe) and (A<L)?A--
:getkey(3) and ({B+3*L+6+A+GDB0}=numero tile de l'herbe) and (A<L)?A++
:getkey(4) and ({B+2*L+5+A+GDB0}=numero tile de l'herbe) and (B<I)?B--

:EndIf getkey(15)
:return^^r

:Lbl Map
:for(Y,0,7)
:for(X,0,11)
:pt-off(X*8,Y*8,{B+Y*L+A+X+GDB0}+1*(X>I or (Y>L))+pic1)
:End
:End
:return


J'ai aucune idée si le code fonctionne j'ai fait ca vite fait (si les autres voyent des erreur corriger les) mais ce code fonctionne dans le principe meeme si il est pas du tout du tout optimiser !

Ça peut parraître bête comme question, mais est-ce qu'il est possible de mettre de l'executable dans une appvar ?

En gros, est-ce que c'est possible de mettre l'équivalent d'un executable dans une appvar,et de l'executer à partir d'un programme axe ?

Je pensais à un truc du genre faire un programme axe, puis le compiler sous le nom PRGM par exemple. Ensuite je fait un autre programme axe qui à l'aide de GetCalc pointe sur PRGM, et copie son contenu dans une appvar au choix. Mais je ne sais pas comment faire pour l'executer, c'est possible ?

Et comment peut on faire une recherche des appvar dans la mémoire (cette question est facultative), par exemple chercher toute les appvar qui sont dans ma mémoire ?

Hum... pour ta premiere question, en axe pur c'est impossible, après je vois peut etre comment on pourrais faire mais ca serais trivial et peut securitaire...

pour ta deuxieme question, soit tu utimlise MemKit (axiom pour se ballader dans la VAT) mais va voir le tuto axe il y a une partie qui l'explique bien. la VAT rassemble tout les objet d'OS donc toute les appvar après il faut juste savoir la maitriser...

Ok merci. Sinon au lieu d'executer des appvar, comment peut-on faire pour executer d'autre programmes en axe à partir d'un programme axe ?

Mais ton RPG n'est quand même pas si gros que ça, si ? Même en mettant toute la data (sprites, textes, splashs, stats, etc) en appvar externe ?

D'une part, si, quand on voit que l'on peux seulement se déplacer sur une carte et frapper les ennemis, et qu'il prend déjà 1/4 de l'espace maxi autorisé, alors qu'il n'y a pas encore de pnj et les relations avec eux (dialogue différent pour chaque = beaucoup de dialogue différent), ni les quêtes (chaque quête a un objectif différent, donc une condition différente pour vérifier l'accomplissement de celle-ci) etc etc...

D'autre part, je me suis mal expliqué pour les appvar.
J'ai pensé à un système qui pourrait être vraiment sympa si il était possible, j'ai donc besoin de votre aide.

Je me suis dit qu'il serait bien de pouvoir avoir plusieurs personnages différents, certains plus au cac et d'autres à distance par exemple.

Des appvar contiendraient les informations qui indiqueraient au programme quoi faire lorsque telle combinaison de touche est effectuée.

Par exemple l'appvar GUERRIER
Lorsque la combinaison "▲►▼◄" est faite, le programme va dans l'appvar, et voit qu'il doit faire une "attaque circulaire", et qu'il doit attaquer toute la zone se trouvant autour du personnage, avec tant de dégats etc etc...

Pour la même combinaison "▲►▼◄", dans l'appvar MAGICIEN, il est indiqué qu'il faut faire un bouclier et donc réduire les dégats etc...

Ces appvar pourraient aussi contenir les skinn des personnages en question, leur vie maximum...

Ce qui serait bien dans ce système, c'est qu'il serait possible de créer d'autre personnages en dehors su jeu après que celui-ci soit fini, et donc d'en avoir en théorie une infinité, surtout qu'on ne serait pas obliger de tous les prendre.

Je sais que ce n'est surement pas facile voir impossible, mais ça serait tellement beau... Et comme on dit l'espoir fait vivre

En gros, ce n'est pas forcement stockée de l’exécutable, mais pourquoi pas une sorte de codex en quelque sorte "interprété" par le jeu.

maxence a écrit:Je sais que ce n'est surement pas facile voir impossible, mais ça serait tellement beau... Et comme on dit l'espoir fait vivre

Au contraire, ça me semble plus facile à coder que de mettre un tas de If dans l'exécutable. Comment tu crois que j'ai codé les 44 Pokémon ? Avec 44 If ? Non avec de la data. Et si tu regardes l'historique de mes projets (qui n'est disponible nulle part), tu verras que Pokemon est le premier jeu que j'aie codé en Axe, et même le premier jeu que j'aie codé en bas niveau. Donc c'est largement faisable pour un débutant.

C'est plausible et je ne voie pas ce qui t'inquiète. Les datas ça sauve la vie, car beaucoup de choses se résolvent par de simples pointeurs.
Récupère un pointeur vers l'appvar qui correspond au personnage au début de la partie, puis utilises ce pointeur pour y accéder chaque fois que tu as besoin des datas du personnage.

Si tu voulais placer du code executable ailleurs que dans l'emplacement habituel des programmes ou des applications, tu devrais faire attention aux addressages et aux sauts. Si quoi que ce soit est absolu, il faut compiler en connaissant à l'avance l'emplacement du code. Si tout est relatif, aucun problème excepté la gestion des pages. Mais je ne sais pas comment fait AxeParser, ni comment lui dire d'executer.

EDIT : ou bien tu devrais simplement copier ce code sous la forme d'un programme qui sera executé à sa place normale, cela n'a donc plus d'intérêt de stocker du code quelque part. Rappelé par nikitouzz.

Récuperer les données telles que la vie, le skin etc ça oui c'est facile.
Mais dire au programme "Lance une attaque dans la zone autour du personnage" avec simplement des données ça l'est moins.

Ton executable peut contenir des routines d'actions et effectuer un test du contenu de l'appvar pour savoir quelle action effectuer.
Jusque là c'est trivial, et je pense qu'il est innutile de se compliquer la vie avec une execution de code contenu dans l'appvar.

Oui c'est exactement ce que je veux faire, mais en un peu plus complexe dans le sens où il faut que le nombre d'actions possibles soitle plus grand possible, que ce soit des attaques, des buff, ou autre tel que des actions de déplacement.

Je réfléchi à un encodage des actions, si vous avez des idées n'hesitez pas.

Ça pourrait être quelque chose du genre :
0 = attaque
1= buff
2 = déplacement

si c'est une attaque, alors les deux valeurs qui suivent sont les coordonnées de l'endroit à attasuer par rapport au perdonnage (par exemple 0 et -1 pour juste au dessus du perso).
Puis la valeur des dégats.

Si c'est un buff, alors...

Hum ou alors pour reprendre ton idee, tu stocke de l'executable sous forme de tokens dans une appvar, tu cree un nouveaux programme avec getcalc, tu copie tout dedans et tu l'execute en asm 

c'est donc "possible" maiss.... ca ne sert a rien

fais des data des data et des data !

mais pour le moment reflchis pas a ca, fais tout ce que tu peux faire avant !

nikitouzz a écrit:Hum ou alors pour reprendre ton idee, tu stocke de l'executable sous forme de tokens dans une appvar, tu cree un nouveaux programme avec getcalc, tu copie tout dedans et tu l'execute en asm 

c'est donc "possible" maiss.... ca ne sert a rien

Sauf que là tu n'as que la première partie, où tu exécute l'appvar, mais tu as oublié qu'après avoir exécuté l'appvar, il faudrait ensuite revenir à l'exécutable principal, et là tu fais comment ? Tu re-copies l'exécutable principal là où il faut, ok, mais comment tu retrouves le "label" où tu dois aller ? Toujours possible mais bien plus difficile.
Je suis donc plus d'accord avec la deuxième partie de ton post, il faut faire des datas.

Et Maxence, afin d'utiliser des datas plus efficaces, pense à utiliser les bits aussi, pas que les octets. Par exemple, ta data "portée" pourrait tenir sur un nibble, le premier bit indiquant si l'attaque atteint devant le perso, le second si elle attaque derrière, le troisième indiquerait la gauche, et le quatrième la droite (évidemment, tu peux choisir l'ordre toi-même, je donne juste un exemple). Et donc une attaque directe aurait un nibble de la forme 1000, une attaque plus étendue (qui attaque devant et sur les côtés) aurait un nibble de la forme 1011, et le nibble d'une attaque qui atteint partout serait de la forme 1111.

De même, au lieu d'attribuer des numéros au types d'actions, tu peux leur attribuer des bits, sur le nibble qui complèterait le précédent par exemple. Cela te permettrait de ne pas te restreindre aux actions simples mais d'avoir aussi la possibilité de combiner les actions. Du coup, si 1000 est une attaque et si 0100 est un soin, alors 1100 peut être une action qui attaque et qui soigne en même temps !

Avec un tel codage, une action prendrait maximum 5 octets de data, sans pour autant être trop restreint puisque tu as 4 types d'actions disponible et 16 possibilités de directions d'attaque quand même. Les 4 autres octets seraient l'amplitude des dégâts, le nombre de PVs restaurés, etc...

Oui hayleia j'ai dit que c'etait possible ùais c'est super super dur...

Bref l'idée d'hayleia est bonne (je le fais pour mon gravity guys) mais c'est une optimisations ca pour lui, il est encore debutant, pour le moment 

Bref fais les chose principal, poste un screen et vois apres pour ce genre de details