Utiliser un BitMap CGFX en VSprite
14 sujets de 1 à 14 (sur un total de 14)
-
Rolala c’est pointu comme sujet
Alors voilà, j’ai une superbe fonction qui me crée un Gel (utilisant donc un VSprite) pour faire le Bob de mon Drag’n’Drop. Tout est fabuleux, c’est merveilleux. Le problème c’est que comme j’alloue toute la mémoire graphique comme un grand au lieu d’utiliser AllocBitMap(), ben tout ce qui dépasse 8bit n’est pas copié.
Du coup, j’ai tout changé pour utiliser AllocBitMap(). Le problème c’est que même si je peux me servir du BitMap comme je veux (copier des morceaux d’écran dedans par example) le VSprite est tout pourrit, il affiche n’importe quoi. J’ai pourtant bien utilisé “(UWORD *)(&BitMap -> Planes[0])”…
C’est pénible, parce que le VSprite fait tout le boulot pour moi : restaurer le fond qu’il détruit, clippe automatiquement aux limites de l’écran, et tout et tout…
Y a t’il un espoir ? Faudrait-il que je réécrive tout pour utiliser mes propres fonctions ?
Le source de la fonction est disponible dans l’archive des source c’est le fichier “Sources/AppServer/Bob.c”…
Si quelqu’un pouvait m’aider ce serait bien sympa… sinon je me sortirais les doigts du cul…
J’ai pourtant bien utilisé “(UWORD *)(&BitMap -> Planes[0])”…
Houuuuu que c’est mal.
Il ne faut jamais accéder directement à la mémoire des bitplanes avec CGFX, ni avec picasso96 d’ailleurs. C’est écrit partout dans les docs. Il faut utiliser WritePixelArray().
Si vraiment tu as besoin d’accéder à la mémoire graphique directement, il faut faire un LockBitMap() (je sais pas si c’est le nom exact, mais ça y ressemble) ce qui te file un pointeur sur les données du bitmap, pointeur qui est valide jusqu’à l’appel à UnlockBitMap() que tu prendras évidemment soin d’appeler dès que possible, dès la fin de ton traitement.
Et pour copier d’un bitmap à l’autre c’est BltBitMap().
Edit : En cas d’accès direct à la mémoire graphique il convient de gérer correctement le format des pixels, qu’ils disent aussi, qui n’est pas forcément celui demandé lors de l’appel à AllocBitMap(), parce que ça dépend du matériel utilisé.
Ben je sais bien, mais le problème c’est que ce n’est pas moi qui accède au BitMap, mais une fonction de graphics.library : DrawGList() et autre… Je vais essayer de bloquer le BitMap avec LockBitMap() le temps du DnD, mais je me demande si c’est bien… c’est pénible
en tout cas merci Lanza !Si vous avez d’autres brillantes suggestions, n’hésitez pas
Normalement, LockBitMap est le seul moyen légal d’obtenir une adresse valide sur les datas du bitmap.
Sinon tu peux ptet aller jeter un oeil sur le source d’Ambient. Il fait bien du drag&drop d’icones png, et comme il est GPL…
Patapééééééééééé!
Le Workbench n’utilise pas de VSprite ?? Ca me ferais mal tient. Je sais qu’il les utilise parce qu’aux balbutiement de ma function, j’utilisais la liste GelsInfo de l’écran du Workbench. Tout marchait sans problème jusqu’au moment où j’essayais de tirer une icône du Workbench… comme quoi les réponses courtes sont parfois trop faciles
BTW: Les Bobs sont aussi des VSprites…
Ah, et bien sûr le tout ne gère pas autre chose que du 8 bits (avec CGX). Mais j’imagine que je parle dans le vide de toute façon.
Service quand même.
Tu parles pas du tout dans le vide, mais les Bobs sont un “sur-ensemble” des vsprites, puisque pour créer un Bob il te faut une structure GelsInfo et un vsprite… bon tout ça ne m’avance pas de toute façon, et je pense qu’il va faloir tout faire à la main comme d’hab
Je vais finir pas réécrire tout le système si ça continue Non, non, c’est justement là qu’est le piège
Les Gels sont à mon sens superbement mal conçus. On voit que la
personne qui a fait ça s’est planté au début en pensant uniquement à
gérer des sprites et a essayé de caser un moyen pour gérer des bobs
avec les mêmes routines.
Résultat, il dit créer un bob à partir d’un vsprite (qui n’a du coup
plus rien à voir avec un véritable vsprite) alors qu’en fait tout est
entremêlé et qu’on a un bob qui contient un vsprite qui contient le
même bob… pour enfin obtenir ce à quoi il aurait dû penser dès le
début : une structure de gel pouvant à la fois définir un vsprite ou
un bob. Manque de pôt il ne l’a pas appelé gel mais vsprite au début
et c’est resté ainsi…
Commodore… dehors
Donc au final, les bobs sont bien un sous-ensemble des vsprites, même
si l’API laisse à penser le contraire au premier abord…
CGX n’implémente que la partie bob d’un vsprite (au sens graphics.library
donc), puisqu’il n’existe pas vraiment d’appli utilisant le reste. Et
la majorité des cartes gfx n’ont qu’un sprite (je crois même que la
Domino n’en a pas du tout).
Maintenant que j’y pense, les SuperGels de CGX doivent gèrer le
24bits mais je ne me souviens pas en avoir vu la doc un jour.
Pour ton drag’n drop, tu peux utiliser les bobs de la graphics
et te limiter à 8 bits, ou tout refaire à la main (ce qui est
certainement plus simple, BltBitMap&co étant tout de même plus sympa à
utiliser que les gels débilos:)
Haaaaaaaa ça c’est de la réponse. Merci Henes ! Tout à coup tout est plus clair
Donc, comme d’hab, c’est tout pourrit faut tout faire tout seul
14 sujets de 1 à 14 (sur un total de 14)
- Vous devez être connecté pour répondre à ce sujet.