[lyon4]

bonjour,

voilà, j'ai un petit soucis avec ce petit code:

Code

(c):
//ces premieres lignes sont au début du programme principal//
#include "monGif.h" //gif dans le dossier data
u8 buffer[256*192];
u16 pal[256];
//....//
 
PA_Init8bitBg(1, 3);
DecodeGif((void*)monGif, (u8*)buffer, (u16*)pal,0, 256);
PA_LoadBgPal(1,3, pal);
dmaCopy((u8*)buffer,(u8*)PA_DrawBg[1],192<<8);//on affiche le buffer
 
 

l'image s'affiche, mais la palette affichée n'est pas du tout la bonne.
où ai-je commis mon erreur ?

NB: avec PA_LoadGif(1,(void*)monGif);  à la place des trois dernières lignes, tout fonctionne correctement (mais j'ai besoin de savoir où je me suis planté)

[Mollusk]

Alors, 2 choses

1. PA_LoadBgPal ça va pas pour les fonds 8bit. Pourquoi ? Parce que comme c'est con ce truc, le fond 8bit utilise pas une palette 'classique' comme les autres fonds, mais LA palette par défaut qui est ailleurs Essai genre PA_LoadPal(PALETTE_BG1, bg_pal) (PALETTE_BG1 pour palette de fond sur écran 1).

Ensuite, pour ta copie DMA, je n'ai jamais utilisé la fonction dmaCopy, donc je vais peut-être dire une connerie. Mais quand je fais mes copies DMA, c'est en 16bit, donc il faut largeur*hauteur/2. Mais peut-être que dmaCopy divise par 2 pour toi, je ne sais pas

[lyon4]

merci.
pour la palette ,c'est réglé (avec PAL_BG1 )

pour dmaCopy, en divisant par 2, j'obtiens la moitié de l'ecran, donc ca devait etre la bonne taille comme ça...


cependant, j'ai encore un soucis:  vers le bas de l'image, ça merdouille (la dernière ligne comporte des traits etranges...de la couleur 0, visiblement). ces traits semblent différents à chaque fois que je redemarre la DS.


sinon, si il y a un moyen plus simple d'utiliser des buffers, je suis preneur.

[Mollusk]

Et si tu fais une copie toute bête avec un for, tu as les lignes ? J'ai le même problème dans HexaVirus je crois :s

[lyon4]

salut,

avec une boucle for, ca fonctionne très bien, en effet.

en cherchant un peu, j'ai vu qu'il y a avait deux fonctions: DmaCopy et DMA_Copy...
c'est quoi la différence ?

[Mollusk]

Une venant de PAlib, l'autre de libnds Mais bon, en théorie ça ne change pas grand chose :/

edit : pourquoi tu fais pas juste PA_LoadGif ?

[lyon4]

parce que PA_LoadGif affiche directement à l'écran. et comme la decompression n'est pas instantanée (même si elle est tres rapide), on voit l'affichage s'effectuer, ce qui peut etre genant dans certaines situations.
C'est sur que je pouvais faire autrement (utiliser un fichier bin par ex), mais ça me permet de mieux saisir comment tout ça fonctionne.


sinon, je viens de voir que je pouvais eviter les dmacopy simplement en utilisant PA_Load8bitBitmap..mais bon, comme ca fait appelle à DMA_Copy, il y a exactement les memes bugs d'affichage.

après recherches sur google, j'ai trouvé (enfin, j'ai trouvé quelqu'un qui a trouvé ) pourquoi le DmaCopy bugue. (sur ce blog )

Je n'ai pas le fin mot de l'histoire, mais n'oublions pas que tout ce que le processeur ARM lit/modifie passe par un cache, alors que les déplacement DMA, pas. En clair, pour peut que la commande DMA se mette à lire notre ligne de données avant que le cache n'ait été réécrit en mémoire centrale, c'est foutu.

cette explication semble etre la bonne car en mettant juste un PA_WaitForVBL(); (afin juste de lasser le temps au cache d'etre réécrit) avant le DMA_Copy, cela fonctionne.

[Mollusk]

Ouep, pas faux