Pure1945 !!!

[comtois]

Le principe que tu utilises consiste à compenser un retard en multipliant par un facteur temps, ça donne un truc de ce genre ,si pour un FPS normal de 75 , tu te déplaces de 4 pixels , on aura :

Si le FPS calculé est de 150 alors le déplacement = 2
Si le FPS calculé est de 75 , alors le déplacement = 4
Si le FPS calculé est de 37,5 alors le déplacement = 8

Dis moi si je me trompe ? c'est bien ainsi que tu fais ?

L'inconvénient de cette méthode ,c'est que ta détection des collisions n'est pas du tout la même si ton FPS est de 150 que s'il est de 37,5 !
si tu as des petits objets de taille inférieure à 8 , il est possible que tu passes au travers avec un mauvais FPS .

alors qu'avec la méthode que je t'ai indiqué , le déplacement est toujours le même quelque soit le FPS, et donc la gestion des collisions est la même aussi.

[Marcus]

L'inconvénient de cette méthode ,c'est que ta détection des collisions n'est pas du tout la même si ton FPS est de 150 que s'il est de 37,5 !

t'as tout à fait raison !
quoi que du 37,5 hz difficile à trouver

alors qu'avec la méthode que je t'ai indiqué , le déplacement est toujours le même quelque soit le FPS, et donc la gestion des collisions est la même aussi.

Oui mais adieu le fluide

tu comprends pourquoi j'ai abandonné toutes ces methodes et en suis revenu au bon vieux :

Code : Tout sélectionner

SetRefreshRate(75) 
If OpenScreen(1024,768,32,"") = 0 :SetRefreshRate(0): OpenScreen(1024,768,16,"") :SetFrameRate(75):EndIf

[Marcus]

autre soluce : au lieu de calculer le fps en temps reel il suffit de retourner la sync par defaut avec DesktopFrequency() et de calculer le facteur de deplacement avec .

Fini le probleme des collisions , reste fluide , mais bon faut pas que le fsp descende en dessous de la sync sinon ramage serieux.

[comtois]

t'as tout à fait raison !
quoi que du 37,5 hz difficile à trouver

Je parlais du FPS , pas de la fréquence de l'écran .
Et en 3D si tu n'as pas de carte graphique adaptée , tu peux facilement y être au FPS de 30.

Quand j'ai mis mon invader3D sur un forum de "développeurs de jeux" , certains m'ont signalé un FPS supérieur à 300 , et pour eux le jeu était incontrôlable Et pourtant je valide bien la synchro de l'écran avec Flipbuffer() , mais je ne m'étais pas ton truc:

SetRefreshRate(75)
If OpenScreen(1024,768,32,"") = 0 :SetRefreshRate(0): OpenScreen(1024,768,16,"") :SetFrameRate(75):EndIf

j'ai fait un essai hier soir , et si je désactive la synchro avec l'écran au niveau de ma carte ( ce que font ceux qui se plaignaient de la vitesse) , alors j'ai moi aussi un FPS supérieur à 400 malgré le SetRefreshRate(75) et le Flipbuffer() .

C'est pour ça que j'en suis venu à utiliser la méthode que je t'ai indiqué , elle permet de prendre en compte aussi bien les configs avec une mauvaise carte graphique que les configs avec un FPS important à cause de la synchro supprimée.

Autre avantage de la méthode c'est qu'en modifiant le paramètre Dt_jeu on peut faire des ralentis , des accélérés , sans rien toucher au code.

Bref , à chacun sa méthode, je voulais juste la signaler ici pour ceux que ça intéresse .

[Dräc]

Selon vos conseils, petite mise à jour avec au choix mode fenêtré ou plein écran.

Une chose de bien, serait d’éviter au mieux de présumer de certaines caractéristiques du matériel dont dispose le joueur.
Par exemple, en proposant le mode plein écran, il serait plus correct de considérer dans un premier temps des caractéristiques physiques de l’écran du joueur, puis de s’y adapter si besoin.
Ainsi pour windows, on trouvera le nécessaire dans le post suivant :
http://purebasic.hmt-forum.com/viewtopi ... aysettings

Malheureusement Pure ne permet pas, à ma connaissance, de connaître les caractéristiques courantes d’un écran quel que soit l’OS.
Cela complèterait parfaitement le jeu d’instructions ExamineScreenModes() et NextScreenMode()

Cependant si certaines personnes peuvent me renseigner sur les instructions équivalentes sur Linux et AmigaOS, ca comblerait cette lacune.

[Marcus]

un FPS supérieur à 400 malgré le SetRefreshRate(75) et le Flipbuffer() .

Dsl Comtois ,j'ai l'impression que tu as pas bien lu
bien evidenment avec la sync deactivé le SetRefreshRate(75) est ignoré .
c'est pour cela que je met un SetFrameRate(75) qui limitera le fps a 75 quelle que soit la syncro activée ou pas . (en perdant la fluiditée si deactivée bien sur ! )

Et en 3D si tu n'as pas de carte graphique adaptée , tu peux facilement y être au FPS de 30.

Avec mon principe sans SetRefreshRate(75) oui ,
comme j'ai dis plus haut, pour eviter le problemes decollisions suffit de calculer le facteur de deplacement sans utiliser le fps en temps reel mais plutot avec DesktopFrequency():

Code : Tout sélectionner

facteur_deplacement = 75/ DesktopFrequency()

Ne suportant pas les saccades, j'essais de concevoir des truc optimisés pour une config minimale , eviter que le fsp descende en dessous de la sync .Tampis pour les trop vieilles configs , toutes manieres elles rameront forcement quelle que soit la technique .
C'est tellement plus beau le lisse et même en 3D.

Bref , à chacun sa méthode, je voulais juste la signaler ici pour ceux que ça intéresse .

Et c'est bien de donner ses methodes , c'est un sujet tres peu abordé et pourtant ô combien essenciel .
j'aimerais bien que tu nous montre un exemple de la tienne

[comtois]

Dsl Comtois ,j'ai l'impression que tu as pas bien lu

bien evidenment avec la sync deactivé le SetRefreshRate(75) est ignoré .
c'est pour cela que je met un SetFrameRate(75) qui limitera le fps a 75 quelle que soit la syncro activée ou pas . (en perdant la fluiditée si deactivée bien sur ! )

Si si j'ai bien lu , j'ai mal écrit par contre
Ce que je voulais te dire c'est que le SetFrameRate(75) ne limite pas le FPS si la synchro est désactivée , du moins chez moi , as-tu fait des essais en désactivant la synchro de ton écran ???

Pour l'exemple , il se trouve dans mon SpaceInvaders3D , et aussi un petit essai que j'ai fait avec un sprite dans la section trucs et astuces , sous le titre "gestion du temps dans les jeux"

[comtois]

Malheureusement Pure ne permet pas, à ma connaissance, de connaître les caractéristiques courantes d’un écran quel que soit l’OS.
Cela complèterait parfaitement le jeu d’instructions ExamineScreenModes() et NextScreenMode()
Cependant si certaines personnes peuvent me renseigner sur les instructions équivalentes sur Linux et AmigaOS, ca comblerait cette lacune.

ben la nouvelle librairie "Desktop" te renseigne sur les caractéristiques du bureau , valable pour Window et Linux .

[Dräc]

ben la nouvelle librairie "Desktop" te renseigne sur les caractéristiques du bureau , valable pour Window et Linux .

Moi ? J'ai dis quelque chose...

Ben ouais! Ca à l'air d'etre ca...

[Marcus]

t'as effectivement raison Comtois
le SetFrameRate(75) ne freine rien avec la sync deactivée

quel degout

je vais tester ta methode

[Le Soldat Inconnu]

bah, tu fais simplement un test de FPS au début du jeu et si tu vois que le FPS n'est pas celui du setframerate, tu quittes le jeu en disant : "la synchro de l'écran n'est pas activée."

et basta

[Le Soldat Inconnu]

sinon, j'ai ça qui traine :

Code : Tout sélectionner

#Rapidite_Regulation = 3
    Cpt_Temps + 1
    If Cpt_Temps = #Rapidite_Regulation
      FPS = Int(#Rapidite_Regulation * 1000 / (GetTickCount_() - Temps))
      Temps = GetTickCount_()
      Cpt_Temps = 0
      If FPS < 30 And VitesseJeu > 0
        VitesseJeu - 1
      ElseIf FPS > 35
        VitesseJeu + 1
      EndIf
    EndIf
    Delay(VitesseJeu)

pour réguler un delay afin d'obtenir un FPS entre 30 et 35 dans cet exemple

et la pas de soucis de synchro

[Marcus]

tu fais simplement un test de FPS au début du jeu et si tu vois que le FPS n'est pas celui du setframerate, tu quittes le jeu en disant : "la synchro de l'écran n'est pas activée."

Tout à fait Thierry

sinon, j'ai ça qui traine :
bonjour les saccades

un petit essai que j'ai fait avec un sprite dans la section trucs et astuces , sous le titre "gestion du temps dans les jeux"

Avec cette methode il est impossible de faite du fluide non plus

[Le Soldat Inconnu]

tu as changé le FPS de mon truc avant de raler ?

la il est sur 30 de FPS donc forcément

Le mieux est de combiner un Setframerate avec ça je trouve

si il y a la synchro, le setframerate fait tout, sinon, mon truc se lance et limite le FPS.

[Marcus]

tu as changé le FPS de mon truc avant de raler ?

lol je vois que tu commence à me connaître

la il est sur 30 de FPS donc forcément

bien evidenment rien que de voir ce 30 j'avais même pas testé

Si non j'ai testé ton truc avec :

Code : Tout sélectionner

SetRefreshRate(75)
If OpenScreen(1024,768,32,"") = 0 :SetRefreshRate(0): OpenScreen(1024,768,16,"") :SetFrameRate(75):EndIf

;boucle
  
  
  #Rapidite_Regulation = 3 
  Cpt_Temps + 1 
  If Cpt_Temps = #Rapidite_Regulation 
    fps = Int(#Rapidite_Regulation * 1000 / (GetTickCount_() - Temps)) 
    Temps = GetTickCount_() 
    Cpt_Temps = 0 
    If fps < 75 And VitesseJeu > 0 
      VitesseJeu - 1 
    ElseIf fps > 75
      VitesseJeu + 1 
    EndIf 
  EndIf 
  Debug   fps
  Delay(VitesseJeu)
  
  ------------------------

cela semble marcher
si l'ecran accepte le 75 hz il se calle dessus ,donc hyper fluide
s'il veut pas du 75, SetFrameRate(75) limite le fps ,( pas lisse ,s'ont qu'a avoir un ecran qui accepte le 75 hz , le 60hz en 1024x768 s'a fait mal au yeux )
et si la sync est déactivé ton truc regule le fps ( saccadé mais bonne vitesse , s'ont qu'a pas déactiver leur syncro )

Merci Soldat Inconnu