Wow ! Peut-on perdre ? C'est-à-dire, qu'est-ce qui se passe si ton pokémon s'évanouit ?

Quand tu ajouteras l'expérience et les niveaux on aura un vrai jeu, même si l'on ne peut pas attraper d'autres pokémon, il serait comme un RPG traditionnel grin

A propos, dans les routines de rectangle, tu peux enlever le "or a" après le "ex af,af'" et sauver encore un octet.

Mais une chose : il faut un petit saut ou quelque chose quand on baisse de ces rebords, je ne savais pas ce qu'ils étaient au début.

Si tu as besoin de quelque chose ou veux de l'aide, n'hésite pas à nous en demander !
Pour le moment ça quitte simplement le combat (enfin je croit grin), je coderai ça plus tard.
chickendude (./30) :
A propos, dans les routines de rectangle, tu peux enlever le "or a" après le "ex af,af'" et sauver encore un octet.

Ok smile
chickendude (./30) :
Mais une chose : il faut un petit saut ou quelque chose quand on baisse de ces rebords, je ne savais pas ce qu'ils étaient au début.

Oui j'ai repris ça du jeu original (mais sans l'animation, je l'ajouterai peut être ensuite).
chickendude (./30) :
Si tu as besoin de quelque chose ou veux de l'aide, n'hésite pas à nous en demander !

Je n'ai pas touché au code source depuis ce que j'ai posté en ./29, hormis la routine flash_screen qui est devenu :
flash_screen:
	push bc
	ld bc,$4060
	ld de,0
	call rectangle_filled_xor
	call ionFastCopy
	pop bc
	djnz flash_screen
	ret

Donc à la limite tu peux essayer d'optimiser ce qui te semble flagrant (par contre beaucoup de choses de battle.inc et ia.inc risquent de changer plus tard), mais franchement tes routines sont déjà bien sympa, merci smile
A propos, tu n'as pas besoin de mettre mon nom avec les routines. En outre, j'ai peur que quelqu'un qui veule les utiliser ne les utiliserait pas, en craignant qu'il faut d'abord demander ma permission ou quelque truc bizarre comme ça wink Mais enfin tu peux faire avec elles ce que te plaira !

Et oui, je voulais justement jouer avec l'IA, mais je suppose que je devrais attendre jusqu'à ce qu'elle sera un peux plus ... dans son état final grin Je vais peut-être regarder les routines de menu.

Ce jeu avance vraiment bien et il semble que tout est bien organisé. Je crois que tu pourras faire de vite progrès et j'ai hâte de le voir ! Je commence à retrouver mon interêt pour mes propres projets, alors merci à toi aussi ! (Il faut aussi que je me remette à niveau en français :P)
chickendude (./32) :
A propos, tu n'as pas besoin de mettre mon nom avec les routines. En outre, j'ai peur que quelqu'un qui veule les utiliser ne les utiliserait pas, en craignant qu'il faut d'abord demander ma permission ou quelque truc bizarre comme ça wink

Toutes les sources de mes programmes sont aussi en "copyleft" et je tiens à spécifier ce qui n'est pas de moi (pour plus de transparence et par respect du travail d'autrui). Donc ça m'embête de retirer ton pseudo tongue
chickendude (./32) :
Et oui, je voulais justement jouer avec l'IA, mais je suppose que je devrais attendre jusqu'à ce qu'elle sera un peux plus ... dans son état final grin

Oui c'est très basique pour l'instant (ça se contente de choisir une attaque parmi celles disponibles, enfin en réalité parmi les 4 possibles, et si celle sélectionnée n'existe pas on recommence le choix aléatoire... mais je modifierai ça plus tard pour dénombrer les attaques disponibles dès le début de la routine "battle_wild_pokemon_ai") grin
chickendude (./32) :
Ce jeu avance vraiment bien et il semble que tout est bien organisé. Je crois que tu pourras faire de vite progrès et j'ai hâte de le voir !

Oui j'essaie d'organiser toutes les données au mieux pour ne pas avoir à modifier le code plus tard si leur structure change (je travail beaucoup en calculant les longueurs des données avec la soustraction d'adresses de labels, même si certains routines utilisent simplement des "inc" pour passer de certaines données à d'autres (il serait plus propre d'ajouter les "longueurs", mais nettement moins optimisé)) smile

Ce qui est bien dans ce projet c'est qu'il n'y a pas de difficulté exceptionnelle, donc ça avance assez rapidement smile
chickendude (./32) :
Je commence à retrouver mon interêt pour mes propres projets, alors merci à toi aussi !

Tant mieux, j'ai tout aussi hâte de voir le résultat happy
chickendude (./32) :
(Il faut aussi que je me remette à niveau en français :P)

Ton français est tout à fait acceptable (bien plus que mon anglais sans doute) tongue
Au fait deeph tu n'utilises pas de gestionnaire de version? Ca aide bien en général ...

Pour l'instant non, avant j'avais mon site sur servhome mais ils ont des problèmes semble-t-il :/

Je ne sais pas, peut être lorsque j'aurai étoffé un peu le moteur du jeu/combat et que j'aurai besoin d'aide pour la création des cartes etc...
EMbY

J'ai mis à jour l'éditeur de carte : le pokémapper cool

Il faudra que je lui ajoute la gestion des évènements (transitions de cartes, dresseurs, pokémons sauvages...), mais ce sera dans longtemps tongue
UXaB wink
event_down_cliff:
	ld hl,(player_direction)
	ld de,player_down
	call cp_hl_de
	ret nz
	ld hl,player_y
	dec (hl)
	dec (hl)
	dec (hl)
	push hl
		call walk_down_no_collision
	pop hl
	inc (hl)
	push hl
		call walk_down_no_collision
	pop hl
	inc (hl)
	inc (hl)
	ret


EDIT : et j'ai trouvé quelques petites optimisations dans engine.inc et je l'ai commenté un peu : engine.inc (mais j'ai pas fini)
Cool smile

Mais je ne sais pas pourquoi ça bug sur VTI et WabbitEmu (d'ailleurs sur ton screen certains pixels s'allument au hasard, non ?), je vais regarder ça tongue

Autrement j'ai mis à jour ion.inc :
#ifdef	TI83
#define bcall(romcall)	call romcall\	di
#define bcallz(romcall)	call z,romcall\	di
#define bcallnz(romcall)	call nz,romcall\	di
#define bcallc(romcall)	call c,romcall\	di
#define bcallnc(romcall)	call nc,romcall\	di
#endif
#ifdef	TI83P
#define bcall(romcall)	rst 28h\	.dw romcall\	di
#define	bcallz(romcall)	jr nz,$+5	\	rst 28h	\	.dw romcall\	di
#define	bcallnz(romcall)	jr z,$+5	\	rst 28h	\	.dw romcall\	di
#define	bcallc(romcall)	jr nc,$+5	\	rst 28h	\	.dw romcall\	di
#define	bcallnc(romcall)	jr c,$+5	\	rst 28h	\	.dw romcall\	di
#endif

Parce que je veux être tranquille avec les interruptions quand je testerai le link mais aussi parce que certaines routines utilisent les registres "shadow" (dont la tienne pour le rectangle, mais je compte les utiliser aussi plus tard). Par contre ça m'a rajouté 90 octets tsss

Donc je me demande s'il ne vaudrait mieux pas que je liste les rom calls qui rallument effectivement les interruptions...

Autrement j'ai mis à jour engine.inc mais l'animation du personnage bug, du coup j'ai modifié quelques trucs :
draw_map:
	call gbaRestoreMap
player_direction = $+1
	ld hl,0				;contient l'adresse du sprite selon la direction du joueur
	ld a,(walk_anim)
	sla a				;a*8
	add a,a				;a*2
	ld d,b				;b est à 0 après gbaRestoreMap
	ld e,a
	add hl,de
	ld bc,(player_y)
	ld de,$0108
	call gbaClipSprite
	call gbaDrawMaskSprite
	jp ionFastCopy

inc_walk_count:
walk_count = $+1
	ld a,0
	inc a
	ld (walk_count),a
	cp walk_frequency
	ret nz
	xor a
	ld (walk_count),a
walk_anim = $+1
	ld a,0
	inc a
	cp 3
	ret z
	ld (walk_anim),a
	ret

Mais ça ne marche toujours plus (la multiplication par 16 devrait fonctionner pourtant sad).

Ah et sinon la routine "battle_menu_valid_second_line" doit être placée avant "battle_menu_run", sinon ça bug (j'avais oublié de la replacer).

edit : bon maintenant ça marche avec 4 'add a,a' à la place de 'sla a \ add a,a', et le saut des "falaises" aussi... Je vais faire l'animation gauche/droite aussi smile

edit2 : voilà :
event_down_cliff:
	ld hl,(player_direction)
	ld de,player_down
	ld bc,walk_down_no_collision
	ld (event_jump_cliff_direction),bc
	jr event_jump_cliff

event_right_cliff:
	ld hl,(player_direction)
	ld de,(player_right)	; l'adresse est relative au sexe du joueur
	ld bc,walk_right_no_collision
	ld (event_jump_cliff_direction),bc
	jr event_jump_cliff

event_left_cliff:
	ld hl,(player_direction)
	ld de,(player_left)		; idem
	ld bc,walk_left_no_collision
	ld (event_jump_cliff_direction),bc

event_jump_cliff:
	call cp_hl_de
	ret nz
	ld hl,player_y
	dec (hl)
	dec (hl)
	dec (hl)
	push hl
event_jump_cliff_direction = $+1
	ld hl,0
	call jp_hl
	pop hl
	inc (hl)
	push hl
	ld hl,(event_jump_cliff_direction)
	call jp_hl
	pop hl
	inc (hl)
	inc (hl)
	ret


edit3 : bon bah Contra tu m'a convaincu, j'ai créé un compte google code : http://code.google.com/p/pokemon-monochrome/

Ceux qui veulent contribuer au projet (en modifiant le code source), je peux vous ajouter comme membre (chickendude > c'est déjà fait normalement) smile
J'ai commencé à lister les rom calls ne modifiant pas l'état des interruptions :
_op1toop4
_op2toop1
_op4toop2
_setxxop1
_setxxop2
_setxxxxop2
_fpdiv
_fpmult
_fpadd
_int
_convop1
_dispop1a
_grbufclr
_ldhlind
_vputs
_vputmap
_lcdbusy

Bref, toutes celles que j'utilise tongue

Du coup j'ai gagné 92 octets en virant le 'di' à la fin de mes bcall, et en créant un 'bcalldi' que j'utiliserai si jamais je rencontre des rom call se terminant par un 'ei' smile
Alors ça avance?

J'ai vu un commit récent sur le repo grin
Ça avance doucement on va dire tongue

Je fais la partie la plus barbante quand j'ai 5min : continuer le moteur de combat...

Depuis le post ./39 il me semble que j'ai amélioré les interactions entre les types (les pokémons peuvent maintenant en avoir deux), terminé les calculs des points expérience (qui se répartissent entre tous les pokémons qui ont participé au combat, même si pour le moment on ne peut pas encore les "switcher"), les changements de niveaux et là j'attaque l'apprentissage des nouvelles attaques puis ensuite la gestion des évolutions. Ensuite j'entamerai la gestion des changements d'états.

C'est pas compliqué mais pas super intéressant non plus (je ne peux pas faire de grosses optimisations).

Un petit screen (sur lequel fantominus veut apprendre une attaque qu'il connait déjà, mais c'est pour le debug tongue)

XGrP
Ca n'a pas l'air si pénible, faire des map pour un jeu et placer les ennemis dedans en étant obligé de tester le niveau à chaque fois, ça c'est pénible !

Mais là c'est du code, ça reste à mon avis plutôt agréable, non?

Joli travail en tout cas, je crois bien que tu es lancé poru finir ce jeu eeek
Je sais pas, ça perd un peu de son charme quand on sait pertinent comment faire le truc et qu'il reste plus qu'a l'écrire "tel quel", je préfère de loin me lancer dans un truc sans trop savoir ce que je fait mais en découvrant petit à petit pour ensuite pouvoir me dire "'tain je pensais pas y arriver, même finalement ça a de la gueule" cheeky

Créer les maps et la (petite) histoire, choisir les pokémons qui auront l'honneur de faire partit des rares élus de cette version etc... c'est aussi nettement moins rasoir (là le système de combat, en gros, c'est des maths et des tas de conditions), mais bon dans l'ensemble c'est un projet qui me plait, donc j'ai pas à me plaindre smile
Contra (./42) :
faire des map pour un jeu et placer les ennemis dedans en étant obligé de tester le niveau à chaque fois, ça c'est pénible !

Bof il y a les bêta-testeurs pour ça ! grin

Autrement oui, j'espère vraiment le finir, c'est d'ailleurs pour ça que je prend mon temps, même s'il y a encore des tas de problèmes à résoudre (dont le fait de se cantonner aux 20 et quelques ko de mémoire RAM ou tenter d'en faire une APPS, sachant que j'aimerai vraiment faire une version 83).
http://code.google.com/p/pokemon-monochrome/source/browse/#svn%2Ftrunk

Bon j'ai trouvé le courage de m'y remettre, et du coup j'ai réglé de nombreux bugs, optimisé pas mal de choses, et surtout j'ai enfin terminé le système d'apprentissage de nouvelles attaques smile

Demain si j'ai le temps je pense (commencer à) coder l'évolution des pokémons.

Finalement le moteur de combat est quasi-prêt, il ne me restera plus qu'a faire le "switch" des pokémons, la gestion des objets, le système de capture puis enfin la gestion des dresseurs et il sera terminé... Même si j'avoue que c'est intéressant à coder ça devient un peu pénible de s'y retrouver (battle.inc fait déjà 1439 lignes à lui tout seul sick).
Perso je divide mon code dans de nombreux fichiers, si j'utilise une routine d'un autre fichier j'ajoute un comment qui dit dans quel fichier elle se trouve. Moi non plus je n'aime pas chercher dans des fichiers énormes !
Le code source est déjà divisé en 20 fichiers différents, mais je pense encore diviser battle.inc, en mettant les routines "graphiques" d'un côté, et le code du menu de l'autre.

J'ai compté rapidement le nombre de lignes (sans compter gba lib 2) : ~4000 (dingue, je pensais pas autant) tongue
Le début du système d'évolution :

hUYY

Vous en pensez quoi ? L'animation est pas trop longue/rapide ?

Il me reste à ajouter la possibilité d'annuler l'évolution, puis à calculer les nouvelles stats du pokémon smile

Ah et j'en suis à 10393 octets, mais il y a encore pas mal de choses à optimiser (certaines parties du code se répètent, il faut que je le mette en commun).
Elle est pas mal l'animation
Je crois que c'est très bien smile Peut-être un peu court, je crois que dans l'original au final de l'animation le clignotement est plus rapide.
Dans l'original l'animation "pulse", il me semble. Mais j'ai la flemme de coder ça pour ce que ça apporte tongue

3 secondes c'est suffisant pour se décider à stopper l'évolution, non ?
Oui, d'ailleurs tu as le texte que l'annonce avant de commencer l'animation smile Il me semble que bientôt il ne te restera à faire que remplir les datas !

EDIT : Mais tu surement ne veux pas ce _GetKey après l'évolution ! Si tu veux une pause, écris ta propre routine grin

Ou utiliser celle-ci :
waitKey:
	di
	ld a,$FF			;effacer le port
	out (1),a
	xor a				;n'importe quelle touche
	out (1),a
;il faut relâcher les touches d'abord
	in a,(1)			; lire
	inc a				;si on n'a rien touché, a = $FF
	 jr nz,$-3			;$FF+1 = .. 0 !

	in a,(1)			;une autre lecture
	inc a
	 jr z,$-3
	 	dec a		;pour le "inc a"
		ld b,a		;sauver la touche poussée
		in a,(1)	;maintenant il faut relâcher la touche
		inc a		;sinon, il est probable que la prochaine routine l'utilise
		ld a,b		;a = la touche poussée
		 ret z		;
		jr $-5		;répéter jusqu'à ce que l'on a relâcher la touche
Ta routine peut être plus simple, cette routine attendra jusqu'à ce que tu aura relâché toutes les touches, puis lit la prochaine touche poussée et attende jusqu'à ce que tu l'aura relâchée.
Ok merci, je pense que je vais faire quelque chose comme ça dans la boucle qui gère l'animation smile
Tiens j'avais pas vu ce projet, ça a l'air vraiment génial. Et ça me donne envie de reprendre ma calculette pour coder grin
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741
Merci ! smile

Malheureusement ce forum passe un peu inaperçu aux yeux du reste des membres de yN, en partie à cause du fait qu'yn24 ne prend pas nos posts en compte, malgré le fait qu'on est loin d'être le dernier des forums en terme de nombre de posts/visites... :/

Oui je ne sais pas pourquoi, mais à chaque fois que je découvre d'autres projets de jeu sur TI ça me remotive aussi à continuer les miens... La nostalgie peut être tongue

Autrement j'ai terminé le système d'évolution, optimisé pas mal de trucs et là je pense entamer le "switch" de pokémon en cours de combat. Ensuite je ferais sans doute les objets.
Bump grin Tu as des nouvelles pour nous ?
J'ai pas beaucoup de temps à consacrer à la programmation en ce moment :/

Autrement je crois que je m'étais arrêté au début du système pour changer les pokémons en cours de combat.

Si j'ai le temps ce week-end (et si je suis motivé tongue), je m'y remettrai peut être smile
Donc il faudra que je te motive un peu ce week-end :P Tu veux de l'aide avec quelque chose ?
Pour l'instant j'en suis toujours à coder les combats, alors certaines parties du code vont encore énormément changer, donc je ne sais pas comment s'organiser si on veut coder à plusieurs...?

Mais bon, parmi les choses qui ne sont pas entamées et que quelqu'un d'autre pourrait éventuellement coder il y a le menu des stats des pokémons (par contre, je ne sais pas encore comment il sera organisé, peut être comme dans l'original... Je ferai un "mock up" si nécessaire), l'IA des dresseurs et quelques autres petits trucs. Autrement je suis toujours preneur d'optimisations (notamment dans les trucs que j'ai codé en premier, à savoir le menu, les routines de textes, voire celles de GBA Lib 2).

Le code source dispo sur http://code.google.com/p/pokemon-monochrome/ est relativement à jour, je crois que j'avais juste un peu avancé le switch de pokémon en combat.

edit : Ah oui et si je me rappel bien il y a un petit bug quand on annule une évolution : la sprite affiché après annulation est parfois celle du pokémon évolué cheeky

C'est pas grand chose, mais je le marque surtout pour m'en rappeler tongue

edit 2 : bon j'ai mis à jour le code sur le repo, donc j'en étais à tenter de régler un bug avec la répartition de l'xp entre chaque pokémon ayant combattu... Je verrai ça ce week-end mais je me rappel avoir déjà bien galérer avec ça... :/

edit 3 : pour le menu des stats, je pensai à un truc du style :

tK9w

L'original étant :

817x

Mais ça fait un peu vide, non ?
Oui, je crois que l'on peut faire comme l'originale, avec les stats à un côté et le(s) type(s) du pokémon. Je vais voir les routines de menu après le déjeuner smile Et quelle est la bogue avec l'XP ? Je peux y jeter un coup d'oeuil.

EDIT : Tu pourrais peut-être sauver quelques octets si tu mettais le string "MONOCHROME" dans le sprite qui dit "Pokémon". 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 :
	ld de,$2b1d			;e = pencol, d = penrow
	ld hl,menu_sample	;
	call drawMenu
;...
menu_sample:
	.db 3				;nombre de choix
	.dw continuer			;aller ici si on choisit la première option
	.dw nouvJeu			;option 2
	.dw quitter			;option 3
	.db "Continuer",0
	.db "Nouveau jeu",0
	.db "Quitter",0
Mais si tu préfères, on peut enlever la partie d'options et quand on choisit une option la routine mettra l'option choisie dans a.

EDIT2 : Ok, j'ai fini les menus normales (de haut à bas), je crois que les autres menus ne seront pas trop difficile non plus...
Ç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