bonne idéeDobro a écrit :faudrait tester si vous aviez encore la V3.94
On s'était amusé à tester sur le forum anglais... Là : http://www.purebasic.fr/english/viewtop ... sc&start=0 et là : http://www.purebasic.fr/english/viewtop ... r&start=30Dobro a écrit :heu ! t'es sur ??;tout en flottants, c'est plus pratique et plus rapide
plus pratique , bon ok , cela permet de mieux jouer sur la vitesse éventuellement , mais pas pour les coordonnées puisqu'elle sont entière sur un pc X,y ce sont des coordonnées entiere !! donc les flottants ne se justifie pas , parce qu'on effectue un déplacement en ligne ..
bien sur si l'on fait intervenir les Cos(),et autre Sin() là c'est différent
ce qui m'interpelle c'est ton affirmation "et plus rapide" .....
en principe les flottants non pas la réputation d'etre plus rapide que les entiers !! de par la convertion en binaire, deja ....
Là c'est justement un cas d'écoleDobro a écrit :pour ce qui concerne les constantes , je ne suis pas vraiment pour,
pour une simple raison, lorsqu'on veux modifier le nombre de sprites par la suite dans le code (modif faite par le code), on ne peut pas , a moins de bidouiller ...
les constantes pour certains trucs, oui, mais pour moi, ça n'est pas automatique !! loin de là !!
, on s'en fout à notre époque, qu'est-ce que c'est quatre octets pour une variable?C'est vrai, on pourrait, c'était pour donner l'astuce, utile pour les vectors-ballsde plus tu utilise une astucieuse façon de trier tes sprites ,
mais c'est inutile, puisqu'on peut faire la meme chose sans tri
Mercienfin ce code est tres bien conçu effectivement
Pareil, c'est pas fluide ici non plus, de temps en temps ça saute. On peut essayer d'augmenter la priorité de notre tâche, mais rien de plus. PB se base déjà sur la VBL (quand elle existe), puisqu'il utilise DirectX (voir la doc de flipbuffers()). Sinon il utilise un timer. Mais ça ne sert à rien, Windows prend la main et te fait avoir un frame drop régulièrement, par exemple lors d'un accès au disque pour la mémoire virtuelle, ou un événement réseau.cependant , pour en revenir a notre sujet
chez moi le déplacement des sprites n'est pas plus fluide !!
il est tantot acceléré , tantot ralenti , de façon uniforme, l'ensemble donne l'impression d'etre dans une boucle qui ne tournerai pas rond !:lol:
si Fred passe : franchement on a vraiment du mal sous windows a avoir un
déplacement de sprite qui ne soit pas influencé par les désidérata de windows , meme en plein ecran , et il me semble qu'avant en version 3.94
notamment , c'etait bien plus fluide !!
il n'y aurai pas un moyen qu'un prg purebasic est une reference
comme un VBL ou hbL (de dans le temps) , bref une impulsion
Réguliere, et fiable , qui fasse tourner notre application
sans tenir compte de l'ordonanceur windows ????
Pareil avec le smartsynchrobeauregard a écrit :chez moi en plein écran, c'est en bas uniquement que çà merdouilleBuckethead a écrit :non, où qu'elles soient
Je suis sous PB 4.02, Windows XP SP2 (DirectX à jour)beauregard a écrit :non le coupable, c'est le delay, arg !!!
résumer: pour avoir un défilement d'étoile bien fluide en plein écran, faut être sous la 3.94 et ne pas utiliser de delay. Buckethead, c'est à toi de jouer et de me dire si tu obtiens le même résultat...
sans delay(1) le fps monte à 187, c'est dingue !Cpl.Bator a écrit :Désactivé la syncro vertical de vos cartes , ici c'est nickel , fluide. pas de saccade.
!!
Code : Tout sélectionner
Structure sprite
x.l
y.l
vitesse.l
EndStructure
nbr_sprite=1000
Dim sprite.sprite(nbr_sprite)
; Test
EcranX = GetSystemMetrics_(#SM_CXSCREEN)
EcranY = GetSystemMetrics_(#SM_CYSCREEN)
InitSprite(): InitKeyboard()
;hwnd=OpenWindow(1,0,0,EcranX,EcranY,"test", #PB_Window_ScreenCentered | #PB_Window_MinimizeGadget )
OpenScreen (EcranX,EcranY,32,"Test")
; *********** prepare les parametres de chaque sprite *****************
For t=0 To nbr_sprite
sprite(t)\x = Random(EcranX)+1
sprite(t)\y= Random(EcranY)+1
sprite(t)\vitesse=Random(4)+1
CreateSprite(t, sprite(t)\vitesse, sprite(t)\vitesse)
; dessine le sprite
StartDrawing(SpriteOutput(t))
Box(0,0, sprite(t)\vitesse, sprite(t)\vitesse,RGB(Random(100)+100,Random(100)+100,Random(100)+100))
StopDrawing()
Next t
; ***************************************************************
SetFrameRate(50)
Repeat
go= ElapsedMilliseconds()
For t= 0 To nbr_sprite
DisplaySprite(t,sprite(t)\x,sprite(t)\y)
sprite(t)\x=sprite(t)\x+sprite(t)\vitesse
If sprite(t)\x>EcranX
sprite(t)\x=0
EndIf
Next t
temps=ElapsedMilliseconds()-go
StartDrawing(ScreenOutput())
DrawText(10,10,"Temps: "+Str(temps))
StopDrawing()
ExamineKeyboard()
If KeyboardPushed(#PB_Key_Escape)
End
EndIf
FlipBuffers(#PB_Screen_WaitSynchronization )
ClearScreen(0)
Delay(2)
ForEver 
C'est ce que je pensais aussi, tu te doutes bien... Jusqu'à à avoir fait quelques tests sur des calculs. Et là, et bien, je ne suis plus sûr de rien! Chez moi, très souvent les flottants sont largement au dessus des entiers.Dr. Dri a écrit :Juste quelques remarques sur le post de djes
Pour moi des entiers de la taille de ton processeur sont forcément plus rapides (surtout si on fait intervenir des calculs un tant soit peu évolués) que des nombres réels.
Non, mais on peut encore faire des démos, même techniques! Rien n'empêche de dépasser les limites de Windows, en faisant une démo en ring 0Tout ça pour dire qu'on est plus à l'époque des démos techniques d'affichage d'effet plasma qu'on fait tourner sur un bon vieux DOS avec en sortie un VGA de 320x200...
(-hum- j'en serais bien incapable)Oui, c'est souvent bien, et dans le reste des cas, faire un gros sprite de la taille de l'écran... Ou alors tout redessiner.Un petit pavé dans la marre avec l'histoire du clearscreen. C'est cette commande qui bouffe le plus de ressources pour moi (en une seule fonction). Elle bouffe autant que FlipBuffers sans être réellement utile. Ce que je propose est très compliqué mais apporte de vrais gains de perfs... Ne redessiner que ce qui a changé d'une frame à l'autre!
Ils en seraient bien capables! On a vu pire chez Microsoft! Et les débutants qui font cinquante instructions pour avoir moins à taper... (vu sur le forum anglais y'a pas longtemps, j'ai failli pleurer)Vous pensez que Windows redessine tout l'écran à chaque Frame pour un simple dépassement de souris ?
tu devrai redémarer ta machine et tester avec le moins possible de logiciel( chuis sûr que ce sont mes vieux logiciels qui foutent la merde de temps à autres...)Dobro a écrit :le code ou j'obtiens la meilleur fluidité
c'est celui ci parceque je commence par un setframerate(50)
avant la boucle
bon en fait cette fonction sert a ça
ps : CplBator : oui, peut etre, mais sur mon petit NC10 point de parametres de la sorte
@Dri :
oui, meme qu'un Clearscreen(X,Y,Larg,Haut) serai un vrais plus dans le purebasic !!
avec la possibilité de pouvoir agir sur l'ecran caché (ecran Logic) (celui que le Flipbuffer() affiche par un swap)
pour ça le Stos etait bien ou pouvait dessiner sur l'ecran logique (celui dont je parle)
l'ecran physic etait celui que l'utilisateur vois !
et l'ecran Back qui etait l'ecran du decor des sprites !!
en jonglant avec ces 3 ecrans, (avec un Swap ) on pouvais vraiment faire ce qu'on voulais
ps : on peut encore simuler ces ecrans avec les sprites() ou des images()
Pas fluide du tout chez moi. Le code le plus fluide est avec la smartsynchro : le haut est parfaitement fluide, en dessous, sur une centaine de pixels c'est hachuré (sur un écran CRT). On voit que la synchro est au timer, et que le double-buffer est swappé là!Dobro a écrit :le code ou j'obtiens la meilleur fluidité
c'est celui ci parceque je commence par un setframerate(50)
avant la boucle
Code : Tout sélectionner
Structure sprite
X.l
Y.l
Vitesse.l
EndStructure
nbr_sprite=1000
Dim sprite.sprite(nbr_sprite)
; Test
EcranX = GetSystemMetrics_(#SM_CXSCREEN)
EcranY = GetSystemMetrics_(#SM_CYSCREEN)
InitSprite(): InitKeyboard()
;hwnd=OpenWindow(1,0,0,EcranX,EcranY,"test", #PB_Window_ScreenCentered | #PB_Window_MinimizeGadget )
OpenWindow(0, 0, 0, EcranX, EcranY, "", $80000000)
OpenWindowedScreen(WindowID(0), 0, 0, EcranX, EcranY, 0, 0, 0)
;OpenScreen (EcranX,EcranY,32,"Test")
; *********** prepare les parametres de chaque sprite *****************
;For t=0 To nbr_sprite
; sprite(t)\x = Random(EcranX)+1
; sprite(t)\y= Random(EcranY)+1
; sprite(t)\vitesse=Random(4)+1
; CreateSprite(t, 4 * sprite(t)\vitesse, sprite(t)\vitesse)
; ; dessine le sprite
;StartDrawing(SpriteOutput(t))
; Box(3 * sprite(t)\vitesse,0, sprite(t)\vitesse, sprite(t)\vitesse,RGB(Random(100)+100,Random(100)+100,Random(100)+100))
;StopDrawing()
;Next t
; ***************************************************************
CreateSprite(0, 2 * EcranX, EcranY)
StartDrawing(SpriteOutput(0) )
For i = 0 To 999
Box(Random(2 * EcranX - 1), Random(EcranY - 1), 4, 4, RGB(Random(255), Random(255), Random(255) ) )
Next i
StopDrawing()
Global Dim x_.F(15)
Global Dim V_.F(15)
Nb_ = 3
For I = 0 To Nb_
V_(I) = 4.0 / Pow(2, I)
Next I
Repeat
go= ElapsedMilliseconds()
;For t= 0 To nbr_sprite
; DisplaySprite(t,sprite(t)\x,sprite(t)\y)
;
; sprite(t)\x=sprite(t)\x+sprite(t)\vitesse
; If sprite(t)\x>EcranX
; sprite(t)\x=0
; EndIf
;
;Next t
For I = Nb_ To 0 Step -1
If I = Nb_
DisplaySprite(0, x_(I), 0)
DisplaySprite(0, x_(I) - 2.0 * EcranX, 0)
Else
DisplayTransparentSprite(0, x_(I), 0)
DisplayTransparentSprite(0, x_(I) - 2.0 * EcranX, 0)
EndIf
x_(I) + V_(I)
If x_(I) > EcranX
x_(I) = 0 - EcranX
EndIf
Next I
temps=ElapsedMilliseconds()-go
StartDrawing(ScreenOutput())
DrawText(10,10,"Temps: "+Str(temps))
StopDrawing()
ExamineKeyboard()
If KeyboardPushed(#PB_Key_Escape)
End
EndIf
FlipBuffers()
;ClearScreen(0)
Clic.I + 1
Clic & 3
If Clic = 0: Delay(1): EndIf
ForEver