Performance d'un jeu en 2D
J'ajouterais que cette histoire de delay() m'a toujours parue louche car par définition, le flipbuffers() est sensé le faire, et même mieux, puisque le flipbuffers(2) utilise un timer.
Par contre, en mode fenêtré il ne faut pas oublier de traiter les événements, et en plein écran de gérer la perte de focus avec IsScreenActive() (ce que je ne vois jamais dans vos codes)
Par contre, en mode fenêtré il ne faut pas oublier de traiter les événements, et en plein écran de gérer la perte de focus avec IsScreenActive() (ce que je ne vois jamais dans vos codes)
Flipbuffers(2) ne fonctionne que sous plein écran.
Du reste, c'est vrai que gérer la perte de focus est intéressant pour les boucles qui attendent un entrée keyboard, mais reste que pour un jeu, il est supposé continuer à tourner, même en arrière-plan (les ennemis, etc ..., en tout cas je préfère ça pour un jeu en mode fenêtré).
Du reste, c'est vrai que gérer la perte de focus est intéressant pour les boucles qui attendent un entrée keyboard, mais reste que pour un jeu, il est supposé continuer à tourner, même en arrière-plan (les ennemis, etc ..., en tout cas je préfère ça pour un jeu en mode fenêtré).
c'est pas plutôt un problème de directX sa ? j'avais remarqué ceci sous DB pro il y a quelques année et c'est ce qu'on m'avait expliqué.djes a écrit :Le problème vient surtout que quand tu perds le focus, tu es bon pour recharger tes sprites, car sur certaines cartes graphiques la mémoire vidéo est corrompue.
Dernière modification par cha0s le lun. 16/mars/2009 17:29, modifié 1 fois.
Sous Windows, c'est DirectX qui gère ça ; mais comme sur certaines cartes il n'y a pas de souci, j'en déduis que ce n'est pas lui qui est en cause, puisqu'il avertit le programmeur que les ressources sont perdues. Mais je ne suis pas sûr.cha0s a écrit :c'est pas plutôt un problème de directX sa ? j'avais remarqué ceci sous DB pro il y xa quelques année et c'est ce qu'on m'avait expliqué.djes a écrit :Le problème vient surtout que quand tu perds le focus, tu es bon pour recharger tes sprites, car sur certaines cartes graphiques la mémoire vidéo est corrompue.
Exactement! Merci d'avoir testé. En fait, on se provoque un peu, mais on avance... Exactement : elle n'est pas fiable à 100%, parce que je n'ai qu'un 1 GHz "mono-coeur". Elle marche parfaitement bien chez moi, alors que sur le tiens, (2 coeurs) la fiabilité de ce code est anéantie.Norswap a écrit :Donc ta formule, même si très liée à la réalité, ne me semble pas fiable à 100%. Elle est même décalée puisque d'après elle un Delay(16) devrait me donner 32ms alors qu'il ne m'en donne que 16 et qu'un Delay(32) devrait me donner 48ms alors qu'il m'en donne que 32.
La raison est simple : "à vide", c'est-à-dire sans grandes ressources consommées en arrière-plan par d'autres tâches, voilà ce qui se passe (je spécule, n'ayant pas de double-coeur sous la main):
1) Ton application laisse la main à l'OS (Delay(1) )
2) L'OS indique que le CPU 1 cesse d'exécuter ton appli temporairement
3) Mais!!! Le CPU 2, lui ne branlait rien!! Résultat: à peine tu as rendu la main à ton OS, qu'il te la rend illico avec l'autre CPU!!! D'où une valeur à 0 ms pour un Delay(1)...
@ChaOs
Quand je vois les performances que Linux affiche, je me dis que XP c'est vraiment une machine à gaz! Par contre, tu as trouvé une valeur de 1 ms sous Linux. Est-ce que tu peux faire une boucle de ce type :
Code : Tout sélectionner
For I.I = 1 To 40
Depart.I = ElapsedMilliseconds()
Delay(I)
Fin.I = ElapsedMilliseconds()
Debug Fin - Depart
Next I
Je pense aussi qu'il faut que l'on mouche ce problème. "On" s'est arrêté parce que l'on pensait que les paramètres étaient trop nombreux. Mais, en tant que possesseur d'une des plus grosses daubes matérielles et logicielles du moment, je vous l'infirme :Beauregard a écrit :Un post spécial Delay() serait le bienvenue pour débattre du truc afin qu'on en finissent une fois pour toute avec cette commande, qu'en pense-tu Dobro ?
Seul le type d'OS et le nombre de CPU compte réellement dans la compatibilité entre une très grosse bécane multi-coeur sous Linux (Y'a pas photo, c'est le most) et une petite bécane mono-coeur sous XP.
[/quote]
Intéressant tout ça...
Je ne savait pas qu'il y avait tout ça derrière un petit delay() !
Cette histoire de delay() n'est pas anodine, l'année dernière suite à une mauvaise lecture de contrat
, j'ai dû acheter cinq jeux chez bigfishgames ! Bilan, les concepteurs ont complètement négligés cet aspect : sur la page des menus où rien ne bouge, le CPU est déjà à fond (ainsi que le ventilo!). En plein jeu(type "hidden objects"), il y en a même un qui plante sérieusement en cas de double-clic trop musclé (The count of monte cristo). Pour tous, quand le jeu tourne, il faut verser de l'azote liquide sur le processeur
!
Quant à l'article
http://www.nofrag.com/2003/nov/24/8629/
Ce concept est révolutionnaire!
Un graphiste en a-t-il déjà tenu compte lors de la création de ses planches de sprites ?
Hasta la vista !
Je ne savait pas qu'il y avait tout ça derrière un petit delay() !
Cette histoire de delay() n'est pas anodine, l'année dernière suite à une mauvaise lecture de contrat



Quant à l'article
http://www.nofrag.com/2003/nov/24/8629/
Un bon sprite est un sprite flouCet effet de flou est tel qu'au cinéma, 18 images par seconde suffisent à rendre les mouvements fluides

Ce concept est révolutionnaire!
Un graphiste en a-t-il déjà tenu compte lors de la création de ses planches de sprites ?
Hasta la vista !
@Olivier
Comme tout bon scientifique (enfin il parait) la première chose que j'ai fait c'est de tester sur un grand nombre d'itération pour savoir si les résultat sont constant et il le sont ce qui ma valut d'attendre 15minute les résultats sous Windows alors que 1 minute a suffit a Linux xD.
me donne 1 et ton code me donne un décompte de 1 a 40
Comme tout bon scientifique (enfin il parait) la première chose que j'ai fait c'est de tester sur un grand nombre d'itération pour savoir si les résultat sont constant et il le sont ce qui ma valut d'attendre 15minute les résultats sous Windows alors que 1 minute a suffit a Linux xD.
Code : Tout sélectionner
#boucle = 100000
Debut.l
Debut = ElapsedMilliseconds()
For n = 1 To #boucle
Delay(1)
Next n
Debug (ElapsedMilliseconds() - Debut)/#boucle
heu! beauregard!! le delay(10) ca me servais a debugger et le 20 pour calmer le processeur a la fin du jeu!
sinon j aime pas le delay
les ordinateurs ne vont jamais assez vite pour moi, alore je ne vois pas pourquoi j irai y foutre des delay dedants
comme le dit djes mon delay c' est le raffraichissement de l' ecran
donc la vitesse du jeu est constante a 60 herz ,meme si vous utilisez
un 8088!
sinon j aime pas le delay


comme le dit djes mon delay c' est le raffraichissement de l' ecran
donc la vitesse du jeu est constante a 60 herz ,meme si vous utilisez
un 8088!
Un bon sprite qui se déplace, en effet est un sprite correctement flouté. Par contre le graphiste n'a pas trop à gérer ça je pense.Huitbit a écrit :Un bon sprite est un sprite flou
Ce concept est révolutionnaire!
Un graphiste en a-t-il déjà tenu compte lors de la création de ses planches de sprites ?
En fait, il doit y avoir quelques termes techniques avec lesquels j'ai une ignorance totale.
Mais le plus simple est de regarder une cassette video sur un vieux VHS. Un arrêt sur une image en mouvement n'est jamais net en réalité. La caméra analogique enregistre avec une "persistance d'enregistrement". Une balle de tennis qui est ronde, à la base, aura l'aspect d'une comète (la sphère + la queue floue).
Au niveau de l'image, on a tellement évolué que les performances techniques sont aujourd'hui limitables avec un bonheur que nous n'imaginons pas.
En fait, le seul domaine qui a encore nécessité à demander une fréquence élevée, c'est le dessin animé. En gros, si on fabrique un jeu avec les traits d'une B.D. (désolé pour l'absence de vocabulaire technique), il est plus simple d'avoir une fréquence élevée plutôt que de pré-enregistrer des sprites floutés spécialement pour le déplacement.
Par contre, pour le son, ça semble être l'inverse : depuis trente ans, pour certains (qui ont l'oreille fine) c'est la crise de la qualité. Des enceintes des années 70 peuvent avoir un son inreproduisibles avec les enceintes actuelles. Pourquoi? Je n'en sais rien. Cette observation ne vient pas de moi mais de musiciens confirmés. Aussi, reproduire les sons des instruments de musique (comme un violon, etc...) est encore impossible...
Mais comme l'image de synthèse, les sons de synthèses dépasseront (du moins "atteindront") tôt ou tard les sons traditionnels en matière de qualité.
Donc, sous Linux vous avez un accès "à la milliseconde près". Ce qui n'est pas le cas sous Windows.ChaOs a écrit :Comme tout bon scientifique (enfin il parait) la première chose que j'ai fait c'est de tester sur un grand nombre d'itération pour savoir si les résultat sont constant et il le sont ce qui ma valut d'attendre 15minute les résultats sous Windows alors que 1 minute a suffit a Linux xD.
Pour résumer, un Delay(1) sous XP et sur un CPU mono-coeur maintient une compatibilité totale vers les autres XP qui n'ont qu'un coeur. N'ayant ni un double coeur ni un quadruple coeur sous la main pour tester, je ne pourrai pas vous en dire davantages...
Cpl.Bator a donc raison d'utiliser son modèle simple qui, pourtant consomme quelques cycles d'horloge CPU sous XP...
Tu n'as aucune pitié pour les daubes comme moi. C'est impardonnable... Pour la peine, je vais faire ce que j'aurai dû faire dès le début : aller voir et, si possible tester ton jeu!Tonton a écrit :heu! beauregard!! le delay(10) ca me servais a debugger et le 20 pour calmer le processeur a la fin du jeu!
sinon j aime pas le delay les ordinateurs ne vont jamais assez vite pour moi, alore je ne vois pas pourquoi j irai y foutre des delay dedants
comme le dit djes mon delay c' est le raffraichissement de l' ecran
donc la vitesse du jeu est constante a 60 herz ,meme si vous utilisez
un 8088!
@ChaOs
Désolé de te prendre un peu de temps pour ça mais ce code, quelle valeur retourne-t-il sous Linux?
Code : Tout sélectionner
Ref.I = ElapsedMilliseconds()
Repeat
Test = ElapsedMilliseconds()
Until Ref <> Test
Debug Test - Ref
Dernière modification par Ollivier le lun. 16/mars/2009 19:56, modifié 1 fois.
Ollivier a écrit : @ChaOs
Désolé de te prendre un peu de temps pour ça mais ce code, quelle valeur retourne-t-il sous Linux?Code : Tout sélectionner
Ref.I = ElapsedMilliseconds() Repeat Test = ElapsedMilliseconds() Until Ref <> Test Debug Test - Ref
1
-
- Messages : 1307
- Inscription : dim. 08/juil./2007 18:32
- Localisation : Toulouse
oui, j'ai étudie, hum, ton code et effectivement ce delay n'est pas utilisé lors du jeu, et tu n'utilise pas de sprite, preuve de l'optimisation, respect.tonton a écrit :heu! beauregard!! le delay(10) ca me servais a debugger et le 20 pour calmer le processeur a la fin du jeu!
sinon j aime pas le delayles ordinateurs ne vont jamais assez vite pour moi, alore je ne vois pas pourquoi j irai y foutre des delay dedants
![]()
comme le dit djes mon delay c' est le raffraichissement de l' ecran
donc la vitesse du jeu est constante a 60 herz ,meme si vous utilisez
un 8088!
mode fenêtre: http://www.purebasic.fr/french/viewtopi ... 5005#95005
ps: le nombre de vaisseau, en bas à droite, disparait en même temps que le texte( NIVEAU 1)
Dernière modification par beauregard le lun. 16/mars/2009 20:11, modifié 1 fois.
vous vous barrez dans des complications...
vos écrans sont limité en nombres d'images par secondes (un écran à 60hz , livre 60 images secondes) donc inutile d'inverser les buffers 100,120,300x par secondes... autant gardé le temps CPU pour faire autre chose , rendre la main à l'OS , faire marché vos algos , etc...
vos écrans sont limité en nombres d'images par secondes (un écran à 60hz , livre 60 images secondes) donc inutile d'inverser les buffers 100,120,300x par secondes... autant gardé le temps CPU pour faire autre chose , rendre la main à l'OS , faire marché vos algos , etc...
Non, ils ont raison de chercher
. Sur des écrans sans synchro ou des OS qui te piquent ton CPU, l'une des solutions pour faire un bon jeu 2D apparemment fluide est d'afficher le mouvement sous une autre forme: dessiner le déplacement de N pas d'un coup (correspondant aux N étapes entre deux temps de réaction clavier ou réseau ou synchro au timer), avec un effet de flou pour améliorer le rendu.
