PureBasic

@Ollivier

Je n'ai pas compris ton avant dernier message... Et je ne compte pas brancher mon cerveau, il est déjà à plein régime sur autre chose.

Je me la sent un peu ? Que je revienne sous PB ?

Je veux bien répondre "oui" aux deux mais pour la deuxième j'ai déjà répondu (ou anticipé) en disant que je reviendrait dans le courant de cet été... Si j'ai le temps de coder en pure...

Dri en mode courtois (et non pas comtois =)

@Dr Dri

Mes plus plates excuses. Je me branche sur le même mode : courtois. (Je n'étais pas en mode Comtois)

Si tu es un nostalgique de la 2D, tu vas trouver tout ton bonheur.

Pour la tasse de thé, il s'agit de ton regretté avatar qui n'est plus.

La version 4.30 a ses défauts mais aussi ses qualités en nouveautés. Notamment dédier la quasi-totalité des effets 2D à la carte vidéo via Ogre et DirectX. Bon, c'est vrai que, vu les screenshoots de DreamMotion, ce n'est pas une nouveauté pour tout le monde.

Mais d'excellents (très excellents) jeux en 2D "enrichis" peuvent être désormais créés en "natif".

Et si je jète mon dévolu sur toi, c'est parce que je lis une règle que tu dis et qui est vraie (ImportanteCondition = StartDrawing() ) en théorie. Mais, l'architecture proposée par Comtois pour faire de la 3D à la base, évite la nécessité d'user de cette instruction dans une boucle principale. Donc, finalement, ce que tu as dit ne correspond hélas plus à la réalité!
(Zéro dessins en temps réel, 0 sprites, etc...) Et puis ça marche très bien sous Windows, comme sous Linux (à moins d'une remarque contraire).

Tu le découvriras sûrement avec grand bonheur, d'où mon enthousiasme dont le trop de sarcasme, je l'espère te passe bien en dessous des semelles...

Voilà Dr Dri!

Ollivier

@Beauregard et tonton par la même

Voilà un peu un code léger en ressources (j'ai mis les commandes de flèche du jeu de tonton) qui donne une idée des déplacements du fond d'écran. Maintenant, je n'ai hélas pas envie ni le temps suffisant pour faire ou refaire un jeu actuellement.

(Et, toujours la même : ne pas oublier Directx9 dans l'option sous-sytème du menu des options de compilation)

Bon courage à vous.

Code : Tout sélectionner

;PB 4.30 le 10/01/09 (Comtois)
;20/03/09 Test défilement 2D (Ollivier)

Global Full.I = 1 ; 1 = FullScreen, c'est comme la boîte
                        ; auto : ça marche tout seul...

InitEngine3D()
InitSprite()
InitKeyboard()

#R2D = 180.0 / #PI

;Pour enregistrer au format PNG
UsePNGImageEncoder()

ExamineDesktops()
EcrL = DesktopWidth(0)
EcrH = DesktopHeight(0)
EcrP = DesktopDepth(0)
If Full
   OpenScreen(EcrL, EcrH, EcrP, "Tutoriel 3D")
Else
   OpenWindow(0, 0, 0, EcrL, EcrH, "DX9ParalX", $80000000)
   OpenWindowedScreen(WindowID(0), 0, 0, EcrL, EcrH, 0, 0, 0)
EndIf
;Pour charger une texture, mesh, entity , etc, indiquer le chemin où se trouvent ces médias
Add3DArchive("/", #PB_3DArchive_FileSystem)

Global ScrollX.F
Global ScrollY.F
Global AngleTeta.F
Global Coef.F

Global Angle.f, Vitesse.f

;-Mesh
#Mesh = 0
CreateMesh(#Mesh, 100)
Options = #PB_Mesh_Vertex | #PB_Mesh_Normal | #PB_Mesh_Color | #PB_Mesh_UVCoordinate
SetMeshData(#Mesh, Options      , ?Sommets, 24)
SetMeshData(#Mesh, #PB_Mesh_Face, ?Triangles, 12)

;-Textures
#Texture = 0
CreateImage(#Texture, 64, 64)

;Remplissage de la texture en blanc
StartDrawing(ImageOutput(#Texture))
Box(0, 0, ImageWidth(#Texture), ImageHeight(#Texture), $FFFFFF)
DrawingMode(#PB_2DDrawing_Outlined) ; Pour tracer le contour
Box(0, 0, ImageWidth(#Texture), ImageHeight(#Texture), 0)
StopDrawing()

;Enregistre l'image dans le même répertoire que le code source
Fichier$="TextureDVP1.PNG"
SaveImage(#Texture, Fichier$, #PB_ImagePlugin_PNG)

;Maintenant on peut charger notre texture
LoadTexture(#Texture, Fichier$)


#TextureSol = 1
CreateImage(#TextureSol, 512, 512)

;Remplissage de la texture en blanc
StartDrawing(ImageOutput(#TextureSol))
   Box(0, 0, ImageWidth(#TextureSol), ImageHeight(#TextureSol), $0)
   For I = 0 To 500
      R = Random(127) + 128
      X = Random(511)
      Y = Random(511)
      Plot(X, Y, RGB(R, R, R) )
      For D = 1 To 5
         C = RGB(R / 1 << D, R / 1 << D, R / 1 << D)
         Line((X - D << 1) & 511, (Y) & 511, -2, 1, C)
         Line((X + D << 1) & 511, (Y) & 511, 2, 1, C)
         Line((X) & 511, (Y - D << 1) & 511, 1, -2, C)
         Line((X) & 511, (Y + D << 1) & 511, 1, 2, C)
         For DX = -1 To 1 Step 2
            For DY = -1 To 1 Step 2
               Plot((X + DX * D) & 511, (Y + DY * D) & 511, C)
            Next DY
         Next DX
      Next D
   Next I
StopDrawing()


;Enregistre l'image dans le même répertoire que le code source
Fichier$="TextureDVP2.PNG"
SaveImage(#TextureSol, Fichier$, #PB_ImagePlugin_PNG)

;Maintenant on peut charger notre texture
LoadTexture(#TextureSol, Fichier$)

;-Matière
#Matiere = 0
CreateMaterial(#Matiere, TextureID(#Texture))

#MatiereSol = 1
CreateMaterial(#MatiereSol, TextureID(#TextureSol))
For I = 1 To 3
   AddMaterialLayer(#MatiereSol, TextureID(#TextureSol), #PB_Material_Replace)
Next I

;-Entity
#Entity = 0
CreateEntity(#Entity, MeshID(#Mesh), MaterialID(#Matiere))
ScaleEntity(#Entity, 10, 10, 10) ; Agrandi l'entity
EntityLocate(#Entity, 500, 5, 500)

#EntitySol = 1
CreateEntity(#EntitySol, MeshID(#Mesh), MaterialID(#MatiereSol))
ScaleEntity(#EntitySol, 1000, 2, 1000) ; Agrandi l'entity
EntityLocate(#EntitySol, 500, -50, 500)

;-Camera
#Camera = 0
CreateCamera(#Camera, 0, 0, 100, 100)

;-Light
;AmbientColor(RGB(55,55,55)) ; Réduit la lumière ambiante pour mieux voir les lumières
;#LightRouge = 0 : CreateLight(#LightRouge,RGB(255, 0, 0),    0, 500,    0)
;#LightBleue = 1 : CreateLight(#LightBleue,RGB(0, 0, 255),    0, 500, 1000)
;#LightVerte = 2 : CreateLight(#LightVerte,RGB(0, 255, 0), 1000, 500, 1000)

;- Sprite pour afficher l'aide
Procedure SpriteText(Text.S)
   CreateSprite(64000, 256, 24)
   StartDrawing(SpriteOutput(64000) )
      DrawText(0, 0, Text, #White, #Black)
   StopDrawing()
EndProcedure

;- Démarrage
CameraLocate(#Camera, 500, 500, 500)
RotateCamera(#Camera, 270, 270, 0)

Angle = #PI / 2.0

RotateEntity(#Entity, 0.0, 90.0, 0.0, PB_Absolute)
Repeat
   Delay(1) ; On prévient Windows qu'on est cool
   If Full
      Delay(1)
      Delay(1) 
      Delay(1)
      Delay(1)
      Delay(1)
      Delay(1)
      Delay(1)
   Else
      WindowEvent()
   EndIf
   If ExamineKeyboard()

    If KeyboardPushed(#PB_Key_Up)
      Vitesse + 0.0001
    EndIf
    Vitesse * 0.99
   
    If KeyboardPushed(#PB_Key_Left)
      Angle + 0.1
      RotateEntity(#Entity, 0.0, Angle * #R2D, 0.0, PB_Absolute)
    ElseIf KeyboardPushed(#PB_Key_Right)
      Angle - 0.1
      RotateEntity(#Entity, 0.0, Angle * #R2D, 0.0, PB_Absolute)
    EndIf

  EndIf
  ScrollX + Cos(Angle) * Vitesse
  ScrollY + Sin(Angle) * Vitesse
     
   For I = 0 To 3
      Coef = 1.0 / (1 + I)
      ScrollMaterial(#MatiereSol, ScrollX / Coef, ScrollY / Coef, #PB_Material_Fixed, I)
   Next I
  RenderWorld()

  FlipBuffers()

Until KeyboardPushed(#PB_Key_Escape)

End
;{ Définition du cube
DataSection
  Sommets:
  ;Dessus 0 à 3
  Data.f -0.2,0.5,-0.5
  Data.f 0,1,0
  Data.L 0
  Data.f 0,0

  Data.f 0.2,0.5,-0.5
  Data.f 0,1,0
  Data.L 0
  Data.f 0,1

  Data.f 0.2,0.5,0.5
  Data.f 0,1,0
  Data.L 0
  Data.f 1,1

  Data.f -0.2,0.5,0.5
  Data.f 0,1,0
  Data.L 0
  Data.f 1,0

  ;Dessous 4 à 7
  Data.f -0.5,-0.5,0.5
  Data.f 0,-1,0
  Data.l 0
  Data.f 0,0

  Data.f 0.5,-0.5,0.5
  Data.f 0,-1,0
  Data.L 0
  Data.f 0,1

  Data.f 0.5,-0.5,-0.5
  Data.f 0,-1,0
  Data.L 0
  Data.f 1,1

  Data.f -0.5,-0.5,-0.5
  Data.f 0,-1,0
  Data.L 0
  Data.f 1,0

  ;Devant 8 à 11
  Data.f -0.5,0.5,0.5
  Data.f 0,0,1
  Data.l 0
  Data.f 0,0

  Data.f 0.5,0.5,0.5
  Data.f 0,0,1
  Data.l 0
  Data.f 0,1

  Data.f 0.5,-0.5,0.5
  Data.f 0,0,1
  Data.l 0
  Data.f 1,1

  Data.f -0.5,-0.5,0.5
  Data.f 0,0,1
  Data.l 0
  Data.f 1,0

  ;Derrière 12 à 15
  Data.f 0.5,0.5,-0.5
  Data.f 0,0,-1
  Data.l 0
  Data.f 0,0

  Data.f -0.5,0.5,-0.5
  Data.f 0,0,-1
  Data.l 0
  Data.f 0,1

  Data.f -0.5,-0.5,-0.5
  Data.f 0,0,-1
  Data.l 0
  Data.f 1,1

  Data.f 0.5,-0.5,-0.5
  Data.f 0,0,-1
  Data.l 0
  Data.f 1,0

  ;Cote gauche 16 à 19
  Data.f -0.5,0.5,-0.5
  Data.f -1,0,0
  Data.l 0
  Data.f 0,0

  Data.f -0.5,0.5,0.5
  Data.f -1,0,0
  Data.l 0
  Data.f 0,1

  Data.f -0.5,-0.5,0.5
  Data.f -1,0,0
  Data.l 0
  Data.f 1,1

  Data.f -0.5,-0.5,-0.5
  Data.f -1,0,0
  Data.l 0
  Data.f 1,0

  ;Cote droit 20 à 23
  Data.f 0.5,0.5,0.5
  Data.f 1,0,0
  Data.l 0
  Data.f 0,0

  Data.f 0.5,0.5,-0.5
  Data.f 1,0,0
  Data.l 0
  Data.f 0,1

  Data.f 0.5,-0.5,-0.5
  Data.f 1,0,0
  Data.l 0
  Data.f 1,1

  Data.f 0.5,-0.5,0.5
  Data.f 1,0,0
  Data.l 0
  Data.f 1,0

  Triangles:
  ;Face en Haut
  Data.w 2,1,0
  Data.w 0,3,2
  ;Face en Bas
  Data.w 6,5,4
  Data.w 4,7,6
  ;Face Avant
  Data.w 10,9,8
  Data.w 8,11,10
  ;Face Arrière
  Data.w 14,13,12
  Data.w 12,15,14
  ;Face Gauche
  Data.w 18,17,16
  Data.w 16,19,18
  ;Face Droite
  Data.w 22,21,20
  Data.w 20,23,22
EndDataSection
;}

Ollivier a écrit :@Dr Dri

[...]

Pour la tasse de thé, il s'agit de ton regretté avatar qui n'est plus.

[...]

Et si je jète mon dévolu sur toi, c'est parce que je lis une règle que tu dis et qui est vraie (ImportanteCondition = StartDrawing() ) en théorie. Mais, l'architecture proposée par Comtois pour faire de la 3D à la base, évite la nécessité d'user de cette instruction dans une boucle principale. Donc, finalement, ce que tu as dit ne correspond hélas plus à la réalité!
(Zéro dessins en temps réel, 0 sprites, etc...) Et puis ça marche très bien sous Windows, comme sous Linux (à moins d'une remarque contraire).

[...]

Voilà Dr Dri!

Ollivier

Pour la tasse de thé j'aurais pas pu trouver tout seul

Elle a disparu en même temps que PureStorage et je n'ai pas reçu le contenu de mon compte alors que je l'ai demandé en message privé...

Pour le reste, j'adore comtois en tant que membre du forum (comme beaucoup de monde ici d'ailleurs) mais je ne suis pas non plus fan de comtois au point de faire tout pareil. Là t'as juste réussi à me démontrer que tu n'as jamais eu de StartDrawing qui échoue dans un topic où on se rend compte que la config de l'utilisateur joue énormément sur les performances et le comportement du programme.

Je n'ai pas non plus de preuve que StartDrawing a déjà échoué chez moi donc tu devras te contenter de ma parole... Dans la mesure où il est possible que ça arrive, il faut traiter l'éventualité! Le risque zéro n'existe pas, et non je ne suis pas sponsorisé par durex

C'est pareil pour les fonctions InitXXX(), il faut absolument s'assurer que l'initialisation a fonctionné avant de poursuivre. Faut pas se dire que puisque sa fonctionne sur ma machine y'a pas de raison que ça fonctionne pas chez les autres... Y'a des centaines de raisons puisque chaque machine est unique.

Dri

Ollivier a écrit :@Dobro

Des questions techeniques à ce sujet ?

(Woilà pourquoi, pour moi ce débat est clos depuis 3 pages )

Ollivier

pourquoi aurai-je des questions ??

j'apprends rien là !

tu n'emplois pas clearscreen() parceque tu efface les traces de tes sprites !!

(au fait le "chalenge" n'est pas respecté , car nos exemples contiennent des sprites de tailles différentes et de couleurs différentes !! )

donc je disais tu efface la trace de tes sprites, c'est une technique que j'ai deja employé ici, il y a fort longtemps (je peux le prouver

)

mais ton exemple reste tres intéressant malgré tout

toutefois le "debat" enfin, la discutions est intéressante , elle ne sera jamais vraiment close

toutefois, je me demande (j'ai la bulle d'analyser la fonction en ass )
comment fred a fait le clearscreen !!??

il aurai peut etre pu nous faire un clearscreen rapide
en copiant direct un champs de valeur dans la memoire video

enfin un truc qui fasse l'effacement en un seul vbl

parcequ'au vu du ralentissement provoqué, je supose que clearscreen()
est particulierement lent ... et pas synchro avec la vbl (d'ou les saccades)

enfin ....

faudrai un Tonton ou un denis pour nous expliquer comment fonctionne le clearscreen()

pour ma part, je ne pense pas que clearscreen() soit une technique de debutant !!

c'est simplement le clearscreen() qu'il faut surement revoir !!

Dr. Dri a écrit :Les entiers sont "has been" ??? Entièrement d'accord avec toi. On est plus à une époque où on calquait le fonctionnement interne d'un "jeu" sur les coordonnées de l'écran.

L'influence de la famille de cpu des PC a peut être une influence sur ce sujet précis: le 68060 semble architecturé différement:

Code : Tout sélectionner

Cependant, la FPU du 68060 n'est pas pipelinée et fonctionne trois fois moins vite que celle du Pentium dans les applications à virgule flottante. A contrario, les multiplications entières et les instructions de décalages de bits sont sensiblement plus rapides sur les 68060.

http://fr.wikipedia.org/wiki/Motorola_68060

@Dr Dri,

Tiens? Je t'ai énervé tant que ça ?!? Bon...

1) Je n'ai pas le temps des débats "caduques", c'est-à-dire sans code, ni référence technique.

2) Quite à débattre, ne t'étale pas sur autre chose: t'emmène les InitMachin() maintenant?

Ben tiens! Code! Il y a un glandu sur le forum officiel qui, il y a 15 mois a écrit ici, ceci:

Code : Tout sélectionner

Macro Init(a, b = Init, c = ")

      If b#a() = 0
     
            MessageRequester("Message", "DirectX error !" + Chr(10) + c#a can't be initialized !")
            End
     
      EndIf

EndMacro



      Init(Sprite)
      Init(Mouse)
      Init(Keyboard)

Tu veux que je te prouve qu'un StartDrawing ne crashe pas?
Ben, prouve-moi que mes StartDrawing() sont susceptibles de crasher dans mon code ci-dessus!!! Après tu viendras émettre une critique sur du code que je déballe pour le bonheur de ce sujet et sous l'intérêt majeur du titre de ce sujet : performance des jeux en 2D.

Je traduis cela par une étude précise de la boucle principale, où, visiblement je suis le seul à avoir fait valser les startdrawing() et les sprites, et, à l'exception de la chronométrie sous Linux, place à une qualité irréprochable de code.

Et je suis déçue que, toi quelqu'un que j'apprécie depuis Ben-Hur, tu viennes me dire, sans aller à la pêche que mon poisson, il pue!

@Dobro

Dobro a écrit :
pourquoi aurai-je des questions ??

j'apprends rien là !

Mh... Si tu regardes les performances de ce code, je te défies de poster un code plus puissant que ça. A mes yeux, ceci est la base d'un moteur de jeu 2D.

C'est en ce sens que le ClearScreen() est hors sujet et obsolète, comme les StartDrawing() dans une boucle principale, et comme les sprites, et Sprite3D()!!!

Maintenant, si le débat n'était pas la où je pense qu'il doit être, je ne vais pas continuer à déballer du code si je ne vois pas naître (et oui, parce c'est nouveau, il faut l'admettre aussi, ce serait sympa!) une maîtrise de ce code.

Merci beaucoup.

Ollivier

voila donc ma version du code avec sprite effaceur au lieu d'utiliser clearscreen()

et qui garde la taille des sprites,

c'est vrais que de se passer de clearscreen() ajoute une stabilité au mouvement !

va vraiment falloir que Fred nous ponde un clearscreen() turbo !!
car c'est quand meme pratique

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")
; ******************** le sprite effaceur ********************** 
CreateSprite(8000, 5, 5)
StartDrawing(SpriteOutput(8000))
    Box( 0,0,5,5,RGB(0,0,0))
StopDrawing()
; *************************************************************
; *********** 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
; ***************************************************************

Repeat
    go= ElapsedMilliseconds() 
    For t= 0 To nbr_sprite 
   
         DisplaySprite(8000,sprite(t)\x-(sprite(t)\vitesse*2),sprite(t)\y) ; le sprite effaceur !
        DisplayTransparentSprite(t,sprite(t)\x,sprite(t)\y) 
     
        sprite(t)\x=sprite(t)\x+sprite(t)\vitesse 
    
        If   sprite(t)\x>EcranX+(sprite(t)\vitesse *2)
            sprite(t)\x=0-sprite(t)\vitesse 
        EndIf 
    Next t
    FlipBuffers()
    
    temps=ElapsedMilliseconds()-go
    StartDrawing(ScreenOutput())
        DrawText(10,10,"Temps: "+Str(temps))
    StopDrawing() 
    ExamineKeyboard()
    If  KeyboardPushed(#PB_Key_Escape)
        End
    EndIf 
   ; ClearScreen(0) ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  voila retiré !
   Delay(2) 
ForEver [quote][/quote]

Ben, prouve-moi que mes StartDrawing() sont susceptibles de crasher

J'ai déjà eu à faire a se genre de comportement étrange lors de l'écriture de ma GUI. pourquoi ca plante ? j'en sais rien.

C est tres long pour éffacer un écran
pour une resolution de 1280*1024 32bits
il faut une boucle de 1 310 720 cycles

en utilisant les instructions SSE 128 bits on passe a 327 680 cycles....

c est claire qu en se passant d éffacer ca va bien plus vite

j ajoute que les entiers ne sont pas démodé.. il n y a pas que la 3D dans un PC

Ollivier a écrit :@Dr Dri,

Tiens? Je t'ai énervé tant que ça ?!? Bon...

1) Je n'ai pas le temps des débats "caduques", c'est-à-dire sans code, ni référence technique.

2) Quite à débattre, ne t'étale pas sur autre chose: t'emmène les InitMachin() maintenant?

Ben tiens! Code! Il y a un glandu sur le forum officiel qui, il y a 15 mois a écrit ici, ceci:
Code : Tout sélectionner
Macro Init(a, b = Init, c = ")

      If b#a() = 0
     
            MessageRequester("Message", "DirectX error !" + Chr(10) + c#a can't be initialized !")
            End
     
      EndIf

EndMacro



      Init(Sprite)
      Init(Mouse)
      Init(Keyboard)
Tu veux que je te prouve qu'un StartDrawing ne crashe pas?
Ben, prouve-moi que mes StartDrawing() sont susceptibles de crasher dans mon code ci-dessus!!! Après tu viendras émettre une critique sur du code que je déballe pour le bonheur de ce sujet et sous l'intérêt majeur du titre de ce sujet : performance des jeux en 2D.

Je traduis cela par une étude précise de la boucle principale, où, visiblement je suis le seul à avoir fait valser les startdrawing() et les sprites, et, à l'exception de la chronométrie sous Linux, place à une qualité irréprochable de code.

Et je suis déçue que, toi quelqu'un que j'apprécie depuis Ben-Hur, tu viennes me dire, sans aller à la pêche que mon poisson, il pue!

@Dobro
Dobro a écrit :
pourquoi aurai-je des questions ??

j'apprends rien là !
Mh... Si tu regardes les performances de ce code, je te défies de poster un code plus puissant que ça. A mes yeux, ceci est la base d'un moteur de jeu 2D.

C'est en ce sens que le ClearScreen() est hors sujet et obsolète, comme les StartDrawing() dans une boucle principale, et comme les sprites, et Sprite3D()!!!

Maintenant, si le débat n'était pas la où je pense qu'il doit être, je ne vais pas continuer à déballer du code si je ne vois pas naître (et oui, parce c'est nouveau, il faut l'admettre aussi, ce serait sympa!) une maîtrise de ce code.

Merci beaucoup.

Ollivier

Oulaaaaaaaaa, je ne suis pas énervé, j'ai pas le temps pour ça!

A la base je parle des Start/Stop à titre indicatif, vu que j'ai fait l'effort de lire un de tes codes pour constater que tu avais effectivement mis en commentaire le ClearScreen. C'est en lisant ton code que j'ai constaté que les Start ne sont pas vérifiés.

Pour les Init, je dérive juste en disant qu'il n'y a pas que les Start à vérifier, sans vouloir lancer le débat là dessus.

Je sais qu'on parle de performances mais je ne pense pas qu'il faille gagner quelques cycles d'exécution pour ne pas contrôler le Start. La performance au détriment de la qualité est selon moi une dérive.

Là où tu me déçois, c'est quand tu dis "Tu veux que je te prouve qu'un StartDrawing ne crashe pas? Ben, prouve-moi que mes StartDrawing() sont susceptibles de crasher". J'ai déjà dit que je n'ai aucune preuve que ça peut échouer, et que je n'ai que ma parole pour affirmer que ça m'est déjà arrivé.

Maintenant je ne crache sur le code de personne. J'ai juste donné mon avis sur la forme à plusieurs reprises. Je dis aussi que pour moi aucune fonction n'est à l'abri de l'échec... Ta macro est sympa, et surtout bien pensée. Mais ça ne change pas mon avis sur les Start/Stop.

Je le répète, y'a plein de gens que j'adore sur ce forum, je ne suis certainement pas venu créer des conflits...

Dri

@Dobro

J'ai testé ton code. Le problème est désormais dans la prise de ressources (90% sur 1GHz mono-core avec XP). J'en parle tout en bas de ce post, à tonton.

Cpl.Bator a écrit :
Ben, prouve-moi que mes StartDrawing() sont susceptibles de crasher
J'ai déjà eu à faire a se genre de comportement étrange lors de l'écriture de ma GUI. pourquoi ca plante ? j'en sais rien.

@Cpl.Bator

Je charrie un peu Dr Dri. Je sais bien qu'il faut vérifier cette instruction dans un système stable. Et que la stabilité fait partie de la performance. Seulement, je trouvais gros qu'il zoome sur une partie de prog superflue alors que le détail qui me semblait important à démontrer lui est passé sous les semelles!

Et puis le coup du Comtois fan, ou pas fan : ça n'a rien à voir. Je respecte dûment chaque personne qui m'apporte du code que j'utilise par la suite. Je cite Dr Dri dans un commentaire près d'une procédure Atan en assembleur en le remerciant, ou Dobro pour son aide pour les années bissextiles, etc...

Je trouve que c'est plus cool de mettre un peu l'historique des auteurs, même si ça reste une notion éphémère.

Et sans un code de Comtois qu'il a fait après la sortie de la version 4.30, je ne pense pas que j'aurai retesté Ogre et ces nouvelles fonctionnalités.

Aussi, est-ce que tu as pu tester le code sous Linux? Logiquement, ça fonctionne mal, puisque ce n'est pas "bridé". Je vais inclure la chronométrie que t'as préciser en début de sujet.

@tonton

tonton a écrit :j ajoute que les entiers ne sont pas démodé.. il n y a pas que la 3D dans un PC

Pour les entiers, je suis entièrement d'accord avec toi, sinon Fred n'a plus qu'à virer le type entier pour la version 5.

J'ajoute aussi que je critique le code de ton jeu, en ayant bien conscience que tu as fait avec les moyens du bord, et que tu t'es très bien démerdé, notamment dans l'absence de médias externe.

tonton a écrit :il n y a pas que la 3D dans un PC

Alors c'est tout à fait vrai. Seulement, c'est quand même un plaisir de créer quelque chose de très fluide. Et s'il y a bien un progrès optimiste à l'heure actuelle c'est celui de la puissance informatique: une carte graphique gère les translations et les rotations comme une poignée de registres à modifier pour chacune des deux fonctionnalité.

A mon avis (et je vais me contredire par rapport aux "éléments obsolètes" décrits plus hauts) la vraie 2D, c'est à dire la 2D des jeux de plate-forme nécessite une mise à jour interne du monde à découvrir. Et c'est là qu'interviennent les sprites.

Dessiner directement en temps réel est rarement nécessaire. Avant, c'était la seule méthode possible. Mais aujourd'hui, les sprites remplissent le rôle de "réafficheur": il n'y a plus besoin de vectoriser les calculs, les optimiser au risque de perdre de la fluidité pour obtenir des calculs de "réaffichage", c'est-à-dire dessiner un dessin semblable sur un décor modifié à l'écran.

Les sprites dit "sprite3D" permettent de déformer, tourner et zoomer. Les zoom et rotation sont assez légères en ressources. Seulement, d'une part, on reste dans le concept du sprite, c'est-à-dire un réaffichage quasi-constant, d'autres part, les déformations bouffent des ressources en calcul au niveau CPU central.

La 3D a, comme fonctionnalité nouvelle de:
- calculer les déformations de sprite3D au niveau GPU selon le concept de vision 3D.
- réafficher au niveau GPU
- scroller les textures, selon le concept purement 2D
- éventuellement obtenir une rotation de texture toujours selon le concept 2D

Et bien quand ces fonctionnalités sont disponibles sur la plus pourrie des cartes vidéo actuelles, on se rend compte que la face d'une entité (2 triangles rectangles) est analogue à la "mémoire-ruban" dans anciennes cartes EGA et premières cartes VGA.

Et qu'une instruction comme ScrollMaterial() est analogue aux fonctions antiques consistant à modifier les registres d'offset d'affichage du contrôleur CRT de la carte vidéo.

ça n'est pas exact, mais entre l'instruction simplissime et le résultat de défilement, le process employé et obtenu est, lui, exactement le même.

Alors pourquoi lui faire la gueule à cette 3D!?!

@Dr Dri

Désolé, on a répondu dans le même temps!

tonton a écrit :C est tres long pour éffacer un écran
pour une resolution de 1280*1024 32bits
il faut une boucle de 1 310 720 cycles

en utilisant les instructions SSE 128 bits on passe a 327 680 cycles....

c est claire qu en se passant d éffacer ca va bien plus vite

crois tu que Fred pourrai nous faire un clearscreen() plus rapide que celui qu'on a ??

si je me pose la question, c'est que je reste persuadé que la fonction clearscreen() est une bonne solution, il suffirait juste qu'il soit optimisé

bien sur qu'on peut bidouiller, mais cette fonction , si elle etait vraiment rapide, serai un plus pour le purebasic
apres tout elle est prevu pour ça a la base !

je reste meme persuadé qu'un clearscreen (x,y,larg,haut,coul)
hyper rapide, pourrai permettre quelque bon delire !!

ne serai-ce que pour dessiner un decors de jeux 2d

l'utilisation d'un sprite devrai en principe etre plus rapide qu'un clearscreen() , puisque qu'une copie peut etre utilisé
peut etre moins de cycle a ce niveau ...

finalement , on a peut etre deja tout ce qu'il faut !

bon j'arrete de penser tout haut !

Merci de ta lumiere Tonton

Ollivier a écrit :La 3D a, comme fonctionnalité nouvelle de:
- calculer les déformations de sprite3D au niveau GPU selon le concept de vision 3D.
- réafficher au niveau GPU
- scroller les textures, selon le concept purement 2D
- éventuellement obtenir une rotation de texture toujours selon le concept 2D

Et bien quand ces fonctionnalités sont disponibles sur la plus pourrie des cartes vidéo actuelles, on se rend compte que la face d'une entité (2 triangles rectangles) est analogue à la "mémoire-ruban" dans anciennes cartes EGA et premières cartes VGA.

Et qu'une instruction comme ScrollMaterial() est analogue aux fonctions antiques consistant à modifier les registres d'offset d'affichage du contrôleur CRT de la carte vidéo.

ça n'est pas exact, mais entre l'instruction simplissime et le résultat de défilement, le process employé et obtenu est, lui, exactement le même.

Alors pourquoi lui faire la gueule à cette 3D!?!

Tu as tout à fait raison

D'ailleurs on pourrait appliquer quelques-unes de ces "fonctionnalités" très simplement aux "sprites3d" de pure, pour pouvoir faire de beaux scrolls par exemple.

PureBasic

Performance d'un jeu en 2D