). C'est un simple algo bête et méchant.
GoldenCrystal (./28) :
./25 > Le truc c'est qu'un timer n'aura jamais une précision suffisamment bonne pour te permettre d'obtenir un rendu fluide.
Pour avoir un truc fluide, il y a d'autres méthodes, plus simples qu'un timer.
En fait, il suffit de compter le temps dans ta boucle principale. Avec un API précis bien sûr… Il te faut au moins une précision de l'ordre de 10ms, mais si tu peux avoir 1ms c'est encore mieux ^^int lastTime = …; // Obtenir le temps de référence (je suppose qu'on compte en millisecondes dans cet exemple) int newTime; int desiredInterval = 1000 / 60; // Si tu vises 60 FPS while (loop) { do { usleep(1); // Sleep(1) sous Windows… Tu as peut-être même un équivalent portable SDL ? … // Gestion des évènements newTime = …; // Obtenir le temps actuel } while (newTime - lastTime < desiredInterval); // On répète la boucle d'évènements tant qu'on a pas attendu assez newTime += desiredInterval; // On incrémente le temps de référence de la durée d'une frame fixe. … // Rendu }Par contre cet algo ne gère pas le frameskip. C'est pas forcément dur à ajouter, mais tu n'en auras pas besoin au début.
./27 > Et tu as raison !
Un truc qui bloque toutes les autres opérations sur le système même quand il fout rien, c'est ultra chiant…
Godzil (./31) :T'auras un peu plus de changements de contexte, mais rien de trop dramatique non plus…
Le probleme avec cette boucle, c'est que tu va consommer plus de CPU qu'il ne faut..
il vaux mieux partir sur (comme l'indique le siteduzero, meme si je n'ai aps fait comme ça moi ^^) une base de temps, ie 30ms d'attente, de mesurer le temps que la boucle a prise, et mesurer le temps reel de l'attente et au prochain cycle, avec le delta, fait (30ms + delta) etc...
!!!!!!!!!!!!!!!!!!!!!!!!!!!)Zerosquare (./32) :
Euh, il me semble qu'on peut faire de l'événementiel pur avec SDL, sans devoir utiliser ce genre de hacks crades.
Zerosquare (./32) :
Et de toute façon, un jeu digne de ce nom est synchronisé avec le refresh de l'écran
).Zerosquare (./32) :
vérifier les événement une fois par frame c'est bien suffisant
Zerosquare (./32) :Mais mes recherches google ont suggéré que SDL ne permettait pas de gérer le vsync dans tous les cas, donc je n'ai pas proposé cette option, et j'ai montré l'option de la limitation de FPS manuelle.
Et de toute façon, un jeu digne de ce nom est synchronisé avec le refresh de l'écran, et vérifier les événement une fois par frame c'est bien suffisant
GoldenCrystal (./33) :Godzil (./31) :T'auras un peu plus de changements de contexte, mais rien de trop dramatique non plus…
Le probleme avec cette boucle, c'est que tu va consommer plus de CPU qu'il ne faut..il vaux mieux partir sur (comme l'indique le siteduzero, meme si je n'ai aps fait comme ça moi ^^) une base de temps, ie 30ms d'attente, de mesurer le temps que la boucle a prise, et mesurer le temps reel de l'attente et au prochain cycle, avec le delta, fait (30ms + delta) etc...
Oui mais dans la pratique, le temps que va prendre ta gestion des événements est totalement indéterminé, et on compte des trucs de l'ordre de la milliseconde. 1000 / 30 ça fait déjà que 33 FPS au maximum (donc moins dans la réalité).
Tu ne peux pas te permettre d'attendre trop, ça va détruire le jeu.
Un sleep(0) ça n'épargne pas l'usage du CPU, mais ça permet au système de rester fluide. Un sleep( > 0 ) ça va permettre au système de rester fluide, et peut-être même réduire l'utilisation CPU (si c'est possible).
Pour 60 FPS, t'as que 16,6 ms entre deux images, c'est à dire presque rien. Avec une granularité en millisecondes, tu ne peux clairement pas te permettre de faire joujou avec des durées de sommeil variables.
Je rapelle d'ailleurs que un sleep a pour garantie de dormir au moins la durée indiquée (sauf exception genre le programme se fait tuer, etc.), mais ne te spécifie en aucun cas que tu vas dormir exactement la durée spécifiée. Ça sera toujours supérieur.
En plus, mesurer le temps pris par la boucle est une aberration. Tu ne peux pas prédire combien de temps prendra l'abération suivante. Tu vas ralentir le jeu parce que tu as présumé que la prochaine itération allait prendre que 1ms parce que c'était le cas de la dernière, mais en vrai la suivante va faire 20 ms, donc tu auras attendu en réalité (29+20 = )59 ms… Tu me suis ? En gros y'a une frame qui s'évapore dans la nature, sans aucune raison valable.
S'il y a un truc à ne jamais faire, c'est justement ça.
Au même titre que les timer, les sleep ne sont pas (jamais) une source de temps fiable.
Economiser le CPU oui, mais pas au détriment de la réactivité du jeu.
)#include <SDL/SDL.h>
#include <SDL/SDL_image.h>
#include "data.h"
void SetCursor(DATA *Data, const char * Filename)
{
// Free the current cursor if it exists
if (Data->CursorSpr != NULL)
SDL_FreeSurface(Data->CursorSpr);
// Load the new one
Data->CursorSpr = IMG_Load(Filename);
}/* Convenience functions */
extern DECLSPEC SDL_Surface * SDLCALL IMG_Load(const char *file);
extern DECLSPEC SDL_Surface * SDLCALL IMG_Load_RW(SDL_RWops *src, int freesrc);
) à la ligne de commande de gcc.GoldenCrystal (./40) :
(Même chose pour Brunni)
), mais comme Godzil je ne me fais pas trop de souci pour ma méthode de gestion du frameskip, elle donne les mêmes résultats sur de faibles configs que les meilleurs émulateurs que j'ai vus (et on peut imaginer que leurs impléms sont justement très bonnes car c'est critique pour l'expérience de jeu 
).
Normalement, il faudrait utiliser des sémaphores ou des attentes de type select pour gérer ça proprement, eux, ils se contentent de bloquer avec SDL_Delay(10); dans une boucle. 
(D'ailleurs, un de mes TODOs est d'utiliser la minizip système dans la libcalcfiles.)[/li][li]personnellement, je te conseillerais la libarchive qui gère le format tar, et qui peut aussi être combinée avec des libs de compression comme zlib, libbzip2 ou xz-utils (cette dernière étant la meilleure solution). Cette lib est utilisée entre autres par KDE et GNOME dans leurs archiveurs graphiques et la licence (BSD sans "advertising clause" à la con) est compatible avec la GPL.[/li][/ul]Kevin Kofler (./52) :Heu excuse moi mais le principe d'un « Wait » quelconque n'est il pas d'attendre que quelque chose se produise ?
En principe, la solution propre pour la boucle d'évènements, c'est d'utiliser SDL_WaitEvent à la place de SDL_PollEvent.
Cela dit, l'implémentation n'est pas optimale non plus.Peut-être qu'il n'y a pas de façon simple de gérer ça de manière unifiée sur toutes les plate-formes ?Normalement, il faudrait utiliser des sémaphores ou des attentes de type select pour gérer ça proprement, eux, ils se contentent de bloquer avec SDL_Delay(10); dans une boucle.
(Mais il faut bien garder en tête de ne pas utiliser des archives solides pour un jeu par contre ! ZIP ne gère pas ça donc ça évite le problème)GoldenCrystal (./54) :
Serais-tu en train de supposer qu'un événement doit forcément se produire à chaque frame ? Car si tel est le cas je t'arrête tout de suite: tu rêves.
Peut-être qu'il n'y a pas de façon simple de gérer ça de manière unifiée sur toutes les plate-formes ?
Folco (./49) :
Quand on fait des graphismes, on se retrouve vite avec plein de petits fichiers d'images dans tous les sens.
GoldenCrystal (./54) :
Kevin Kofler (./52) :Heu excuse moi mais le principe d'un « Wait » quelconque n'est il pas d'attendre que quelque chose se produise ?
En principe, la solution propre pour la boucle d'évènements, c'est d'utiliser SDL_WaitEvent à la place de SDL_PollEvent.
Serais-tu en train de supposer qu'un événement doit forcément se produire à chaque frame ? Car si tel est le cas je t'arrête tout de suite: tu rêves. Le seul cas où une fonction comme ça pourrait être utile, c'est quand le jeu est en pause. Là oui, tu ne veux probablement pas vérifier les événements en boucle, ni redessiner le jeu en permanence. Et encore, y'a plein de jeux ou tu veux qu'il se passe des trucs quand le jeu est en pause (si tu joues en réseau, que tu as un menu de pause avec des animations, etc.)
Jyaif (./56) :Folco (./49) :
Quand on fait des graphismes, on se retrouve vite avec plein de petits fichiers d'images dans tous les sens.
Tu peux aussi regrouper des images dans une seule, que tu découpe toi même plus tard en software.
