Voir la version complète : [GBA][Aide] soucis prog GBA avec include fichier .raw.c
Salut!
Voilà, j'ai un soucis dans la prog GBA avec le stockage de mes images en rom.
Apres conversion des fichiers graphiques en 8bits couleur, je les passe en table d'octets avec gfx2gba qui me sort les fichiers xxx.raw.c.
Disons que j'ai envi de charger 3 fonds 8 bits de la taille de l'ecran 240*160 que je veux pouvoir afficher pendant le jeu, je suis en mode 3.
Disons que mon fichier graphique est Titre.raw.c apres conversion
Alors je fais
#include "Titre.raw.c" comme d'hab puis
for(n=0; n < 38400; n++)
videoBuffer[n] = Titre_Bitmap[n];
pour le charger en memoire video, ça marche nikel mais je peux charger qu'un fond ou deux, apres ça marche plus, le prog affiche plus rien (ecran noir).
Donc pour résumer, si je fais 3 includes sur 3 différents fichiers .raw.c au debut de mon prog, ça chie.
Je pensais qu'en rom (et donc pas en memoire video qui est limité) je pouvais mettre autant d'info que je voulais ou presque mais là, ça fait quoi dans les 39*2Ko max, ya un truc que j'ai pas du comprendre.
Donc voilà, je suis bloqué et je cherche un peu d'aide, merci.
salut si tu arrive deja a afficher un bitmap ca me parrai bizzard que les autres ne suivent pas, en tout cas c'est surrement pas une question de place.
peut etre que tu ne regle pas bien ta couleur de transparence(je connais pas bien gfx2gba)
tien essaye ca ;)
#include "Titre.raw.c"
#include "Titre2.raw.c"
#include "Titre3.raw.c"
void (*pRoutineLointaine)();
#define Exec(a,b...) ({ pRoutineLointaine = (void*)(a); pRoutineLointaine(b); })
/*################################################# #################################################
## Fonc: BOOSTAfficheSpriteSoft_Mode3
## Def : affiche un bitmap (tres lent)
################################################## ################################################*/
void __attribute__ ((section(".ewram"))) BOOSTAfficheSpriteSoft_Mode3(int x,int y,int largeur,int hauteur,unsigned short *src, unsigned short largeurecran)
{
unsigned int loop, loop1 ;
unsigned int mem =(y*largeurecran)+x ;
for (loop=0; loop<hauteur; loop++){
for (loop1=0; loop1<largeur; loop1++){
if (*src != 0)(unsigned short *)0x6000000[mem] = *src ;
mem++ ;
src++ ;
}
mem += (largeurecran-largeur) ; // saute a la ligne plus bas
}
}
int ProgPrincipal()
{
unsigned short x = 0 ;
unsigned short y = 0 ;
while(1)
{
Exec(BOOSTAfficheSpriteSoft_Mode3,x,0,240,160,Titr e_Bitmap+((y<<8)-(y<<4)),160) ;
Exec(BOOSTAfficheSpriteSoft_Mode3,x,0,240,160,Titr e_Bitmap1+((y<<8)-(y<<4)),160) ;
Exec(BOOSTAfficheSpriteSoft_Mode3,x,0,240,160,Titr e_Bitmap2+((y<<8)-(y<<4)),160) ;
AttendVBL() ;
}
return 0 ;
}
mais n'espere pas des miracles meme avec l'iwram, ca va ramer a mort si tu pose pixel par pixel, et surtout en mode 3 ce qui veut dire "sans buffer" !!!!!! :blink:
ps: je sais pas si j'ai bien pigé la question maintenant que je la relis. dit moi en cas ;)
Tu utilises l'option multiboot ou pas ? (ca limite la taille à 256ko)
j'utilise l'option multiboot!!!! oui!!!!
je teste ça tout de suite, si ça marche, tu me sauve la vie!!!!
Je re dans 10s le temps de compiler
EDIT (10s apres :-))
YAHOOOOOOOOO, trop bien, ça marche, merci merci :-) :-)
je savais pas du tout qu'il y avait cette limitation de 256ko et en effet ça correspondait bien à la taille de mon code + deux images de 240*160 en 8bits !!
magnifique, je vais pouvoir continuer mon jeux peinard, c'est genial. Je suis tres content de m'etre inscrit sur ce forum.
merci pour ta reponse NES également.
En gros, la vitesse, pas d'importance, c'est juste pour changer le fond en fonction du mode de combat (defense, attaque, etc... donc ya le temps) mais bon, je vous dis ça, je vous ai rien dis sur mon code alors bon... en tout cas merci.
Au pire, sinon, faudrait que je m'occupe d'implementer les copies DMA, je n'utilise pas de librairies alors ça prend tjrs un peu plus de temps.
Quelques conseils :
- Utilise les copies DMA pour ce genre de choses.
- Laisse tomber le mode 3.
- Code toutes les fonctions qui te sont utiles (copie DMA par ex) ou alors utilise une librairie.
- N'utilise pas l'option Multiboot si tu n'en a pas besoin ou si tu ne sais pas à quoi elle sert.
thoduv, tout à fait d'accord...
la copie DMA c'est top :p et c'est genre 3 lignes de code, c'est pas méchant
Le mode 3 c'est mal :p
Tu peux trouver des genres de mini-libs pour gba, qui ne sont pas des libs mais plus des ensembles de définitions, ca t'évitera de perdre du temps à faire des copier/coller...
Je sais pas pourquoi partout on voit le multiboot de base, alors qu'au fond... je n'ai jamais connu quelqu'un qui s'en servait !
je n'utilise pas de librairies alors ça prend tjrs un peu plus de temps
D'ailleurs je suis en train de faire une mini-lib avec juste les trucs des base (DMA, Keyinput, IRQ). Si ca t'interesse envoie moi un MP.
roh, il est bon ce thoduv...
roh, il est bon ce thoduv...
Il y a aussi la mol_lib de Mollusk qui marche bien et qui est plus tout-en-un. :)
Je sais pas pourquoi partout on voit le multiboot de base, alors qu'au fond... je n'ai jamais connu quelqu'un qui s'en servait !
C'est vrai que c'est marrant, je crois d'ailleurs que VHAM le met d'office quand on crée un nouveau projet, et il n'est peu être pas le seul ;)
Disons que quand on est si proche du matériel, je prefere bien comprendre où vont mes petits octets de façon à ce que si ya un truc qui marche pas comme je veux, je puisse le comprendre, le trouver et solutionner (pas comme si on bossait avec SDL non plus :-)).
De plus, la plupart des tuto abordent les sujets classiques mais que en superficie et en sautant comme par hazard tous les points obscures et compliqués, du coup, faut aller farfouiller dans les fonctions pour bien comprendre le principe. On peut le faire dans les lib qui existent, on peut écrire les notres et bien tout comprendre.
Ce n'est que mon humble avis.
J'ai dejà implementé un paquet de fonctions, mais ils en reste encore. J'ai pas fait le son, pas les copies DMA, pas les sauvegardes et surement d'autre trucs encore.
Au sujet du mode 3, je comprend pas pkoi vous aimez pas? dans mon cas là, j'ai pas besoin de double buffering, ni de map, ni de rotation, ni de scaling, ni enfin quasi rien, lol. Ptet que je peux faire pareil avec le mode 0 à la rigueur mais bon, si ça marche... enfin pkoi pas.
Mon seul soucis avec le mode 3, c'est que j'ai besoin de dessiner des rectangles et que j'utilise une fonction qui dessine pixel par pixel dans le buffer video, alors des que je l'utilise, ça prend un temps fou et il faut ruser comme un renard pour ne pas faire ramer le jeu. Ce n'est pas lié au mode 3 mais ptet que ya moyen de faire mieux.
Pour le multiboot, oui, je sais à quoi il sert et c'est vrai que comme j'utilise une supercard, j'en ai pas besoin. Cette histoire de limite de 256Ko, j'avais jamais entendu avant. C'est genial que quelqu'un y ai pensé pour me sortir de ce probleme un peu louche à premiere vue :-)
:) sincèrement, si tu veux rester en mode bitmap, tu n'auras que des avantages ( hormis pour la palette ) à passer en mode 4
1 ) buffer hardware.
2 ) 8 bit au lieu de 16, donc pour la meme resolution ( 240*160), tu copieras forcément plus de pixels dans le meme laps de temps cpu .
sinon, pour les zoom, rotations, etc... tu en bénéficie tout autant en bitmap 3 ou 4 que en mode 0 tile, ça, ça ne change pas.
bon courage et vivement ta démo .;)
sinon, mollib c'est pas du tout ce qu'il veut, puisque c orienté pour éloigner du hardware (comme PAlib)
concernant les tutos, je te conseil TONC (j'ai pas de lien, mais cherche sur le net), ca explique TOUT TOUT TOUT avec des schémas, ca zap rien, c'est super bien fait... et tout est livré avec des bouts de codes
N'oublions pas GbaTek (http://nocash.emubase.de/gbatek.htm) ...
Sans cette doc où serions nous pauvres codeurs GBA ?
c'est vrai, mais niveau tuto... gbatek faut connaitre un minimum... :)
alors que TONC explique tout
Merci pour les liens vers les tutos.
Perso, j'ai lu ça :
http://www.jharbour.com/gameboy/default.aspx
entierement et j'ai expérimenté tous les exemples, c'est bien mais je trouve que parfois, ya des impasses assez grosses, le mec fait des raccourcis.
Je vais lire TONC et GBATEK alors.
Sinon, c'est vrai que je devrais ptet passer en mode 4 vu que je suis en 8bits pour tous mes graph en plus parce que GFX2GBA n'accepte pas plus.
Je bosse sur un rpg, ça fait un mois que je suis dessus (un mois que je fais de la prog sur GBA en gros :-)) mais le systeme de combat est quasi fini (sauf graphisme definitif). Pour la partie RPG, je comptais utiliser le mode0.
si je puis me permettre:
- les copies dma c'est mal
- areter le processeur c'est mal !
- les do while en iwram c'est bien
- l'iwram c'est treees bien
- les lib c'est mal
- le mode tile c'est bien
- le mode 3 c'est... pour tester si ca rame avant de passer en mode 4 XD
:whst: :ange:
pour le multiboot on avais pas mal de question sur le sujet dans l'ancien forum
donc t'est pas le premier on va dire ;)
si ca peut quand meme t'aider :(
/*################################################# #################################################
## Fonc: CopieDMA
## Def : fait une copie DMA normale
################################################## ################################################*/
void CopieDMA0(void* source,void* dest,unsigned short taille,unsigned short type)
{
IRIS_REG_DMA0SAD = (unsigned long)source ;
IRIS_REG_DMA0DAD = (unsigned long)dest ;
IRIS_REG_DMA0CNT = taille ;
IRIS_REG_DMA0CNT_H = type ;
}
void CopieDMA1(void* source,void* dest,unsigned short taille,unsigned short type)
{
IRIS_REG_DMA1SAD = (unsigned long)source ;
IRIS_REG_DMA1DAD = (unsigned long)dest ;
IRIS_REG_DMA1CNT = taille ;
IRIS_REG_DMA1CNT_H = type ;
}
void CopieDMA2(void* source,void* dest,unsigned short taille,unsigned short type)
{
IRIS_REG_DMA2SAD = (unsigned long)source ;
IRIS_REG_DMA2DAD = (unsigned long)dest ;
IRIS_REG_DMA2CNT = taille ;
IRIS_REG_DMA2CNT_H = type ;
}
void CopieDMA3(void* source,void* dest,unsigned short taille,unsigned short type)
{
IRIS_REG_DMA3SAD = (unsigned long)source ;
IRIS_REG_DMA3DAD = (unsigned long)dest ;
IRIS_REG_DMA3CNT = taille ;
IRIS_REG_DMA3CNT_H = type ;
}
edit: oups pardon vire les "IRIS_" devant chaque macro c'est ma lib
Les DMA c'est mal ? Pourquoi ? Parce que ca arrete le processeur ? Tu peux t'expliquer ca m'interesse là ?
J'espere que moi aussi c'est pas ça car j'ai lemême soucis!!!
Je mate ce soir!!!
Petit rappel, pensez à mettre en "const" les données qui doivent rester en ROM, sinon les datas seront recopiés dans la RAM en même temps que le code.
Alekmaul
23/12/2005, 22h27
nesgba, je comprends pas ton truc, pourquoi c'est mal les copies dma ???:huh: :huh:
perso, je trouve que cela accélère beaucoup les transferts sur GBA .. du moins, dans mon ChipAdvance ...
nesgba, je comprends pas ton truc, pourquoi c'est mal les copies dma ???:huh: :huh:
perso, je trouve que cela accélère beaucoup les transferts sur GBA .. du moins, dans mon ChipAdvance ...
as tu vraiment besoin des dma pour faire tourner chips advance ?
les transferts hard c'est bien mais stopper le processeur c'est mal, lorsque tu copie de grandes quantités de donnés avec le dma tu causes des "a coups" dans ton programme qui sont visibles sur l'ecran et sur le son donc la ou les dma seraient utiles (la copie de grosses quantités de donnés a la suite) elles causent des problemes, donc a quoi bon les utiliser pour copier de petites quantités de donnés ?
sur playeradvance je ne voit aucun jeu qui pourrai tourner sans dma, essayez seulement d'optimiser votre code (transfert iwram/ram->proc 32 bits) et vous verrez que les dma sont completement inutiles.
et surtout en as tu reelement besoin ? si tu optimise correctement tes boucles (en debouclant celles qui s'occupent des gfx par exemple) tu peut pratiquement egaler le dma donc a quoi bon l'utiliser ? tu fait du code propre et portable
attention les avis contraires vont fuser je suis paré au combat :brucelee:
Alekmaul
23/12/2005, 23h11
Je mets à jour mes tiles pour animer le fond en temps réel, alors, à part le DMA sur GBA, je vois pas comment faire :|
Le DMA est utile pour les transferts de données assez importantes de la mémoire vers la mémoire tiles ou sprites ...
Je dis pas une connerie là , non ???:huh:
Attention, je parle de codage C et non assembleur ARM (/me est aussi paré au combat, et toc :D )
Je mets à jour mes tiles pour animer le fond en temps réel, alors, à part le DMA sur GBA, je vois pas comment faire :|
Le DMA est utile pour les transferts de données assez importantes de la mémoire vers la mémoire tiles ou sprites ...
Je dis pas une connerie là , non ???:huh:
Attention, je parle de codage C et non assembleur ARM (/me est aussi paré au combat, et toc :D )
tout ca pour ca Oo, essaye de virer toutes les copies dma et lance toutes les operations gourmandes de ton jeu 2 fois d'affilé et ose me dire qu'il ne tourne pas :) :whst:
la gba a quand meme de la ressource pour la 2D voyon :p
Dr.Vince
23/12/2005, 23h27
as tu vraiment besoin des dma pour faire tourner chips advance ?
les transferts hard c'est bien mais stopper le processeur c'est mal, lorsque tu copie de grandes quantités de donnés avec le dma tu causes des "a coups" dans ton programme qui sont visibles sur l'ecran et sur le son donc la ou les dma seraient utiles (la copie de grosses quantités de donnés a la suite) elles causent des problemes, donc a quoi bon les utiliser pour copier de petites quantités de donnés ?
sur playeradvance je ne voit aucun jeu qui pourrai tourner sans dma, essayez seulement d'optimiser votre code (transfert iwram/ram->proc 32 bits) et vous verrez que les dma sont completement inutiles.
et surtout en as tu reelement besoin ? si tu optimise correctement tes boucles (en debouclant celles qui s'occupent des gfx par exemple) tu peut pratiquement egaler le dma donc a quoi bon l'utiliser ? tu fait du code propre et portable
attention les avis contraires vont fuser je suis paré au combat :brucelee:
tu as certainement raison Nes.
Mais si comme tu le dit si bien, ça ne pose des problèmes que sur des grosses quantités de données alors pourquoi s'en priver sur des petites ?? nan ???
en gros ce que je veux dire c'est : pourquoi réinventer la roue ??
Alekmaul
23/12/2005, 23h29
tout ca pour ca Oo, essaye de virer toutes les copies dma et lance toutes les operations gourmandes de ton jeu 2 fois d'affilé et ose me dire qu'il ne tourne pas :) :whst:
PAs d'accord mon pote :p !!!
Testé moult fois et prouvé moult fois, la copie DMA permet de gagner du temps sur ce genre de copie, cela ramait avant, cela rame plus avec !
je pense qu'il veut dire que ca n'a d'intéret que pour des grosses copies (puisque des petites ca va vite...)...
Perso, je sais que je n'ai pas eu de soucis avec (alors que pour Ham ca posait un problème, je sais pas pourquoi, ptet parce que j'utilise des DMA3 et pas ham), donc bon...
Sinon, ca se passe comment sur DS, sachant que tu as 2 procs, et que celui qui gère le son n'est pas le proc principal ? :)
tu as certainement raison Nes.
Mais si comme tu le dit si bien, ça ne pose des problèmes que sur des grosses quantités de données alors pourquoi s'en priver sur des petites ?? nan ???
en gros ce que je veux dire c'est : pourquoi réinventer la roue ??
justement !! pourquoi les utiliser sur de petites quantités ? pour gagner 2ns ? ca rime a rien, garde un code portable et si vraiment tu as une routine critique et que tu ne peut vraiment pas faire autrement tu peut te permettre d'ouvrir la boite de pandore =_=
Alekmaul
23/12/2005, 23h35
Sur DS, j'utilise effectivement le même principe pour copier toutes les tiles en mode 0 (256x192) octets pour chaque écrans. Sans les registres DMA, je te dis pas le temps que cela prend ...=_=
On est d'accord nesgba, pas pour de petites quantités
PAs d'accord mon pote !!!
Testé moult fois et prouvé moult fois, la copie DMA permet de gagner du temps sur ce genre de copie, cela ramait avant, cela rame plus avec !
mais tu fait comment pour arriver a faire ramer chips advance Oo
j'arrive presque a remplir 2 ecrans plottés de tiles uniques "softs" sans dma et sans que ca rame (alors je te laisse imaginer si je copiai des tiles entiers) et tu me dit que tu arrive a faire ramer chips advance sans dma, toi tu doit vraiment copier a l'arrache.
tu connais l'iwram ? :o :p
Alekmaul
23/12/2005, 23h51
Non, c'est exact, mon problème vient certainement de là, j'utilise pas l'IWRAM ...
Je vais regarder cela ...
Sur DS, j'utilise effectivement le même principe pour copier toutes les tiles en mode 0 (256x192) octets pour chaque écrans. Sans les registres DMA, je te dis pas le temps que cela prend ...=_=
ben le voila le probleme, tu n'optimise pas. ces 256x192 tu n'as a les copier qu'une seule fois, a l'entrée de programme ou a un changement complet d'ecran, ensuite pour un defilement tu n'a a copier que 1x512 en hauteur + 1x256 pour la largeur en utilisant la propriétée du wrap (dans le cas d'un d'un deplacement dans tout les sens de l'ecran) si besoin est tu peut meme copier tes tiles de facon dynamique selon le tile que demande ta map tu stock ce que tu as comme tiles deja present a l'ecran et tu les affiches si ils sont deja presnt, ou si ils ne le sont pas tu les copies a la suite sur le charblock. (bien sur faut copier sur les inutilisés sinon tu deborde vite, c'est un peu le meme principe qu'un bon moteur de sprites)
l'IWRAM est de toute facon indispensable pour moi, ton code est executé 4 fois plus vite !! c'est vraiment allucinant le boost que ca met a ton programme !! ca m'a sauvé la mise + d'une fois :]
J'utilise maintenant le canal DMA3 pour faire la copie de mes backgrounds en mode 4. J'ai une amélioration notable dans le rafraichissement de l'ecran lors du passage au nouveau fond, alors qu'avec une boucle for, ça faisait pas propre.
Sachant que ça arrete le proc (et donc les timers je suppose, c'est l'hypothese que j'ai fait) je ne l'utilise que quand ça ne gene pas l'utilisation des timers precis.
Dois-je l'utiliser ou pas pour la copie des palettes par exmple qui ne représente qu'une quantité de données moindres comparé à un fond 8bits entier mais qui sont chargé pendant une phase non critique pour l'animation?
Mes principaux problemes viennent evidemment de la plateforme particuliere qu'est la GBA et la connaissance precise de son architecture et des subtilité de son fonctionnement, je parle des difficultées rencontrées en général (histoire de registre, de memoire dispo, de vitesse de proc, etc..).
Pourrais tu expliquer l'histoire du IWRAM, qu'est-ce que c'est precisement, ou alors m'indiquer une page de tuto pour chopper la base, parce que tu en parles beaucoup, ça à l'air génial mais je connais pas (si ça se trouve, je connais mais je l'appel pas comme ça). :-)
Dans un autre topic (je le retrouve et j'affiche la citation), vous parlez de "préconisation" de la part de Nintendo pour les jeux commerciaux de façon de coder dans l'utilisation des DMA, IWRAM et autre VBL et j'en passe et des meilleurs. Quelqu'un connait ces préconnisation et pourrais m'en faire part. Pourrait-on peut-etre mettre en place un topic avec des astuces de bonne programmation ?
Pour des raisons de fetes de noël, je ne vais pas pouvoir suivre les reponses pendant 3j, mais j'ai déjà hate de lire tout ça en rentrant.
EDIT1:
Bon ok, alors petite visite sur TONC et voilà:
http://user.chem.tue.nl/jakvijn/tonc/hardware.htm
ya le role et l'adresse des emplacement IWRAM, que je confondais avec l'EWRAM comme cité au dessus.
En gros, en dehors des variables, si on utilise pas l'IWRAM et l'EWRAM d'ailleurs, on peut tout stocker dans les emplacements autres spécifiques comme le buffer video pour les images, la ram pour les palettes, celles pour les sprites, etc...donc l'IWRAM est tout le temps vide si on l'appel pas, ou alors ya des trucs qui vont dedans par default?
Par défaut tu ne dois rien mettre dans l'IWRAM, mais souvent tu mets genre ton tableau d'interruption histoire que ca aille plus vite... L'IWRAM fait vraiment des miracles :) De ce que j'avais testé, avec calcul du temps pour faire une boucle donnée et tout, tu gagnes en gros 50% de temps d'execution si c'est en IWRAM (donc 2x plus rapide que le meme code en EWRAM), et tu gagnes ENORMEMENT de temps à l'appel de la fonction... En fait, selon mes tests (mais quelqu'un en a peut-etre fait d'autres et mieux), mettre une petite fonction (genre 2 lignes) en IWRAM la rendait aussi rapide que si tu avais mis la fonction en inline, donc je suppose que ca veut bien dire qu'elle est appelée beaucoup plus rapidement qu'une fonction EWRAM, non ?
En gros, ce que j'avais fait pour optimiser :
- Petites fonctions de 1-2 lignes -> en inline pour pas prendre de place pour rien, puisque tu gagnes pas tellement dans l'IWRAM
- Autres fonctions 'critiques' -> en IWRAM, et là tu gagnes vraiment beaucoup !
- Tout le reste -> en EWRAM
Et en laissant les variables et tout en EWRAM pour moi...
Sinon, concernant le DMA3, je peux me tromper, mais il n'y a pas une histoire de priorités, et que le DMA3 a une très faible priorité, donc ne gène pas trop les timers, ou une connerie du genre ?
DMA3: This is is the lowest priority and thus often used as a "general purpose" DMA. Using this DMA for your basic memory transfers ensures that sound FIFO DMA and other time-critical DMA are not delayed, making audio or visual artifacts less likely. http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#DMA%20Source%20Registers
Bon, ptet pas, mais en tout cas moi j'ai jamais eu de soucis avec :p Je me sers de la copie DMA pour copier les palettes, tout ce qui va en VRAM, l'OAM dans le VBL, et puis c'est déjà pas mal :p
J'avais testé une copie DMA vs copie normale (celle de ham, qui n'est pas en DMA), et la mienne allait 3x plus vite... Alors bon, certes, celle de ham n'était peut-etre pas en IWRAM, mais bon :)
J'utilise maintenant le canal DMA3 pour faire la copie de mes backgrounds en mode 4. J'ai une amélioration notable dans le rafraichissement de l'ecran lors du passage au nouveau fond, alors qu'avec une boucle for, ça faisait pas propre.
si tu utilise un transfert dma pour transferer un backround en mode 4 , tu sera limité à transferer des images statiques. ça ne te permet aucun scrolling horizontal pixel par pixel par exemple du fait de la nécéssité d'alignement en mode 4.
Pour les dma en général, moi je laisse ça pour le son. Si je rajoute un transfert dma en plus, ça va poser des problemes de priorité de transfert oligatoirement.
les conséquences peuvent etre un crachotement du son, petits ralentissement voire meme crash pure et simple de la gba ( officiellement reconnu par nintendo )
Pour mes transferts de données, petites ou grande quantité, je privilégie le transfert software en ASM à partir d'un code logé en iwram.
Et imagine, pour effacer ton buffer en mode 4 , tu vas quand meme pas monopoliser 38 ko en rom rempli de "0" à transferer par un dma ???:hum:
... à moins que tu ai toujours une image qui fasse la totalité de l'écran à rafficher par dessus qui donc va t'effacer ton écran à chaque fois, mais là tu perd franchement en souplesse.
bref, je rejoint en gros NESGBA sur son analyse , mais chacun voit midi à sa porte.:)
à plus ! ;)
Pour info, dans crazy racer 3D, je fais aucun transfert dma ( sauf pour le son ), je me permet le luxe d'effacer à chaque frame completement le buffer ( mode 4 ), et je pense pas que l'on puisse dire que c'est un jeu qui rame.
J'utilise maintenant le canal DMA3 pour faire la copie de mes backgrounds en mode 4. J'ai une amélioration notable dans le rafraichissement de l'ecran lors du passage au nouveau fond, alors qu'avec une boucle for, ça faisait pas propre.
Sachant que ça arrete le proc (et donc les timers je suppose, c'est l'hypothese que j'ai fait) je ne l'utilise que quand ça ne gene pas l'utilisation des timers precis.
Dois-je l'utiliser ou pas pour la copie des palettes par exmple qui ne représente qu'une quantité de données moindres comparé à un fond 8bits entier mais qui sont chargé pendant une phase non critique pour l'animation?
Mes principaux problemes viennent evidemment de la plateforme particuliere qu'est la GBA et la connaissance precise de son architecture et des subtilité de son fonctionnement, je parle des difficultées rencontrées en général (histoire de registre, de memoire dispo, de vitesse de proc, etc..).
Pourrais tu expliquer l'histoire du IWRAM, qu'est-ce que c'est precisement, ou alors m'indiquer une page de tuto pour chopper la base, parce que tu en parles beaucoup, ça à l'air génial mais je connais pas (si ça se trouve, je connais mais je l'appel pas comme ça). :-)
Dans un autre topic (je le retrouve et j'affiche la citation), vous parlez de "préconisation" de la part de Nintendo pour les jeux commerciaux de façon de coder dans l'utilisation des DMA, IWRAM et autre VBL et j'en passe et des meilleurs. Quelqu'un connait ces préconnisation et pourrais m'en faire part. Pourrait-on peut-etre mettre en place un topic avec des astuces de bonne programmation ?
Pour des raisons de fetes de noël, je ne vais pas pouvoir suivre les reponses pendant 3j, mais j'ai déjà hate de lire tout ça en rentrant.
EDIT1:
Bon ok, alors petite visite sur TONC et voilà:
http://user.chem.tue.nl/jakvijn/tonc/hardware.htm
ya le role et l'adresse des emplacement IWRAM, que je confondais avec l'EWRAM comme cité au dessus.
En gros, en dehors des variables, si on utilise pas l'IWRAM et l'EWRAM d'ailleurs, on peut tout stocker dans les emplacements autres spécifiques comme le buffer video pour les images, la ram pour les palettes, celles pour les sprites, etc...donc l'IWRAM est tout le temps vide si on l'appel pas, ou alors ya des trucs qui vont dedans par default?
ben evidemment si tu copie 1 pixel par 1 pixel des longues series des donnés a la suite que le dma est enormement plus rapide qu'une boucle for ou un do while, le comparatif n'a pas lieu d'etre etant donné que tu n'utilisera jamais une methode de ce genre pour un jeu. mais il faut aller a l'essenciel si tu veut faire tourner un jeu en mode 4 il va falloir plotter des tiles soft de facon tres tres rapide 4 par 4 ou 8 par 8, y'a meme des dingues en asm qui plottent 32 par 32 (hein mike :D)
donc la je doute tres serieusement que le dma puisse faire quelque chose pour toi ^^
l'IWRAM une petite memoire de 32ko qui est prevue pour acceuillir tes variables mais tu peut stocker des fonctions a l'interieur et ca te permet de papoter avec le proc en 32bits.
nintendo n'interdit pas le code en iwram ;)
edit: mollusk ca depend de ce que fait le code placé en IWRAM tu peut gagner beaucoup plus que 2x en iwram ;)
ok, merci nesgba, moi c'était à vu d'oeil sur des comparatifs rapides, je me suis pas amusé à testé sur des fonctions super complexes ou quoi :)
les conséquences peuvent etre un crachotement du son, petits ralentissement voire meme crash pure et simple de la gba ( officiellement reconnu par nintendo )
Et imagine, pour effacer ton buffer en mode 4 , tu vas quand meme pas monopoliser 38 ko en rom rempli de "0" à transferer par un dma ???:hum:
1) Bizarre, je l'utilise à fond dans mon Sonic (DMA3 pour les copies normales, DMA1/2 pour le son et DMA0 pour les changements de palette, scrolling, etc. pendant la HBLANK), et je n'ai heureusement pas de ces problèmes, mais c'est bien de m'avoir averti... est-ce que tu aurais plus de précisions stp?
2) Il y a le bit "repeat" pour ça :p (même effet qu'un memset). Et si tu mets l'entier utilisé pour ça en IWRAM, c'est vraiment très rapide.
Sinon je ne suis pas complètement d'accord avec vous. La copie optimisée ASM est presque aussi rapide que le DMA mais elle pète tous les registres donc elle n'est pas vraiment valable pour les petites copies puisqu'on perd le temps de les sauver/restaurer... pour les grandes ça peut valoir la peine de le faire en soft s'il est nécessaire de toujours avoir les interruptions.
Si je n'utilise pas volontairement l'EWRAM et l'IWRAM, ya rien qui est mis dedans? ou bien par defaut, certaines données sont balancées dedans ?
Le programme compilé est chargé dans l'EWRAM par defaut?
Si tu mets MULTIBOOT, le code sera en EWRAM (ça limite la taille de ta ROM à 256 ko), sinon il sera en ROM (sauf si tu spécifies le contraire).
Par défaut, la partie supérieure de l'IWRAM est utilisée pour la pile (variables locales) et les interruptions. La partie inférieure est utilisée pour les données (variables globales, tableaux déclarés sans l'attribut const). Un malloc allouera un bloc en EWRAM.
Donc l'idéal est de spécifier aux fonctions critiques qu'elle doivent être placées en IWRAM, et faire attention à placer les grandes variables (spécialement tableaux) en EWRAM (avec l'attribut section .ewram, ou en faisant un malloc mais c'est plus compliqué) pour éviter de gaspiller l'IWRAM.
le programme est lu depuis la rom? ah ok, je pensais qu'il etait transféré dans une ram avant l'execution. Sur une supercard, le programme est mis dans une ram de la cartouche, non (je sais ça à rien à voir ;) ) ?
vBulletin® v.3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org