Caractéristiques techniques
Dimensions : 135 x 80 x 25 mm  
Taille de l'écran : 2,9 pouces  
Piles : 2 AA (3V)  
Autonomie : 20 heures  
Poids (sans les piles) : 140g  
CPU principal : 32 bit ARM (ARM7TDMI) à 16, 2 MHz  
CPU secondaire : Z80 8 bits / 8 MHz (processeur de la GB originale pour la compatibilité des jeux)  
Nombre de couleurs : 512 (numérotées de 0 à 511)  
Palette : 65 535  
Résolution : 240x160  
Scrolling : horizontal et vertical  
 
 Processeur RISC 32bit développé par la société Cambridge, la filiale de ARM Corporation réputée pour avoir développé de nombreux processeurs pour les téléphones portables.
 
 
Voila !! c'est fait !!
un topic dédié à la programmation sur cette merveilleuse petite console !!
 
 
Le Hard !! :
     http://gba.w.free.fr/technique/tech.htm
 
ARM7TDMI :
http://www.nalanda.nitc.ac.in/indu [...] oc0747.pdf
 
Environnement de developpement :      
     www.gbadev.org
     www.ngine.de
     www.ifrance.com/edorul/index.html
     http://devkitadv.sourceforge.net
 
Tutoriels :
  http://www.thepernproject.com/French/tutor1.htm
  http://www.maxoedev.com/tutoriaux/ [...] tion.shtml
  http://www.afdac.org/prog.php
 
Le top du top :  
     http://www.taylors.org/cim/ARM-GBA/loirak_030303.html
Hello.c pour GBA !!!!
 
 
Contribution des participants :
    http://getget.no-ip.com/Tout/Gba/hfr.gba  
    http://pifou.myftp.org/eris/  
 
 
FORUM :
http://forum.hardware.fr/forum2.ph [...] subcat=250  
 

 
A suivre d'autre lien interressant pour cette console .
 
Si vous avez des idées !!

Drapal ??

faudra un jour que je me mette a la démo sur cette machine

Ca bouffe quoi ce machin? des cds?

ah mais je suis sérieux hein quand je parle de démo
y'a plein d'émulateurs pour cette machine, avec débuggers et tout !

 
 c une tres bonne console , sur lequel on peut developper pleins de trucs

on peut aussi coder avec CodeWarrior pour la gba

Hello a tous
Moi j'ai entamé un RPG, je pars de rien, on verra au fur et a mesure .... siq uelqu'un a des planches de sprites de décors ca m'interesse

Par contre, j'espere que quand HAM compile le prog, il utilise les fonctions hard de la GBA pour la gestion des sprites / background (je pense quand meme lol, sinon ca va ramer ....).
 
Quelqu'un a des idées de comment on fait un algo de detection de coliisions ? Je pensais faire une map (non affichée) qui comprendrait les zones accessibles et les zones non accessibles, il faut que je teste ca.

Bon, allez, drapal !
 

Oui, ce sont bien les fonctions hard qui sont utilisées (du moins avec HAM)
 

Oui, c'est ce qu'il faut faire
Il me semble que c'est la technique utilisée dans la majorité de ce type de jeux.

+1, je m'étais légèrement penché dessus à une certaine époque, avant de laisser tomber faute d'émulateurs assez avancés. Mais maintenant c'est autre chose, j'ai bien envie de m'y remettre
 
Et puis quand je vois ce genre de truc, je saute de bonheur
 

Ca me rappelle trop le mode 13 du DOS

moi aussi tiens, je

Il faudrait ptèt faire un topic unique, non ?
Il y a un autre topic fait par Getget sur JV, il faudrait en garder un des deux...

Je ne vais consacrer l'autre plus qu'au jeu en lui meme
 
Sinon j'ai encore quelques probleme dans HAm :
 

• Probleme de priorités entre les Background (bg) et les sprites, j'arrive pas a afficher un sprite entre 2 bg, j'ai mailé le concepteur de HAM on verra bien.
• Et puis toujours des problemes pour editer les maps et les tiles, surtout au niveau couleurs comme on a que 256 couleurs dans le mode ou je suis, je me suis fixé une palette mais le convertisseur n'en fait qu'a sa tete et me la change ...

Pour le jeu justement, avant d'attaquer le code, tu as un scénar de prêt (dialogues, NPCs, histoire, etc...), ou tu te lances les mains en avant dans le cambouis ?

 
Pour le moment je regarde ce qu'on peut faire, et g un pote qui bosse au graphs et au scenar.
 
En gros moi je fais le moteur lol

Donc au final, c'est la fonction de création des sprites qui est buggé, il faut réattribuer la priorité apres la création avec ham_ObjPrio(sprite,prio).
 
Pour ce qui est de la palette, si on rajoute un -x dans la ligne de commande, gfx2gba ne modifie plus la paletet d'origine de l'image.
 
Voila ou j'en suis :

 
Le perso passe maintenant entre les 2 BG (pour simuler quil se trouve derriere un objet).
 
J'attaque la detection de collisions.
 
Pour le dnld c'set toujours l'adresse du 1er post.

 
   
 
C quoi ce reponpage de sprite de secret of mana?!

chrono trigger je dirais plutot

c'est marqué dans l'autre post "En attendant de faire un perso"

Nan nan, secret of man sur SNES

pourtant il me semble que le personnage est Crono, mais peut-etre que je me trompe

Oui c'est secret of mana

 
le perso c Secret of Mana
 
et pour ce qui est des textures ce en serait pas un certain RPG Maker ??  

Sisi mais je suis en train de les refaire là
Enfin je m'en sers comme base quoi, jvais aps non plus réinventer la poudre lol

 
les hommes, les vrais font tout eux-memes, directement en asm  

Bah vas y alors lol

 
oue ! moi je di il faut faire les textures en asm

par contre, les vrais développeurs GBA utilisent MAppy VM comme émulateur

En tout cas, nouvelle version, avec la map de collision

tu peut aussi te faire une structure TILE qui contient les infos de chaque bloc (sprite, type, accessible ou non) et stocké ta map dans ce format

Au fait Getget, ton éditer de BG/tiles, c'est celui qui est fourni avec VisualHAM, ou un autre ?
Et aussi, tu devrais éventuellement poster tes sources en même temps que la ROM, ça aiderait du monde (comment ça, moi ?)

Non j'utilise un autre editeur, puis je sors en BMP, et je passe ca a la moulinette dans gfx2gba (avec un batch que jme suis fait)qui me décompose ca en tiles / map, tout en optimisant avec des symetries etc...
 
Les sources pkoi pas lol mais c gros et surtout euh pas documenté... mais pkoi pas, je vais faire un zip.

Bon j'ai commenté un peu mais pas "rangé" le code (surtout au niveau des IF), et j'ai pas optimisé pis les commentaires sont en franglais lol (bilingue powa)
 
http://getget.no-ip.com/Tout/GBA/getget.zip