Mon affichage de sprite a moi (ASM) - Page 3

okey merci

et en utilisant le sdk gp, un truc du style gpDraw[nflip].ptbuffer = &MonBufferAMoi ; c possible ? (je c je pourrais tester ^^')

ThunderZ: c'est ce que je fais, la routine sprite en asm travail en 240x320, c'est comme tu le dis, il faut raisonner a l'envers.
r043v: oui 1000 fois a condition que ton compteur fps gère les centièmes de seconde histoire d'être bien précis. c'est simplement pour testé et se faire une petite idée en tête rien de plus.

Un truc que vous oubliez c'est que dans cette memoire virtuelle, il va y a voir plein de traitement graphiques de ce style là:

plusieurs couches, sprites, etc.

ensuite l'affichage, ce qui fait quand même un traitement beaucoup plus impossant que la copie vers l'écran (mais je suis d'accord sur le fait qu'il faut aussi optimisé ça, même si c'est minime )

ce qui est bien c'est que par exemple si l'on prend l'image de mégaman, on peut vraiment optimisé chaque élément de l'image comme on veut, en créent une routine adéquoi même si c'est pour 2,3 éléments seulement, c'est du temps gagné.
Dans le genre, le fond, si c'est statiques ou a scrolling horizontal, alors, on peut l'afficher tous simplement en 32 bits en faisant une copie 32 bits de l'image fond sur la mémoire virtuelle.
si le scrolling et en map tilé, par exemple de 8x8, alors, on peut imaginez de crée des routines spécialement optimisé 8x8 du genre GP32SpriteTile8x8FxClip.
Les tiles remplis sans transparance ---> GP32SpriteTile8x8Clip.
les tiles a l'interieur de l'écran sans utilisé les clippings ---> GP32SpriteTile8x8Fx et GP32SpriteTile8x8
la bar d'energie en GP32SpriteFX sans les clipping
la jauge de vie dans la bar en GP32Sprite sans la transparence et les clipping, etc...

bref, pas mal de petit détail par ci par là qui donne au final un résultat "rapide", bref, j'espère que vous avez compris mon point de vu a ce sujet là ;-)

je vais rajouter une petite chose, c'est que les routines du sdk, les sprites notamment sont généraliste, c'est a dire que bien souvant, il y a du code/traitement en trop qui ne sert pas a grand chose pour se que l'on veut afficher, là par contre, comme je décrit au dessus, on ne pert rien en code vu qu'on l'on affiche uniquement se que l'on a besoin au code près.

CoderMan
: adéquoi

LOL
(désolé je t'attaque pas ou quoi mais ça m'a juste fait marrer de lire ça )

moumou j'ai pas compris mais c'est pas grâve ^^;

CoderMan > et tu as cb de fps en effaçant 1000 fois ton ecran ?


je viens de passer ma fct de blit (non clippé) en 16/32 bit
j'ai du passer le tableau des pixels pleins en un tableau de pointeurs pour avoir chaque colones pleines aligné sur 4 octet, ce qui a baissé les perf de 30% au debut :/

c tj la mm image , tj affichée 20000 fois

* image non transparente

en 51.50 : 2334 tick
en 51.49 : 1561 tick
en 51.48 : 2334 tick
en 51.47 : 897 tick

je suis encore tres loin du sdk gp

* image transparente

en 51.50 : 787 tick
en 51.49 : 902 tick
en 51.48 : 792 tick
en 51.47 : 947 tick

(non je ne doit pas avoir un prblm ac mes coordonnées, tt depend de l'alignement des colones pleines à l'ecran, et de leur tailles)

bref mon systeme n'a d'interet que pour les images transparentes, et tout va dependre de l'image.

CoderMan > et tu as cb de fps en effaçant 1000 fois ton ecran ?

4 à 5 fps si mais souvenir son bon, c'est correct même si c'est pas énorme. ^^;

Sinon, je suis pas trop expert du mode 16bits sur gp32 c'est à dire 65536 couleurs, j'aimerai bien essayé une ecran virtuelle en 16 bits(76800*2) mais je sais pas trop comment l'afficher (je précise que je suis pas un grand programmeur de la gp32, je débute la dessus).
Le but c'est de refaire la routine spritefx supportant les 65536 couleurs et vu que je travail en 8bits, autant travailler en 16bits, je pense pas qu'il y aura de perte de vitesse et le resultat sera bien plus sympatique. j'imagine pas les effets d'alpha blending et de blur, pour la même vitesse qu'un 256 couleurs, ca peut être sympa.

Si quelqu'un peut m'eclairer la dessus sur l'affichage en 65536 couleurs sur l'écran lcd, ce serait cool.

5 fps, ca va c rapide ^^

ben en 16 bit, 1 pixel utilise 2 octet lol c le seul truc qui change
la couleur est codé en 5 5 5 1, la memoire est organisé de la mm maniere qu'en 8 bit, de bas en haut et de gauche a droite

ac la routine asm que tu as pondu un peu plus haut et vu comme tu la ramene, ca m'etone qt mm un peu (bc ?!) que tu ne sache pas ca.

non mais r043v...merci mais je sais déjà ca tu sais ^^; 16 bit c'est 2 octets, pour les couleurs, c'est pareil hein...lol, ok mais merci quand même...;-)
et justement après le code en asm que j'ai "pondu", tu dois t'en douté un peu que je sache ca non?

je parle du mode graphique en 16bits, de l'affichage final sur l'écran lcd en 65536 couleurs(32768 pour les frustrer ^^; ), "la routine" qui affiche l'écran "virtuelle 16bits/couleurs" sur "l'écran lcd".

je m'en fou de savoir pour l'instant que c'est en 5 5 5 1, vu que cela se joue uniquement lors de la convertion de la couleur du pixel du sprite en 2 octets dans le tableau avec un prog externe. donc, dans la routine, tu travail toujours en 16 bits, donc t'oublie le 5 5 5 1 pour le moment vu que tu n'utilisera pas ce procédé pour les sprites (mise à part pour les effets d'alpha blending mais c'est pas encore le but pour le moment)

ac la routine asm que tu as pondu un peu plus haut et vu comme tu la ramene, ca m'etone qt mm un peu (bc ?!) que tu ne sache pas ca.

ok...après avoir chipoter 2,3 heures pendant la nuit sur ça, c'est sympa d'entrendre ce genre de réfléxion dit moi...

> je parle du mode graphique en 16bits, de l'affichage final sur l'écran lcd en 65536 couleurs(32768 pour les frustrer ^^; ), "la routine" qui affiche l'écran "virtuelle 16bits/couleurs" sur "l'écran lcd".

si tu avais lu ce qui est ecrit plus haut, tu aurais compris que ton ecran virtuel est EXACTEMENT le meme que celui de gp (car tu le blitte ac un gpbitblt)
donc en 16 bit, c magique tu peut utiliser un gpbitblt16, ou, comme dis plus haut, un memcpy, ou encore direct blitter ac ta fct sur le buffer d'ecran (encore et tj comme dis plus haut ^^')
et ca m'etone tj, que tu sache comment sa marche en 8 bit et non en 16 (gpbitblt16 est comme gpbitblt ds la doc du sdk gp)

> vu que tu n'utilisera pas ce procédé pour les sprites
que c tu de ce que je v utiliser ou pas ?
- tu n'utilisera + j'utiliserais ??

> donc t'oublie le 5 5 5 1 pour le moment vu que tu n'utilisera pas ce procédé pour les sprites (mise à part pour les effets d'alpha blending mais c'est pas encore le but pour le moment)

non, moi j'oublie pas, je le c, si toi tu veut l'oublier, ben oubli lol tu demande des info sur le 16 bit je t'en donne
et c pas moi qui ai parlé d'alpha blending

> ok...après avoir chipoter 2,3 heures pendant la nuit sur ça, c'est sympa d'entrendre ce genre de réfléxion dit moi...
c plus une remarque qu'une reflexion, (mais c vrai que le 'comme tu la ramene' est un peu deplacé), enfin bon, c cool vu que tu as dis savoir déjà tout ca tu n'a pas a en etre véxé ;-)

> vu que tu n'utilisera pas ce procédé pour les sprites
que c tu de ce que je v utiliser ou pas ? - tu n'utilisera + j'utiliserais ??

je parlais pas de toi, c'est une façon de parler...

non, moi j'oublie pas, je le c, si toi tu veut l'oublier, ben oubli lol tu demande des info sur le 16 bit je t'en donne et c pas moi qui ai parlé d'alpha blending

je ne t'ai jamais demander comment fonctionné le RGB de la GP32 et j'aurais bien pu trouvé sur le net ce genre de chose facilement.
De plus, j'insiste sur le faite que pour l'instant, avec ce que je veux faire, ca ne sert a rien, dans une routine sprite par exemple, tu ne fais que des copies de 16bits entre mémoire et tu ne gère pas le RGB dans la routine. Pour l'apha blending je m'en doute un peu, c'est logique même, mais à la base, je parlais plus des sprites et tu dois le savoir. Faut évitez dans rajouter dans les réponses alors que c'est pas spécifier dans la question, surtout dans un ton du genre "tu sais pas ca???" comme le tiens qui est très vexant je trouve.

c magique tu peut utiliser un gpbitblt16

apparament, il n'y a aucun mode a activé avant. si tu as programmer dans d'autre plat-forme du doit savoir ça aussi. c'est uniquement ce que je voulais savoir pas besoin de jouer au "programmeur gp32 le plus doué" -_- ...
j'ai toujours travaillé avec un écran virtuelle sur d'autres plate-formes, ci c'est le même ou pas, peut importe, ca reviens au même, sauf que pour moi, je crois que c'est plus facile a programmer comme ça, mais chaqun son truc après tous.
Je vous apporte mon idée et je demande un renseignement, tu sais répondre ok mais t'es pas obligé de faire le malin dans tes propos...

salut à tous, je ai lu l'ensemble de vous commentaires et j'aurais aimé avoir une ou deux précisions.

c'est quoi un sprite clippé ou une routine clippée?

j'ai compris que le sens du screen c'est 240*320, mais où est le 1er pixel ? et dans quel sens ça part?

merci de repondre à ces petites questions aprés je me joins au debat.

ne prennez pour un noob, MERCI.

-

-

Et ca part vers le haut.
(le deuxieme pixel est sur la premiere colonne, le deuxieme en partant du bas)

> je ne t'ai jamais demander comment fonctionné le RGB de la GP32 et j'aurais bien pu trouvé sur le net ce genre de chose facilement.
trouver comment init la gp en 16 bit est 1000 fois plus simple que de trouver comment est codé une couleur 16bit sur le net
(pour la bonne raison qu'init la gp en 16 bit est marqué ds la doc, contrairement au rgba.)

> Faut évitez dans rajouter dans les réponses alors que c'est pas spécifier dans la question
putain tu saoule, je t resumé en 2 ligne le mode 16 bit, si t pas content, oubli que je t parlé du rgba, ou va te jeter

> ca ne sert a rien, dans une routine sprite par exemple
ah ui, et si g envi que la couleur transparente de mon sprite ne soit testé que sur la composante rouge ou sur l'alpha ?!

> surtout dans un ton du genre "tu sais pas ca???" comme le tiens qui est très vexant je trouve.
... kes tu veut que je te dise, ta trouvé comment init la gp en 8 bit et utiliser le flip d'ecran ainsi qu'un gpbitblt, alors, ui je suis étoné que tu n'est pas trouvé comment on faisais en 16 bit surtt que c ds la mm doc.
alors a moins que tu te soit reveillé un matin (ou un apres midi hu²) et que ta fct soit *pouf* ecrite, ben ué ca m'etone

> apparament, il n'y a aucun mode a activé avant.
si, faut qt mm init l'ecran en 16 bit, mais je te laisse aller voir la doc du sdk, au cas ou je te dise trop d'info ;-)

> si tu as programmer dans d'autre plat-forme
nope :/ un peu de code pc, et un pti jeu pas fini en C sur Ti (par contre moult de ti basic)

> pas besoin de jouer au "programmeur gp32 le plus doué" -_- ...
arf mais lol :] je suis tres loin d'etre le plus doué, je suis un noob ds la programation, ca ne fait que 2 ans que je code reelement, et toute les nuit j'en apprend.
par contre, escuse moi, mais qt tu as débarqué ac ta fct asm mmm mmm ;-)

> j'ai toujours travaillé avec un écran virtuelle sur d'autres plate-formes, ci c'est le même ou pas, peut importe, ca reviens au même, sauf que pour moi, je crois que c'est plus facile a programmer comme ça
depuis le debut on te dit que c pareil, ca y est ta enfin compris ^^

> mais chaqun son truc après tous.
ah bah ta juste compris 2 secondes alors :/

> tu sais répondre ok mais t'es pas obligé de faire le malin dans tes propos...
arf mais lol² serieux koi, c qui qui nous sort une fct asm qui casse le cul, qui nous prend pour des noob en disans qu'afficher un truc au millieu de l'ecran est plus rapide ac une routine non clippé ect ??!

sache que 9 fois sur 10, qt j'ecrit un post, celui ci n'a rien a voir au final ac ce qui etait ecrit au debut, je fait vachement gaffe sur ce que j'ecrit, et c encore plus rare qt je clique sur ok, (je n'ai pas reaji a ton premier post ici alors que pourtt j'en avais vachement envi) donc non je ne fait pas le malin (j'aimerais bien avoir l'avis des autre sur ce sujet.)

ce qu'a dis tibool sur ton compte ds l'autre thread est finalement vachement vrai je trouve :/

et dsl si tu n'aime pas ce que g ecrit, clique donc sur la petite croix rouge

j'ai beau creuse le problème et il n'y a mon avis qu'un changement de format, pour optimiser le tout. autrement je vois pas comment on pourra faire bcp mieux que le sdk. je taf tout ça et je vous le présente sous peu.

ok

> je ne t'ai jamais demander comment fonctionné le RGB de la GP32 et j'aurais bien pu trouvé sur le net ce genre de chose facilement.
trouver comment init la gp en 16 bit est 1000 fois plus simple que de trouver comment est codé une couleur 16bit sur le net (pour la bonne raison qu'init la gp en 16 bit est marqué ds la doc, contrairement au rgba.)

tu crois ca toi? j'ai du mal chercher alors, parce que j'ai fait que ca hier soir et je t'assure, j'ai rien trouvé. D'ailleur pour le 5 5 5 1, le savait déjà avant, j'en avait parlez sur ce forum dans un autre sujet a propos des couleurs de la GP32. mais soit, l'important c'est que j'ai jamais demandez le comment ce traitement RGB. (t'es soulant avec ca en passant)

alors a moins que tu te soit reveillé un matin (ou un apres midi hu²) et que ta fct soit *pouf* ecrite, ben ué ca m'etone

j'ai pas compris mais soit.

putain tu saoule, je t resumé en 2 ligne le mode 16 bit, si t pas content, oubli que je t parlé du rgba, ou va te jeter

ta pas compris que je savais déjà ca??? c'est l'"affichage" sur l'écran qui m'interesse, la "ROUTINE du sdk" faut savoir lire de temps en temps sans ce la jouer!
Ca te viens pas a l'expris que j'ai travailler uniquement sur les routines en asm avec l'ecran virtuelle et non avec les "fonction sdk" (dout le manque d'optimisation exprimez par orion et ce que je demande pour le 16bits/couleurs), J'ai beau cherchez sur le net, aucun site ne parle de ca avec précision et c'est pas dans la doc mal détaillé du sdk que je vais apprendre quelque chose, dout ma question sur le forum afin d'évitez pleins de test inutile (faut dire aussi qu'il etait tard hier, regarde l'heure au j'ai poster!)

> ca ne sert a rien, dans une routine sprite par exemple ah ui, et si g envi que la couleur transparente de mon sprite ne soit testé que sur la composante rouge ou sur l'alpha ?!

concretement un sprite transparent comme tu dis ca ne sert a rien, pourquoi faire au juste? tu n'as fixé une couleur standard, le plus utilisé c'est le rose ou le vert, ca donne une valeur fixe non du style 15420 (j'invente, je sais pas de mémoire), pourquoi décomposé en 5 5 5 1 alors? ca sert a rien et c'est super lent au final.

> tu sais répondre ok mais t'es pas obligé de faire le malin dans tes propos... arf mais lol² serieux koi, c qui qui nous sort une fct asm qui casse le cul, qui nous prend pour des noob en disans qu'afficher un truc au millieu de l'ecran est plus rapide ac une routine non clippé ect ??!

Excuse moi, mais soit t'es vraiment le roi des con ou soit tu le fait exprès sérieux. Si tu prend tout à de son contexte, c'est normal. hein, j'ai cité pleins de point d'optimisation décomposé, mais si t'en prend qu'un seul, effectivement, je fait très "noobs de chez noobs", si c'est ce que tu veux et bien...

> apparament, il n'y a aucun mode a activé avant. si, faut qt mm init l'ecran en 16 bit, mais je te laisse aller voir la doc du sdk, au cas ou je te dise trop d'info ;-)

voila, ca fait le malin depuis hier et ca n'est même pas capable de répondre correctement, d'abord tu me dis qu'il faut simplement mettre en bitblt16 maintenant, tu me rajoute qu'il faut mettre un Init pour active le 16 bits, alors que c'est ce que je demandez tous simplement. TU a vas tous le blabla inutiles qu'il y a fait pour une simple "bête petite question"????

ce qu'a dis tibool sur ton compte ds l'autre thread est finalement vachement vrai je trouve :/

mais je commence a comprendre pourquoi tu changes de comportement vis à vis de moi du jour au lendemant, bonjours les préjuger...c'est petit, très petit.

Toujours ce jeu du "plus con" avec qui déjà CODERMAN, tiens comme par hasard...

je perds mon temps.

........ je croi que c moi qui v cliquer sur la croix :/

dsl je joue bc sur les mot ac toi mais tu n'a ka t'exprimer corectement (reli tes post !)

bon, apres 10 secondes de recherches ds le pdf du sdk gp :

int GpGraphicModeSet(int gd_bpp, int *gp_pal);
This function is used to set the graphic mode for the system.
int gd_bpp : This function designates the bit per pixel value, either 8 or 16.
...

romarin ct bien caché
en + tu utilise déjà la fct pour activer l'ecran en 8 bit ;-)

par contre, essai de trouver le 5 5 5 1 ds le pdf

> ta pas compris que je savais déjà ca???
sisi regarde la derniere ligne 10 post plus haut

> Ca te viens pas a l'expris que j'ai travailler uniquement sur les routines en asm avec l'ecran virtuelle et non avec les "fonction sdk"
si, sinon tu n'aurais pas utilisé ton buffer d'ecran 'virtuel' (et puis, entre () si ta pu trouver tout seul le format des images gp, tu aurais aussi pu trouver le format du buffer d'ecran)

> pourquoi faire au juste? tu n'as fixé une couleur standard, le plus utilisé c'est le rose ou le vert, ca donne une valeur fixe non du style 15420 (j'invente, je sais pas de mémoire), pourquoi décomposé en 5 5 5 1 alors? ca sert a rien et c'est super lent au final.

g jamais dit que ct la façon ultime de coder (mm si je pense (attention j'en c rien) que faire un & sur la couleur pour voir si le bit alpha est activé ou non est plus rapide que de faire un == ac ta couleur de transparence)
mais tu dit que ca ne sert a rien pour une routine de sprite, c juste un contre exemple, et puis merde je m'en tappe severe si tu savais déjà que c en 5 5 5 1

> j'ai pas compris mais soit.
ct pour te faire comprendre que tu a du aller matter la doc pour savoir faire init l'ecran, le flipper, ou utiliser le gpbitblt, et que si ta trouvé pour le 8 bit ben t'aurais du trouver pour le 16 (marre de me repeter :/)
mais c pas grave, laisse tomber la neige.

> je fait très "noobs de chez noobs", si c'est ce que tu veux et bien...
g pas dit que tu etait un noob, rien qu'a voir ton code asm c moi le noob, mais a ton comportement tu nous prend pour des noeud

> mais je commence a comprendre pourquoi tu changes de comportement vis à vis de moi du jour au lendemant, bonjours les préjuger...c'est petit, très petit.
d'ou mon comportement a changé ? t'ai je leché le cul un jour ?

> Toujours ce jeu du "plus con" avec qui déjà CODERMAN, tiens comme par hasard...
si c tj ac toi, pose toi des questions ;-)

ne compte plus sur moi pour repondre ca y est j'en ai marre et si ca te fait plaisir considere que ta gagné

c'est pas un jeu à la base r043v et j'ai rien gagné c'est toi qui a commencé a t'enflammer pas moi.

pour info, je risque de ne plus poster, je vais mettre un password à la "nawak", ca va en faire des heureux! (et des vacances surtout pour moi!)

Dites les enfants vous voulez un des pistolets à eau ?

Non parce que ça ressemble plus tellement à un post dédié à la recherche de performances pures !!

Chaqu’un à son avis à donner et c'est pas forcement intéressant, si c'est le cas faut pas en tenir compte ou demander des explications.

Mais pas délirer sur deux agressifs, puis quand c'est le cas autant le prouver avec un benchmark.

Hello all,

Je me suis interessé au probleme de l'affichage rapide de sprites en assembleur ARM pour l'ecriture de la bibliotheque multiplateformes d'int13, a savoir uEngine, que j'ai porté sur GP32 il y a peu (lib interne int13 pour le moment).

Les specs de la routine de sprite etants :

- Gestion du clipping
- Integration d'un plan alpha pour avoir des pixels semi transparents
- Possibilité de dessiner le sprite en alphablending ou additive blending ou d'autres modes exotiques
- Aucune contrainte sur la taille du sprite, celui ci doit pouvoir etre plus grand que l'ecran

Vu qu'un sprite compilé n'est pas envisageable a cause du clipping et de la memoire necessaire, la meilleure solution d'apres moi reste l'encodage en RLE.

Run Lenght Encoding, cela consiste a coder le sprite sous la forme de segments, on evite ainsi les tests de transparences et on peut blitter jusqu'a 16 pixels d'un coup.

Le processeur ARM dispose en effet d'instructions ldmia et stmia qui permettent de lire puis ecrire le contenu de 8 registres 32bits en meme temps, donc 16 pixels 16 bits d'un coup, d'un seul.

Le defaut qui complique pas mal de choses, c'est que le processeur ARM ne sait pas lire ni ecrire des mots de 32bits a une adresse non alignée sur 32bits, il faut donc s'arranger pour que le depart des segments RLE soit TOUJOURS alignés, et gerer les deux cas aligné/non aligné pour l"ecriture, il est aussi preferable de faire bien attention au format utilisé pour pouvoir y integrer simplement un plan alpha et d'autres infos utiles.

Il est egalement utile se bien reflechir au probleme de l'alphablending, il est possible de limiter le nombre de multiplication a une seule, en faisant attention.

Le dernier point important est le prefetch du cache memoire, comme on sait qu'on va lire bientot la suite du sprite, il est interessant de faire des lectures bidons une ou deux lignes de cache a l'avance... histoire de ne pas attendre quand on va vraiment lire les pixels.

Voila, je n'en dis pas plus, je publierais un bench GP32 d'ici quelques temps je pense, sur PocketPC il est possible d'afficher dans les 3000 sprites de 32*32 a 30FPS.

Woow j'ai hate de voir sa !!!

c klair!
avec un pti .h a integrer dans les projets et hop on accelere tout!!

tres interessant tout ça

Ah donc ça s'appelle du RLE ce que j'essayais de faire
Bon ben maintenant je sais que ma fonction RLE marchait pas

JyCet :
Ah donc ça s'appelle du RLE ce que j'essayais de faire

Si ca peut te consoler, j'avais bien vu qu'il parlait de ce que tu tentais de faire. Non tu n'es pas un incompris. Au moins une personne est a ton ecoute !

Ca me consolerait un peu plus si tu me disais que tu avais essayé et que ca marchait pas aussi

JyCet :
Ca me consolerait un peu plus si tu me disais que tu avais essayé et que ca marchait pas aussi

Si j'avais essaye, ca aurait marché