150

Merci smile Je ne sais pas si je vais le compresser ou non, pour le moment je ne vais pas le faire. Si je les compresse, il faudra les extraire en RAM et je ne veux pas forcer le joueur à avoir beaucoup de RAM. On verra plus tard ! Pour le moment je mets à jour la routine de menu/texte.

EDIT: J'ai récrit la vputc routine et changé le formate de l'alphabet, maintenant il n'est pas compressé, mais il est plus facile d'utiliser.

151

Cool tu as mis à jour le repo, je vais pouvoir jeter un coup d’œil à ton code smile

edit : ah ouais mais du coup ton alphabet prend deux fois plus de places. Enfin pour une application ça n'est peut être pas si gênant.

Avant tu avais une routine de sprite 4*6, non ?

152

Avant j'utilisais des sprites 5*6, 4*6, 3*6 et 2*6 :P Donc un .bmp contenait ou deux sprites 4x6, ou un sprite 5x6 et un 3x6, ou quatre 2x6. De plus ça ne suivait pas l'ordre ASCII donc je ne pouvais pas utiliser des strings "blablabla", il fallait l'écrire: _b,_l,_a,_b,_l,_a,_b,_l,_a. Je me suis dit que je veux simplement pouvoir finir le jeu, que je veux écrire le jeu que j'ai toujours voulu écrire (et jouer grin) et je ne vais pas me prendre la tête pour quelques octets. Pour le moment, tous les textes ne marcheront pas, mais le "nouveau" système de tilemaps marche nickel grin

153

Pourquoi ne pas "formater" tous les lettres/caractères en 5*6 dans ce cas ? À cause de l'espacement ?

Enfin tu fais comme tu veux, ça à l'air plus simple à utiliser comme ça effectivement smile

154

Parce que certaines lettres se voient très rares si elles sont trop larges ou trop petites.

EDIT : J'ai fini la plupart des routines de menu, mais il reste encore les menus "scrolling".
BF86

155

Wow c'est vraiment très beau, les lignes ont juste un peu l'air serrée je trouve (il faudrait peut être les décaler toutes les deux d'un pixel vers le haut je pense) smile

156

Voici la nouvelle routine de textes/menus :
Cssl
Je crois qu'il reste encore quelques petites choses à faire, mais maintenant elle est plus organisée. Maintenant je pourrai commencer à faire de vrai progrès smile

157

Pouah c'est magnifique bravo !

158

Merci smile Je viens de finir le menu de stats, donc maintenant l'affichage des stats marche sans problèmes.

Avant, j'utilisais la routine de menu pour gérer les batailles, mais maintenant je crois que je vais écrire une routine spécifique à la routine de bataille. J'ai pas encore décidé comment je veux gérer les batailles, peut-être il y aura cinq places dans le champ pour les méchants... Avez-vous joué Legend of Legaia? Ou sinon, Marc the Superkid Quest? J'aime beaucoup ce type de système de combat, mais je ne veux pas le copier... Je veux quelque chose unique...

Et pour que je m'en recorde, je veux utiliser les flèches gauche/droite pour avancer 8 options dans les menus "scrollables".

EDIT : Je crois que je vais limiter les boîtes à des coordonnées multiples de 8 (pour les coordonnées X), la routine de rectangle et simplement trop lent pour mettre à jour tout l'écran. C'est dommage...

EDIT : Au final j'ai dû écrire une autre routine "nonalignée", mais cette fois elle est beaucoup plus rapide. Le code n'est pas beau, mais au moins ça marche !

159

On veut d'autres screens ! tongue

C'est vraiment beau, je crois que tu es en train de préparer l'un des meilleurs RPG pour TI 83+ smile

J'ai hâte de pouvoir tester tout ça.

160

Il n'y a pas beaucoup à afficher, la plupart du travail a été en réécrire ce que j'avais déjà programmé :P Demain je vais commencer le menu d'items, puis les shops, puis les batailles smile
cnzL

Je ne sais pas si tu veux utiliser cette routine d'affichage de rectangles, elle est plus rapide (mais peut-être un peu plus grande). Le code peut surement être optimisé, mais comme il est on peut faire des menus très élégants, avec des bords spécials, etc.

EDIT : Et le code (avec un .8xk) est toujours disponible sur http://code.google.com/p/juego-rpg/ wink

161

Génial, j'ai juste quelques propositions : faire une transitions "douce" entre les maps avec par exemple un fondu d'écran (avec le contraste), et ne penses-tu pas que ce serait mieux de scroller l'écran dès que le sprite du joueur est au milieu de celui-ci (au lieu d'attendre qu'il atteigne le bord) ? Voire même un peu avant le milieu de l'écran, comme ça le joueur a plus de visibilité devant lui (parce que là on a du mal à voir devant soit, limite on voit mieux derrière grin).
chickendude (./160) :
Je ne sais pas si tu veux utiliser cette routine d'affichage de rectangles, elle est plus rapide (mais peut-être un peu plus grande). Le code peut surement être optimisé, mais comme il est on peut faire des menus très élégants, avec des bords spécials, etc.

Pour pokémon ? Je ne sais pas, je ne pense pas que ce soit utile d'en avoir une plus rapide, et l'écran est tellement petit que je pense qu'il vaut mieux se contenter d'un simple rectangle comme cadre (ceci dit ça rend bien comme tu fais, avec les deux lignes supplémentaires, d'ailleurs tu pourrais même faire un effet 3d en les mettant à droite et en bas du cadre, mais ça c'est toi qui voit wink).

162

Je le dis simplement parce que quand tu veux faire des menus scrollables (le pokédex ou les items, par exemple) la méthode actuelle peut-être trop lente, surtout si tu vas utiliser tout l'écran. Au moins c'est ce que je trouvais moi dans mes routines. Peux faire une boîte simple, la routine occuperait près de 150 octets. Mais bon, les inputs son les même, donc si on décide de changer plus tard il sera facile d'implémenter.

Merci pour les suggestions, je vais expérimenter avec l'effet 3D et, pourquoi pas, écrire un simple effet de transition entre les maps.

Et aujourd'hui... les items !

163

Comme tu veux, mais de toute façons on en est pas encore là (et pour l'instant je n'ai pas trop le temps de m'y remettre sad).

C'est surtout l'histoire du scroll de l'écran qui est important je pense.

164

Si les menus scrollables seront alignés ça ne sera pas de problème, un peut LDIR le menu. Aujourd'hui, en lieu de programmer j'ai fait une longue sieste grin Donc j'ai rien fait, demain je bosserai sur le menu d'items smile

165

Je veux dire le scroll de la carte par rapport au sprite du joueur : ce serait plus pratique si la caméra était toujours centrée dessus, sauf quand on arrive aux bords de la carte.

166

Ah j'avais pas compris alors, bon je vais voir ce que je peux faire, je veux avoir une petite boîte dans le milieu de l'écran où le joueur peux se déplacer sans faire scroller l'écran, mais je peux essayer de la diminuer un peu.

Et maintenant, les menus sont presque complètement faits :
iM2K

EDIT : Oh, c'était trop facile, j'ai trouvé ces constants :
SCROLL_LEFT	 = $24		;donde empezar a mover la cámara
SCROLL_RIGHT = $2C		;donde empezar a mover la cámara
SCROLL_DOWN	 = $1C
SCROLL_UP	 = $14
haha grin J'ai fermé la boîte un peu, si tu trouves que c'est pas encore bon, je peux le changer comme tu dis pour que le joueur soit toujours centré dans l'écran.

167

chickendude (./166) :
je veux avoir une petite boîte dans le milieu de l'écran où le joueur peux se déplacer sans faire scroller l'écran, mais je peux essayer de la diminuer un peu.

Pourquoi ? Je trouve que c'est beaucoup mieux de déplacer l'écran (scroller) lorsque le joueur n'est pas en bordure de carte. Un peu comme faisait spencer avec son zelda :

pSsN

C'est un peu aussi ce qu'on fait dans pokémon d'ailleurs smile

168

Je ne sais pas pourquoi, mais je trouve que c'est meilleur comme ça smile

Je ne sais pas s'il serait possible ou non, mais est-ce qu'il serait possible de partager un groupe de masques entre deux fichiers .ini ? J'ai séparé les tiles en deux, inside/outside, mais je veux qu'ils utilisent les mêmes masques. Maintenant chaque fois que j'ajoute un nouveau masque il faut mettre à jour les deux .inis. Je ne sais pas si tu peux comprendre ce que je veux dire :/

Et voilà les arbres :
PgSp

169

chickendude (./168) :
J'ai séparé les tiles en deux, inside/outside

Oui mais pourquoi ? Actuellement tu utilises deux éditeurs dans des dossiers distincts donc c'est normal qu'ils n'utilisent pas les mêmes fichiers. Ce serait plus simple d'utiliser un seul éditeur, et si nécessaire qu'il gère lui même les tiles d'intérieurs/extérieurs (même si je ne vois pas trop comment faire ça).
chickendude (./168) :
Et voilà les arbres :

Cool smile

J'ai l'impression que certains pixels aux extrémités des sprites haut/bas du joueur sont copiées par dessus le reste de l'arbre (qui n'est pas praticable) quand on s'en approche trop, non ?

170

Tu as raison, je l'ai réglé smile

Oui, il serait plus facile d'avoir l'éditeur gérer les deux types de maps, mais je croyais que ça serait pas mal de travail d'implémenter. Je pensais que l'on pourrait sauver les masque dans un autre fichier dont les deux programmes pourraient se servir.

Et j'ai dessiné une simple arche (et ajouté une simple transition) :
Iuli

171

C'est génial grin

Tu vas pouvoir nous faire des villes très détaillées et vivantes avec ça smile

D'ailleurs vas-tu remettre les tiles animés et les npcs pourront-ils se déplacer ?

Pour les transitions, je pensais simplement à un "fondu d'écran" avec les contrastes comme dans pokémon, mais là c'est tout aussi bien tongue
chickendude (./170) :
Je pensais que l'on pourrait sauver les masque dans un autre fichier dont les deux programmes pourraient se servir.

Bon ok je vais essayer de faire ça ce soir, c'est juste que je trouve ça un peu gênant d'avoir deux fois l'éditeur, mais c'est comme tu veux smile

172

Bon, si tu peux faire pour que tout soit dans un programme je serais très content, je pensais seulement que ça serait assez gênant de programmer. Je viens d'ajouter le support multipage smile Je crois que je vais décompresser les maps dans RAM, mais je voudrais avoir de très grands maps...

Quant à la transition, je ne l'aime pas du tout, mais je n'avais aucunes autres idées.

EDIT : Oui, je pense rajouter les tiles animés, il faut faire d'abord quelques petites modifications au tilemapper mais c'est une des prochaines choses que je veux ajouter. Quant aux NPCs, je veux vraiment avoir des NPCs déplaçables, maintenant le tilemapper et beaucoup plus rapide et je veux que je pourrai le faire sans problèmes smile

173

chickendude (./172) :
Bon, si tu peux faire pour que tout soit dans un programme je serais très content, je pensais seulement que ça serait assez gênant de programmer.

Enfaite je ne vois pas trop ce qui te gène, ça fait trop de tiles d'avoir les extérieurs+les intérieurs ?
chickendude (./172) :
Je crois que je vais décompresser les maps dans RAM, mais je voudrais avoir de très grands maps...

Il y a des jeux qui décompressent seulement quelques bouts de la carte, et ne charge le reste que si le joueur y va. Ou alors tu peux décompresser les tiles qui t'intéresse "à la volée", mais ça risque d'être très lent pour les grandes cartes.
chickendude (./172) :
Quant à la transition, je ne l'aime pas du tout, mais je n'avais aucunes autres idées.

Tu pourrais faire la "pixellisation" bit par bit au lieu d'octet par octet, mais ça risque d'être plus compliqué et de prendre plus de place. Autrement si tu veux faire beaucoup plus simple sans que ce soit moche il suffit de jouer avec le contraste.

174

Pour le moment les brushes suffisent, mais je crois qu'avec d'autres lieux (des montagnes, des forêts, des villes, des champs, etc.) je n'aurais pas d'espace. C'est pour ça que je les ai divisés, plus tard il se peut que j'aie à les diviser encore plus.

SI je veux avoir des cartes plus grandes, j'aurai peut-être à les diviser dans des sections, je crois que je pourrai le faire... Si les maps sont compressés ça sera un peu plus compliqués, mais on verra.

Je ne vais pas me concerner de la taille du jeu, c'est mon "jeu de rêve", donc je vais utiliser tout l'espace que je voudrai !

EDIT : Ok, les maps sont chargés de la seconde page de l'app grin

175

chickendude (./174) :
Pour le moment les brushes suffisent, mais je crois qu'avec d'autres lieux (des montagnes, des forêts, des villes, des champs, etc.) je n'aurais pas d'espace. C'est pour ça que je les ai divisés, plus tard il se peut que j'aie à les diviser encore plus.

Bon je peux peut être ajouter une option "inside/outside" aux brushes, et séparer leur listes avec une "boîte à onglets" (panel), non ?

Autrement j'ai l'impression que les screenshots prisent par TilEm on des "pixels artefacts", c'est moins "fluide" qu'avec wabbitemu, c'est dommage.

176

deeph (./175) :
Bon je peux peut être ajouter une option "inside/outside" aux brushes, et séparer leur listes avec une "boîte à onglets" (panel), non ?
Ça serait parfait !
deeph (./175) :
Autrement j'ai l'impression que les screenshots prisent par TilEm on des "pixels artefacts", c'est moins "fluide" qu'avec wabbitemu, c'est dommage.
Oui c'est vrai, je l'ai testé oncalc et c'est pas comme ça. Je l'ai remarqué aussi dans les screenshots pour Pokémon Monochrome.

EDIT : Ok, aujourd'hui (dimanche) j'ai commencé à penser comment je veux faire le système de combat. J'ai pas mal d'idées, maintenant il faut commencer à les coder !

177

Deeph, peut-on créer des maps 6x4 ? Je veux avoir de petits maps pour les batailles qui change selon ton endroit, si tu es dans un forêt il y'aura pas mal d'arbres, si tu es dans un champ, il y aura de l'herbe, etc...

EDIT : Ah désolé, je peux simplement écrire le numéro tongue

178

Ok (j'avais mis une limitation parce que je pensais que ça serait gênant de créer une carte plus petite que l'écran) : http://www.mirari.fr/gwJL

J'ai rajouté l'option inside/outside aux brushes, mais je n'ai pas encore eut le temps de faire deux listes séparées (je fait ça dès que j'ai un peu plus de temps) smile

179

Merci beaucoup ! Et j'utilise des tuiles 16x16, donc 6x4 occupe tout l'écran smile

EDIT : Et ce n'est pas très important, mais on peut pas changer les dimensions d'un map après l'avoir créé.

180

Oui c'était paramétré pour des tiles 8*8.

J'ai réglé le changement de la taille de la map une fois créée : http://www.mirari.fr/gwJL