Voir la version complète : [NDS][Aide] AlphaBlending et PA_Lib
Bodom-Child
20/01/2006, 15h41
Voilà, je suis en train de créer mon ptit jeu sur DS (les infos sur le jeu viendront à temps ;) ), et j'ai un petit problème pour rendre un sprite transparent au dessus des autres sprites.
Voilà mon code, tout bête :
PA_CreateSprite(0, 1, (void*)Pointeur_Sprite, OBJ_SIZE_32X32, 1, 1, 2, 12);
PA_SetSpriteMode(0, 1, 1) ; // Alphablending
PA_EnableSpecialFx(0, SFX_ALPHA, 0, SFX_BG0 | SFX_BG1 | SFX_BG2 | SFX_BG3 | SFX_OBJ | SFX_BD);
PA_SetSFXAlpha(0, 9, 15);
Le sprite est donc bien rendu transparent, mais seul le background apparaît par transparence, c'est à dire que les sprites (de numérotation > 1, donc de priorité moindre) n'apparaissent pas derrière le curseur, comme s'il n'y avait rien entre le curseur et le background.
Voilà, en espérant que quelqu'un saura me dépatouiller de ce problème :) .
Merci d'avance.
pas possible a faire, la transparence n'est pas gérée sprite sur sprite (a moin que ca a été corrigé sur nds mais ca m'etonnerai que nintendo se soient fait ch.. a le rajouter :D)
tu peut aussi faire da la transparence soft sprite sur sprite mais c'est tres limité et tres tres difficile a implementer et le resultat est assé moche au final.
Bodom-Child
20/01/2006, 16h35
Arg.
Merci de ta réponse, mais ça me surprend quand-même que le hardware ne permette pas de chose "aussi simple".
Tant pis je passerai outre ^^
Arg.
Merci de ta réponse, mais ça me surprend quand-même que le hardware ne permette pas de chose "aussi simple".
Tant pis je passerai outre ^^
pas si simple que ca :)
je sais pas comment c'est géré en hard mais imagine que tu ai 128 sprites les uns sur les autres en alpha avec un normal tout en bas, esque c'est vraiment gérable ?
en tout cas en soft avec une palette 256 couleurs tu ferrai largement ramer ta nds.
Bodom-Child
20/01/2006, 16h51
Oui tu as raison c'est sûr. Tant pis, je m'arrangerais pour faire un autre genre de curseur.
Encore merci pour ta réponse rapide, ça m'évitera de chercher des heures ce qui va pas dans mon code :lol:
Je viens de tester, effectivement tu peux pas faire de l'alphablending entre 2 sprites :/
Par contre, t'as la méthode que j'ai utilisée dans nDoS et qui marche pas trop mal, qui est de sortir le sprite de l'écran une image sur 2... ca fait une transparence de 50%, pas trop mal... à voir en utilisation pratique
Je viens de tester, effectivement tu peux pas faire de l'alphablending entre 2 sprites :/
Par contre, t'as la méthode que j'ai utilisée dans nDoS et qui marche pas trop mal, qui est de sortir le sprite de l'écran une image sur 2... ca fait une transparence de 50%, pas trop mal... à voir en utilisation pratique
ah ouii exelente idée mollusk !!!! je pensai pas que ca pouvai bien rendre sur gba !!
ca marche ? le resultat est bien ? pas de clignotement ? :w00t:
c'est con mais j'y avai jamais pensé ! :D
Bah écoute, dans nDoS c'était pour des icones, ca passait pas trop mal. Sachant que t'es à 60fps, ca fait un tres léger, mais vraiment léger, clignotement... mais si ca se trouve l'effet du clignotement est diminué si c'est en mouvement... et peut-etre que l'effet de transparence aussi, par contre, donc faut voir :/
Bah écoute, dans nDoS c'était pour des icones, ca passait pas trop mal. Sachant que t'es à 60fps, ca fait un tres léger, mais vraiment léger, clignotement... mais si ca se trouve l'effet du clignotement est diminué si c'est en mouvement... et peut-etre que l'effet de transparence aussi, par contre, donc faut voir :/
ce qui m'inquiete c'est si ton programme utilise pas mal de ressources ca risque de se voir enormement :(
utilisable que a 60 fps, a 20 ou 30 fps ca se voit trop je pense :(
ah c'est clair, mais bon, en général je pense qu'il faut le vouloir pour avoir moins de 60 fps là... apres faut optimiser :)
edit : sinon tu le fais changer dans le vbl, ca le fera quoi qu'il arrive à 60fps, non ?
ah c'est clair, mais bon, en général je pense qu'il faut le vouloir pour avoir moins de 60 fps là... apres faut optimiser :)
edit : sinon tu le fais changer dans le vbl, ca le fera quoi qu'il arrive à 60fps, non ?
ben ecoute si tu affiche 3 sprites qui se tapent dessu ok.
optimiser ok, mais des fois si tu utilise des techniques peut academiques tu te retrouve dos au mur et a moin d'optimiser en asm tu peut pas faire autrement :D (plottage, 3D, moteur tres gourmand...)
perso je pense pas que quelqun puisse optimiser mon code + qu'il ne l'est deja (en c bien sur).
pour l'histoire du vbl oui tu as raison mais il faut calculer le truc et bien betonner ta fonction qui gere le faux alphablend :D genre dans ta structure de sprites tu met l'etat actuel de ton sprite (1:fauxalphablend actif?, 2:hors d'ecran ou pas ?).
tu peut meme definir combien de cycles qu'il reste hors ecran si tu le souhaite il sera + transparent donc.
mais des que tu va changer ton fps, ca foire tout :p (a moin que tu ai fait un truc qui gere ca aussi)
c'est pas super sorcier a faire non plus ;)
:)
Non mais on parlait de dev DS, sur lequel t'as quand meme pas mal de ressources en plus...
Non mais on parlait de dev DS, sur lequel t'as quand meme pas mal de ressources en plus...
oups pardon. :-'
mais d'ici un ans quand tu maitrisera la bete au poil avec la 3D ... tu dira pas ca donc autan le faire tout de suite :p
si la transparence des sprites que tu veux mettre est différente pour chaque sprite mais qu'elle reste la même au cours du temps, tu peux aussi utiliser des astuces de dessin.
- Si le sprite ne se déplace pas et donc que tu connais l'etat du fond, alors, tu peux dans ton logiciel de dessin preférer, créer l'alpha en intégrant le fond sur un claque inférieur et en reglant la transaprence.
- Si le sprite se déplace mais ne change pas de transaprence, tu peux utiliser la technique qui consiste à dessiner un point sur deux en damier avec la couleur 0, ce qui permet de faire un effet de transparence bizarre mais interressant des fois et qui consomme rien (on est pas obligé de faire un point sur deux, tout est possible pour augmenter ou diminuer l'effet).
- Si le sprite se déplace mais ne change pas de transaprence, tu peux utiliser la technique qui consiste à dessiner un point sur deux en damier avec la couleur 0, ce qui permet de faire un effet de transparence bizarre mais interressant des fois et qui consomme rien (on est pas obligé de faire un point sur deux, tout est possible pour augmenter ou diminuer l'effet).
arf ca fait super moche ca :D tu pourrai meme limite faire une routine qui te fait ca sur un sprite complet a la creation genre tu gicle un pixel sur 2 sur les tiles du sprite :p.
Quand mon mario se fait toucher par un ennemi, il devient transparent quelques secondes (il clignote aussi méchament, mais c'etait voulu) je fait comme Mollusk a dit, j'affiche/j'efface le sprite avec un bon rythme (moi je le fait de telle sorte qu'il clignote, mais en le faisant bien, ca devrait aller) :)
ouais, je sais, mais parfois ça donne un style oldschool ^^
Pour faire clignotter, perso, je change le registre d'alphablending aussi (parce que on peut faire des effets sympa en même temps comme un fondu transparent rapide sur le sprite) mais evidemment si ya d'autres sprites transparent, faut pas utiliser cette methode.
Perso j'avais le même problème avec le menu transparent, alors j'utilise le BG3 à la place (et là on voit bien en-dessous), et les sprites seulement si le niveau a besoin de plus de tiles ou du BG3.
Par contre dans ton cas je pense que ce n'est pas vraiment utile, à moins de justement écrire les sprites indispensables en soft sur un BG dédié. :unsure:
Sinon le hard de la GBA/DS, pour chaque pixel, parcourt la liste de 0 à 127 et le premier sprite qui a un pixel non transparent à cet endroit et de priorité égale au BG en cours est pris comme sprite à dessiner, et ce pixel est dessiné. En temps normal tout va bien puisqu'on ne peut pas voir les sprites au-dessous d'un sprite solide, mais avec l'alpha ça pose ce problème... :(
Sinon, méthode dérivée d'un 1 pixel sur 2 :
Tu charges en mémoire 2 copies de ton image, un avec 1 pixel sur 2 à partir du premier pixel, un avec 1 pixel sur 2 à partir du deuxième, et à chaque frame tu changes l'image utilisée... Ca devrait supprimer l'effet de clignotement si tu en as un, mais ca double la mémoire utilisée et c'est chiant :p
Bodom-Child
30/01/2006, 18h33
J'ai trouvé quelque chose d'encore plus simple avec PA_Lib : il suffit de doubler la taille du sprite (par exemple un 32x32 devient 32x64) et de laisser l'espace en dessous du sprite rempli de la couleur de transparence.
Ensuite y'a plus qu'à créer le sprite, et lancer l'anim :
PA_StartSpriteAnim(0, x, 0, 1, 60) ;
Où les paramètres sont, dans l'ordre :
0 pour l'écran du bas
x pour le numéro dudit sprite
0, 1 pour donner les limites de l'animation
60 pour dire qu'à chaque frame il change l'animation (à 60 images/seconde)
L'effet est nickel et le clignotement invisible sur hardware :)
Si je peux me permettre, j'aurai une critique à propos de ce que tu as fait :)
En fait, la fonction d'animation, comme son nom l'indique, anime le sprite... Et pour ce faire, elle copie chaque fois que nécessaire l'image en mémoire. Donc là elle copie à chaque frame une image de 32x32... Avec un seul sprite ca va, mais si tu veux faire ca pour plusieurs, ca va ramer à mort !
Autre solution pour le faire disparaitre rapidement : tu le mets en DblSize on/off. Si en doublesize sans avoir les rotations dessus, ca cache le sprite il me semble, donc si ton sprite ne tourne pas ca sera nickel.
ca va ramer à mort !
la pluparts des jeux commerciaux renouvellent tout les tiles de leurs sprites utilisés a chaque frame et cela sur gba, donc sur nds et sur un jeu amateur en + je pense pas que ca puisse poser un soucis ;)
mais c'est vrai que c'est du gachi !! >(
Bah ca va ramer s'il commence à faire ca pour la transparence des fonds aussi ;)
Non, je déconne, mais ca serait dommage de perdre du temps CPU pour si peu de choses... Surtout que c'est juste une question de :
transp = !transp;
PA_SetSpriteDblsize(screen, sprite, transp );
(a tester)
vBulletin® v.3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org