Week end SDL :) - Page 1

Salut les gens,

Quelques problèmes rencontrés au cours de mon dernier week end "Je m'emmerde, tiens si je codais ?" avec la SDL sur GP2X :

- le rendu des images affichés ( BMP pour le moment en 16 bits ) est extrémement saturé , comment faire pour avoir une image à peu près identique à ce que l'on a sur un écran de PC ? on peut trafiquer les images sous photoshop mais c'est du pifomètre, j'ai tenté d'utiliser le SetGamma de la SDL sans succès ( ça marche sous windows seulement ). Peut être qu'il n'y a pas de solution autre que de trafiquer les images mais par exemple les jeux tournant sous émulateurs me paraissent avoir des couleurs très proches des jeux d'origine, pas spécialement ultra saturés. Certain softs permettent de simuler l'affichage de certains types d'écrans TFT et d'apporter une correction sur l'image d'origine, mais ce sont souvent des outils Pro ( Optpix sur nintendo DS et son simulateur d'écran TFT ).

- Ensuite en jouant avec SDL_BlitSurface, j'ai trouvé que c'était particulièrement lent sur GP, j'ai fait un test de fade in fade out d'écran en jouant sur l'alpha de la surface source. Je me suis dit qu'on pouvait peut être activer le double buffering pour améliorer un peu mais visiblement ma GP bloque dès que j'essaie d'initialiser ce mode ( je me rends compte qu'un OGG tourne en même temps avec SDL_mixer, possible que ça plombe autant le framerate ?).

Du coup j'en viens à me demander quelle librairie utiliser pour faire quelque chose de fluide ( j'entends par là 60 fps pour des jeux 2D ), en fait il n'existe pas tant de solutions que ça, j'ai trouvé quelques exemples en C++ qui semblent utiliser la lib OpenGL en plus de la SDL, mais j'ai pas testé, j'avoue avoir pleins de problèmes de compilation et surtout de linkage quand il s'agit de tester ces diverses solutions ( GMath3D par exemple, pas moyen de compiler/linker ) sous DevC++.

Parfois j'arrive à compiler un projet SDL, je dupplique le projet dans un autre répertoire, j'inclue les mêmes fichiers et plus rien ne marche. Puis en rajoutant un -lSDL dans les options de linker d'un seul coup ça marche ( alors que le premier projet fonctionnait sans... ). Ou alors je tombe sur un "link error WinMain@16", il parait qye ça vient de l'ordre des options de linker, mais dans ce cas pourquoi ça arrive à certains moments et pas à d'autres ? J'ai l'impression que tout ça se joue au niveau du makefile généré pour chaque projet et pas forcément mis à jour d'une compile à l'autre. Quelqu'un pourrait-il m'expliquer comment marche un peu tout ça ? merci !!

En tout cas, je suis encore loin de réaliser un plateformer ^^;

Salut,

- Ensuite en jouant avec SDL_BlitSurface, j'ai trouvé que c'était particulièrement lent sur GP, j'ai fait un test de fade in fade out d'écran en jouant sur l'alpha de la surface source. Je me suis dit qu'on pouvait peut être activer le double buffering pour améliorer un peu mais visiblement ma GP bloque dès que j'essaie d'initialiser ce mode ( je me rends compte qu'un OGG tourne en même temps avec SDL_mixer, possible que ça plombe autant le framerate ?).

essaye d'utiliser le hack mmu qui booste pas mal (j'ai eu quelques probs de perfs sous SDL en portant mon moteur mais j'ai résolu en partie ses ralentissement grâce au hack mmu )

Pour les libs ta les minimals libs mais c'est beaucoup moins facile de les utilisers que SDL, je connait pas d'autres libs comme SDL sur GP2X, actuellement je porte mon moteur 2D (qui utilise SDL et plusieurs autres libraries) sur GP2X mais c'est pas encore totalement prêt.

Merci pour l'info ! je vais me renseigner un peu pour savoir concrétement comment ça s'utilise

pour avoir des infos sur le wiki page anglaises

Yopla

J'ai testé hier soir le MMU Hack, alors peut être me suis je planté dans l'ordre d'appel ( j'ai rajouté les 2 fonctions dans mon Main en appelant l'init du MMU Hack après le chargement de mes images, j'ai vu quelque part qu'il fallait le faire après que la mémoire soit allouée ), en tout cas pas de d'accelération significative. Au mieux j'ai vu que l'ogg bouffait pas mal de ressources, je sais qu'on peut balancer le playback son sur le deuxième proc mais moyennant un peu de code et un module à charger, pas réussi à compiler d'autres libs qui utilisent cette méthode...

J'ai chargé un module à la place ( pas forcément moins gourmand je sais pas ) ça marche sous Windows, sous GP ça passe pas. Possible que mes libs SDL Mixer GP2X soient pas up-to-date, j'ai utilisé pourtant un package récent fait par Emeric contenant DevC++ et la SDL. Je vais mettre la dernière version 1.2.8 ce soir du Mixer ( il me fallait un rpm browser pour extraire les fichiers libs et j'ai plus le net à la maison ^^ ).

Sinon il va falloir aussi faire un petit frame counter pour mieux me rendre compte de la consommation de ressources, la SDL_TTF me parait un peut compliquée ( format TTF , bof ), d'autres idées pour afficher du texte simplement ? Merci !

Bizarre ici ça booste pas mal ici (mais j'ai pas que l'affichage donc c'est peut être ça...)

Pour l'utilisation du 2° proc tu peux utiliser cette lib: http://wiki.gp2x.org/wiki/Rlyeh's_Minimal_Library_SDK l'exemple dual core est assez simple à comprendre

Pour le texte tu peux utiliser des fonts bitmaps ça prend beaucoup moins de ressources que les ttf, un ptit tuto dispo ici: http://ubuntu-gamedev.pbwiki.com/Using+Bitmap+Fonts+with+SDL

Merci pour les infos, je me penche là dessus

Hopla, je continue mes aventures

Je me suis fait un compteur de frame ( avec SDL_ttf finalement ) pour tester la rapidité d'exécution. Avec seulement une image affichée, pas de son, et l'affichage de 2 compteurs, je tourne à 40 fps en gros, ce qui me parait délirant ! Je pense pas que la SDL soit aussi naze niveau perf donc je soupçonne un problème dans ma chaine de prod. J'ai le package DevC++/SDL préinstallée téléchargé sur gp2xfr.info . Est ce possible qu'il manque des options et que le code du *.gpe ne soit pas optimisé ?

Dans l'absolu il faudrait que j'essaie de tout retélécharger à part ( SDL, DevC++, MingW32, linux_arm_gcc... ) mais je m'en étais pas très bien tiré la première fois ( idem avec l'utilisation de CodeBlocks où il faut récupérer des versions de l'espace pour avoir le dernier à jour... ).

Pour tenter d'avoir un point de comparaison je vais essayer de faire un programme équivalent ce soir en GLBasic découvert par Brainois, sinon si quelqu'un a une idée il est le bienvenu ^^

Tu utilise SDL_DisplayFormat après le chargement de ton image ? c'est une astuce qui boost pas mal le blit car l'image seras converti au format de l'écran avant le blit (genre si l'image est en 32bits SDL va devoir vérifier chaques pixels pour le convertir au format de l'écran à chaques blit) donc on gagne pas mal à utiliser cette fonction

SDL_Surface* nouvelle_image = SDL_DisplayFormat(image_charge); // optimise la surface
//gestion erreurs
SDL_FreeSurface(image_charge); // libére l'anciennne image

J'ai eu des bons retours aussi sur la fonction SDL_UpdateRect à la place de SDL_Flip quand l'application est pas en double buffering mais j'ai jamais testé

Hop

En fait j'initialise la VIDEO en 320*240*16 et les BMPs que j'utilise sont bien dans ce format là, Update_Rect semble ne pas attendre la VBL du coup les trashs graphiques s'accumulent, si quelqu'un sait comment attendre la VBL d'ailleurs, je crois pas avoir vu de fonction pour ça dans le doc de la SDL.

Merci pour ta réponse en tout cas

Hop

Après 2 weeks end laborieux, voici mon premier jeu réalisé en SDL pour Gepette (en fait mon premier jeu tout court) fait avec mes bribes de DUT info d'il y a 10 ans ( j'ai dévié tout de suite après le diplôme et je suis graphiste maintenant). Graphismes, code et son donc faits par mes soins, c'est une pré-version, il me reste quelques points à ajouter ou corriger mais on va dire que c'est quand même un Tetris bien avancé



Fichier joint : tetrablocks.0.2.GP2X.rar

Ca tourne sans problème sur F200 mais comme je n'ai pas réussi à compiler en static, il est possible que ça ne marche pas sur F100, donc si quelqu'un pouvait tester ça, merci

Salut, plutôt qu'un long commentaire, une image:

[URL=http://img367.imageshack.us/my.php?image=dsc00532rg5.jpg][IMG]http://img367.imageshack.us/img367/105/dsc00532rg5.th.jpg[/IMG][/URL]
Très bon jeu, rien à redire...

Ca tourne nickel sur une gp2x-F100 mk2 avec le firmware 3.0.0

Excellents graphismes

Pas mal les sons aussi en passant

salut ton jeux a l'air pas mal dutout je vais test quand mes piles seront chargées ... je suis étudiant (2eme année et bientot 3eme j'esperer ... j'attend mes résultats) en réseaux et telecom (bac+3 pour les français ou plutot bachelor ici en belgique)...

si j'ai le temps j'aimerais pendant la periode de vacance adapté un jeux que j'ai du réaliser en cpp mais pour ce faire je dois apprendre un peut à utiliser les lib sdl...