60

Autrement je commence à me demander comment afficher du texte à l'écran. Les BG 0 et 1 sont fait pour ça ? Je me demande si c'est simple et comment il faut faire (autant de sprites que de lettres ?).

Ce serait peut être plus simple de faire sa propre routine de sprite pour ne pas avoir à utiliser l'OAM, en plus ça permettrait d'avoir des tailles plus optimisées pour les lettres (genre 5*3 comme sur TI, j'aime assez sa police d'ailleurs).

Je vais y réfléchir !

61

Il faut créer ta propre police et les afficher comme sprites, je ne crois pas qu'il soit trop difficile, le plus difficile sera faire les sprites wink Et je crois que 5x3 serait très petit, mais oui il faut expérimenter un peu smile Comment va pong ?

EDIT : Ah et j'ai ajouté le code source (et un screenshot grin) dans mon dernier post (mais l'on ne va pas le voir parce que nous avons avancer de page).

62

Ça avance lentement (j'ai pas trop le temps ce soir) tongue

Prochaine étape : collision avec la raquette (+ modification de la trajectoire de la balle en fonction de son impact), game over et gestion des vies (ça c'est simple).

J'aimerai bien faire quelque chose comme avoir des angles moins droits avec la trajectoire (donc des vitesses pour la balle qui ne soient pas 1 et -1 mais des choses comme 0.5 etc...), mais je ne sais pas si c'est possible. Pour le moment la balle a toujours les mêmes trajectoires, donc ça n'a aucun intérêt... Autrement je pourrais utiliser un peu de géométrie, je me demande s'il y a des fonction dans le bios pour ça.

Ensuite peut être que je placerais des briques pour faire un arkanoid-like (mais sans doute pas aussi poussé grin).

Ton tilemapper a l'air génial (l'effet de défilement parallaxe est super, il faudrait l'utiliser dans un jeu !) top

Je vais avoir besoin d'un peu de temps avant de bien comprendre son fonctionnement tongue

63

Moi-même je ne le comprends pas complètement :P

Les functions du BIOS sont tous expliqués ici : http://nocash.emubase.de/gbatek.htm#biosfunctions
J'aimerai bien faire quelque chose comme avoir des angles moins droits avec la trajectoire (donc des vitesses pour la balle qui ne soient pas 1 et -1 mais des choses comme 0.5 etc...), mais je ne sais pas si c'est possible.
Bien sûr c'est possible, mais il faut penser un peu différemment smile Maintenant, tu utilise un octet pour les coordonnées et vélocités, mais si tu les changes à des halfwords, tu pourras utiliser le premier octet comme fraction. Donc si la vélocité X = $0080 la balle bougera un pixel chaque deux frames. Si la vélocité X = $0180, la balle bougera 3 pixels chaque deux frames, etc. Facile !

Et le problème que j'avais c'était que les sprites des fonds de rotation n'occupent qu'un octet dans CHARMEM pendant que les sprites des fonds de texte en occupent deux. Le formate est : 10 bits pour l'id de tile, 1 bit pour "flipper" un sprite horizontalement, un bit pour le flipper verticalement, et les derniers 4 bits sont le numéro de palette (je suppose que chaque sprite ne peut utiliser que 16 couleurs).

Je veux bien faire un RPG grin

64

chickendude (./63) :
Maintenant, tu utilise un octet pour les coordonnées et vélocités, mais si tu les changes à des halfwords, tu pourras utiliser le premier octet comme fraction. Donc si la vélocité X = $0080 la balle bougera un pixel chaque deux frames. Si la vélocité X = $0180, la balle bougera 3 pixels chaque deux frames, etc.

Heu... J'ai pas tout saisi confus

$0080 = %10000000 et $0180 = %00000001,%10000000, jusque là ok, mais après... ?
chickendude (./63) :
Et le problème que j'avais c'était que les sprites des fonds de rotation n'occupent qu'un octet dans CHARMEM pendant que les sprites des fonds de texte en occupent deux. Le formate est : 10 bits pour l'id de tile, 1 bit pour "flipper" un sprite horizontalement, un bit pour le flipper verticalement, et les derniers 4 bits sont le numéro de palette (je suppose que chaque sprite ne peut utiliser que 16 couleurs).

C'est assez bizarre, oui, il n'y a pas moyen d'utiliser deux background de rotation (en mode 2 avec les BG 2 et 3) ?
chickendude (./63) :
Je veux bien faire un RPG

Moi aussi ! Mais il y a encore quelques petits trucs à régler (comme comment afficher du texte).

65

Heh, bon, disons que la coordonnée X = $0700 et la coordonnée Y = $0180. La vélocité X = $0004 et la Y = $0180.
On peut dire donc que :
X =$07.00
Y = $01.80
velX = $00.40
velY = $01.80

Quand tu veux afficher la balle, il ne faut qu'ignorer le premier octet (après le décimal). Après un frame, X = $07.40 et Y = $03.00, donc la balle ne change pas de position X, mais saute DEUX pixels vers le bas (parce que la coordonnée Y était $0180, mais on peut pas afficher la moitié d'un pixel, donc on n'utilise que l'entier, le "1"). Si tu veux, je peux te donner un simple bout de code pour te montrer le concept, comme ce petit programme z80 que j'ai fait il y a quelques semaines :
fDNI

66

Ah ok, je comprend mieux du coup tongue

C'est un peu comme manipuler des variables "flottantes" (float ou à virgule).

Je testerais ça dès que j'ai le temps !

67

Je comprendrai jamais comment on peut à ce point aimer faire de l'assembleur quand ça demande autant d'efforts pour faire d'aussi petites applis.
Je veux dire, ce que j'aime dans le C++ et la java, c'est qu'on peut faire des trucs performants de façon efficace et que ça passe à l'échelle...
Dans l'industrie des jeux vidéos, il reste pas mal de routines de base codées en ASM non ?

68

Déjà ça permet d'avoir le contrôle total de la machine smile

Et puis en y regardant de plus près c'est pas si compliqué que ça (c'est l'algorithmie le plus dur !).

Par contre sur les consoles récentes je ne pense pas qu'il reste beaucoup de code en asm, sinon ça empêcherait de cross-compiler facilement (enfin je pense). De toutes façons elles sont devenues tellement puissantes que ce n'est plus la peine de se casser le cul à optimiser à mort, alors que c'est ce qui fait le charme de l'asm tongue

Le C/C++ je trouvais ça très lourd quand je voulais m'y mettre, et concernant le Java je n'ai jamais aimé être obligé de trimballer sa machine virtuelle (même s'il est parfois possible de s'en passer, il me semble...).

Enfin je comprend que les programmeurs professionnels se tournent vers ces langages (meilleur compromis puissance/facilité), mais en tant qu'amateur je ne leur trouve aucun charme.

69

Ce que j'aime le plus de l'assembleur c'est savoir ce que fait exactement chaque instruction, avoir contrôle complet du dispositif. Bien sûr, sur la plupart des ordinateurs modernes tu passerais toute la vie en programmant un jeu en assembleur, mais les TIs, la GB/GBA, la SNES, etc. sont assez simples comme pour fournir un atmosphère agréable pour programmer. Et de plus, avec les consoles de jeu vidéo, le hardware fait la plupart du travail. Programmer la GBA est mille fois plus facile que programmer les z80s, avec le hardware et la flexibilité/puissance des instructions ARM.

Ce qui me gène (peut-être ce n'est pas le mot correct) le plus de C/++ et al c'est que pour faire les choses les plus simples il faut me servir de libraires, des choses que je n'ai pas écrit et en plus je n'ai aucune idée de comment il fonctionne (de leurs contenus). Plus que programmer de l'assembleur, ce que j'aime sont les consoles simples où l'on a un haut niveau de contrôle. Je suppose que l'on pourrait dire que programmer en assembleur c'est parler avec le dispositif en sa langue maternelle, pendant que du C/++ etc. c'est lui parler à travers un traducteur. Je ne veux pas de traducteur, même si je ne parle pas parfaitement la langue smile

J'ai ajouté un petit personnage qui peut se promener par le map smile
VAU7

70

C'est génial !

Par contre, ce que je fait souvent avec le scrolling, c'est que j'attends de le déclencher quand le personnage est au milieu de l'écran (ou un peu avant même), pour avoir une meilleur vue de ce qu'il y a devant.

Pour les nuages, je crois avoir vu quelque part qu'il existait même une fonction pour faire de l'alpha blending (transparence)... Ah oui c'était là : http://gfx.developpez.com/prog-gba/effets/#L4 . Je me demande si c'est compliqué ?

71

C'est fait ! Je ne le comprends pas, j'ai choisi les numéros par hasard mais l'effet est beau :P
h1le

Le code :
	ldr r0, =REG_BLDMOD
	ldr r1, =BLEND_BG2T|BLEND_BG1S|BLEND_ALPHA|10<<16|8<<24
	str r1, [r0]

J'ai dû ajouter quelques choses à gba.inc. Pour plus d'informations : http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#REG_BLDCNT

Voici le dernier source : tilemapper v3.7z

72

C'est super happy

Je met à jour mon gba.inc, merci !

73

De rien, maintenant je veux ajouter la détection de collision, mais j'ai une petite doute concernant comment gérer les tuiles derrière lesquelles on peut passer, parce que si tu es avant la tuile le sprite du joueur doit se montrer, mais si tu es derrière, il faut cacher le sprite. Bon, je vais ajouter une autre couche pour les objets intéractifs et puis on verra comment nous le gérerons.

EDIT : Et pour les cmps, il peut être utile de penser ainsi : cmp r2, r3 = r3-r2, donc gt (greater than) signifie que r2 > r3, cs = r2 > r3, cc/lt = r2 < r3, etc. Je crois que c'est comme ça...

74

Il y a le bit 10 du troisième attribut pour gérer la priorité d'affichage entre les sprites.

En gros je pense qu'il faut le changer selon l'axe y (plus la coordonnée y est élevée, plus la priorité d'affichage est élevée, donc la valeur du bit 10 faible). Par contre :
Si un sprite possède la même priorité qu'un arrière-plan, le sprite sera dessiné par dessus.

Je ne sais pas si ça va être gênant... Tu comptes utiliser un autre background de rotation pour afficher les objets/bâtiments ?

75

Oui, je crois que je vais utiliser encore deux couches : une pour les objets/les choses qui parfois peut être avant le joueur, parfois derrière lui, et une pour les choses qui seront toujours affichées sur le joueur (comme les ponts ou la partie haute d'un arbre). Ton idée avec la priorité est bonne, je crois que je pourrai chercher le tile où est le joueur et si c'est un de ces tiles je change la priorité du sprite du joueur. D'abord je vais ajouter la détection de collision, puis la priorité smile

EDIT: J'ai fini la détection de collision, je me perds un peu avec tant de registres à ma disposition ! grin

76

Je viens d'acheter un Revo K101. Ils m'ont dit que si je ne suis plus ici quand ils me l'enverront ils peuvent m'en envoyer une autre à mon adresse nouvelle, donc il ne faut qu'attendre... grin

A propos, pendant que je pensais à comment faire quelque chose avec le tilemapper GBA, je me suis rendu compte que je peux utiliser le même concept avec (la version z80 de) Juego pour avoir des plafonds/ponts, quelque chose que j'ai voulu dès le début. smile

77

Cool, perso j'ai déjà un linker (M3 pour le port gba, l'un des tout premiers !) avec une vieille nds (première génération, la toute grosse avec les petits écrans grin), mais si elle en vaut vraiment le coup, j'en prendrais peut être une aussi smile

Pour juego, si tu as besoin de nouvelles choses pour l'éditeur, n'hésite pas à demander tongue

Autrement je n'ai pas trop avancé de mon côté mon "pong", je n'ai plus trop ni le temps ni la motivation :/

78

Je crois qu'il faut écrire des jeux plus "amusants" (comme un RPG grin), comme ça on ne perdra pas la motivation (et on trouvera du temps où il n'y en a pas wink).

EDIT: Quant à l'éditeur de Juego, la seule chose pour le moment c'est la vitesse, ajouter certaines choses (je crois que c'est surtout les brushes) peut prendre pas mal de temps, mais à vrai dire ça ne me gène pas, en tout cas c'est plus vite et beaucoup meilleur que le faire manuellement smile

79

Je veux bien qu'on démarre un projet à plusieurs (même si on a clairement pas le même niveau grin), ce sera effectivement plus amusant smile

On crée un svn google pour un "juego gba" ?

Sinon pour l'éditeur, je pense que pour la prochaine version je vais utiliser mon propre format de fichier pour sauvegarder les brushes/tiles/masques plutôt que sqlite, parce que c'est vrai qu'il devient vraiment lent au fur et à mesure qu'on lui rajoute des requêtes...

80

Oui, ou l'on peut faire un branch GBA dans l'svn actuel de Juego : http://code.google.com/p/juego-rpg/
Dès que j'ai un peu de temps je crois le tilemapper GBA va bientôt atteindre le tilemapper z80 de Juego smile

81

Cool, il faudra absolument que je trouve le temps de lire/comprendre comment il marche !

82

L'assembleur ARM est très simple, je crois que le plus complexe c'est le hardware smile

83

Ettttt voilà !
zrv3

grin

84

Wow t'as finalement mis la main sur un linker ?

85

Oui, j'ai acheté un Elink2 (et une GBA pour 90元, environ 13€) grin

86

Cool smile

Alors finalement, les émulateurs rendent (pour l'instant) exactement la même chose que sur gba ?

87

Oui, exactement. La vitesse avec No$GBA est un peu meilleure, mais seulement parce que pour moi VBA court toujours à environ 200%, si je limite la vitesse à 100% ça a pas mal de lag :/

C'est très cool de voir ce que tu as écrit marche sur une vraie GBA grin

88

C'est sûr ! Même si ça reste un peu fastidieux de devoir transférer les fichiers du PC vers le linker tongue

Je viens de penser à une chose, il y a un émulateur gba sur nspire, du coup nos programmes pourront même être joués dessus ! Ça ça doit être sympa à voir (qui veut prendre une photo du tilemapper dessus ? tongue) happy

D'ailleurs il y en a vraiment partout (j'en ai même un sur android).

89

Oui, j'ai déjà pensé à ça (l'émulateur marche vraiment très bien), mais je crois qu'on ferait mieux de faire une version native pour l'nSpire quand on aura fini le jeu grin D'ailleurs, le processeur de l'nSpire est plus rapide, heh.

90

Oui mais si on utilise une grande partie du hardware gba (pour les bg/sprites etc...), le portage risque d'être assez difficile, non ?