Je commence - Page 1

Bon pour commencer, j'ai décidé de me mettre moi aussi doucement à la prog sur gp32
J'ai fait pas mal de C++ (sur Unix) quand j'étais étudiant mais rien depuis, ceci dit j'ai de bons restes

J'ai suivi le tuto pour installer gcc pour gp32 sous Linux (pas de win chez moi): ça roule
MAIS
l'exemple de Makefile avec gcctest ne va pas jusqu'au bout, ça plante sur b2fexec:
"** Error: failed to open file 'Test.bin'.."
Pourtant Test.bin est bien apparu dans mon rep gcctest ...
C'est parce que j'utilise pas Debian ? :'(

Sinon une fois ce petit pb résolu, par où commencer ?
Utiliser SDL comme base est-ce une bonne idée pour gp32 ? (je veux dire: ça tourne suffisamment bien pour avoir un résultat correct ?)
Ou faut-il absolument utiliser des librairies proprio pour faire qch ...

Merci

pour ton blemme je c pas,
pour sdl, ben c lent vu que c une surcouche mais elle possede des fonction de blit en asm rapide donc sa compense
le sdk gp est suffisant pour la plupart des petit jeux, apres si ta besoin de bc de vitesse, trouve autre chose ^^

pour ton pb revoie les paths

Merci pour les réponses
Je compte bien utiliser SDL pour commencer en suivant le tutorial sur gp32news.


hum, b2fexec est bien dans /usr/bin puisqu'il se lance tout seul,
d'ailleurs quand je suis dans /usr/share/doc/sample-gp32/gcctest, si je lance en direct:
b2fexec Test.bin
j'ai le même msg d'erreur ... Pourtant Test.bin est dans mon rep courant ... Idem avec ./Test.bin et $PWD/Test.bin ...
je pense plutot à un pb du prog lui même ...

Y a-t-il d'autres versions de bf2exec ? (ou même les sources, que je le recompile pour ma distrib ...)

Sinon j'ai vu qu'il existe aussi GDL, quels sont ses avantages/inconvénients ?

le site de spiv (et donc de b2fxec) : http://www.deadcoderssociety.tk/

gdl est tres simple a utiliser, elle utilise le sdk gp, donc coté performance y a mieux mais c suffisant pour la plupart des jeux.

va voir les demo pour voir ce quelle peu faire. http://procvor.free.fr/gdl/

Haaa merci pour tout ça, un peu de lecture pour m'occuper

Sinon encore une question qui peut paraitre un peu prématurée:
y a-t-il des choses particulières à éviter en C/C++ pour GP32 pour ne pas dégrader trop les perfs ?

Des types de variables privilégiées (genre utiliser des double au lieu de int), des fonctions standard à éviter (connues pour être lentes sur cette architecture) ?

evite les floats! deja ca sera bien, sinon les fonctions standard a evite a peu pres toutes(d apres Orion celle d affichage est 2 fois trop lente!) mais bon si tu utilises pas le SDK bon courage ^^

euh moi aussi je commence et g un blem avec minigp32, je suis en train de suivre le tutopr l'install sous windows, j'arrive a compiler en exe, mais qd j'edite le makefile pr avoir un fxe, qd je recompile, j'ai "***missing separator" ca ve dire koi ca? g fait exactement ce k'a dit le tuto, vs pouvez m'aider svp , note je suis sous win2kpro

pour le missing separator il faut mettre une tabulation devant la ligne concernée.
le pb a été maintes fois résolu et dit sur ce forum notament dans un post très récent.

pour le pb de bin2fxec, édite ton makefile et remplace le par bin2fxe

en effet il semble que la version des gcc linux cafouille à ce niveau. j'en ai parlé à Mr Spiv qui a dû recompiler un nouveau bin2fxec, donc télécharge le dernier et essaye le.
Mais bin2fxe fonctionne sans pb.

merci pr la reponse et dsl si ca été déjà dit, mais maintenant g un otre problem :P, j'utilise minigp32-2 et gdl mais apparement ya plein de blem avec des fcts 16 bits, je pense tout simplement kils les trouve po, vs savez ou je pourrias les download? merci, et dsl si c'a a étét évoké, mais je promets ke g regarder les topics et ya po la réponse

dans ton makefile vérifie que tu appelles bien les librairies graphiques :
-lgpgraphic16.a -lgpfont16.a

pour les questions maintes fois posées c'est pas grave, je vais prendre mon courage à 2 mains et faire une faq

tien un petit truc qui t aidra si tu veux utiliser les virgule fixe

typedef long fixed; // Our new fixed point type.

#define itofx(x) ((x) << 8) // Integer to fixed point
#define ftofx(x) ((x) * 256) // Float to fixed point
#define dtofx(x) ((x) * 256) // Double to fixed point
#define fxtoi(x) ((x) >> 8) // Fixed point to integer
#define fxtof(x) ((float) (x) / 256) // Fixed point to float
#define fxtod(x) ((double)(x) / 256) // Fixed point to double
#define Mulfx(x,y) (((y) * (x)) >> 8) // Multiply a fixed by a fixed
#define Divfx(x,y) ((y << 8) / (x)) // Divide a fixed by a fixed

Merci pour tout ça, en remplaçant b2fexec oar b2fexe ça marche parfaitement

Je reprend donc l'exemple "gcctest" comme base pour commencer.

1er problème

Je lance la compil de mon programme, et on dirait que ça plante dans le SDL:

arm-thumb-elf-g++ -c -Wall -mcpu=arm9 -mthumb-interwork -msoft-float -O2 -g -o gpmain.o gpmain.cpp
In file included from /home/albator/gp32dev/sdl/libc-wrap/stdio.h:4,
from gpmain.cpp:7:
/home/albator/gp32dev/sdl/libc-wrap/gpwrap.h: In function `char* strdup(const
char*)':
/home/albator/gp32dev/sdl/libc-wrap/gpwrap.h:173: invalid conversion from ` void*' to `char*'

La fonction en question:

static inline char *strdup(const char *s)
{
char *ret=NULL;
size_t l=strlen(s);
if (s>0)
{
ret=calloc(l+16,1);
strcpy(ret,s);
}
return ret; }

Je fais comment moi ? :'(
(la ligne 173 c'est celle avec le calloc)

Hum je commence à comprendre, dans l'exemple donné avec SDL, le code inclue gpstdio.h, gpstdlib.h etc ... Alors que moi j'inclue stdlib.h, stdio.h ... contenus dans le rep libc-wrap ...

Qqn sait à quoi servent les headers dans le rép libc-wrap de gpsdl ?

Autre chose, dans le GP32 cross toolchain, j'ai bien le fichier include/string.h , mais il manque des fonctions genre "atoi" ... C'est normal, où elle se situe ailleurs ?

Merci

aïe !aïe !aïe !aïe !aïe ! Tu commences direct avec du C++
le g++ est - conciliant que gcc. Du coup il y a des fonctions à redéfinir si tu t'embarque là dedans. Surtout ce qui est pointeur...Par exemple le gpstart.c est carrément à réécrire.

les includes dans le libc-wrap sert de wrapper, de passerelle vers les includes habituelles d'entrée sortie et standart.
Tu n'as donc rien à toucher, les includes des librairies GP sont autonatiquemnts inclus dans le gpwrap.h. Dès que tu inclus stdio.h ou sdtlib.h, ces 2 fichiers font appel au wrapper gpwrap.h où les inclused propre à la gp32 sont appelées.

atoi n'est pas une fonction ANSI C, donc pas forcément incvlu dans toutes les libs. Ici elle n'y est pas. Il faut donc l'écrire toi m^me.

dans un poste récent tu trouveras un début de code que jai posté et qui devrait être suffisant dans la plupart des cas.
les conversions de chaine de caractères s'effectue grâce à sprintf()

pour l'erreur de ta compil je remplacerais les static inline.

Si ton prog peut être converti aisément en C, compile le avec GCC
Désolé mais en c++ je suis une bille

En fait c'était un pb de cast, effectivement ça compilait avec gcc mais pas avec g++
J'ai juste eu à faire:
ret=(char *)calloc(l+16,1);
Et hop ça marche en C++ ...

En regardant le libc-wrap j'ai vu qu'effectivement il "redirige" vers les librairies du sdk gp.
Par contre ce qui me gène en l'utilisant, c'est que include <stdlib.h> va donc me rediriger vers <gpstdlib.h>, or j'ai aussi un "vrai" stdlib.h fourni avec arm-cross-toolchains ... Du coup je sais jamais trop si je dois utiliser les librairies officielles GP ou bien le toolchain ...

Sinon oui j'ai écrit moi même un atoi, mais ça m'ennuie quand même de devoir réécrire plein de fonctions "usuelles" en C++ (des strnXXX pour la plupart).

Quand au choix C/C++, en fait je n'ai jamais fait de C, toujours que du C++ alors ...

moi ce que j aurais le plus peur cela serais les pointeurs fou ....