Ça fait un bout de temps que je n'y ai pas retouché, mais je crois qu'enfaite lorsque plusieurs pokémons ont combattu, leur ID+1 (autrement le pokémon avec l'ID 0 poserait problème) est stockée dans la liste pokemon_who_fought afin de pouvoir s'occuper de la répartition équitable de l'XP entre chaque, sauf que justement ça posait problème (dans la boucle battle_experience_distribution_loop) : je crois qu'il fallait uniquement mettre à jour la barre d'XP du dernier pokémon ayant combattu (donc qui est à l'écran) et que justement ça posait problème... Après un premier tour de la boucle les données doivent être corrompues (hl ne pointe plus vers pokemon_who_fought et/ou b ne contient plus le nombre de pokémon ayant combattus, ou alors c'est que quelque chose cloche dans la boucle elle même) :/

D'ailleurs je m'étais mis un commentaire pour savoir où j'en étais (avec un ld b,25\ call wait pour me permettre d'avoir le temps d'accéder au debugger).
chickendude (./59) :
Tu pourrais peut-être sauver quelques octets si tu mettais le string "MONOCHROME" dans le sprite qui dit "Pokémon".

Pas sûr, parce qu'il faudrait augmenter légèrement la taille du sprite pour que ça rentre tongue

Mais de toute façons je trouve l'écran titre assez moche (vide ?), donc j'y retoucherai peut être.
chickendude (./59) :
J'ai commencé à coder une routine de menu plus compacte, mais je ne sais pas comment tu veux gérer la sélection d'une des options, je pensais que l'on pourrait faire quelque chose comme :

C'est vrai que c'est un peu plus optimisé que ce que je fait déjà smile

Par contre il faudrait que la routine gère les déplacements gauche/droite du curseur (ce que fait la routine actuelle, mais avec un "hack" assez moche : je suis obligé de récupérer les coordonnées du curseur (par rapport à l'écran) pour pouvoir deviner à quelle ligne/colonne il est. Une solution plus simple et plus propre serait sans doute d'avoir deux variables (cursor_row/col) en SMC, parce que ça me simplifierait pas mal la vie (par exemple, lorsque je doit stocker ces coordonnées pour pouvoir me servir à nouveau de la routine du menu, dans le cas des sous-menu, et après pouvoir revenir au menu initial avec le curseur au bon endroit).

Il faudrait aussi que comme avec l'actuelle, les routines appelées lorsqu'on bouge le curseur soit spécifiables en paramètres : menu_valid_addr, menu_cancel_addr, menu_down_addr, menu_up_addr, menu_left_addr, menu_right_addr, menu_oncursor_addr.

Autrement, je trouve ma routine de texte _vputs_ml assez moche, j'hésite à la recoder...

Enfin merci, ça va me motiver à m'y remettre smile
deeph (./60) :
Par contre il faudrait que la routine gère les déplacements gauche/droite du curseur ...
Facile ! smile
DG8m
Il faut justement ajouter les touches [Up]/[Down]. Voici le code qui affiche ça :menu: call fade_out bcall(_grbufclr) ld bc,$240c ;c = largeur, b = hauteur xor a ;a = x ld l,a ;l = y ld ix,title ;sprite de titre call ionLargeSprite ld hl,$201d ld (pencol),hl ld hl,monochrome_str bcall(_vputs) ;afficher "MONOCHROME" sous le sprite de titre xor a ;option choisie par défaut ld de,$2b06 ;e = pencol, d = penrow ld hl,menu_battle ; call drawMenu ;afficher le menu call fade_in call menuKey ;attendre une réponse ret menu_battle: .db 4 .db "Attaquer",$FF,$36,"Pok",$96,"mon",0 .db "Inventaire",$FF,$36,"Fuite",0$FF signifie que tu veux changer la coordonnée X, ici on la change à $36. 0 = Fin de ligne.

EDIT : Annnd... :
FTxg
Génial ! tongue

Mais comment sont gérés les mouvements ? Parce qu'enfaite ce serait plus "souple" de pouvoir spécifier les évènements qu'on veut appeler lorsqu'on appui sur une touche : les touches directionnelles ne doivent pas toujours bouger le curseur (comme dans le menu des pokémon pour voir les attaques 3 et 4), et lorsque le curseur a été bougé, il n'a pas toujours à appeler une routine (avec menu_oncursor_addr dans la routine actuelle).

Ah et, y'a-t-il moyen de récupérer la ligne/colonne du curseur ? Certains menus n'ont pas une adresse à laquelle on saute après avoir sélectionné telle ou telle option, mais une adresse commune menu_valid_addr qui pointe vers une routine dans laquelle on veut juste savoir quelle option a été choisie (pour les attaques par exemple), donc finalement faire comme en ./59 serait problématique...

De mon côté je me prend la tête à essayer de comprendre pourquoi lorsqu'on change de pokémon, qu'on termine le combat avec et qu'il reçoit son XP, sa barre d'XP ne bouge pas... Je vais voir ça cette après-midi :/
Je ne sais pas si j'ai compris, si tu veux tu peux voir le code :
menu
menu: call fade_out bcall(_grbufclr) ld bc,$240c ;c = largeur, b = hauteur xor a ;a = x ld l,a ;l = y ld ix,title ;sprite de titre call ionLargeSprite ld hl,$201d ld (pencol),hl ld hl,monochrome_str bcall(_vputs) ;afficher "MONOCHROME" sous le sprite de titre xor a ;option choisie par défaut ld de,$2B1D ;e = pencol, d = penrow ld hl,menu_sample ; call drawMenu ;afficher le menu call fade_in call menuKey ;attendre une réponse exit: ret newGame: call fade_out bcall(_grbufclr) call ionFastCopy call fade_in ld hl,genderTxt call drawDialogue call ionFastCopy bcall(_GetKey) ld de,$0108 push de ld bc,$1c12 ld hl,player_man_right call gbaDrawMaskSprite pop de ld bc,$3e12 ld hl,player_woman_left call gbaDrawMaskSprite xor a ld (menu_cursor),a call draw_new_game_cursor ret ;une boîte de dialogue drawDialogue: ld bc,$1560 ld de,$002b push hl call draw_frame pop hl ld de,$2C02 ld b,1 ld a,COORD_SKIP ld (textWait),a ;nous voulons une valeur non-zéro jr drawMenu_start ;menu, avec options drawMenu: ld (menu_cursor),a ld a,(hl) inc hl ld (optionList),hl ld ix,menuCoordinates+1 ld (ix-1),a ;combien d'options il y a add a,a ld c,a ld b,0 add hl,bc rra ld b,a xor a drawMenu_start: ld (coordSMC),a ld (penCol),de ld a,e ld (defaultCol),a ld a,d ;a = penRow drawMenuLoop: coordSMC = $+1 jr $ ;ne sauver pas les coordonnées ld a,e sub 4 ld (ix),a ;coord X ld (ix+1),d ;coord Y inc ix inc ix COORD_SKIP = $-coordSMC-1 ld a,(hl) push ix drawTextLoop: push de bcall(_vPutMap) pop de ld a,(textWait) ;= 0 si pas de delai, != 0 s'il y en a or a call nz,textDelay inc hl ld a,(hl) or a jr z,endOfLine cp $FE call z,newLine cp $FF jr nz,drawTextLoop endOfLine: pop ix inc a jr nz,addNewLine inc hl ld e,(hl) ld (penCol),de inc hl djnz drawMenuLoop addNewLine: call newLine djnz drawMenuLoop ld hl,textWait ld (hl),0 ret textDelay: exx xor a call getKey inc a jr z,$+6 xor a ld (textWait),a ld b,6 ;charger ici une valeur selon la vitesse du texte push bc call ionFastCopy pop bc djnz $-5 exx ret newLine: ld a,d add a,6 ;penRow+6 ld d,a defaultCol = $+1 ld e,0 ld (penCol),de inc hl ld a,(hl) ret menuSelect: ld a,(menu_cursor) add a,a ld c,a ld b,0 optionList = $+1 ld hl,$0000 add hl,bc ld a,(hl) inc hl ld h,(hl) ld l,a jp (hl) menuKey: call drawCursor menuKeyLoop: ei halt halt di ;verif 2nd/clear ld a,$BF ;groupe 7 (Y= -> Graph, 2nd, Mode, Del) call getKey cp 223 ;2nd jr z,menuSelect ;verif fleches ;************************* ld hl,menuKeyLoop ;* push hl ;* où sauter ;************************* ld a,$FE ;les fleches call getKey or $F0 ;effacer bits 4-7 ld b,a inc b ;si b+1 = 0, b = $FF alors on n'a pas touché une fleche ld hl,cursorWait ;le compteur/delai jr nz,$+4 ;sauter si une touche a été poussée ld (hl),b ;remettre le compteur à zéro ret dec (hl) ;compteur-1 ret p ;quitter si positif (>=0) ld (hl),cursor_speed push af call drawCursor ;effacer le cursor pop af ;************************* ld hl,drawCursor ;* push hl ;* où sauter ;************************* ld hl,menu_cursor rra jr nc,cursorDown rra jr nc,cursorLeft rra jr nc,cursorRight cursorUp: ld a,(hl) or a ret z ld b,a ;menu_cursor actuel call getCursorCoords ;ne modifie pas la valeur de DE ld a,(hl) ;coordonnée X findNextUp: dec b dec hl dec hl cp (hl) jr z,foundUp jr findNextUp ret foundUp: ld a,b ld (menu_cursor),a ret cursorDown: ld a,(menuCoordinates) ;# de coordinées dec a cp (hl) ret z ld c,(hl) ;menu_cursor actuel sub c ;nombre d'options - cursor actuel ret z ld b,a ;nombre de coordonnées à chercher call getCursorCoords ;ne modifie pas la valeur de DE ld a,(hl) ;coordonnée X findNextDown inc c inc hl inc hl cp (hl) jr z,foundDown djnz findNextDown ret foundDown: ld a,c ld (menu_cursor),a ret cursorLeft: ld a,(hl) or a ret z dec (hl) ret cursorRight: ld a,(menuCoordinates) ;# de coordinées dec a cp (hl) ret z inc (hl) ret drawCursor: ;afficher le cursor call getCursorCoords ld a,(hl) ;x inc hl ld l,(hl) ;y ld ix,cursorSprite ld b,5 call ionPutSprite call ionFastCopy ret getCursorCoords: ld a,(menu_cursor) add a,a ld e,a ld d,0 ld hl,menuCoordinates+1 add hl,de ret getKey: out (1),a push af pop af ;un petit delai in a,(1) ret cursorSprite: .db %10000000 .db %11000000 .db %11100000 .db %11000000 .db %10000000 cursorWait: .db 0 textWait: .db 0 menuCoordinates: .db 0 ;nombre de choix .dw $0000 .dw $0000 .dw $0000 .dw $0000 .dw $0000 .dw $0000 .dw $0000 menu_sample: .db 3 ;nombre de choix .dw new_game .dw newGame .dw exit .db "Continuer",0 .db "Nouveau jeu",0 .db "Quitter",0 menu_battle: .db 4 .db "Attaquer",$FF,$36,"Pok",$96,"mon",0 .db "Inventaire",$FF,$36,"Fuite",0 genderTxt: .db $94,"tes vous un gar",$b3,"on ou une",$FE .db "fille ?",0

Je suis en train de finir les boîtes de dialogues, tu peux voir que le code pour afficher un menu/boîte de dialogue est plus simple smile (il ne faut que "ld hl,dialogueTxt \ call drawDialogue").

EDIT : Et voici ce que fait ce code là :
jOG1
Enfaite il faudrait plus quelque chose du genre :
ld hl,menu_valid ld (menu_valid_addr),hl ld hl,menu_down ld (menu_down_addr),hl ld hl,menu_up ld (menu_up_addr),hl ld hl,menu_nothing ld (menu_cancel_addr),hl ld (menu_oncursor_call_addr),hl ld (menu_left_addr),hl ld (menu_right_addr),hl ld hl,menu_sample call drawMenu call fade_in jr menuKey menu_valid: ld a,(menu_cursor_row) or a jr z,menuKey ; pas de 'continuer' pour le moment cp 1 ret nz ; quitter ; nouveau jeu
Mais pourquoi ? Je crois que comme ça on perd pas mal d'espace. Tout ça prend plus de 40 octets ! Je vais convertir tes dialogues/menus pour voir la différence.
Je ne sais pas, j'ai l'impression que ça va être beaucoup plus compliqué pour certains menus (notamment ceux des attaques et celui des pokémons dans le sac, bref tout ceux qui sont un peu "dynamique" : il faudrait au moins pouvoir récupérer l'ID de l'option choisie)...

Autrement il faut obligatoirement un appel vers la routine menu_pokemon_disp_attack dans le menu menu_disp_pokemon à chaque mouvement du curseur, je ne sais pas si tu peux ajouter ça.

Ah et j'ai fait un commit sur le repo parce que j'ai changé quelques trucs minimes en rapport au bug de l'XP, mais je n'ai toujours pas réussis à le résoudre...

edit : ça y est je l'ai réglé smile

Par contre, quand plusieurs pokémon ont combattus, le combat continue alors que le pokémon adverse est mort. Il doit y avoir encore quelque chose sur la pile arrivé à la ligne 717 de battle.inc... :/
Ok, j'ai optimisé quelques choses dans new.inc (qui d'ailleurs utilise la nouvelle routine de menu), maintenant je vais essayer de convertir le menu start, mais je crois qu'il n'y aura pas de problème smile

EDIT: Oui, ça marche sans problèmes.
Ok, j'attends de voir, d'ailleurs je pense que pour les attaques ont peut faire un truc du genre :
menu_attack4: inc a menu_attack3: inc a menu_attack2: inc a menu_attack1: inc a ; a=selected attack # ; gérer les attaques
Par contre il faudrait que a=0 en sortant du menu.
Quelle touche veux-tu utiliser pour annuler ? [Alpha] ou [Clear] ?

Maintenant on peux annuler un menu avec [Alpha], tu peux gérer l'annulation comme tu voudras :menu_start: call gbaRestoreMap ld hl,(player_direction) ld bc,(player_y) ld de,$0108 call gbaClipSprite call gbaDrawMaskSprite ld bc,$2d25 ld de,$3b00 call draw_frame xor a ;option par défaut ld de,$0141 ;les coordonnées ld hl,menu_start_str call drawMenu call menuKey ;si on retourne ici, on a annulé le menu jp draw_mapJ'ai pas encore vu les routines d'attaques, mais j'ai quelques idées wink
Alpha, pour ne pas avoir quelque chose de trop différent d'A/B sur game boy smile
Je crois que nous pourrions ajouter quelques tokens à la routine de texte pour "ouvrir" un pokémon puis afficher ses stats : son nom, son niveau, ses PV, etc. Qu'en penses-tu ?

Et l'ID d'un pokémon c'est son id dans le pokédex ?

EDIT : Est-ce que tu as une liste des types de pokémons ? Il serait plus facile si tu faisais des equates, par exemple TYPE_BUG = 7
chickendude (./71) :
Je crois que nous pourrions ajouter quelques tokens à la routine de texte pour "ouvrir" un pokémon puis afficher ses stats : son nom, son niveau, ses PV, etc. Qu'en penses-tu ?

Comment ça ?
chickendude (./71) :
Et l'ID d'un pokémon c'est son id dans le pokédex ?

Ça dépend de quel ID on parle (oui je sais c'est assez confus tongue) : l'ID contenu dans la table pokemon_stats est bien l'ID du pokédex (bien que celui-ci n'est pas encore été décidé), autrement c'est l'ID du pokémon par rapport à cette table (les ID de la table player_pokemons sont les numéro des entrées de la table pokemon_stats en gros, sauf que là ça ne commence pas à 0 mais à 1).
chickendude (./71) :
Est-ce que tu as une liste des types de pokémons ? Il serait plus facile si tu faisais des equates, par exemple TYPE_BUG = 7

Elle est dans types.inc, mais oui pourquoi pas, on peut les définir comme ça.
chickendude (./69) :
Maintenant on peux annuler un menu avec [Alpha], tu peux gérer l'annulation comme tu voudras :

Mmh c'est assez différent de ce que je fait déjà : faire un appel à menuKey ne pose pas de problème pour sauter à un autre label ? Actuellement je fais un saut plutôt...
Ah parfait, j'avais pas vu types.inc. Et je crois qu'il serait plus facile de travailler avec le data comme ci :
code
TYPE_NORMAL = 1 TYPE_COMBAT = 2 TYPE_VOL = 3 TYPE_POISON = 4 TYPE_SOL = 5 TYPE_ROCHE = 6 TYPE_INSECTE = 7 TYPE_SPECTRE = 8 TYPE_PLANTE = 9 TYPE_FEU = 10 TYPE_EAU = 11 TYPE_ÉLECTRIQUE = 12 TYPE_PSY = 13 TYPE_GLACE = 14 TYPE_DRAGON = 15 ;listes d'attaques TACKLE = 0 GROWL = 1 LEECH_SEED = 2 VINE_WHIP = 3 POISONPOWDER= 4 RAZOR_LEAF = 5 GROWTH = 6 SLEEPPOWDER = 7 SOLAR_BEAM = 8 bulbasaur: .dw bulbasaur_txt .db 45 ;HP .db 49 ;Att .db 49 ;Def ;Sp. Atk ;Sp. Def ;Speed .db 64 ;Base EXP .db TYPE_PLANTE ;Type 1 .db TYPE_POISON ;Type 2 .db 2 ;EXP curve .dw bulbasaur_attacks .db 16 ;niveau d'évolution ivysaur: .dw ivysaur_txt .db 60 ;HP .db 62 ;Att .db 63 ;Def ;Sp. Atk ;Sp. Def ;Speed .db 141 ;Base EXP .db TYPE_PLANTE .db TYPE_POISON .db 2 ;EXP curve .dw ivysaur_attacks .db 32 ;niveau d'évolution venusaur: .dw bulbasaur_txt .db 80 ;HP .db 82 ;Att .db 83 ;Def ;Sp. Atk ;Sp. Def ;Speed .db 208 ;Base EXP .db TYPE_PLANTE .db TYPE_POISON .db 2 ;EXP curve .dw venusaur_attacks .db 0 ;pas d'évolution ;noms des pokémons bulbasaur_txt: .db "Bulbasaur",0 ivysaur_txt: .db "Ivysaur",0 venusaur_txt: .db "Venusaur",0 ;attaques des pokémons ;level, id de l'attaque bulbasaur_attacks: .db 11 ;nombre d'attaques .db 1, TACKLE .db 1, GROWL .db 7, LEECH_SEED .db 13, VINE_WHIP .db 20, POISONPOWDER .db 27, RAZOR_LEAF .db 34, GROWTH .db 41, SLEEPPOWDER .db 48, SOLAR_BEAM ivysaur_attacks: .db 11 ;nombre d'attaques .db 1, TACKLE .db 1, GROWL .db 1, LEECH_SEED .db 7, LEECH_SEED .db 13, VINE_WHIP .db 22, POISONPOWDER .db 30, RAZOR_LEAF .db 38, GROWTH .db 46, SLEEPPOWDER .db 54, SOLAR_BEAM venusaur_attacks: .db 11 ;nombre d'attaques .db 1, VINE_WHIP .db 1, TACKLE .db 1, GROWL .db 1, LEECH_SEED .db 7, LEECH_SEED .db 13, VINE_WHIP .db 22, POISONPOWDER .db 30, RAZOR_LEAF .db 43, GROWTH .db 55, SLEEPPOWDER .db 65, SOLAR_BEAM
Je vais essayer d'appliquer mon idée ce soir à la routine de texte pour que tu puisses voir un peu mieux de quoi je parle...

Quant à menuKey, pas du tout, si on quitte on retourne à l'instruction prochaine, sinon, on pop l'adresse de la pile et continue comme normale smile
chickendude (./73) :
Et je crois qu'il serait plus facile de travailler avec le data comme ci :

Je veux bien mais ça va changer beaucoup de choses...

Tu penses pouvoir appliquer ta routine de menu à tout ceux existant ?

Il vaut mieux que j'attende que tu ais modifié les menus avant de commencer à modifier leur contenu et l'accès aux données des pokémons je pense, non ?
Oui, en plus je crois qu'elle sera même plus facile d'utiliser. Je veux essayer de simplifier l'accès aux données (et leur affichage). J'essayerai d'appliquer tous les changements nécessaires, mais ici il est déjà tard... Il faudra peut-être attendre un peu jusqu'à pouvoir faire tous les changements.

EDIT : pokemon_stats semble ne pas avoir les autres stats (attaque, défense, etc.)
Ok prend ton temps, je vais pas te presser non plus, c'est déjà super sympa de m'aider tongue

Et puis de mon côté j'ai d'autres choses à faire d'ici là (comme la formule pour calculer le nouvel XPmax après un lvl up) smile

Le nouveau types.inc :
types.inc
#define type_normal 1 #define type_fighting 2 #define type_flying 3 #define type_poison 4 #define type_ground 5 #define type_rock 6 #define type_bug 7 #define type_ghost 8 #define type_grass 9 #define type_fire 10 #define type_water 11 #define type_electric 12 #define type_psychic 13 #define type_ice 14 #define type_dragon 15 type_index: .dw normal,fighting,flying,poison,ground,rock,bug,ghost,grass,fire,water,electric,psychic,ice,dragon normal: .db 0 ; types contre lesquels c'est super efficace (multiplie par deux l'attaque) .db 1,type_rock ; types résistants contre lesquel ça n'est pas très efficace (divise par deux l'attaque) .db 1,type_ghost ; types contre lesquels l'attaque n'a aucun effet .db "Normal",0 fighting: .db 3,type_normal,type_rock,type_ice .db 4,type_flying,type_poison,type_bug,type_psychic .db 1,type_ghost .db "Combat",0 flying: .db 3,type_fighting,type_rock,type_grass .db 2,type_rock,type_electric .db 0 .db "Vol",0 poison: .db 1,type_grass .db 4,type_poison,type_ground,type_rock,type_ghost .db 0 .db "Poison",0 ground: .db 4,type_poison,type_rock,type_fire,type_electric .db 3,type_ground,type_bug,type_grass .db 1,type_flying .db "Sol",0 rock: .db 4,type_flying,type_bug,type_fire,type_ice .db 2,type_fighting,type_ground .db 0 .db "Roche",0 bug: .db 2,type_grass,type_psychic .db 5,type_fighting,type_flying,type_poison,type_ghost,type_electric .db 0 .db "Insecte",0 ghost: .db 2,type_ghost,type_psychic .db 0 .db 1,type_normal .db "Spectre",0 grass: .db 3,type_ground,type_rock,type_water .db 6,type_flying,type_poison,type_bug,type_grass,type_electric,type_dragon .db 0 .db "Plante",0 fire: .db 3,type_bug,type_grass,type_ice .db 4,type_rock,type_fire,type_water,type_dragon .db 0 .db "Feu",0 water: .db 3,type_ground,type_rock,type_fire .db 3,type_grass,type_water,type_dragon .db 0 .db "Eau",0 electric: .db 2,type_flying,type_water .db 3,type_grass,type_electric,type_dragon .db 1,type_ground .db "Electrique",0 psychic: .db 2,type_fighting,type_poison .db 1,type_psychic .db 0 .db "Psy",0 ice: .db 4,type_flying,type_ground,type_grass,type_dragon .db 3,type_fire,type_water,type_ice .db 0 .db "Glace",0 dragon: .db 1,type_dragon .db 0 .db 0 .db "Dragon",0

chickendude (./75) :
pokemon_stats semble ne pas avoir les autres stats (attaque, défense, etc.)

Oui enfaite il contient les données des pokémons du dresseur, donc le strict nécessaire (comme dans cette version les pokémons ne peuvent pas être personnalisables, leur ATT/DEF sont calculés "à la volée" en fonction de stats de base. Enfin je crois, je ne me rappel plus trop ce que j'ai fait :/).

En gros ce sont les données du PC+des 6 pokémons du sac, donc c'est vrai qu'il faudrait y trouver un meilleur nom (player_pokemons_datas ou quelque chose du genre ?).
Je crois que le nom player_pokemons est bon, et s'il n'y a pas d'EVs etc. pas besoin de sauver les stats. D'ailleurs, je crois qu'il vaudra mieux mettre tout ça dans saferam smile
chickendude (./77) :
D'ailleurs, je crois qu'il vaudra mieux mettre tout ça dans saferam

Je viens de vérifier et enfaite je calcule bien les stats en fonction de niveaux uniquement lorsque nécessaire (dans les formules de combat, dans maths.inc), donc pas besoin de les stocker où que ce soit.

Changer la mise en forme des données risque d'entrainer pas mal de modifications un peu partout, mais c'est vrai que si on s'y retrouve un peu mieux ensuite ça ne peut être que bénéfique ! smile

De mon côté je vais bosser sur le calcul des courbes de niveaux grâce à cette page : http://bulbapedia.bulbagarden.net/wiki/Experience .

edit : bon enfaite j'ai codé ces fonctions, sauf qu'elles donnent l'XP du prochain niveau depuis le niveau 0 (ce qui fait que ces fonction peuvent renvoyer des valeurs bien au delà de ce que peuvent contenir 16bits...), or je reset l'XP à chaque niveau (de toute façons je n'ai aucun moyen facile de stocker 1 600 000 points d'XP cheeky).

Bref il faut que je trouve un autre moyen de récupérer l'XP nécessaire entre deux niveau, sans avoir à utiliser ces fonctions (je me tape que des overflow autrement), si quelqu'un à une idée...?
L'addition 24-bit n'est pas trop difficile wink Un extra "adc a,0" pour ajouter AHL+DE (add hl,de \ adc a,0). J'ai fini la première partie de la nouvelle routine de menu : xor a ld de,$0605 ld hl,menu_noAction call drawMenuReturn call menuKeyReturn ;pas d'actions, retourner ici ret menu_noAction: .db 3 ;nombre de choix .db _PKMN,3,_NAME,5,0 .db _PKMN,2,_NAME,5,0 .db _PKMN,1,_NAME,5,0_PKMN charge les datas d'un pokémon de ton équipe, _NAME,## affiche le nom du pokémon à la coordonnée X "##" (ici, 5).
9h2z
Comme ci il sera plus facile d'arranger/créer les menus, tu n'as que changer le # du pokémon, tiré de player_pokemons, et la routine de texte fera tout le reste. smile

Maintenant je me couche !
Ahh ok c'est ça tongue

Génial, sauf que le nombre de pokémons n'est jamais le même (on peut avoir de 1 à 6 pokémons dans le sac), donc je me demande si on va s'en servir de cette façons ? À moins qu'on puisse mettre l'ID=0 (pas le premier pokémon, donc aucun), et que le déplacement maximal du curseur en prenne compte (ne pas descendre au choix 3 si l'ID du troisième pokémon de la liste est égale à 0).

Merci ! Et bonne nuit smile
On pourra faire quelque chose comme ci :
ld hl,player_pokemons
ld de,menu_buffer
ld a,(hl)
loop:
push hl
ld hl,menu+1
ld (hl),a
dec hl
ld bc,9
ldir
pop hl
ld a,(hl)
or a
jr nz,loop
ret

menu:
.db _PKMN,3,_NAME,5,_HP,30,_HP_TOT,40,0

et... bonne nuit smile
Je ne sais pas, c'est comme tu veux, mais au final je pense que ces tokens seront surtout utiles avec les messages durant les combats.

Enfin je me demande comment tu as codé ça tongue
chickendude (./79) :
L'addition 24-bit n'est pas trop difficile wink Un extra "adc a,0" pour ajouter AHL+DE (add hl,de \ adc a,0).


Oui mais j'utilise beaucoup les op et leurs bcall, sauf qu'on est cantonné au 16bits (et faire les calculs "à la main", je n'imagine même pas comment on va galérer/perde de la place, rien que pour calculer les puissances par exemple...).

Mais de toute façons il doit y avoir moyen de calculer ça plus simplement, je vais chercher smile

edit : bon finalement les écarts d'XP entre chaque niveaux sont trop élevés... Par exemple pour atteindre le niveau 50 (avec la courbe d'XP moyennement rapide) : 50^3-49^3=7351 :/

À mon avis il faut que les combats rapportent moins d'XP, donc il va falloir que je modifie la formule actuelle, et que j'en définisse de nouvelles pour les courbes d'expériences...

Les programmeurs de la version originale ont dû s'amuser avec la game boy et ses mêmes restrictions cheeky

edit 2 : ce genre de formule serait plus adaptée :

V6bE

Avec ça, du niveau 1 au 2 il faut 5xp, et du 99 au 100, 255.

Donc maintenant il me faudrait 3 autres formules avec différentes allures, comme ici (avec toujours, pas plus de 255 points d'xp pour atteindre le niveau 100) :

ExpGraphLv100.png

edit 3 : une autre formule un peu plus rapide :

mcZx

N'hésitez pas à proposer mieux ! (parce que moi et les maths... tongue)

edit 4 : une troisième :

XLkV

Ce serait bien d'en avoir une quatrième un peu plus lente que ces trois là, mais ça commence un peu à me prendre la tête sick
deeph (./82) :
Je ne sais pas, c'est comme tu veux, mais au final je pense que ces tokens seront surtout utiles avec les messages durant les combats.
Oui, c'est ça l'idée smile Aussi faire le pokédex/les boîtes de tes pokémons sera extrêmement facile. Pour le coder j'ai changé un peu la structure des datas, j'utilise ceux que j'ai posté dessus wink

255 EXP pour avancer au niveau 100 ? Ça me semble très peu... Je crois que les routines de TI peuvent facilement gérer 1,600,000: http://t.eeems.ca/ASMin28Days/lesson/day18.html Sinon, c'est seulement l'EXP qui le nécessite, non ? Quand je terminerai les routines de menu je peux t'aider un peu avec ça si tu veux, mais je ne sais pas si j'aurai temps aujourd'hui/les prochains jours. En tout cas, il faut pas que les routines soient trop rapide.
chickendude (./83) :
Oui, c'est ça l'idée Aussi faire le pokédex/les boîtes de tes pokémons sera extrêmement facile. Pour le coder j'ai changé un peu la structure des datas, j'utilise ceux que j'ai posté dessus

Ok, je vais attendre d'avoir tes routines parce qu'autrement ça ne sert à rien que je mette en forme mes données pour l'instant.
chickendude (./83) :
255 EXP pour avancer au niveau 100 ? Ça me semble très peu... Je crois que les routines de TI peuvent facilement gérer 1,600,000: http://t.eeems.ca/ASMin28Days/lesson/day18.html Sinon, c'est seulement l'EXP qui le nécessite, non ?

Ça semble peu mais je compte bien faire en sorte que les combats rapportent moins d'XP... Les OP peuvent sûrement gérer de très grands nombres, mais j'ai besoin actuellement de les récupérer dans des registres pour tout un tas de calculs.

Enfin en y réfléchissant, tout ce qu'il faudrait c'est stocker quelque part les 11 octets d'un OP contenant la valeur de l'XP actuelle, et d'un autre contenant celle de l'XPmax, sauf que s'il faut le faire pour chaque pokémon ça risque de prendre énormément de place...
chickendude (./83) :
Quand je terminerai les routines de menu je peux t'aider un peu avec ça si tu veux, mais je ne sais pas si j'aurai temps aujourd'hui/les prochains jours. En tout cas, il faut pas que les routines soient trop rapide.

Oui mais prend ton temps, il y a des périodes où je n'y ai pas retouché pendant 1 mois (voire plus), alors je ne suis pas pressé tongue

Mais merci !

edit : ou alors je stocke l'xp sur deux octets, et donc pour passer au niveau 100 il faudra 65536 points. Ça laisse plus de marge déjà.

SUIH

Il va juste falloir que je revoie un tout petit peu à la baisse la formule du gain d'xp.

D'ailleurs au final ce n'est même plus la peine de stocker l'XPmax... Du coup ça prendra autant de place qu'actuellement smile
Je crois qu'un numéro 16-bit pour l'xp serait meilleur, 24-bit serait ok aussi, mais peut-être pas nécessaire. Tu pourrais les stocker comme des numéros 24-bit puis les convertir dans le formate FP des OPs. Mais 65k est beaucoup plus flexible que 255 wink Quand je jeu ce petit jeu, j'ai la même sensation que j'avais quand j'avais 10 ans et je jouais au Pokémon Blue pour la première fois grin
Oui, ok pour le 16-bit (24-bit serait mieux, mais pour faire les conversions/comparaisons ça risque d'être plus compliqué... donc on s'en passera) smile

Il faut que je trouve 3 autres formules, celle du ./84 étant la plus lente possible.
chickendude (./85) :
Quand je jeu ce petit jeu, j'ai la même sensation que j'avais quand j'avais 10 ans et je jouais au Pokémon Blue pour la première fois

Tant mieux c'est le but grin

Je me rappel la première fois que j'ai joué à Pokémon bleu, je ne trouvais même pas la sortie de la maison (jusqu'à ce que je comprenne ce qu'était le tapis cheeky).

edit : bon je pense utiliser ces formules :

ys3j

Qu'est-ce que tu en penses ? Ce n'est pas aussi élaboré que celles de la version originale, mais ça fera l'affaire tongue
C'est parfait smile

Moi j'ai passé presque une heure avant d'aller dans l'herbe et recevoir mon premier pokémon grin
Ok je code ça alors, par contre il va falloir modifier pas mal de trucs étant donné que je ne veux plus avoir à stocker l'XPmax dans les stats des pokémons.
chickendude (./87) :
Moi j'ai passé presque une heure avant d'aller dans l'herbe et recevoir mon premier pokémon

Pourtant la première ville n'est pas énormément grande grin
menu_noAction: .db 3 ;nombre de choix .db _PKMN,3,_NAME,5,_LVL,67,_HP,79,0 .db _PKMN,2,_NAME,5,_LVL,67,_HP,79,0 .db _PKMN,1,_NAME,5,_LVL,67,_HP,79,0

EfI4

Maintenant il faut ajouter tous les stats, même ceux qui ne sont pas partie de pokemon_stats (atk, def, PV max, etc.) et convertir les attaques en strings en lieu de numéros.
Super smile

J'ai terminé de coder les nouvelles formules, sauf qu'avec la rom call _convop1 j'ai un "ERR:DIM"... D'après le wikiti :
This routine is used to convert a floating-point number OP1 to a hex value in DE, but if the number in OP1 is greater than 9999, an error will occur.

Encore heureux que j'apprends ça ici, vu que le SDK n'en dit rien roll

Donc il faut que je trouve un autre moyen de copier le contenu entier d'un OP dans un registre 16-bit... Je vais voir s'il y a d'autres rom calls, parce que j'ai un peu du mal à comprendre comment sont organisés les OP en mémoire :/

edit : enfaite c'est parfaitement expliqué ici : http://z80-heaven.wikidot.com/floating-point-stuff , donc je peux faire :
; mes calculs bcall(_int) ld a,(op1+2) ld d,a ld a,(op1+3) ld e,a
Sauf que ça me donne le résultat en décimal... Y'a-t-il une façons rapide de le convertir en héxa ?

edit 2 : De toute façons ça buggera aussi au delà de 9999 cheeky

Pourquoi stocker ça sous forme décimale aussi ? :/

Mais il doit y avoir des rom calls, je vais chercher.

edit 3 : Bon je ne trouve rien, et faire une conversion décimal->hexadécimal à la main avec des divisions euclidiennes risque d'être très prise de tête...

Je pense que je vais faire les calculs avec des routines plutôt que les rom calls, quitte à perdre un peu de place.

edit 4 : Les nouvelles formules sont codées (et dispo sur le repo), à priori ça marche, mais je ne sais pas pourquoi l'animation avec la barre d'XP est super lente... confus

En plus ça a l'air de rebugger avec les changements de pokémons en cours de combats sick

Bref je verrais ça en semaine si j'ai 5min :/