1

Bonjour,

une petite question de programmation. Savez-vous où trouver des ressources précises sur la GP2X (F200) pour faire du code sans passer par une librairie type SDL ? Du genre, si la mémoire de l'affichage est linéaire (j'espère), à quelle adresse mémoire, comment initialiser un mode graphique, quels sont les possibilités, etc. Bref une bible du codeur sur GP2x.

Je n'ai jamais été un vrai fan des librairies toutes faites qui font un code de 100Ko pour afficher un point là où y'a besoin que de 4 octects... Et pour le fun c'est plus comme ça que je souhaiterais programmer des tout petits trucs sur la GP2x.

Merci d'avance.

2

J'ai trouvé le minimal sdk de ryleh, ça semble beaucoup mieux (à mon sens) que SDL (pour le code code optimisé, sinon nettement moins portable smile), mais c'est pour Linux a priori (et linux ne tourne pas encore sur ma machine).

Y'a du mieux, mais c'est pas encore ça : donc si vous avez les infos ci-dessus, je suis toujours preneur !

3

Bon, je potasse le minimal lib SDK de ryleh, y'a tout dedans (à priori) smile

4

Vu qu'il est impossible de s'enregistrer sur le forum de ryleh, qu'il ne laisse pas d'email, rien, quelqu'un pourrait-il me mettre à disposition la version 0.C de sa minimal lib sdk, qui serait disponible en preview (mais pas dans ses files sur son site) ?

Merci !

5

sur le forum anglais t'as essayé ? gp32x.com smile
avatar
Tout probleme a sa solution
Oeil de feu

6

nope, mais faut le trouver... je vais voir ça.

7

Salut,

Tout dépend de ce que tu veux faire , mais sur le wiki y'a quelque information concernant la prog comme accéder au buffer video par exemple, et pas mal d'autre truc: http://wiki.gp2x.org/wiki/Development_Tutorials

il y a plein de doc ici : http://wiki.gp2x.org/wiki/Docs_and_Papers

je te conseille tout particulierement la doc du mmsp2 si tu veux vraiment attaquer le hard , c'est la bible smile http://mudiweb.com/gp2x/MP2520F_Manual_Eng_V1.0.pdf.


et bonne chance....
/ukko
avatar

8

Merci. J'avais récupéré la doc du mmsp2, pas encore eu le temps de la parcourir. De même, pas réussi à trouver la minimal lib 0.C de ryleh (ni un moyen de le contacter !). Quelqu'un aurait ça ?

9

la lib c est plus lente que la lib b actuellmeent car la c est en test et qu'elle contient les ligne de debug.

10

Merci pour l'info. Mais j'ai vu qu'elle gère bien plus de choses, d'où un certain intérêt. Et accessoirement, je compte ré-écris tout l'aspect écriture vidéo, pour tenter d'optimiser au max cet aspect (vieux réflexe d'une vie antérieure), quitte à apprendre un peu l'asm arm.

11

s9rStef (./8) :
Merci. J'avais récupéré la doc du mmsp2, pas encore eu le temps de la parcourir. De même, pas réussi à trouver la minimal lib 0.C de ryleh (ni un moyen de le contacter !). Quelqu'un aurait ça ?


je doit avoir ca quelque part, ryleh me l'avait envoyé. je te tiens au courrant..
avatar

12

Super ! Merci.

En fait, j'avais l'habitude de la prog à l'époque 486, où on faisait tout à la main sous Dos. Un pointeur sur le framebuffer d'un côté, un buffer en mémoire ailleurs et on copiait l'un vers l'autre. LA RAM était carrément plus rapide que la RAM Vidéo.

Sur la GP2x, c'est comment ? RAM dédiée pour la vidéo, plus lente ou pas en écriture et/ou lecture ?

13

nan il n'y a pas de memoire spécifique a la video, c'est le pointeur video qui accede a la Ram,
ce pointeur pointe vers un endroit bien précis(defini par linux il me semble) , d'ailleur y'en a plusieur, ce qui te permet d'avoir un un front et un backbuffer que tu affiche une fois rempli , ca te permet de fliper entre 2 buffers.
je crois que tu peux modifier l'adresse du pointeur video , ca peut te permetre de faire un scrolling par exemple en n'ayant qu'a modifier l'adresse du pointeur video.

en ce qui concerne la vitesse de la RAM , c'est assez lent, meme super lent je trouve , c'est un peut le goulot d'etranglement de la GP2x . tu devras donc jouer avec le cache et les intructions de ecriture/lecture de lots (stmia..) propre a l'ARM.

puis si il te reste un peut de courrage tu as les DMA et le BLITTER pour gerer les déplacement de mémoire smile et ca c'est pas super documenté.

donc si tu aime bien faire les truc a la main bienvenue ..

/ukko
avatar

14

Je viens de chercher un peu, le coup des flip(), où c'est l'adresse de la zone affichée qui change, c'est carrément énorme (je découvre un truc vieux de 10 ans car je n'étais plus dedans smile). Ca change de l'époque où on faisait des copy dword en déroulant au max les boucles...

Modifier le pointeur, je n'en ai pas l'utilité maintenant, mais c'est effectivement excellent aussi, ça.

Pour la RAM, c'est un peu ballot ça, faire une console de jeux avec un élément aussi lent, c'est antinomique ! Le cache est de combien, si tu sais, sur le proc ? Pour le blitter, c'est un peu utile de savoir y accéder, sinon ça va vite ramer.

Je creuse petit à petit, j'espère que j'arriverai quelque part smile

Sinon, mon gros souci c'est les sons/musique. Là, je ne vais pas le gérer moi-même, j'en suis incapable. Une idée sur quoi utiliser pour ça ? Possibilité de mettre ça sur le 2eme proc pour libérer le cpu ?

15

tu as 16ko de cash sur le 920 et 4ko sur le 940, si tu travailles avec le cash regarde les instruction ARM , il y a des instruction pour le gere (flush..)

pour la music c'est pas super documenté, et c'est bien dommage car il y a une vrai carte son a l'intérieur de la GP2X, les libs dispo ne sont pas super optimisée, moi j'utilisais celle de DZZ qui permetait de jouer un .OGG sur le 940, mais meme avec cette lib tu perts encore 15-20% du temps cpu du 920 sad , car d'apres ce que j'ai pu voir le 940 decode le flux mais le c'est le 920 qui fait les transfert mémoire sad
ca reste quand meme la lib la plus intéréssante.
avatar

16

bon bin ça promet, là j'en suis encore à monter mon environnement de dev. Un bête test de compilation avec la SDL, juste pour afficher une image, ça fait déjà 500Ko ! au secours. En revanche j'ai des petits soucis de compilation avec la mini lib de ryleh, elle compile pas, j'ai des erreurs... faut que je creuse, c'est peut-être un truc bête.

17

j'ai fait pas mal de tests de performances ce week-end pour de simples affichages de pixels, et j'ai été surpris de voir que la SDL donnait de meilleurs perfs que la mini lib (je n'ai que la version 0.b)
est-ce que j'ai loupé quelque chose ? est-ce qu'il y a des améliorations au niveau affichage dans la 0.c ?

18

Quel type de tests en fait ? Faut faire gaffe au cache si tu fais des trucs trop simples...

19

comme je disais, rien de spécial, écritures dans le buffer vidéo puis flip
je vais faire des tests avec mesures prochainement
tu aurais la version 0.c toi ?

20

non, je ne l'ai pas.
Optimisations de base à faire : écriture par dword, déroulage de boucle (trouver la limite avec le cache), virer les opérations complexes (virer les multiplication par 320 par exemple).

21

La SDL de Paeryn utilise les acceleration hardware, ce qui explique peutêtre ca plus grande velocité que la minilib.
Pour ce qui est des acces memoire, ce n'est pas si catastrophique, surtout qu'il est possible de tuner tous cela pour donner un bon coup de boost.
Pour les 500Ko de taille pour un simple test SDL, je vois pas le problème. C'est le prix à payer pour la convivialité du dev. De plus, la console ayant 64Mo, ce prix est tres faible.
Si c'est pour faire des demo type 64Ko, il y a de tres bon tuto de la part de Dzz sur gp32x.com