Discussion :

[megs]

Bonjour,

j'ai des soucis avec la récuperation de valeurs lorsque je passe du pascal à l'assembleur dans des fonctions tels que celle-ci. Mon objectif est de passer d'un assembleur inclus à une fonction assembleur intégrale, mais ce probleme me freine.En effet soit le compilateur me dit que je fait une erreur de syntaxe, soit il me renvoie une valeur 0... pourtant le guide assembleur delphi est clair:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
//-----------------------------------------------------------------------
Procedure TGView.SetPixel(x,y,c:longint);
//-----------------------------------------------------------------------  <>
var
  W,H:longword;
begin
 W:=self.p_Buffer.Width; H:=self.p_Buffer.Height;
  asm
  push eax  
  // Clipping
   mov eax,W
   dec eax
   cmp eax,x
  JL @Jclip_SetPixel
   mov eax,H
   dec eax
  cmp eax,y
  JL @Jclip_SetPixel
  cmp x,0
  JL @Jclip_SetPixel
  cmp y,0
  JL @Jclip_SetPixel
  // Affichage du pixel
  mov eax,W
  mul eax,y
  add eax,x
  shl eax,2
  pop edx
  add eax,[edx].TGView.p_PTRBuffer    <------------ ça devrais fonctionner
  mov ecx,c
  mov dword [eax],ecx
  @Jclip_SetPixel:
  end;
end;

Ceci me renvoie 0 pourquoi ?, p_PTRBuffer est un "pointer" dans les privates d'un component perso TGVIEW.

Par ailleurs je n'arrive pas non plus à acceder à self.p_Buffer.Width ou self.p_Buffer.Height en ASM, J'ai un Tbitmap en sous objet de mon component(TGVIEW) déclaré dans la partie private(p_pBuffer) mais ceci ne fonctionne pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
push eax
....
pop edx
mov eax,[edx].TGView.p_pBuffer.Width

Ni ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
push eax
....
pop edx
mov eax,[edx].TGView.p_pBuffer
mov edx,[eax].Tbitmap.Width

un coup de pouce please !

[ShaiLeTroll]

Question conne : Pourquoi en Assembleur ?
A l'époque du Cross-Plateforme, c'est une direction étrange !

si p_pBuffer est un TBitmap
Width d'un TBitmap, c'est une propriété avec un accesseur virtuel abstrait GetWidth, a mon avis ce n'est pas aussi simple que cela !

[megs]

Bha pasque je ne fait pas du code pour du cross platform... je recherche a optimiser les performances pour le plaisir de me faire mal .

C'est surtout par ce que je créer un component d'affichage qui utilise le pointeur de scanline d'un Tbitmap pour un "moteur 3D" maison.. ca faisait si longtemps que je cherche à en faire, un. J'ai compris comment obtenir un buffer au travers d'un canvas, et tbitmap que depuis tres peut de temps en fait. (Je suis resté bloqué au tp7...Le passage à delphi ma fait perdre trops de repères..Et puis disparition du DOS...malheur mais ou c'est qu'on affiche un pixel ? Et comment qu'on fait l'attente de retour faisceau ??? ca cintille pas bô ... perdu quoi.... Alors quand j'ai vu un post qui parlait de rapidité avec un buffer tbitmap et les scanline, j'ai retrouver mon élément... d'ailleurs je l'ai tellement retrouvé que mes procédure accaparent carrément tout le temps machine, et ne traite les events bouton qu'une foi les affichages terminé...Sur c'est rapide.. je suis obliger de caler des delay(100) pour pouvoir voir les animations... mais bon... pas d'event dans la boucle d'affichage .

D'ailleurs si quelqu'un sait comment invoquer le traitement des évents en appel de procédure au sein d'une boucle sans que le travail d'affichage soit trops sacrifié je suis preneur.

ARGHHH! C'est ce que je craignais..... bon bah va falloir que je creer une variable privée à la base du TGVIEW contenant les bonnes données, mises a jours aux bon moments. C'est vraiment de la mémoire et du temps machine bouffé pour rien.

Et donc en private, comment j'accède à ses variables en ASM ???

[ShaiLeTroll]

Et donc en private, comment j'accède à ses variables en ASM ???

En théorie, private indique qu'une propriété n'est pas visible de l'extérieur, j'ignore si le compilateur ASM inclu à Delphi respecte la visibilité des objets ou pas !
En fait, j'espère qu'il les respecte !

Tu utilises de l'ASM mais tu passe par un TBitmap
C'est pas logique, autant utiliser directement les "Device Context" des API Windows directement !
Un code Delphi bien écrit sera peut-être plus performant qu'un mauvais ASM !
On a vu cela souvent sur Phidels !

Sinon, pour éviter les scintillement, la technique est de travailler sur deux buffers
un thread A, écrit dans le buffer Off, une fois prêt, il envoie un signal A à un thread B pour lire ce buffer Off (un TEvent par exemple), il attend le Signal B
ce thread B prend ce buffer Off et le permute avec le Buffer On, emet le Signal B puis le dessine sur le Form.Canvas
le thread A ayant reçu le signal B, utilise le nouveau buffer Off pour créer l'image suivante, dès qu'il a fini, il envoi un signal A à thread B et attend
le thread B ...
les deux threads passent leur temps à intervertir les deux buffer entre la position OffScreen et OnScreen, le Thread A ne travail que sur le buffer en mode Off et le Thread B ne travail que sur le buffer en mode On

le thread B pourrait être le thread principal, dans ce cas, une simple TCriticalSection pour la méthode de synchronisation protégeant la permutation au lieu d'un système de Signaux
OnIdle pourrait être le bon moment pour gérer l'affichage
Ne pas oublier la TCriticalSection autour du Canvas.CopyRect
le thread principal étant peu sollicité, il devrait pouvoir recevoir ses évènements

Si tu n'utilises aucun thread, il te faut faire appel à Application.ProcessMessages() pour réagir au Clic, Clavier ... attention, cela consomme un peu de temps !


C'est la technique nommé "Switch Surface" pour DirectX ou "Page Flipping" pour DirectDraw que j'ai expérimenté via DelphiX en D4

Il y a aussi le TForm DoubleBuffered, cela peut améliorer le travail sur le Form.Canvas

Pense que la plupart des jeux vidéos 3D utilisent le Proc à 100% car leur boucle principale carbure à fond tout le temps !

D'ailleurs, pour augmenter les performances, on utilise même la technique du triple buffer, avec un buffer Off, un buffer Wait et un Buffer On, car si l'on calcule plus vite les images qu'on les affiche, on peut ainsi permuter avec le buffer Wait plusieurs fois sans bloquer le thread de calcul ! le thread d'affichage affichant le BufferOn va le plus vite qu'il le peut mais peu louper des images, il peut aussi se synchroniser avec le défilement vertical (voir les API des drivers des CG)

Sinon pour la 3D, il existe FireMonkey, qui sera plus performant que ton moteur perso, pour la simple raison qu'il utilise DirectX ou la lib lié à l'OS, et profite des accélérations matérielles liés au carte graphique, le processeur ne faisant lui pas grand chose sur la 3D en réalité à part mettre les ressources à dispositions, par contre, il gère le modèle physique qui influe sur le modèle graphique 3D

[Nono40]

SI tu veux vraiment travailler en assembleur sur une image je te conseille très fortement d'utiliser la propriété ScanLine. Si le bitmap est au format pf32Bits tu as un pixel RGB sur un mot de 32 bits (y'a 8 bits qui ne servent pas).

Tu peux ainsi fairte une fonction SetPixel beaucoup plus rapide que celle de Delphi.

ScanLine c'est décrit ici : http://nono40.developpez.com/tutorie.../efg/scanline/

Un exemple applicatif ici :
http://nono40.developpez.com/sources/source0069/

Accéder aux objets nécessite de savoir comment ils sont codés, suivant que ce soit ou non des méthodes implictes le code ne sera pas le même. J'avais commencé à regarder ici mais je ne suis pas allé plus loin, trop ingérable. Et aussi dépendant des objets. Par exemple ne méthode d'accès statique devevant virtuelle fonctionne bien en Pascal mais ton code assembleur devient faux.

[tourlourou]

Par ailleurs je n'arrive pas non plus à acceder à self.p_Buffer.Width ou self.p_Buffer.Height en ASM
ceci ne fonctionne pas : mov eax,[edx].TGView.p_pBuffer.Width
Ni ceci : mov edx,[eax].Tbitmap.Width

quand on déréférence un champ, le compilo stocke l'adresse de l'objet dans un registre, additionne le décalage correspondant à l'offset du champ, puis va lire le champ à cette adresse.

en assembleur, il ne doit pas falloir compter faire ceci implicitement...

[Andnotor]

Si le bitmap est au format pf32Bits tu as un pixel RGB sur un mot de 32 bits (y'a 8 bits qui ne servent pas).

Cette notion est assez ancienne et n'a plus court aujourd'hui avec les affichages 32 bits et la généralisation des effets de transparence.

Jusqu'aux 256 couleurs, ce byte définissait la façon dont devait être interprétée une couleur inexistante dans la palette (couleur approchante, pixellisation, etc.)
Ce 4ème octet est devenu inutile avec les 16 et 24 bits. La gamme de couleurs devenant suffisante pour ce passer de pixellisation.

Aujourd'hui, même dans un aplat, il faut le prendre en compte comme multiplicateur

[megs]

hmmm, ca serait bien malvenu qu'une variable private d'un component ne soit pas visible d'une procédure qui lui appartient.
(je sais que l'équivalent du pointeur vers self se trouve dans eax au début de la proc en asm.. pourtant ca na pas l'air de contenir le bon pointeur ("$000000FF")). Comment a coup sûr je peux récupérer une variable du private dans une procédure contenu dans le même component en ASM ? avec le décalage ?

Okay, et le pointeur vers l'instance du component je l'attrape comment ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
LEA eax, ?self? ^^

Des trhead ? houa!!! alors que je ne suis pas encore capable d'en creer?, toutefois l'idée est très intéressante et de toute façon je m'était dit qu'il fallait que je m'y mette pour optimiser le precalc3D et le clipping sur z. (ou y a t'il une bonne doc pour expliquer le fonctionnement de l'objet TThread ? et des threads en générale?)

Je serais très content de me libérer d'un objet Tbitmap qui me sert juste à palier mes manque en terme de device context. l'aide de delphi 7 est nulle la dessus, et je ne comprend pas du tout comment ça fonctionne. un Tbitmap me permet juste de na pas avoir a me soucier de la profondeur de couleur du context justement, et de fixer mes procédures à du 32bits. peut être verrais je le choses autrements une fois tout terminér, mais pour le momment je manque cruellement d'info sur le sujet. SI vous avez des infos sur le sujet je prend aussi... je suis avide de comprendre tout ca... ça fait tellement longtemps que je suis coincé...

[Paul TOTH]

Si tu veux de la 3D en bitmap tu peux taper dans mes vieux projets Delphi 2

comme mes BSP Tree par exemple...trop rapide sur mon PC récent !!


ou encore MyWin3D qui provient directement du DOS


un projet beaucoup plus récent en 2D cette fois qui montre un scrolling 2D performant TetrisRun


ou encore CyberSpace qui a une approche intéressante et là encore directement inspirée d'un projet DOS


Ceci dit, de nos jours on travaille plutôt sous DirectX ou OpenGL