PureBasic

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)

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é).

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.

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.

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é.

cha0s a écrit :
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.
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é.

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.

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.

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.

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

Pour voir si les résultats suivent à la millisecondes près ce que tu lui proposes?

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 ?

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 :
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/

Cet effet de flou est tel qu'au cinéma, 18 images par seconde suffisent à rendre les mouvements fluides

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 ?

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.

Code : Tout sélectionner

#boucle = 100000
Debut.l
Debut = ElapsedMilliseconds()
For n = 1 To #boucle
  Delay(1)
Next n
Debug (ElapsedMilliseconds() - Debut)/#boucle

me donne 1 et ton code me donne un décompte de 1 a 40

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!

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 ?

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.

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é.

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.

Donc, sous Linux vous avez un accès "à la milliseconde près". Ce qui n'est pas le cas sous Windows.

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...

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!

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!

@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

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

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!

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.
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)

ChaOs a écrit :1

Oh Put[censuré]... Là, j'ai du mal: Vous pouvez tout gérer de manière synchrone sur une bande de 1000 Hertz!!!

ça change de la bande à 60 Hertz sous Windows... Quelque soit le nombre de coeur CPU et quelque soit la fréquence CPU...

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...

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.

PureBasic

Performance d'un jeu en 2D