Page 6 sur 10

Publié : dim. 22/mars/2009 13:04
par Backup
Buckethead a écrit :Je comprend bien, mais il y a aussi un interet a effacer juste après le repeat: si on a predessiné des trucs avant le repeat, on épargne 1 instruction clearscreen
ben non !

parce que ce qui apparait a l'ecran ; apparait seulement avec la fonction

Flipbuffer() !
(c'est d'ailleur pour ça que je regroupe flipbuffer() et clearscreen() )
qui aurait d'ailleurs pu être une seule fonction !! avec un parametre pour clearscreen actif ou pas , et un autre pour la couleur :D

donc tant que pas de flipbuffer() , on voit rien !!

de plus lorsqu'on code "comme il faut" , on précalcul/prédessine rien dans l'espace visible par l'utilisateur (sauf si l'effet est voulu) ;)


mais bon, chacun fait comme il veux ! :)

Publié : dim. 22/mars/2009 13:13
par Buckethead
Faux.
La première frame sera entachée de ce qui aurait pu être dessinné avant.
Et s'il y a un grabsprite() c'est toutes les frames qui ont un problème.

Publié : dim. 22/mars/2009 13:15
par Backup
Dobro a écrit :
de plus lorsqu'on code "comme il faut" , on précalcul/prédessine rien dans l'espace visible par l'utilisateur (sauf si l'effet est voulu) ;)


mais bon, chacun fait comme il veux ! :)

Publié : dim. 22/mars/2009 13:18
par Buckethead
On est bien obligé avec les sprite3D, si on doit zoomer, ou toutes autre raisons de toute facon. (sauf si l'effet est voulu: bah voila...)

Publié : dim. 22/mars/2009 13:27
par Backup
Buckethead a écrit :On est bien obligé avec les sprite3D, si on doit zoomer etc

:lol: :lol: :lol: :lol: tu m'fais marrer toi :D

excellent :D

Publié : dim. 22/mars/2009 13:28
par Buckethead
Ok si tu veux, THE END :lol:

Publié : dim. 22/mars/2009 13:42
par djes
Je peux en rajouter une couche? :lol:
Je me suis amusé à modifier vos codes (en attendant madame), histoire de mettre de l'huile sur le feu histoire de participer ;). J'ai beaucoup commenté, mais sur le sujet qui est la fluidité : ce n'est pas fluide.
Y'a pas un code qui traîne pour récupérer le taux de refresh courant?

Code : Tout sélectionner

;pourquoi utiliser des variables alors qu'on a des constantes? Je les mets en maj pour les distinguer
#NBR_SPRITES       = 1000
#VITESSE_MAX       = 8
#IMGS_PAR_SECONDES = 60
#DUREE_FRAME       = 1000/#IMGS_PAR_SECONDES

Structure sprite
  nb.l
  ;tout en flottants, c'est plus pratique et plus rapide
  x.f                
  y.f
  vitesse.f
EndStructure

;Petite astuce perso : le sprites avec un "s" pour différencier le tableau de la structure
;le -1 est indispensable pour que le tri se fasse bien
Global Dim sprites.sprite(#NBR_SPRITES - 1)

;**********************************************************************************************************
; Prépare les parametres de chaque sprite 
Procedure cree_sprites()

  Shared Largeur_Ecran, Hauteur_Ecran

  ;le -1 sinon on calcule 1001 sprites
  For t = 0 To #NBR_SPRITES - 1                             
  
    ;on stocke le numéro du sprite car après le tri il ne correspondra plus
    sprites(t)\nb      = t
    ;ici le -1 ne sert à rien, un pixel de plus ou de moins ne change rien
    sprites(t)\x       = Random(Largeur_Ecran)
    sprites(t)\y       = Random(Hauteur_Ecran)
    ;le 1.0 en tête pour être sûr de l'évaluation en flottants (faudrait corriger ça, Fred! à quand le casting en pb? ;)
    sprites(t)\vitesse = 1.0 + ((t * 1000)/#NBR_SPRITES * (#VITESSE_MAX - 1)) / 1000 
  
    CreateSprite(t, sprites(t)\vitesse, sprites(t)\vitesse)
  
    ; dessine les sprites
    StartDrawing(SpriteOutput(t))
    ;une petite règle de trois pour avoir la couleur en fonction de la vitesse
    col = 55.0 + (sprites(t)\vitesse * 200) / #VITESSE_MAX
    Box(0, 0, sprites(t)\vitesse, sprites(t)\vitesse, RGB( col, col, col ))
    StopDrawing()
  
  Next t

EndProcedure

;**********************************************************************************************************
Procedure affiche_sprites()

  Shared Largeur_Ecran

  For t = 0 To #NBR_SPRITES - 1

    sprites(t)\x + sprites(t)\vitesse

    ;la petite astuce : on ne remet pas le sprite à la position 0 si on dépasse, on soustrait la largeur 
    ;écran, ce qui évite l'effet visible d'apparition sur le bord gauche...
    If sprites(t)\x >= Largeur_Ecran
      sprites(t)\x - Largeur_Ecran
    EndIf

    DisplaySprite(sprites(t)\nb, sprites(t)\x, sprites(t)\y)  

  Next t

EndProcedure

;**********************************************************************************************************
;- Initialisations 

;j'ai parfois du mal mais utiliser les bons termes évite de se creuser la tête, x était trop vague par rapport à largeur
Largeur_Ecran = GetSystemMetrics_ (#SM_CXSCREEN)
Hauteur_Ecran = GetSystemMetrics_ (#SM_CYSCREEN)

InitSprite()
InitKeyboard()

OpenScreen(Largeur_Ecran, Hauteur_Ecran, 32, "Test" )

;SetRefreshRate(#IMGS_PAR_SECONDES)
;SetFrameRate(#IMGS_PAR_SECONDES)

;si le clearscreen est mis à la fin de la boucle principale, il faut faire le ménage au moins une fois au début 
;car souvent le backbuffer n'est pas nettoyé par ce qu'il y avait avant notre effet, voire il peut être pollué par des résidus sur certaines cartes graphiques
;en général on ne voit qu'un petit flash...
FlipBuffers()
ClearScreen (0)                                            

cree_sprites()

;un petit tri pour que les sprites soient affichés du plus lent au plus rapide les uns par dessus les autres
SortStructuredArray(sprites(), #PB_Sort_Ascending, OffsetOf(sprite\vitesse), #PB_Sort_Float)

;Là il faudrait faire un petit test de synchro pour être sûr que notre affichage est stabilisé (plus de chargements...)

;**********************************************************************************************************
;- Main loop 

Repeat

  ;on va calculer le temps que nous prenons
  temps_depart.l = ElapsedMilliseconds()

  ExamineKeyboard()

  If KeyboardPushed ( #PB_Key_Escape )
    End
  EndIf

  affiche_sprites()

  ;si le temps pris par notre affichage nous le permet
;  If ElapsedMilliseconds()<(temps_depart + #DUREE_FRAME - 1)           
    ;on octroie un peu de cpu au système (sinon notre programme effectue une boucle dans le flipbuffers qui monopolise tout)
    Delay(1)
;  EndIf

  ;(mettre ça à la fin, pourquoi pas?) une fois les éléments dessinés, on les affiche
  FlipBuffers(#PB_Screen_SmartSynchronization)
  ;on nettoie l'écran pour la prochaine frame
  ClearScreen(0) 
   
ForEver 

Publié : dim. 22/mars/2009 14:29
par Backup
;tout en flottants, c'est plus pratique et plus rapide
heu ! t'es sur ??

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


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à !! :)


de plus tu utilise une astucieuse façon de trier tes sprites , :)

mais c'est inutile, puisqu'on peut faire la meme chose sans tri :)

enfin ce code est tres bien conçu effectivement

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



je sens la question con là :lol:













<

la lutte est rude

Publié : dim. 22/mars/2009 14:58
par beauregard
djes a écrit :Je peux en rajouter une couche?
Mais c'est toujours un plaisir ! :D
Concernant ton joyeux code, les constantes viennent troubler mon esprit( on peut tout faire avec du global et du local).
Et pour Struture sprite puis sprites.sprite, heu oui mais non, car un peu confus quand même.
Struture objet c'est mieux: fleur.objet, abeille.objet, hirondelle.objet...

allez donc télécharger joyeusement ce jeu, et dites moi si vous le trouver biieenn fluide:http://www.purebasic.fr/german/viewtopi ... sc&start=0

Publié : dim. 22/mars/2009 14:59
par Buckethead
On voit bien la saccade malgrès le fullscreen, même avec 3 étoiles qui scrollent.

Publié : dim. 22/mars/2009 15:03
par beauregard
Buckethead a écrit :On voit bien la saccade malgrès le fullscreen, même avec 3 étoiles qui scrollent.
au bas de ton l'écran ?

Publié : dim. 22/mars/2009 15:05
par Buckethead
non, où qu'elles soient

Publié : dim. 22/mars/2009 15:06
par beauregard
Buckethead a écrit :non, où qu'elles soient
chez moi en plein écran, c'est en bas uniquement que çà merdouille

Publié : dim. 22/mars/2009 15:07
par Buckethead
ha, c'est curieux en effet

Publié : dim. 22/mars/2009 15:09
par beauregard
Buckethead a écrit :ha, c'est curieux en effet
précisément le dernier code de Dobro. Alors que son précedent, en mode fenêtre, c'est no problem. T'as testé demon force ?