2D : Un mur, une raquette et une ball.

[TazNormand]

@LE Maquis : Ce que G-Rom t'explique c'est que tu dois faire attention car ton jeu sera injouable sur certains PC car trop lent ou trop rapide sur d'autres.

Si tu y joues sur un PC qui a 10 ans, ça va ramer grave, sur un Pc de 1-5 ans ce sera jouable, et sur un PC dans 3-5 ans ce sera trop rapide car les processeurs iront à 5-6ghz, les carte graphique à 3ghz, etc... (bon j'extrapole)

Tu dois adapter ton code pour qu'il tourne à la même vitesse pour tout le monde.

Lances ce code et donne le résultat du debug

Code : Tout sélectionner

 
timer1.l= ElapsedMilliseconds() 	
While(Delta < 10000) 
	timer.l = ElapsedMilliseconds()	
	Delta = timer - timer1
	cpt+1
Wend

Debug cpt

[Lemaquis]

merci taz mais c'est quoi le debug???

[TazNormand]

Bon la Le Maquis, on part de loin

Quand tu lances le code donné ce-dessus dans PureBasic, normalement tu dois avoir une petite fenêtre qui a comme titre "Messages du débogueur". Si ce n'est pas le cas, regarde si le petit "scarabée" dans la barre d'outils est "actif".

Si jamais tu trouves pas , essaies ce nouveau code :

Code : Tout sélectionner

timer1.l= ElapsedMilliseconds() 	
	While(Delta < 10000) 
	timer.l = ElapsedMilliseconds()	
	Delta = timer - timer1
	cpt+1
Wend

res=MessageRequester("Compteur","Le compteur a une valeur de : "+Str(cpt))

[Lemaquis]

merci j'ai vu mais je me sert jamais du debugeur

[venom]

Si tu y joues sur un PC qui a 10 ans, ça va ramer grave, sur un Pc de 1-5 ans ce sera jouable, et sur un PC dans 3-5 ans ce sera trop rapide car les processeurs iront à 5-6ghz, les carte graphique à 3ghz, etc... (bon j'extrapole)

Donc cette manipulation doit s'appliquer a n'importe quel jeux qu'on code ?

@Lemaquis Le debugger c'est utile, il peut te renvoyer des d'informations facilement. Tu t'en servira plus tard tu verra







@++

[TazNormand]

Donc cette manipulation doit s'appliquer a n'importe quel jeux qu'on code ?

Je pense que oui, tu n'as jamais essayé de rejouer à de très vieux jeux DOS sous XP, je pense aux Commander Keen, ou Jazz Jack Rabbit, avec des personnages sous amphét' tellement le PC est "trop" puissant pour ces vieux jeux.

bon, après, rejouer à ça, au lieu des softs actuels, faut être un peu taré, mais rien ne vaut un petit retour aux sources des fois (Ahhh WinUAE et FlashBack/SuperFrog/Stunt Car Racer/Indianapolis 500/Lotus/Moonstone/etc...)

Edit : pour le code que j'ai mis plus haut, voici mes résultats, quels sont les vôtres :
Debbuger ON : 93 553 040
Debugger OFF : 708 439 695

[G-Rom]

Merci mais j'ai rien compris du tout

Un PC moins puissant va exécuter un programme moins vite ( logique )
Un PC plus puissant va exécuter un programme plus vite ( Logique aussi )

Ta boucle principale ( Repeat Until ) va donc s'executer à différente vitesse sur deux pc complètement différent, la seul constante qu'il y a entre les 2 PC , c'est le temps , il faut donc basé les mouvements dessus. tout simplement , que ce soit une vieille bécane ou un PC d'enfer de la mort qui tue sa race, le programme , même si il s’exécute plus vite , les mouvement auront la même vitesse.

[djes]

Ce n'est pas aussi simple que ça, les histoires de vitesse de déplacement et de vitesse du pc. Il y a pas mal de papiers là-dessus sur le net. Normalement, le programmeur du jeu doit avoir en tête que l'affichage sur un écran se fait à la façon d'un dessin animé. On donne l'illusion du mouvement par un certain nombre d'images differentes. L'écran, lui, change d'image x fois par seconde (en général 60). L'ordinateur, lui, doit s'adapter à cette cadence et y coller le plus possible, sinon apparaissent des défauts :
Si l'ordinateur n'est pas capable de créer une image en 1/60 eme de seconde, la même image sera affichée deux fois, l'effet sera un ralentissement (ça rame...)
Si l'ordinateur n'est pas synchronisé sur l'affichage, il va calculer des images trop rapidement, mais l'affichage n'en prendra qu'une tous les 1/60 de seconde malgré tout. L'impression donne sera celle d'un déplacement trop rapide.
Si l'ordinateur se cale sur un timer, plutôt que sur l'affichage, il y aura de temps en temps des frame drop, c'est à dire que très régulièrement, deux images identiques seront affichées. L'impression est celle d'un déplacement fluide, puis pause, puis fluide, pause etc. Bref, c'est un peu saccadé. Ç'a toujours été le plus gros problème sur les pc sous windows avec le différents constructeurs qui ne permettent pas toujours de se caler sur l'affichage.
Si l'ordinateur n'est pas synchronisé sur l'affichage, au moment où l'image est envoyée de la carte graphique vers l'écran, deux images différentes sont affichées, c'est le tearing, l'image semble se briser.

Pour avoir un vrai jeu fluide, il faut distinguer les interactions des joueurs, ( par exemple gérer les ralentissements réseau), la logique du jeu, et l'affichage. En 2D, on ne supporte pas les ralentissements, les frame drop et le tearing, car ça se voit très fort. En 3D, seuls les ralentissements sont vraiment gênants, même si dans l'idéal il ne faudrait aucun défaut.

Pour avoir la totale, il faut pouvoir compter sur le système pour la synchronisation avec l'affichage (au moment de la vbl ou du début du transfert mémoire écran) et la gestion des double ou triple buffering. PB est censé gérer tout ça, en accord avec l'os. Il y a les options dans openscreen(). Pour s'en passer, il faut utiliser un autre moteur que celui de pb, ou tout reprogrammer soi-même.

Désolé pour les fautes, mais j'écris d'un mobile...

[venom]

Merci pour toutes ces explications.







@++

[Micheao]

Bonjour

dans la ligne suivante :

Code : Tout sélectionner

Background = LoadSprite(#PB_Any, #PB_Compiler_Home +"Examples\3D\Data\Textures\soil_wall.jpg")

Que veux #PB_Any, #PB_Compiler_Home ?



Merci et Bon dimanche

[TazNormand]

#PB_Any : n'importe quel numéro
#PB_Compiler_Home : Répertoire où se trouve le compilateur de PureBasic

[Micheao]

#PB_Any : n'importe quel numéro
#PB_Compiler_Home : Répertoire où se trouve le compilateur de PureBasic

merci Taz pour les explications