GpBitBlt16 : Bug ou pas ? - Page 1

Yop, j'ai un problème avec la fonction GpBitBlt16... j'ai l'impression que ça provient des libs du gpsdk et si quelqu'un pouvait me le confirmer ce serait sympa paske là ça fait 1 semaine que je me à cause de cette c*nnerie -__-' (obligé de démonter tout mon code pour tenter de localiser où ça foire)

Donc pour isoler le problème et tester, je me suis inspiré de l'exemple 8 & 9 du sdk : je suis en mode 16 bits, j'affiche une image... pas de problème. Voici un screenshot (à gauche elle est blitté avec GpTransBlt16, à droite avec GpBitBlt16) :


Ensuite je déplace mes images de façon à ce qu'elles dépassent en bas... toujours okay...


Mais dès que l'image dépasse en bas et que sa valeur sur l'axe des ordonnées est impaire, GpBitBlt16 donne ceci (alors que ça passe bien avec GpTransBlt16)

(ps: sur un gp32 réelle, c'est plantage direct !!)

C'est moi qui merde ou est-ce qu'il y a bien un bug dans les libs ? Si oui, qu'est-ce qu'il y aurait comme solution ? Utiliser toujours GpTransBlt16, même si je suppose que c'est plus lent qu'un GpBitBlt16 ? Ou peut-être réécrire ma propre fonction de blit 16 bits ?

Rhaaa comment ça me saoul de perdre mon temps sur un truc comme ça

si t'as les sources du SDK, ça donne quoi la comparaison de ces deux fonctions?

C'est mieux de tout simplement réécrire la fonction je dirais. Un blit 16 bits c'est vraiment pas compliqué une fois que tu as compris comment fonctionne la machine (comment accéder au buffer de l'écran principalement). Là où il faut faire gaffe c'est juste la vitesse.

rz (./1) :
C'est moi qui merde ou est-ce qu'il y a bien un bug dans les libs ?

GpBitBlt16 () ne gère probablement pas le clipping, ou du moins pas correctement. Tu peux t'en sortir en écrivant une petite fonction qui calcule les paramètres qu'il faut pour que la zone copiée ne dépasse pas l'écran, puis qui appelle GpBitBlt16().

Brunni : le blitting est peut-être accéléré matériellement sur GP32...

en tout cas entre y gauche et y droit, il y a exactement la largeur de l'image.

si t'as les sources du SDK

Non malheureusement, c'est l'officiel de Gamepark et je crois pas que les sources ont été diffusés ... mais si quelqu'un les a, je suis preneur

C'est mieux de tout simplement réécrire la fonction je dirais. Un blit 16 bits c'est vraiment pas compliqué une fois que tu as compris comment fonctionne la machine (comment accéder au buffer de l'écran principalement). Là où il faut faire gaffe c'est juste la vitesse.

Bin disons que je suis moyen chaud pour la réécrire... en plus faut prendre en compte que sur l'écran gp32 l'ordre des pixels est un peu chelow (si je me souviens bien le premier pixel est située en bas à gauche) donc c'est un peu prise de tête... Enfin bon, why not... de toute façon je suppose que ça se fait à grand coup de memcpy ? (pas taper si je dis une c*nnerie )

Tu peux t'en sortir en écrivant une petite fonction qui calcule les paramètres qu'il faut pour que la zone copiée ne dépasse pas l'écran, puis qui appelle GpBitBlt16()

Yeaaaah !! Bin oui c'est une super bonne idée... pkoi j'y ai pas pensé -__-" c'est tout balot à faire en plus... je test ça de suite et te dis ce que ça donne

-

Ouep c'est pour ça que j'ai proposé ^^
Mais la remarque est juste, ça se *pourrait*.

Bon bon bon... donc j'ai essayé de limiter la hauteur du blit en faisant un test basique qui ressemble en gros à ça :

/*
position_y => variable de la position sur l'écran où doit être affiché l'image
IMAGE_H => constante désignant la hauteur de l'image
blit_height => nombre de ligne à blitter, pour éviter de sortir de l'écran
*/

int bottom = position_y + IMAGE_H;      /* déterminer où se situe le bas de l'image */
if (bottom > SCREEN_HEIGHT) {           /* s'il dépasse la hauteur de l'écran, le limiter à la hauteur visible */
    blit_height = SCREEN_HEIGHT - position_y;
}

Ce qui me donne, toujours avec :
- à gauche GpTransBlt (okay)
- au milieu GpBitBlt (pas okay du tout)
- et à droite, en limitant manuellement la hauteur du blit

240 - 173 = 67 lignes à blitter

Apparemment on dirait que c'est la ligne du bas qui a du mal, car lorsque je blit d'une hauteur de blit_height - 1, là ça marche nickel que Y soit pair ou impaire (avec une ligne en moins évidemment, celle du bas) :

240 - 173 - 1 = 66 lignes à blitter

Petit détail "amusant", lorsque la hauteur de l'image source est impaire, tout fonctionne sans le moindre problème (qu'elle que soit la parité de sa position y)


Rhaaaaaa saleté !!

[edit]

la gp32 c'est un processeur arm, point à la limite ta des petits tricks avec le controlleur lcd mais rien pour le blitting

Ah c'est cool, bon bah dans ce cas je sens que je vais pouvoir me faire mes p'tit blit manuellement, tranquillou... si j'y arrive ^__^'
[/edit]

@Orion_ : Ce serait mortel si un jour tu te remettais à coder des minilib !! Parce que franchement... entre les libs officiels un peu lourdes qui existent en plein de versions différentes (pour ads seulement, d'autres adaptées pour GCC, celles allégé sans les mode 16bits...) celles de Mirko qui sont pas trop mal mais moins rapide parait-t-il... enfin bref, c'est galère :-/

Faudrait des libs de base, stables et optimisées... pas un truc qui te fait perdre 50% du framerate dès que t'appelle certaines fonctions maudites (rhoooo c'est bon hein ! on a tous fait la bêtise d'effacer l'écran avec un GpFillRect ou utilisé GpPointSet au début hein ! lol... bin quoi ! méééé piske j'vous dis kje le fais puuuuu !! ^.^')

les sprites utilisés avec les fonctions standard doivent être convertie avec le logiciel idoine, il rajoute qq octet à la fin des lignes pour aligner sur 4o ou un truc du style, ca peu venir de la.

il y a d'autre routines de blit très rapide, moins buguées
va faire un tour par la :
http://membres.multimania.fr/matkeupon/ // edit ha non dsl, c'est du 8bit ^^ spiv avait du 16 bit ultra rapide avec des sprite précompilés mais la son site dit kukkuu pulu!

tu auras également des infos ici : topics/44897-mon-affichage-de-sprite-a-moi-asm
sinon, tu peu toujours utiliser mon vieux code la : http://procvor.free.fr/orion/gdl.gp.rar

waow... nan mais sérieux, tu veux me tuer ou koa avec tes histoires de framebuffer en assembleur !! lol (au passage, y'avais une sacré ambiance ici en 2004 )

Je crois que je vais plutôt me rabattre sur tes sources de la GDL, là j'aurais plus de chance d'y capter quelque chose... enfin normalement
Ah mais on dirait que c'est cette fameuse v2 codé en C++ ?! Cool ! C'est pas cette version qui se compile aussi sous Windows ?? (ou alors y'a que gdm je sais pu)
(dommage que j'ai jamais réussi à quoi compiler quoique ce soit en C++ pour la GP32, que ce soit avec la version d'ADS que tu m'avais passé ou DevkitArm... enfin sous le dernier GCC compile mais ensuite ça n'arrive pas à linker ché pu quoi ça m'a gavé... en plus me coltiner des makefile à la main, non merci ).

Enfin bon, je vais voir ça, déjà sans afficher la dernière ligne de l'image sa plante pu, ça fait un peu "vieux rafistolage à 2 balles" mais c'est déjà ça ^^ Ah et sinon merci pour la précision des 4ko, c'est bon à savoir ;-) (mais j'ai essayé avec d'autres images, notamment celles du le SDK sans succès).

Faudra aussi que je jette un oeil à d'autres sources, genre celle de sunbeam, ça m'étonne un peu que personne n'ai eu ce problème avant

http://procvor.free.fr/gdl/demo/Gdl_demo_pixel_2.rar


> Ah mais on dirait que c'est cette fameuse v2 codé en C++ ?!
à vrai dire c'est la v3 la v2 est ~~plus rapide mais seulement 8bit, tu la trouvera dans les sources de yAnl

oui, le but de cette enieme lib etais d'etre multiplateforme, mais bon, en fait j'avais plus ou moins dérivé, la version windows est la : http://procvor.free.fr/orion/gdl.x86.rar ('tention, la zik fait de la merde sous vista, la compilation se fait avec vc++ 6 (j'ai essayé recement de recompiller sous le dernier ca à fait de la merde à cause de minifmod) sinon j'avais aussi du le porter pour etre compilable sous codeblock (par contre le compilo deriere je ne sais plus )

sinon pour la version gp, pour compiler la derniere version de ce code, je crois bien que j'avais utilisé gcc ptet avec devcpp, mais je ne retrouve pas la toolchain :/

en tout cas ca devrais bien passer avec ads (ca à etais principalement dev dessus)

je te conseille d'utiliser la lib officielle de gamepark pour utiliser le son et l'acces smc, j'avais essayer d'utiliser mlib de spiv (player de mod) sans succes, et le code de mirko pour la smc etais cassé pour l'ecriture (style 30 secondes pour ecrire 8 octets )
alors que la lib officielle marche tres bien, et la chn mod lib est parfaite (dailleur essais de prendre la derniere release qui devrais lire du s3m je crois ^^)

donc fait un gpfatinit au debut de ton prog, pour init et flipper l'ecran, tu peu direct utiliser le code de gdl (qui est celui de mirko fixé modifié et optimisé, plus inspiré d'autre bout de code pecho ici ou la), mais de ne pas init l'ecran avec le sdk gp, ou bien d'utiliser le sdk gp pour l'init et le flip, et utiliser simplement le code de blit de gdl qui lui sera compatible


en cherchant le compilo que j'avais utilisé sur ce code je suis tombé la dessus, ca pourra ptet t'interesser aussi :- )
Una-i Sprite Library


pour l'histoire de ta derniere ligne à ne pas afficher et l'alignement des sprites convertis, je crois bien que le bleme etais visible sur la demo pixel ici : http://procvor.free.fr/gdl/download.htm appuis sur style L le prog se met en mode 'trace' et tu verra la colision entre le perso et les boules, et surtout le perso et la map, il y aurra une ligne toujours en colision à cause de cette histoire d'octet suplementaire mis par le convertisseur ... bref

en cas je vais essayer de mettre en place ads sur un de mes pc ^^

tiens toi aussi tu es encore debout à cette heure tardive ?

à vrai dire c'est la v3...

ptdr ! okayyyyy, c'est une impression ou j'ai un peu un métro de retard mwé ? lol (mais chuuuut faut pas le dire)

bon bah je jetterai un oeil à tout ça demain, en plus ça tombe bien j'ai codeblock qui traine kekpars héhé Parce que j'aime beaucoup l'idée d'une lib multiplateforme (sinon c'est relou faut sombrer dans du SDL bien lourdingue et tout pfff). En plus je me rappel d'une version en travaux de ton lapinou sous windows, ça tournait du tonnerre !!

... Enfin okay, c'est noté : pour la version GP32 : ADS + SDK GP + CHNModPlay ! Yeaahhh, j'ai tout... ske j'aime quand je sais que je vais pas devoir passer 3 jours à configurer tout un environnement avec tout plein de lib (et qu'au final ça se marche trop pas ptdr ).

j'avais essayer d'utiliser mlib de spiv (player de mod) sans succes

Ah je connais pas du tout, jusqu'à présent j'ai tjrs carburer au modpay de chn J'ai tellement galéré pour le faire marcher paske j'avais pas les fichiers modifiés qu'il fallait (j'commençais à m'arracher le cheveux dessus d'ailleur, lol, heureusement que t'étais là ).
Sinon je me rappel avoir déjà tripatouiller la version qui supporte le s3m (le xm aussi non ? je sais plus), ça se compilais mais je crois que j'avais été obliger de modifier des trucs pour que ça marche...

[edit]ah okay, j'avais zappé mlib parce qu'elle est prévupour GCC à l'origine et oui ça li le xm aussi, ça c'est 'achement cool ![/edit]

je crois bien que le bleme etais visible sur la demo pixel

je regarde ça aussi demain, je vois qu'il faut compiler... et je suis pas sur l'ordi qui compile

en cas je vais essayer de mettre en place ads sur un de mes pc ^^

ça tombe bien je connais un super ftp ou y'a déjà tout c'est... ah bah c'est le tiens (ceci dit c'est une super idée )

Allez, bonneuh nuuuit !!

bon en fait c'etais devkitpro choisi devkitarm à l'instalation et il va tout te dl installer et configurer

par contre il va te mettre toute les lib mirko, et en essayant de compiler gdl avec il ma jeté car des nom de fonction etais existant, j'ai commenté les declaration dans les .h de mirko, ca a compilé mais je n'ai pas de gp sous la main pour tester, et de memoire l'init de l'ecran de mirko marche pas sous geepee :/

bref tout ca pour dire que le but de mon code etais de m'abstreindre du sdk de mirko en ayant simplement recuperer le bas niveau de son code et, je viens de retrouver, également des source de frodo l'emu c64

http://gp2x.org/gp32/frodo/ prend les source matte pogolib

bref je t'uppe la *vrai* derniere release de mon code http://procvor.free.fr/latest.devkitpro.Gdl.rar

essais le fxe si ca marche, ouvre le fichier pnprj avec programmer notepad, essais de compiler, commente les 4/5 lignes dans le .h de mirko (le compilo te dira ou)

sinon, te prend pas la tete et utilise son code ou au pire extrais simplement le necessaire de ma lib niveau blit si ca te tiens à coeur ^^ (tu peu aussi juste degager le code d'init d'ecran et des fonctions en double, ou au pire les renommer et les utiliser, ou encore degager entierement son sdk )

bonne chance lol

Cool du tout frais ^^

Okay sayé g tester ton fxe, y'a pas d'image mais j'ai bien le son... alors finalement mlib fonctionne ? (j'ai vu que tu l'utilisais dans ton projet)

[edit]ah non g rien dit, j'avais vu le libmlib.a, mais pas le modplayer.c de mirko [/edit]

ou encore degager entierement son sdk

... ouais youpi, vive la vie !! lol nan mais j'y penserai pour occuper mes longues soirées d'hiver

Rhaaa faudrait que j'aille dodo là... mais j'ai envie d'installer devkitpro titsuite... (dur dilemme)

'tin tu dormais tjs pas à 9h

int main()
{	
	
	gp_startSoundmixer(0);
	gp_startModfile(shock);

	while(1);
	Gdl_initGp32(freqTable[freq],85);
	unCrunchGfm(zeldaTiles,zeldaTilesFrmNb);
	unCrunchGfm(tile10,tile10FrmNb);

visiblement c'est normal, ca doit être le dernier truc sur lequel j'avais du taffer
essai sans le while(1); le reste du code est un test du lcd avec changement de frequence du proc, j'avais de bon resultat sur blu+

j'adore le while(1); au milieu

Ben quoi c'est commun comme méthode de debug, surtout dans les systèmes embarqués

hé oui, du debug bien à l'ancienne :- D

http://www.gp32x.com/board/index.php?showtopic=32302 la tu trouvera les lib officielles gamepark modifié en "eabi" pour etre utilisable sous devkitarm

'tin tu dormais tjs pas à 9h

ptdr ! ouais j'ai fait nuit blanche sur cette histoire de blit j'étais à fond dedans lol par contre j'ai roupillé toute la journée -__-'
Finalement j'ai réécris ma propre fonction de blit 16bits paske je me voyais mal refaire tout un framebuffer juste à cause ça... ça marche nickel maintenant, et pis ça m'a permis de bien comprendre comment ça fonctionnait. c'est cool chui content

j'adore le while(1); au milieu

lol, pareil, ça c'est du debug comme je les aime ^^

essai sans le while(1);

ah okay, dsl, j'avais juste testé le fxe qui était dans l'archive, sans le compiler moi-même... sinon j'aurai grillé le while (pi vu l'heure j'te cache pas kg pas vraiment pris le temps de regarder ds les sources )

tu trouvera les lib officielles gamepark modifié en "eabi" pour etre utilisable sous devkitarm

ah mortel ! marrchii niveau perf ça change kekchoz de compiler avec devkitarm au lieu de ads ?
(moi je m'en servais que pour compiler les prog en C qui utilisaient SDL)

Finalement j'ai réécris ma propre fonction de blit 16bits

bravo :- )

niveau perf ça change kekchoz de compiler avec devkitarm au lieu de ads ?

à l'époque niveau perf, ads > sdt > gcc
mais la gp ayant bientôt 10 ans si je ne m'abuse, gcc à bien du évoluer depuis ^^

mais bon, c'est sur la il doit falloir transformer les autres lib en eabi, style celle de chn

bravo :- )

Marchi ! J'en ai profité aussi pour faire une fonction qui me blit une image sur tout l'écran en une fois via un memcpy (pour afficher un fond, écran titre, etc), si j'ai bien saisi ça doit être plus rapide qu'un gros GpBitBlt de 320*240 !

style celle de chn

De mémoire je crois que les dernières versions, celles supportant le xm et s3m, sont déjà prévues pour GCC. C pour ça que j'ai du les modifier pour ADS et le sdk gp, genre remplacer les fopen par GpFileOpen etc... (mais ça me donnais des plantage aléatoire de la GP32 alors j'ai pas diffusé mes modifs)

Un memcpy est bêtement une copie software rapide, peut être à coup de ld/stmia, ou bien en C avec des boucles déroulées. Rien que tu ne puisses pas faire par toi même en tous cas ^^
(En plus memcpy a un overhead parce qu'elle doit être générique, en particulier supporter des adresses impaires ou une taille non multiple de 4 )

Ui, c'est ce qui me laisse penser que ce sera plus rapide qu'avec GpBitBlt, qui lui fait certainement une copie ligne par ligne

tu peu aussi prendre le memcopy asm fait pour netbsd
tu as le .s dans mes sources, avec ca pour le déclarer

extern "C" { void asm_memcpy(void*,void*,unsigned int);
void gp_enableCache(void); }

prend aussi le .s qui active le cache, c'est thunderZ qui l'avais fait :- )

Hummm, comme ces fichiers m'intriguais j'ai été voir un peu de docs sur l'assembleur ARM (ça fait pas de mal ^^), puis j'ai dévié sur le fonctionnement des fonctions memcpy/memset sur gba... je savais pas vraiment comment elles fonctionnaient par derrière... et c'est vraiment passionnant !

maintenant brunni je comprend carrément mieux ce que tu me disais dans ton msg précèdent, à propos de cette histoire d'overhead !... enfin je crois lol en fait c'est ce qui est expliqué dans cette page "memcpy and memset replacements for GBA/NDS" (faut copier le plus de blocs possible à la fois afin de réduire le nombre d'itération de la boucle (et donc aller plus vite), puis compléter ce qu'il manque à la fin si la quantité à copier n'en était pas un multiple)

quand je pense qu'en plus c'est les bases... j'ai presque honte lol... enfin bon, j'assume, et pis mieux vaut tard que jamais

rz (./28) :
puis compléter ce qu'il manque à la fin si la quantité à copier n'en était pas un multiple)

et au début si c'est pas aligné ^^