PureBasic

Oliv · Message par **Oliv** » sam. 31/janv./2004 19:24

Oui, en passant par les APIs je crois qu'il y en a une mais par PB je ne pense pas

filperj · Message par **filperj** » sam. 31/janv./2004 19:26

Je vais peut-être dire des conneries, mais, à mon avis:

Si tu as beaucoup de données de sprites à manipuler "à la main" (pléonasme?), il vaut mieux tout coller dans la mémoire principale, donc créer tes sprites avec "#pb_sprite_memory".
Pour chaque sprite, tu récupère l'adresse de ses données avec "startdrawing(spriteoutput()) : *addresse=drawingbuffer()".
Avec cette addresse, tu dois avoir accès au buffer du sprite directement par la suite, sans repasser par un startdrawing à chaque fois. Je te laisse concocter une fonction GetPixel à partir de là

Dr. Dri · Message par **Dr. Dri** » sam. 31/janv./2004 19:47

Dr. Dri · Message par **Dr. Dri** » sam. 31/janv./2004 19:50

filperj · Message par **filperj** » sam. 31/janv./2004 20:09

Je voulais parler du pointeur vers les pixels du sprite, sans l'en-tête:

Code : Tout sélectionner

startdrawing(spriteoutput(#sprite))
*pointeurverslespixels=drawingbuffer()
stopdrawing()

Je n'en suis pas tout-à-fait sûr, mais je pense que peux réutiliser ensuite ce pointeur pour lire les pixels sans refaire un startdrawing sur le sprite.
Mais tu dois alors tout calculer toi-même, en tenant compte de la largeur, hauteur, profondeur de couleur...

apres un petit tour dans l'aide, je vois ke si je fais un loadsprite en mode memory il va dans la RAM

Ben oui, la RAM est plus rapide d'accès pour les calculs.
C'est pour ça que certaines commandes sprite sont à faire de préférence dans un bloc startspecialfx() - stopspecialfx()
startspecialfx(): crée un buffer pour l'écran dans la RAM
stopspecialfx(): copie le buffer-écran de la RAM dans le buffer-écran de la VRAM

Dr. Dri · Message par **Dr. Dri** » sam. 31/janv./2004 20:53

filperj · Message par **filperj** » sam. 31/janv./2004 22:02

Les commandes de la famille specialfx sont justement des manipulations de données sans accélération matérielle, si j'ai bien compris: c'est pourquoi il me semble que c'est du même domaine que ce que tu veux faire.

Pour ce qui est des en-tête de sprite, va voir dans PureBasic\Library SDK\PureBasic library descriptor.txt... Mais ya du boulot!

Dr. Dri · Message par **Dr. Dri** » sam. 31/janv./2004 22:17

filperj · Message par **filperj** » sam. 31/janv./2004 22:33

En fait, ça m'intéresserai de me coller à une petite lib asm pour faciliter l'accès à ces fameux en-(prise de)-tête...
Qu'est-ce qu'il faudrait comme fonctions ?

retrouver les coordonnées du clippage

retrouver la couleur d'un pixel (en la traduisant ou non en code RGB standart? )

...d'autres trucs utiles?

Qui a des idées?

filperj · Message par **filperj** » sam. 31/janv./2004 23:57

Bah voilà déjà un truc tout con à tester:
http://pageperso.aol.fr/Filperj/spriteptr.zip
ça permet au moins d'accéder à l'en-tête (sauf bug, faut encore tester)
Et pas besoin de C

(je dis ça parsque je connait rien au C

)

filperj · Message par **filperj** » dim. 01/févr./2004 2:26

Et puis loadsprite/createsprite renvoie un pointeur non vers l'en-tête du sprite, mais vers une DirectDrawSurface, et on retrouve ce pointeur dans l'en-tête du sprite.
Mais c'est quoi exactement une DirectDrawSurface ? Je suppose que ça a encore son propre en-tête... Quelqu'un sait comment on doit gérer cette bête-là ?

Dr. Dri · Message par **Dr. Dri** » dim. 01/févr./2004 11:51

filperj · Message par **filperj** » dim. 01/févr./2004 16:51

Oui c'est certainement un bon début.
Peut-être que je vais chercher midi à 14h avec ma lib

Mais toi qui fait du C, tu ne connais pas la structure d'un DirectDrawSurface ? Ca a rapport à DirectX...

Dr. Dri · Message par **Dr. Dri** » dim. 01/févr./2004 17:01