DrawingBuffer()

[jerexgrz]

Pour etre plus precis dans la doc, j'aurais mis un exemple de ce type, car l'autre est complexe (long à analyser, ... mais il est bien!!):

Code : Tout sélectionner

InitSprite()
InitKeyboard()

OpenScreen(800,600,32,"")

Repeat
ClearScreen(RGB(150,30,50))

StartDrawing(ScreenOutput())     
  
  Plot(1,1,RGB(255,0,0))   
  Plot(5,5,RGB(15,0,0)) 
  
  pf = 4   ; Car le codage des couleurs est basé sur 4 octets => 32 bits (openscreen ...)
  ; On recupere la couleur du point (1;1)
  ; drawingbufferpitch() est dejà en octet, pas besoin de conversion ...
  test = PeekL(DrawingBuffer() + (1*PF)+ DrawingBufferPitch() * 1) 
  test2 = PeekL(DrawingBuffer() + (5*PF)+ DrawingBufferPitch() * 5)
    
  ; On affiche le point recuperer en (1;1) à l'endroit (32;32)   
  PokeL(DrawingBuffer() + 32*PF + DrawingBufferPitch() * 32,test)  
  PokeL(DrawingBuffer() + 50*PF + DrawingBufferPitch() * 50,test2) 

  verif  = Point(32,32)
  verif2 = Point(50,50)   
       
StopDrawing()
 
  Debug "=== VERIF 1 ===" 
  Debug Str(Red(verif)) + ";" + Str(Green(verif)) +";" + Str(Blue(verif))
  Debug "=== VERIF 2 ==="
  Debug Str(Red(verif2)) + ";" + Str(Green(verif2)) +";" + Str(Blue(verif2))
  Debug "-- ATTENTION LES VALEURS DE ROUGE ET BLEU SONT INVERSEES ----"  
  Debug Str(Red(test2)) + ";" + Str(Green(test2)) +";" + Str(Blue(test2))  
  Debug " "
    
FlipBuffers(0)

ExamineKeyboard()
Until KeyboardPushed(#PB_Key_Escape)

Aussi, on voit qu'il y a des conversions de couleurs Rouge et Bleu (pas d'explications dans la doc). Donc pourquoi ne pas ouvrir un ecran de ce type:
openscreen(800,600,RGB32,"Test1")
ou openscreen(800,600,BGR32,"test1")
ou meme utiliser les constantes de DrawingBufferPixelFormat().
Comme ca, on gagne du temps en evitant des conversions.

question aussi : Debug DrawingBufferPitch() en 1024*768 => 4096
Debug DrawingBufferPitch() en 800*600 => 4096
Debug DrawingBufferPitch() en 640*480 => 4096 (affichage decalé )
Normalement, comme l'ecran en X est plus petit drawingbuffer() devrait etre + petit ??

[Anonyme]

Cette histoire de Couleur c'est une histoire de processeur il me semble.

Little ou big endian. , c'est à dire que les données ne sont pas rangé dans le même ordre ( tu lis de la gauche vers la droite ou l'inverse)
d'ou se "décalage" entre le rouge et le bleu


$64 128 255 ; Big endian.
$255 128 64 ; Litlle endian.


la fonction RGB modifie les composante R & G & B
mais cela ne veut pas dire quelles se suivent dans la mémoire.

$FF0000 , c'est du bleu , pas du rouge.
$FF , c'est du rouge
$0000FF , du bleu.
$00FF du rouge
$00FF00 du vert

Voilà , j'espère être clair.

[djes]

C'est plutôt une histoire de carte graphique. C'est elle qui dicte dans quel ordre les couleurs sont rangées en mémoire. Peut-être une histoire de chip (processeur) sur la carte, tout en sachant que certaines s'accommodent très bien de modes différents.

[jerexgrz]

J'ai travaillé sur ton exemple Cpl.Bator ! C'était franchement interessant !
Je dirais que c'est encore les Anglais qui ont le cerveau a l'envers ... lol
Pourquoi faire simple quand on peut faire compliquer ...