Débuter

[leogamers]

J'aimerai me mettre au developpement sur GBA, mais je n'ai aucunes connaissances en programmation, par quoi es que je dois commencer ?:blink:

[Zepman]

http://www.palib.info/wiki/doku.php?id=homepage

[leogamers]

merci, mais vous avez pas un site francais plutot ?

[RefiX]

merci, mais vous avez pas un site francais plutot ?
http://www.palib.info/wikifr

[Alekmaul]

Si c'est pour GBA, il va avoir des problèmes pour tout comprendre vu que PALIB fonctionne sur DS :whst:
Ceci me semble plus approprié : http://www.afdac.org/prog.php

[RefiX]

Si c'est pour GBA, il va avoir des problèmes pour tout comprendre vu que PALIB fonctionne sur DS :whst:
Ceci me semble plus approprié : http://www.afdac.org/prog.php

erf :S
Sur Gba il y a aussi le tutorial avec Vham de aaron rogers (j'espere ne pas esquinter son nom).

[Alekmaul]

Je crois pas que les tutos d'Aaron soient en Français.
Y'a des articles en Français sur le site developpez ici : http://gfx.developpez.com/prog-gba/

[leogamers]

ils disent qu'il faut des bases .... donc je dois commencer par quoi ???:hum:

[birslip]

Les bases tu vas les acquérir au fur et à mesure, donc la gba ça peut être sympa pour débuter même si tu n'y connais rien... à force tu vas connaître ;)

[leogamers]

sur le site de afdac, j ai fait le 1er jour, mais des que je recopie le code dans HAM, j'ai toujours des erreurs (je l ai meme copier coller, mais rien a faire...)

[Arialia]

Petit conseil :
quand tu installes un environnement de dev, essayes de générer un des exemples fournis ... si tu as des erreurs ç'est un pb de configuration.

Précises nous tes erreurs et ta config pour que l'on puisse t'aider ...

[Dr.Vince]

il y a beaucoup d'exemple fournit avec HAM, ça peut aider au début

[schwaxpl]

Je profite de ce topic pour vous demander aussi si vous aviez un bouquin à conseiller pour debuter en C , j'ai quelques notions en progra mais vraiment très peu ( basic :whst: ) , si possible un bouquin assez clair , qui ne soit pas juste un pavé de lignes de codes :p
merci

[KCV]

Bonsoir,

Achètes un bouquin de C de chez "Eyrolles"
ou
le livre du C premier langage de "Claude Delannoy"

Cordialement,
Kcv

[schwaxpl]

oké , je verrais ça dès que j'aurrais les sous ;) , peut ètre bientot verrez vous des homebrews signés de mon pseudo imprononçable ;) ** a hate de recevoir son ez4 **

[van_tiberium]

Je remonte ce topic pour vous poser quelques questions.
Ayant toujours voulu me mettre au développement de projets en amateurs, j'essai de m'y mettre enfin.
Mais avant de me lancer dans n'importe quoi, je me documente.
Or, après 15 jours de google, c'est de moins en moins clair, du moins pour faire un choix.

Pour essayer de faire clair (dites-moi si je me trompe), j'ai l'mpression qu'il y a deux écoles.

D'une part, celle des "purites", c'est-à-dire du C aux kilos, le devkitpro, emacs pour le code et c'est parti. Pour ce genre de challenge, qui à mon avis est certainement le plus formateur, mais aussi le plus ardu pour de l'amateurisme, les tutos ne manquent pas. J'ai relevé :
http://user.chem.tue.nl/jakvijn/tonc/toc.htm : le TONC, c'est bien, c'est ultra-exhaustif, mais c'est costaud.
http://drunkencoders.com/index.php?system_id=2&page=Tutorials : dit le tuto "ivre" ;) . C'est aussi bien balèze.
Ce sont deux morceaux d'anthologie, je pense. Je n'ai rien contre m'y mettre sérieusement mais j'aimerai des avis, des "certifications", sur le fait que ce n'est pas du temps perdu de se lancer dans ces pavés.

De l'autre côté, on trouve les environnements "assistés". Là, les puristes râlent pour cause de béquilles (pourquoi pas ?), car l'apprentissage d'un code "propre" est moins évident et l'on est tenté par les instructions maisons etc. Je suis pas sectaire, donc largement ouvert à ce genre d'entorse au sacro-saint C :D
J'ai relevé :
http://www.dslua.com/component/option,com_frontpage/Itemid,1/ : ça se lance doucement, ça a l'air facile à capter. A voir.
http://www.palib.info/wiki/doku.php?id=homepage : la PALIB, avec son tuto qui va bien et qui explique les bases du C.
http://www.ngine.de/index.jsp?pageid=3510 : le bien connu HAM, avec son IDE. Là aussi : du costaud. Et en plus, y a le manuel qui va bien avec http://www.jharbour.com/gameboy/default.aspx (il vaut quoi d'ailleurs ?)

Bref, voilà ma demande :
Vous qui développez à tour de bras, vous me conseillerez quoi ?
Quel école adopter (l'une, adepte du C, l'autre, avec ses lib spécialisés) ?
Je compte m'invistire dans un apprentissage, mais je n'ai rien contre une certaine facilité (l'académisme, j'ai mes cours de droit pour ça :D ).

Merci !

[Dr.Vince]

Je remonte ce topic pour vous poser quelques questions.
Ayant toujours voulu me mettre au développement de projets en amateurs, j'essai de m'y mettre enfin.


oui mais sur quel support NDS ou GBA ???


D'une part, celle des "purites", c'est-à-dire du C aux kilos, le devkitpro, emacs pour le code et c'est parti. Pour ce genre de challenge, qui à mon avis est certainement le plus formateur, mais aussi le plus ardu pour de l'amateurisme, les tutos ne manquent pas. J'ai relevé :
http://user.chem.tue.nl/jakvijn/tonc/toc.htm : le TONC, c'est bien, c'est ultra-exhaustif, mais c'est costaud.
http://drunkencoders.com/index.php?system_id=2&page=Tutorials : dit le tuto "ivre" ;) . C'est aussi bien balèze.
Ce sont deux morceaux d'anthologie, je pense. Je n'ai rien contre m'y mettre sérieusement mais j'aimerai des avis, des "certifications", sur le fait que ce n'est pas du temps perdu de se lancer dans ces pavés.


ces tutos sont adaptés si tu ne cherche pas à développer un truc opérationnel de suite.
Après c'est à toi de voir
sinon tu as aussi les cours de l'AFDAC


De l'autre côté, on trouve les environnements "assistés". Là, les puristes râlent pour cause de béquilles (pourquoi pas ?), car l'apprentissage d'un code "propre" est moins évident et l'on est tenté par les instructions maisons etc. Je suis pas sectaire, donc largement ouvert à ce genre d'entorse au sacro-saint C :D
J'ai relevé :
http://www.dslua.com/component/option,com_frontpage/Itemid,1/ : ça se lance doucement, ça a l'air facile à capter. A voir.

oublie LUA, tu pourra y revenir plus tard, c'est en gros un système de scripting, utile par exemple dans les RPG


http://www.palib.info/wiki/doku.php?id=homepage : la PALIB, avec son tuto qui va bien et qui explique les bases du C.


uniquement pour dev sur NDS


http://www.ngine.de/index.jsp?pageid=3510 : le bien connu HAM, avec son IDE. Là aussi : du costaud. Et en plus, y a le manuel qui va bien avec


uniquement pour dev sur GBA


http://www.jharbour.com/gameboy/default.aspx (il vaut quoi d'ailleurs ?)


à ranger du côté "puriste"


Bref, voilà ma demande :
Vous qui développez à tour de bras, vous me conseillerez quoi ?
Quel école adopter (l'une, adepte du C, l'autre, avec ses lib spécialisés) ?
Je compte m'invistire dans un apprentissage, mais je n'ai rien contre une certaine facilité (l'académisme, j'ai mes cours de droit pour ça :D ).

Merci !

tout dépend du support et de ce que tu veux : développer rapidement un truc avec des lib ou alors apprendre direct le hard mais la faut pas être pressé

Moi je te conseil les lib, ça te permet de te faire à un certains style de codage (sur console quoi) et donc d'apprendre les bases.
Après tu pourra approfondir en te passant des libs

Voilà :)

[vgiant]

Cool tiens! Je connaissais pas ce tuto sur wiki, je vais essayer de m'y mettre du coup ;o)

a+ et merci pour le lien!

[van_tiberium]

>Dr.Vince

Dans ce cas, tu choisirais quoi comme lib de développement,comme outils et comme tuto ?
Même arbitrairement.
Pour le bouquin sur Ham, pourquoi tu le classes comme "puriste" ? Là, je pars une semaine et je pensai le sortir pour le potasser (en plus HAM est une lib) :lol:

[cocole]

Si tu veux programmer, tu apprends l'anglais !

[van_tiberium]

Arf, j'avais oublié de préciser (mais bon, vu les liens cité je pensai que ça se voyait), que la langue anglaise n'était pas un problème pour moi ;)

[birslip]

Le bouquin sur Ham est bien foutu mais il n'est pas vraiment utile pour débuter. Je te conseil de t'immerger dans les nombreux exemples de ham :)

[Dr.Vince]

Dans ce cas, tu choisirais quoi comme lib de développement,comme outils et comme tuto ?


Dans quelk cas ?? :ph34r:


Pour le bouquin sur Ham, pourquoi tu le classes comme "puriste" ? Là, je pars une semaine et je pensai le sortir pour le potasser (en plus HAM est une lib) :lol:

parce que c'est pas un bouquin un bouquin sur HAM.....:ph34r:

c'est un bouquin qui t'explique comment coder en hard.
C'est juste qu'il a utilisé l'IDE VisualHAM....

[van_tiberium]

Et bien programmer sur GBA/DS pardi :lol:

Pour le livre, je pensais que, utilisant IDE/HAM, la programmation hard utilisait du code HAM. Ce serait pas un bon bouquin pour s'initier tranquillement sur la prog GBA, mention HAM ?

[Dr.Vince]

bah entre DS et GBA c'est pas pareil....
Donc avec lib :
- DS : PAlib, y a tous les tutos et exemples qu'il faut
- GBA : HAM, y a pleins d'exemples

sinon le livre c'est pour le hard donc rien à voir avec HAM.
Par contre dedans y pas mal d'informations sur le fonctionnement de la GBA

[van_tiberium]

Dans ce cas, c'est pas mal (le bouquin) pour un apprentissage de fond, tout en apprenant à manier HAM IDE, non ?
De toute façon, j'envisage de commencer plutôt par la GBA, comme de nombreux sites l'indique.

[Dr.Vince]

en même temps, l'IDE VHAM est pas très compliqué...

mais bon oui, si tu pars en vacances tu peux le lire et en rentrant tu te met à HAM

[van_tiberium]

Je constate que, comme tu l'as indiqué, l'introduction du bouquin préconise des connaissances en C.
Bon, j'imagine qu'on peut apprendre sur le tas mais ça peut être délicat.
Dans ce cas, PALIB et le tuto du wiki, qui inclus quelques bases de C, pourrait peut être mieux convenir ?
C'est bien PALIB pour débuter ?

[birslip]

Oui, PALib c'est très bien pour commencer, le wiki est très bien foutu, il y a quelques bases sur le C. PAlib contient aussi pas mal d'exemples.

[Dr.Vince]

ha, t'avais pas précisé que t'y connaissais rien au C.

Bah je te conseille d'apprendre d'abord le C, sinon tu risque d'être un peu à la rammasse

[van_tiberium]

J'ai approfondi sur le bouquin.
Les exemples sont clairs et permettent, je pense, de voir le C par le concret.

Donc j'ai deux options :
HAM+bouquin ou
PALIB+wiki.

Pour un noob (motivé), les masters conseillent quoi ? :D

[Tembargo]

PALIB+wiki ;)

[Bobby Sixkilla]

Rien ne vaut un bouquin. ^^ Ca te servira toujours de toute façon. ^^

[Dr.Vince]

t'as pas deux options en fait, ça dépend si tu veux dev sur GBA ou sur NDS...

[van_tiberium]

Et bien, j'envisage sérieusement de commencer sur GBA, puisque beaucoup prétendent que c'est la base.
Maintenant, si vous parvenez à me prouver le contraire... :lol:
(merci de vos conseils les amis ;) )

[Dr.Vince]

donc si c'est GBA alors ce sera forcément : HAM+bouquin

[Tannis Dragon]

Salut
Je vais faire court (vu que je repose la question dans ce forum mais pas dans la meme section car personne ne va plus dans l'autre apparement). Je suis amateur en prog C++ (je l'étudie avec un bouquin)
j'ai créer un sprite de 16*8 que j'ai placer dans la zone 0x060100000 + 512*16 car je suis en mode 3.
j'ai mis dans mon OAMBuffer c'est attribut type WIDE et SIZE_8 (en gros large et 8*8).
première chose bizarre, quand je le met en position 0 dans mon buffer (OAMBuffer[0].attri...) dans OAM viewver sur visual boy advance je n'ai que le premier tiles qui apparait en 8*8.
quand je le met en position 2 dans mon buffer il me le met bien complet 16*8..
déjà sa. Après en laissant avec la deuxieme méthode (donc 16*8) je suis hors de l'ecran, donc je le déplace et là il me refais l'erreur, j'entend par là qu'il me met que le premier tile 8*8 et qu'il a bouffer l'autre morceau (constater dans OAM viexver aussi).
quelqu'un a t'il une idée du pourquoi ???
Si il faut préciser quelque chose dite le moi.
Merci d'avance pour vos conseils :)

[Dr.Vince]

t'as mis WIDE et SIZE de 8 ???

[Tannis Dragon]

Alors en faite j'ai mis dans attribut0 j'ai mis WIDE (=> 0x4000) et dans attribut1 SIZE_8 (=> 0x0)
donc un sprite qui ferais 8*8 en taille mais avec l'option WIDE (large) il double la largeur donc 16*8.
si j'aurais pris SIZE_16 il devrais me le mettre (avec wide) une taille de sprite de 32*16 :)

[Dr.Vince]

hum.... si c'est l'attribut wide auquel je pense il me semble que l'on s'en sert uniquement quand on fait des rotation avec le sprite, en fait ça double pas véritablement sa taille

[Tannis Dragon]

C'est vrai que je n'ai pas encore étudier le system de rotation des sprite, je n'en suis qu'a les faire bouger de gauche a droite et de haut en bas :)

Mais en mode 0, WIDE fonctionne bien (il me prend les 2 tile de 8*8 qui se suive dans la mémoire et quand je regarde OAM viewver il prend bien le sprite comme un sprite de 16*8)... par contre en mode 3 sa foire...

Je pensais qu'avec cela on lui disais que le sprite prenait les 2 tiles qui se suive dans la zone mémoire. Un peux comme quand on fait un sprite de 32*32 et que l'on met en attribut0 SQUARE (carré). J'ai même essayé de le mettre en mode OBJ_MAP_2D dans REG_DISPCNT, sans succès...

Je ne pense pas vraiment que sa soit le mode qui fait la différence.. en plus en mode 0 je n'active que le background 0 donc pas de rotation possible du background (de toute facon la rotation du background n'ai pas lier a celle des sprites...)

Je vais essayer de relire un peut le tout, mais je n'ai pas vu que WIDE , et TALL était lier a la rotation. Je vais tout de meme examiner cette piste, merci :)

[Dr.Vince]

bon comme moi j'utilises des lib je peux pas t'aider plus que ça

donc je te conseille de lire ça :
http://www.jharbour.com/gameboy/default.aspx

tu y trouveras ta réponse

[Tannis Dragon]

merci pour ton aide.

je fonctionne aussi par librairie, mais je préfère les créer (d'accord on me dira que je cherche a réinventer la poudre), en faite j'aime bien comprendre pourquoi sa marche et comment. Si je peux le faire seul, je peux me dépanner de quasi n'importe quoi :lol: .

Mais là j'avoue que je bloque dure sur ce phénomène car j'ai épuiser toute mes idées pour trouver la parade...Normalement sa devrais marcher d'après ce que j'ai vu, mais j'ai trouver personne qui a fait l'expérience ...

J'entend par là faire apparaitre un sprite en mode 3 de taille 16*8 et de le faire bouger. Mais attention j'entend qu'il le prend comme un sprite de 16*8 et non s'amuser a faire 2 sprites de 8*8 qui se chevauche car sa je sais le faire. Car le truc marche bien en mode 0,1,2.

merci pour ton lien vers se site, je ne le connaissais pas, il a l'air interressant, j'ai survoler la partie sprite, mais a aucun moment il montre avec un sprite de forme différent que celui d'un carré. De plus il reste confiner en mode 0.

Moi perso en mode 0 sa marche, mais j'ai mon menu qui est en mode 3 donc faut bien que je lui fait le petit curseur de sélection ;) et celui ci est de 16*8 ... J'ai vu que certain avait réussie un sudoku avec une main de 32*32... bon d'accord c'est du carré, mais si sa marche en carré je vois pas pourquoi sa ne marcherais pas avec les autre attribut (WIDE et TALL).

Je vais continuer a chercher. En plus j'ai encore tellement de chose a résoudre :lol: , comme le faite que mon sprite ne fout pas le camp dans de la flotte ou dans les arbre dans le background que j'ai fait en mode 0, j'ai penser a vérifier le numéro du tile dans le tableau de ma map et de le vérifier avant de faire bouger mon sprite avec un IF mais j'ai du mal programmer car il ne me le prend pas en compte et résultat mon sprite ne bouge plus du tout (vu que l'attribut ce trouve dans le IF et qu'il ne vois jamais mon égalité bonne)... Je verrais bien, pour ce soir je vais stopper là, je reprendrais sa demain :)

[MIKEGBA]

:) hello , pour la taille des sprites :

le bit 9 de l'attribut 0, c'est pour le double size du sprite, ça permet simplement d'éviter qu'un sprite soit tronqué en cas de rotation.


sinon, pour un savoir quoi mettre dans les bits 14 et 15 de l'attribut 0 et 1 , voilà un petit tableau qui résume tout:

attribut 0 attribut 1 taille du sprite

00 00 8x8
00 01 16x16
00 10 32x32
00 11 64x64
01 00 16x8
01 01 32x8
01 10 32x16
01 11 64x32
10 00 8x16
10 01 8x32
10 10 16x32
10 11 32x64


à plus !

[Tannis Dragon]

Salut MIKEGBA

Je connaissais l'existance des codes et si je retransforme en binaire le code hexa de mon premier message ici (voir quelque poste plus haut)
j'ai mis pour WIDE en attribut 0 = 0x4000 = 0100 0000 0000 0000 (donc 01 pour les bit 14 et 15)
et SIZE_8 en attribut 1 = 0x0 (pas la peine que je le met en binaire celui là :lol:)

Voir, je l'avais même noter dans mon prog directement en hexa au cas ou mes #define serais mal fait (une erreur d'un bit c'est tellement fréquent...)
Mais sans succès. Ce n'ai pas non plus l'enregistrement car les donnée de mon sprite sont bien présent dans la zone mémoire et au bonne endroit car en 8*8 j'arrive a les prendres en tant que 2 sprites...

Je vais essayer avec un format différent .. celui du dessus 32*16... Pour voir, il me suffit simplement de ragrandir mon image d'origine a ce format et de le reconvertir.

Merci pour le récapitulatif du tableau ;)

[Meithal]

Bonsoir à vous.

On dirait que c'est le topic des débutants, et on parle de sprites donc j'espère que c'est le meilleur endroit où exposer mon problème:

J'ai voulu faire un petit programme qui fasse défiler les avatars d'un forum que je fréquente, alors j'ai commencé à coder:


#include <mygba.h>

MULTIBOOT

//Fond

#include "gfx/aeriesguard.raw.c"

#include "gfx/aeriesguard.pal.c"


//sprites
#include "gfx/Aedan.raw.c"
#include "gfx/Aiua.raw.c"
#include "gfx/Aka.raw.c"
#include "gfx/Aldareis.raw.c"
#include "gfx/Andaheru.raw.c"
#include "gfx/Ertai.raw.c"
#include "gfx/Gameurjeux.raw.c"
#include "gfx/Kadrik.raw.c"
#include "gfx/Kit_Estivile.raw.c"
#include "gfx/Lebashar.raw.c"
#include "gfx/Licorne.raw.c"
#include "gfx/Lordsanglant.raw.c"
#include "gfx/Meithal.raw.c"
#include "gfx/Nick.raw.c"
#include "gfx/Nmind.raw.c"
#include "gfx/Picsou.raw.c"
#include "gfx/RaDgoo.raw.c"
#include "gfx/Sire_Lancelot.raw.c"
#include "gfx/Zergy.raw.c"

#include "gfx/avatars.pal.c"





int main(void)
{

//Variables
u8 image=0;
u8 touche=0;
u8 avatar;

ham_Init();

ham_SetBgMode(4);



//charge palette fond
ham_LoadBGPal((void*)aeriesguard_Palette,256);

//charge image de fond
ham_LoadBitmap((void*)aeriesguard_Bitmap);

//inverse le buffer
ham_FlipBGBuffer();


//charge palette avatars
ham_LoadObjPal((void *) avatars_Palette,16);



while(1)
{

void ham_ResetObj ();
ham_DeleteObj(0);

switch(image)

{
case(1):avatar = ham_CreateObj((void*)Aedan_Bitmap,0,3,OBJ_MODE_NOR MAL,1,0,0,0,0,0,0,87,100); break;
case(2):avatar = ham_CreateObj((void*)Aiua_Bitmap,0,3,OBJ_MODE_NORM AL,1,0,0,0,0,0,0,87,100); break;
case(3):avatar = ham_CreateObj((void*)Aka_Bitmap,0,3,OBJ_MODE_NORMA L,1,0,0,0,0,0,0,87,100); break;
case(4):avatar = ham_CreateObj((void*)Aldareis_Bitmap,0,3,OBJ_MODE_ NORMAL,1,0,0,0,0,0,0,87,100); break;
case(5):avatar = ham_CreateObj((void*)Andaheru_Bitmap,0,3,OBJ_MODE_ NORMAL,1,0,0,0,0,0,0,87,100); break;
case(6):avatar = ham_CreateObj((void*)Ertai_Bitmap,0,3,OBJ_MODE_NOR MAL,1,0,0,0,0,0,0,87,100); break;
case(7):avatar = ham_CreateObj((void*)Gameurjeux_Bitmap,0,3,OBJ_MOD E_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(8):avatar = ham_CreateObj((void*)Kadrik_Bitmap,0,3,OBJ_MODE_NO RMAL,1,0,0,0,0,0,0,87,100); break;
case(9):avatar = ham_CreateObj((void*)Kit_Estivile_Bitmap,0,3,OBJ_M ODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(10):avatar = ham_CreateObj((void*)Lebashar_Bitmap,0,3,OBJ_MODE_ NORMAL,1,0,0,0,0,0,0,87,100); break;
case(11):avatar = ham_CreateObj((void*)Licorne_Bitmap,0,3,OBJ_MODE_N ORMAL,1,0,0,0,0,0,0,87,100); break;
case(12):avatar = ham_CreateObj((void*)Lordsanglant_Bitmap,0,3,OBJ_M ODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(13):avatar = ham_CreateObj((void*)Meithal_Bitmap,0,3,OBJ_MODE_N ORMAL,1,0,0,0,0,0,0,87,100); break;
case(14):avatar = ham_CreateObj((void*)Nick_Bitmap,0,3,OBJ_MODE_NORM AL,1,0,0,0,0,0,0,87,100); break;
case(15):avatar = ham_CreateObj((void*)Nmind_Bitmap,0,3,OBJ_MODE_NOR MAL,1,0,0,0,0,0,0,87,100); break;
case(16):avatar = ham_CreateObj((void*)Picsou_Bitmap,0,3,OBJ_MODE_NO RMAL,1,0,0,0,0,0,0,87,100); break;
case(17):avatar = ham_CreateObj((void*)RaDgoo_Bitmap,0,3,OBJ_MODE_NO RMAL,1,0,0,0,0,0,0,87,100); break;
case(18):avatar = ham_CreateObj((void*)Sire_Lancelot_Bitmap,0,3,OBJ_ MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(19):avatar = ham_CreateObj((void*)&Zergy_Bitmap,0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87, 100); break;

//default:avatar = ham_CreateObj((void*)Aedan_Bitmap,0,3,OBJ_MODE_NOR MAL,1,0,0,0,0,0,0,87,100); break;
}
//ham_DeleteObj();
ham_CopyObjToOAM;

if(F_CTRLINPUT_LEFT_PRESSED || F_CTRLINPUT_RIGHT_PRESSED)
{
if(F_CTRLINPUT_LEFT_PRESSED)
touche=-1;
if(F_CTRLINPUT_RIGHT_PRESSED)
touche=1;

image=image+touche;

if(image == 0) image=19;
if(image == 20) image=1;
touche=0;
}





}

return 0;
}


/* END OF FILE */



Lorsque je lance l'émulation, dès que j'appuye sur une touche, ca me sort ce bug:

http://grabag.free.fr/fourtout/images/buggba.png

Pourtant, je n'ai théoriquement chargé qu'un seul sprite dans lOAM...

Si vous avez une idée d'où cela peut venir...

Merci :)

[Tannis Dragon]

Salut Meithal

Bon perso je suis amateur en prog (j'ai commencer a apprendre y a de cela 1 mois :whst: )
De plus je n'utilise pas la bibliotheque HAM...donc encore une fois...

Mais je peux tout de même te soumettre peut être une petite idée.
J'ai étudier l'instrustion switch... et d'après ce que je vois dans ton code, normalement une fois qu'il passe sur une des cases (genres cases (1)) et qu'il accomplit l'instruction il passe ensuite sur la cases suivante (donc cases (2)) puis éxécute l'instrustion et ainsi de suite... Donc moi perso je pense qu'il te manque l'instruction BREAK ; dans chacune de tes cases. Cela permettrait de sortir de l'instrustion switch et ainsi de copier le buffer de l'OAM.
Maintenant je ne suis que débutant et je ne sus pas sur d'avoir bien compris ton code a cause de la librairie HAM que je ne connais pas. :-'

Maintenant c'est juste un conseil, ou plus une idée :)
Bon courage ;)

[Meithal]

À priori, ca ne devrait pas venir du break puisque ceux-ci sont présents.

J'ai regardé quelques codes d'exemples qui intégraient des sprites mais ils étaient toujours programmés en tile mode, et je suppose que les fonctions ne sont pas les mêmes.

[Tannis Dragon]

hummm

En faite je n'ai pas fait gaffe qu'il y avais une barre de défilement en dessous :D

Et l'erreur ne pourrait elle pas venir de " case(19):avatar = ham_CreateObj((void*)&Zergy_Bitmap,0,3,OBJ_MODE_NORMAL,1,0,0,0 ..."
Car tu as un "&" devant le nom "Zergy" et que le "&" sert normalement a un déférencement ...

de même "mode Tile", je ne vois pas trop ce que c'est... Car un sprite de 8*8 peut être considéré comme un Tile mais il n'ai pas placer dans le même emplacement mémoire que les Tiles qui servent pour les cartes.

Un sprite d'un Tile a 4 attribut qui lui permette de le définir par sa taille, sa dimension, sa position dans l'écran, ... (J'ai dit un Tile pour faire une comparaison avec celui de la carte)

Un Tile pour une carte fonctionne un peu de la même facon car il ne font que 8*8 mais au lieu d'avoir des attributs qui le compose en tant qu'objet, lui il a un tableau (donc la carte) qui le dispose a un endroit précis sur l'ecran, tu ne peux pas modifier sa taille, mais tu peux au moins l'inverser par un effet mirroir en horizontal et vertical. C'est un peux comme ci le Tile de carte n'avais qu'un seul attribut qui est stocker dans la carte au lieux de l'OAM. Et la position de stockage dans la carte indique à la GBA ou il doit être placé sur l'écran.

Maintenant le sprite qui a 4 Tiles qui le compose n'a toujours que 4 attribut (normalement vu que moi j'ai de gros soucie de ce coté là en mode 3 >( ), alors que 4 Tiles de carte auront 4 attribut aussi mais pour chacun d'entre eux.

Biensur tu a d'autre truc encore qui les différencie entre eux, mais au vu de ton prog c'est je pense l'essentiel.
(un peu brouillon peut être l'explication :whst: )

Maintenant a mon niveau, j'ai relue une dizaine de fois ton code et je ne vois plus rien qui pourrait te donné une piste, après il faut voir de la facon que les paramêtres sont placés dans la fonction ham_CreateObj... :)

De mon coter j'ai trouvé pour mon probleme...
l'erreur était la suivante :
sprite[0].attribut0 = 85 ;

(afin de positionner mon sprite a la position 85 vertical de l'ecran) il met bien 0x55 dans mon attribut et là il remet le bit 14 et 15 a 0 ce qui fait qu'il me met mon sprite avec seuleument mon 1 Tiles. M'en a fallu du temps pour le voir... J'ai trouver une parade peux pratique pour contourner le probleme.
Je fais un masque (sprite[0].attribut0 &= 0xFF00; ) puis je lui donne mon déplacement sprite[0].attribut0 |= 85;

Maintenant si quelqu'un connait une méthode plus courte pour le faire (je parle sans les lib de Ham) sa serais chouette car mon programme va prendre en longueur et aussi perdre en compréhension.... :)

[Meithal]

Le & désigne une adresse non?

Enfin c'est ce que j'ai cru, en modifiant quelques détails de mon code:

#include <mygba.h>

MULTIBOOT

//Fond

#include "gfx/aeriesguard.raw.c"

#include "gfx/aeriesguard.pal.c"


//sprites
#include "gfx/Aedan.raw.c"
#include "gfx/Aiua.raw.c"
#include "gfx/Aka.raw.c"
#include "gfx/Aldareis.raw.c"
#include "gfx/Andaheru.raw.c"
#include "gfx/Ertai.raw.c"
#include "gfx/Gameurjeux.raw.c"
#include "gfx/Kadrik.raw.c"
#include "gfx/Kit_Estivile.raw.c"
#include "gfx/Lebashar.raw.c"
#include "gfx/Licorne.raw.c"
#include "gfx/Lordsanglant.raw.c"
#include "gfx/Meithal.raw.c"
#include "gfx/Nick.raw.c"
#include "gfx/Nmind.raw.c"
#include "gfx/Picsou.raw.c"
#include "gfx/RaDgoo.raw.c"
#include "gfx/Sire_Lancelot.raw.c"
#include "gfx/Zergy.raw.c"

#include "gfx/avatars.pal.c"





int main(void)
{

//Variables
u8 image=0;
u8 touche=0;
u8 avatar[80];

ham_Init();

ham_SetBgMode(4);



//charge palette fond
ham_LoadBGPal((void*)aeriesguard_Palette,256);

//charge image de fond
ham_LoadBitmap((void*)aeriesguard_Bitmap);

//inverse le buffer
ham_FlipBGBuffer();


//charge palette avatars
ham_LoadObjPal((void *) avatars_Palette,16);



while(1)
{

void ham_ResetObj ();
ham_DeleteObj(0);

switch(image)

{
case(1):avatar[0] = ham_CreateObj((void*)&Aedan_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(2):avatar[0] = ham_CreateObj((void*)&Aiua_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(3):avatar[0] = ham_CreateObj((void*)&Aka_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(4):avatar[0] = ham_CreateObj((void*)&Aldareis_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(5):avatar[0] = ham_CreateObj((void*)&Andaheru_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(6):avatar[0] = ham_CreateObj((void*)&Ertai_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(7):avatar[0] = ham_CreateObj((void*)&Gameurjeux_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(8):avatar[0] = ham_CreateObj((void*)&Kadrik_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(9):avatar[0] = ham_CreateObj((void*)&Kit_Estivile_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(10):avatar[0] = ham_CreateObj((void*)&Lebashar_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(11):avatar[0] = ham_CreateObj((void*)&Licorne_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(12):avatar[0] = ham_CreateObj((void*)&Lordsanglant_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(13):avatar[0] = ham_CreateObj((void*)&Meithal_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(14):avatar[0] = ham_CreateObj((void*)&Nick_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(15):avatar[0] = ham_CreateObj((void*)&Nmind_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(16):avatar[0] = ham_CreateObj((void*)&Picsou_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(17):avatar[0] = ham_CreateObj((void*)&RaDgoo_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(18):avatar[0] = ham_CreateObj((void*)&Sire_Lancelot_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;
case(19):avatar[0] = ham_CreateObj((void*)&Zergy_Bitmap[0],0,3,OBJ_MODE_NORMAL,1,0,0,0,0,0,0,87,100); break;

//default:avatar = ham_CreateObj((void*)Aedan_Bitmap,0,3,OBJ_MODE_NOR MAL,1,0,0,0,0,0,0,87,100); break;
}
//ham_DeleteObj();
ham_CopyObjToOAM;

if(F_CTRLINPUT_LEFT_PRESSED || F_CTRLINPUT_RIGHT_PRESSED)
{
if(F_CTRLINPUT_LEFT_PRESSED)
touche=-1;
if(F_CTRLINPUT_RIGHT_PRESSED)
touche=1;

image=image+touche;

if(image == 0) image=19;
if(image == 20) image=1;
touche=0;
}





}

return 0;
}


/* END OF FILE */

Au moins, ca ne me dit pas que l'OAM est saturée, mais ca n'affiche aucun sprite ;(. Peut être en modifiant la priorité d'affichage...

[Tannis Dragon]

je viens de penser a une chose...
Tu créer des sprites en mode 4... OK, tu as du convertir tes avatars en tile... pour l'instant logique... Mais combien de tile différent compose ton avatar ????
Car en mode 4 tu est limiter avec les sprites.... Je sais que en mode 3 on n'a plus que 512 Tile disponible contre 1024 en mode 0 (et encore j'entend en mode 16 couleur là !!!)
Donc possible que tes avatars contienne trop de tile différent et d'une couleur de 256 ...
C'est une autre piste a creusé :)
Tu a raison au sujet du "&" c'est pour référencer mais aussi pour dire que l'on prend l'adresse de la variable :)

http://home.no/neogeo/HOVEDSIDE_INDEX/GBA_HOVEDSIDE_INDEX_ENGELSK/GBA%20HTML%20LEKSJONER%201-5/GBA_Lek3_english.htm

sur ce site il te montre un tableau de la plage mémoire pour les différents mode ;)

Sinon j'ai fait une petite recherche vite fait sur les librairie Ham et je n'ai pas trouvé vraiment de site ou il me parlait de la facon dont il faut marqué dans la fonction que tu utilise... Ne connaissant pas les paramêtre a pasé dans cette fontion pour créer des sprites je ne te suis pas d'un grand secour sur cela :whst:

[Meithal]

Je sais pas si c'est un problème de tiles. En tout cas, je ne crois pas m'en servir. Ce sont juste des sprites de 64x64 en bitmap 16 couleurs :)

[Tannis Dragon]

apparement il n'y a pas de raison a ce que sa sature au niveau de L'OAM, vu que tu enregiste 1 seul sprites à la fois et toujours au même endroit dans la mémoire et que celui ci ne fait que 64 tiles en mode 16 couleurs...

Bon alors tente cela, refais ton programme mais avec 1 seul sprite seulement. Puis quand tu l'emule avec visual boy advance vérifie dans Tools/OAM viewver si ton sprite est là. Déjà si celui ci n'ai pas là tu peux te dire que l'attribut de ton sprite dans L'OAM n'a pas été pris en compte.

Vérifie aussi dans Tools/Tiles viewver. clique sur 0x6010000 et regarde si tu vois ton sprite en petit morceau de Tiles (normalement décomposer en 64 morceaux), si tu ne le vois pas c'est que le sprite n'ai pas copier dans la mémoire. pour info celui ci doit etre copier a l'adresse 0x6014000.

Déjà avec ce petit test tu pourra un peut mieux cerner d'ou vient le problème ;)
Maintenant si tu vois ton sprite ... met un deuxieme sprite dans ton programme et regarde ce qu'il fait avant l'appuie de la touche puis apres l'appuie de la touche dans ces même menus. Tu verras bien si il remplace ton ancien sprite par le nouveau ou si il additionne celui ci et peut être par accumulation fait que la mémoire sature...

[Meithal]

Merci pour la méthodologie :)

J'ai grâce à ca enfin réussi à afficher un sprite sans faire planter le truc.

Reste plus qu'à les faire défiler :P

[Tannis Dragon]

Content d'avoir pu au moins t'aider un peu ;)

Au faite si tu trouve ton erreur (ou du moins la raison pour laquelle il te marquait sa), sa serais bien que tu le marque ici, je suis curieux de savoir d'ou venait le problème :D
Et puis c'est toujours enrichissant de voir le pourquoi du comment :lol:

Chose étonnant chez moi, je galère parfois pendant des semaines sur un problème, puis a bout d'énervement je pose ma question sur un forum et quelque jour après je trouve moi même la solution :lol:

Bon courage pour la suite :)

[Meithal]

L'erreur, c'est que j'ai codé comme un porc :lol: Du coup j'ai tout recommencé :)

L'erreur la plus probable dans mon ancien code était que la fonction d'affichage de sprite était comprise dans la boucle while principale ou qu'il n'y avait aucune fonction de retardement. Je suis en train de tout restructurer mais j'ai un truc qui me chagrine : pourquoi ici (http://www.afdac.org/prog/AFDAC_ProgrammationGBA_Jour02.pdf) par exemple, Ludovic déclare-il l'adresse du contrôleur d'affichage 0x04000000 en volatile? Les registres ne sont pas censés bouger, si? O_ô

[Tannis Dragon]

Volatile, je pense que c'est plutot parce que les bits a l'intérieur du registre peuvent être modifier par des éléments extérieur au programme de la GBA, par exemple le registre KEYS 0x4000130 qui est le registre des boutons, celui ci peut être modifier par un appuis extérieur donc le registre est modifiable par un élément extérieur au logiciel.
Par contre moi mon registre je les mis comme ca :
#define REG_DISPCNT *(u32*) 0x4000000
Et sa marche aussi bien :)