GpBitBlt et GpBitBlt16 - Page 1

Heu c moi qui plane ou ces fonctions rendent des images pivoter de 90 degres vers la gauche...?

(minigp32+geepee32)

Non elles fonctionnent très bien

J'ai u pb de flip horizontal de sprite quand j'utilise la macro Spirit() de defineIt.h

Je ne me rappelle pas avoir eu de pb avec les fn du SDK.....Mais c'est si loin.....

defineIt marche sur SDT

le flip vient de la façon dont est structurer la ram vidéo.
le premier octet de la ram video de la gp32 commence en bas à gauche. Quand tu incrémente l'adresse ça remonte.

en fait un point en x, y sur photoshop se trouve en
indexAddr = (240 - y) + (x * 240)
sur l'écran gp32

Les fonctions de la lib GP écrive donc en partant de y = taille y et x = 0.
de plus, comme la lib gp copie l'image par dword, il faut que ta hauteur soit multiple de 4 sinon tu va avoir des trucs bizarres.

La taille multpile de 4 c'est pour les images en 16 bits, pour celle en 8 bits c'est pas la peine

Je code sous GCC et la macro Spirit prend en compte l'orientation de l'écran.
Mais bon c'est pas très grave, pour ce que je fais.....
Il faudra quand même que j'y jette un oeil à l'occaze mais j'ai tellement de trucs à faire.

les tailles non multiple de 4 me foute la merde en 8 bit aussi.
j'utilise gpblit et cette fonction copi les octets 4 x 4

donc si ta hauteur n'est pas multiple., il copie trop de byte sur la verticale les dernier et déforme l'image

je suis sous minigp32... peut être que la lib std repère ça et affiche en byte dans le cas de taille non multiple

oh la la les problemes, putain pkoi ils ont pas fait un truc standard......

Remark : Simply transfers data area (image) designated as src to a target surface designated as GPDRAWSURFACE.
For reference, the coordinates of GPSDK’s LCD origin is ( 0, 0 ) for left-top and ( 320, 240 ) for right-bottom.
※ GPSDK Graphic Basic API

Ben franchement je sais pas ce qu'ils faisait en redigeant la doc API

Bon moi j'utilise SDT

DeMi-LAiT a écrit :
oh la la les problemes, putain pkoi ils ont pas fait un truc standard......

Ben franchement je sais pas ce qu'ils faisait en redigeant la doc API

ca ne viens pas de l'API mais de l'ecran utilisé. Je ne sais pas trop quel est la reference de l'ecran ou quel est son utilisation premiere, mais il est a l'origine prevu pour etre utilisé verticalement. Dans ce cas l'origine est bien en haut a gauche.
Mais comme le GP32 avait besoin d'etre horizontale, l'origine est donc en bas a gauche.

On se rend compte de cette particularité en regardant comment sont formé les pixels. Au lieu que les parties rouge verte et bleu soit horizontale les une par rapport aux autres, ici elles sont verticales. Rien de bien important sauf pour utiliser des font réalisé en sous pixels ( http://grc.com/cleartype.htm ) qui marche par contre tres bien sur GBA (et pourtant je suis sur que presque qu'aucun jeu n'utilise cette merveilleuse technique).

Par contre je me demande si le format de l'ecran n'est justement pas a l'origine du mode 16 bits. En effet, je sais pas du tout ce qu'il trafique derriere mais il est possible que l'ecran ne soit prevu que pour supporter du 256 couleurs. En utilisant une interruption a chaque ligne (donc chaque colonne dans notre cas) il est possible de changer la palette qui est en 16 bits a chaque fois, palette de 256 couleur pour remplir finallement que 240 pixels, pour finalement avoir un rendu totallement en 16 bits. Si cette technique n'est finallement pas utilisé par l'API il est par contre peut-etre possible d'optimiser avec cette gruge et meme d'avoir certaine lignes en 16 bits et d'autres en 8 selon les besoins (genre un menu a gauche de l'ecran) et meme d'avoir des changement de mode d'ecran a la volée sans passer par l'API.

ils ont du surement utilise un ecran de PDA, ce qui pourrait expliquer le pkoi. Par contre je n'arrive pas a comprendre pkoi ils ont pas prevue ca dans le API, je vois pas trop l'interet de faire une fonction d'affichage si apres faut se tapper une rotation.... ?
Et de la a se planter comme ca dans la descritpion de la fonction c quand meme grave....

OUA ! Lama ! ça faisait longtemps qu'on t'avait pas entendu......Ca fait plaisir de te revoir. Et en + tu nous en met plein la vue

Alors il avance ton ému ?

DeMi-LAiT a écrit :
ils ont du surement utilise un ecran de PDA, ce qui pourrait expliquer le pkoi. Par contre je n'arrive pas a comprendre pkoi ils ont pas prevue ca dans le API, je vois pas trop l'interet de faire une fonction d'affichage si apres faut se tapper une rotation.... ? Et de la a se planter comme ca dans la descritpion de la fonction c quand meme grave....

Pkoi ? parce que si il faisait les rotation a chaque ca serait lourd. C'est toujours possible de faire la fonction qui le fait automatiquement mais ca n'a que tres peu d'interet. Il est preferable de tout precalculer avant de mettre tes bitmap dans la GP32. Tu met directement tes bitmap pre-rotationner (c'est francais ca ?).

saluté pékélé
je poste plus beaucoup, mais je lis le forum regulierement. Et puis bon ce que je dis c'est que du flan, c'est que pour en mettre plein la vue Sinon pour l'emu, ca fait bien 3 mois que je l'ai fini. Il fait tourner toute les jeux Megadrive a 100% de la vitesse avec le son (j'ai meme appliquer le rendu sur un cube 3D tellement ca allait vite). La je bosse sur un emu neo geo. Il fait tourner l'intro de world heroes 2 pour le moment ^^

C'est rigolo de lire avec du recule ... j'essayerai cette expérience encore ....

Patience, l'ADIC 2003 va bientôt être annoncé ...

WOW ! Bille2 !
Je croyais que tu étais parti avec Lama, lol

Lama : je comprends mieux pourquoi tu poste moins, avec les émus que t'as fait, forcément tu as de quoi t'occuper

Bon coding les gars !

Lama : mais dans mon cas l' image que je dois afficher et inconnue donc je dois faire la rotation a chaque fois.

Je comprend vraiment pas pkoi ils ont pas la meme norme pour toute leur fonction...l'affichage de texte marche bien , ils ont les bonnes coordonne quoi...comprend pas

Je connais pas bien les libs de gamepark car honnetement je ne les aient jamais utilisé tellement j'en ai entendu du mal au debut niveau performance. Je ne sais d'ailleurs toujours pas si leur fct de blit utilisait les transfert DMA. SI quelqu'un le sait, ca m'interresserait de savoir.

Donc t'as 2 solutions, soit au chargement de ton image tu fait une fois pour toute le shmiliblick pour faire une rotation de ton image et tu utilises les fonctions de gamepark, soit tu réecris t'es propre fonction de blit.
Je te conseil personnellement la premiere solution.

Ben il me faut le max de performance donc faudrait les reecrires...est ce que il y a des docs sur la ram lcd et compagnie ?

Tu à la description du GPDRAWSURFACE dans le sdk de gamepark et il me semble qu'une des variable est un pointeur vers la zone de mémoire correspondant à l'écran

Ué effectivement y a un truc dans le genre, mais c un tableaux de 4 pointeurs...assew bizar...
Et pis oui l'ecran de la GP c presque sur que c un ecran de PDA...

y a un dma sur gp32 ?
comment qu'on s'en sert ?
un petit exemple ?

J'ai pas trop regarder et je ne l'ai pas encore utiliser, mais il me semble qu'il est assez similaire a celui sur GBA. Par contre son gros avantage est d'etre non-bloquant, enfin disont que c'est tout ce qu'il y a de plus normal, c'est juste que c'est sur GBA ou c'est incroyable que la DMA soit bloquant.

ben dans le datasheet du proco ya vraiment beaucoup dinfos....notamment sur le DMA

heu excusez-moi, mais pour en revenir au sujet du post ...

bin chez moi, compile avec ADS (changé les libs son et timer avec celles de SDT et GCC ^^), et mes images elles s'affichent direct dans le bon sens, sans AUCUN blème

a ue ... ben la je comprend plus rien...en plus comment ca les libs GCC sont compatible ADS ...?

sanosuke tu converti sans doute tes images avec un tool qui te les rotates comme il faut.

possibilus je convertis avec gpconverter ...

Demi-Lait : oui c'est les méthodes a Thun et a rlyeh

Vivi je confirme ca marche nikel.

Si kelkun a besoin de precision je suis la