Version imprimable
Que cela soit en fullscreen ou fenêtré cela consommera toujours autant de ressources CPU.Citation:
Envoyé par Jyaif
Si tu fais du Direct X natif sans SDL de simples surfaces Direct Draw le problème sera le même.
Par contre fullscreen est bien plus rapide que fenêtré c'est normal l'OS a moins de processus visibles à gérer et moins de messages à redistribuer et moins de controles à redessiner ;)
Ben je sais que dans un set_video_mode je peux demander à SDL d'avoir une surface "SWSURFACE" ou "HWSURFACE", ce qui veut dire "ram centrale" ou "carte vidéo". Il y a aussi un flag pour le double buffering, si tu ne l'as pas activé tu risques d'avoir des problèmes puisqu'un SDL_Flip fait alors un SDL_UpdateRect,, qui est plutôt lourd si le rectangle est grand (comme par exemple tout l'écran). Le problème se pose aussi si ta carte vidéo ne peut pas gérer le double buffering.
Non mais j'ai essayer déja pas mal de chose, avec le double buffering et tout et tout ...
Je pense pas non plus que ca vienne de mon ordinateur puisque ca le fait pas que chez moi, mais c'est généralisé. Sinon, personne n'as un code d'une appli graphique windows qui utilise la sdl. Pour que je voit si il y a le meme probleme, et si c'est pas le cas, alors youpiiiiiiiii!
Parce que la, la seule solution, c'est de passer a openGl
ce que je vais faire je croit ...
si cela t'intéresse je peux te donner un morceau de code source avec chargement de bitmaps et appel à Direct Draw direct sans passer par SDL.Citation:
Envoyé par jkalzsmu
Tu pourras comparer la différence...:mouarf:
Tu ne peux pas trop optimiser avec SDL à moins d'aller bidouiller le code source de SDL....:roll:
Mais alors si la SDL n'est pas vraiment optimiser, qu'est ce que vous pouvez me conseiller? J'ai entendu parler de GLUT, mais ca se trouve c'est encore pire ...
On va dire que c'est de la propagande, mais je ne pense pas que tu puisses avoir tant de problème avec la SDL. Beaucoup programment avec et j'ai jamais vu un problème avec.Citation:
Envoyé par jkalzsmu
Il est vrai que depuis que ce fil a été créé je n'ai pas testé sous Windows le temps d'utilisation du CPU d'un programme basique mais cela m'étonnerait que tu sentes vraiment des ralentissements à la longue.
Je te conseille de rester sur la SDL, de bien mettre tes pilotes, tes bibliothèques à jour, je vais voir si un programme SDL vide prend autant de ressources sous mon Windows ce soir,
Jc
Merci, c'est sympa.Citation:
Envoyé par fearyourself
De toute facon, même si j'utilise openGL, il me faudras une librairie pour gérer les fenêtres. Donc, ca serait vraiment bien de régler ce probleme.
J'ai fait quelques tests :Citation:
Envoyé par jkalzsmu
- Avec SDL de base, le code de depart de Code::Blocks tourne effectivement chez moi avec 50% d'utilisation CPU
- Mon jeu de morpion, la derniere partie, tourne aussi avec 50% de CPU meme lors du calcul de l'IA.
- Le jeu de pong, avec 3000 balles et la gestion de collision, tournant avec SDL/OpenGL demeure a 40%
En conclusion, il est clair qu'une fenetre SDL normale utilise plus de ressources que la version avec OpenGL. De la a dire que la version SDL sans OpenGL soit inutile a utiliser est premature. Il faudrait faire un code plus lourd et voir si cela fait vraiment grimper l'utilisation CPU.
Enfin, une fenetre OpenGL/SDL n'utilise pas trop de ressources, on peut donc l'utiliser, a mon avis, sans crainte.
Jc
Donc finalement, l'ideal serait d'utiliser SDL pour la gestion (ouverture, fermeture des fenetre, clavier, joystick, etc...) ,mais utiliser openGl pour gerer l affichage a l interrieur de la fenetre.
Et puis pour le son, je pense qu il foit exister une sorte d'opengl de son?
OpenAL.Citation:
Et puis pour le son, je pense qu il foit exister une sorte d'opengl de son?