30

Orion_ :
CoderMan > j'ai rien compris a ton explication neutral

Soit j'ai loupe un truc soit c'est tout simplement du double buffering comme on fait tous. Tout a fait compatible avec le SDK si on met le pointeur des 76800 octets dans la bonne structure.

31

yaouank: tu peux conciderer ca comme du double buffering ( sauf qu'il y en a qu'1 seul) et c'est tous a fait compatible avec le sdk, mais le principe c'est de ne pas utilisé les routines du sdk qui, d'après moi, sont beaucoup plus lent et de tout crée soit même comme il faut (mise à part pour l'affichage final )

32

-

33

sa fonction tourne sur un ecran virtuel, et ta vu les bench par rapport au sdk ? le sdk est bien plus rapide. donc même refaire ces propres fonction ça peut etre parfois plus lent.

nan sérieux?????? tu me prend pour un con, si oui fait le moi savoir?
ensuite faire passer ton ecran virtuel pour un sprite au yeux du sdk, c completement debile et lent !

et pourquoi tu dis ca? j'ai jamais dit que cette dernière etait rapide, je sais que c'est débile mais c'est pas là le but. de plus, c'est pas si débile que tu le prétant vu que cette dernière est qu'une étape final et elle te permet de faire de effet de window final en peu à la manière de la gba. (le genre de truc qui sert à créer une transition rapide).
Ensuite regarde mon code assembleur, tu verras qu'il est simple et surtout "rapide" pour un sprite surtout "avec une transparance" et du clipping.

test un fillscreen avec le sdk et ensuite avec cette routine ci et on n'en reparlera après.
@ Reference it from C by using:
@  extern void GP32FILLSCREEN (unsigned char color,unsigned char *vscreen);
@
@ Entry:
@  r0 = color, r1 = Vscreen
.EQU Performance, 8

        .ALIGN
        .GLOBAL GP32FillScreen
        .TYPE   GP32FillScreen, function

GP32FillScreen:
                Add r4, r4, #19200/Performance
                mov r2, r0
                add r2, r2, r0, lsl #8
                mov r0, r2
                add r0, r0, r2, lsl #16
               loop:
                .REPT Performance
                str  r0,[r1],#4
                .ENDR
                subs  r4,r4,#1
                bne loop
                bx lr
.fend1:
        .SIZE GP32FillScreen, .fend1-GP32FillScreen



si j'ai un peu de temps, je vais compiler un petit test en .fxe histoire de te montrer que je ne raconte pas de connerie niveau vitesse...non après tous, allez vous faire foutre, j'en ai plein le cul de ce forum à la con !

34

-

35

test 1000 fillscreens en une seul fois puis tu fais une affichage...pas 1 seul fois...

36

-

37

c'est quoi le premier code en asm que je donne déjà? quoi ca? une fonction sprite? tsss....
les 1000 fillscreen c'est pour tester la rapidité, boulet! ca sert a quoi de le faire 1 seul fois puis de l'afficher dit moi? pourquoi tu me sort gm_memset alors?
test aussi 1000 fois la routines sprite en asm et tu fais un affichage ensuite. puis tu test 1000 fois avec le sprite sdk et tu fais le même style d'affichage (comme j'ai décrit plus haut) histoire qu'il n'y ai pas d'avantage dans les 2 camps.

sinon, qu'est ce que tu veux que je te dise, achete toi un cerveau.

mais je laisse tombé, ca sert a rien de discuter, ca pu l'hypocrisie a plein nez tes phrases! contrerement à Baallrog, qui se donne la peine de dire un "petit merci", mais t'es le roi de la prog Orion top ca se voit.

c'est bon, ce forum me soule la, c'est la goute d'eau qui fait déborder le vase. Je m'auto-ban ca sert a rien de venir discuter ici je perd mon temps, je suis encore gentil de te répondre Orion.

38

Ouh la la, faut pas s'echauffer comme ca.
Coderman, je vais mettre ta routine dans mon code qui dessine des sprites.
2 questions pour que ca compile
u16 et s32, ca correspond a quoi en vrai C ? unsigned short et long ?
Sproffset c'est la position du sprite ? Il faut mettre un truc genre (240-hauteurSprite-ySprite) + xSprite * 320 ?

39

-

40

orion: a la base, je discuter avec yaouank et s'impose rien, je partage ma routine, j'ai même pris la peine de mettre mon code source! j'aurais très bien pu inventer des conneries et c'est pas le cas!!! arrête de m'enerver en venant t'incruster dans des conversation qui te dépasses!

yaouank: U16 c'est un unsigned short, et s32 c'est un signed long, U=unsigned et S=signed, 8=byte , 16 =short, 32=long, c'est plus facile de ci retrouver comme ca.
Sproffset, c'est la position du sprite dans un tableau sprite.
par exemple, si ta charger 32 sprites de 64x64 en suivant sur un seul tableau, sproffset sert a indiquer la position du sprite que tu veux utiliser. c'est plus facile a programmer je trouve.

je te donne un exemple:

u8 SpritesPerso[516]; ' ---> 2 sprites de 16x16 -----> 1 sprites fait 258 parce que les 2 premiers octects sont pour la taille X et Y
u8 Vscreen[76800];

GP32SpriteFxClip (60, 74, SpritesPerso, Vscreen , 258);

60 et 74 c'est pour les coordonnez sur l'écran, aucun calcule du style ( xsprite*320, etc donc )
Spritesperso, c'est les data du sprite
Vscreen, c'est la mémoire virtuelle
258, c'est l'offset, pour afficher le 2ème sprite.

Voila, sinon, c'est mon dérnier post, j'espère que ca va t'aider ou t'inspirer un peu pour tes routines, moi je vais prendre un peu de recule avec ce forum, j'en ai marre.

41

Merci, ca va mieux, j'ai compris.

42

je viens de tester ma fonction ac le Y de 32² affiché 20000 fois en 51.51

* image non transparente 2327tick non clippé, 2606 clippé
* image transparente 846 tick non clippé, 917 clippé

43

yaouank :
Merci, ca va mieux, j'ai compris.

Je suis mauvais, j'ai du foirer quelque part, ca crash.

44

coderman t'en va pas steup!!

si g bien compris le test dont tu parles c de faire 1000 fillscreen et de l'afficher la fin!
et faire la mme chose avec le sdk!
comme sa on compare les temps des deux opérations
jme trompe?

sinon pour t routine de sprites pk pas faire du double buffering?
on prendrais 2 buffer 76800 en travaillant sur un buffer a la fois et en faisant un roulement de pointeur sr ces buffers pour l'affichage (comme dans le sdk officiel)
il n'y aurait ke les routines de sprite d'améliorée ce qui pourrait nous donner un gain de temps

jme trompe aussi?

45

yaouank
:
yaouank :
Merci, ca va mieux, j'ai compris.

Je suis mauvais, j'ai du foirer quelque part, ca crash.

Il y a du progres, ca crashe plus mais ca n'affiche encore rien.

46

Baallrog :
jveux d benchs!
le sdk de mrMirko est plus rapide ke le sdk d'origine non?
sinon bravo yaounak et coderman bon boulot!

Reponse tardive: le SDK de MrMirko n'a pas de fonction pour afficher des sprites 8bits.
Le compilateur par contre, lui est cense produire du code plus rapide (pour les fonctions en C, pas celles en assembleur)

47

r043v :
je viens de tester ma fonction ac le Y de 32² affiché 20000 fois en 51.51

* image non transparente 2327tick non clippé, 2606 clippé
* image transparente 846 tick non clippé, 917 clippé

Tu passes le sprite d'origine a la fonction ou t'as precalcule vite fait les zones transparentes avant ?
Content de voir que chez quelqu'un, moins il affiche de pixels, plus ca va vite. C'est pas le cas avec moi et avec le SDK officiel (la transparence rallonge le temps de calcul).

48

Coderman, prend pas la mouche, bien au contraire, prouve que ta fonction est utile, Orion se fait legion de critiquer tout le monde pour montrer qu'il est capable de faire la meme chose voir mieux, meme s'il n'y a aucune veritable raison, donc fait des tests et ne t'enerve pas pour sa, sa n'en vaux pas le coups. Merci pour ta fonction (dont j'avait compris l'interet des le debut, donc vu mon niveau, soit il y en a qui sont de mauvaises fois, soit il devrait se remettre en question).

49

> Tu passes le sprite d'origine a la fonction ou t'as precalcule vite fait les zones transparentes avant ?
le sprite est parsé et recodé en objet Gfm (1 tableau pour les jump entre les colonnes pleines (jump ds l'ecran et non l'image), 1 tableau pour les tailles de colones et 1 pour les pixels pleins)
apres je me positionne ds l'ecran, et je n'ai plus qu'a jumper blitter, jumper blitter ...
c'est tout en C++ et la copie se fait par char

Orion critique peut etre mais ce qu'il dit est vrai.

> affichage du sprite de 320x240(la mémoire virtuelle) sur l'ecran avec la routine blt du sdk.
> Donc, la mémoire virtuelle et bien à l'endroit c'est à dire 320x240

si ton ecran virtuel est a l'endroi, on ne peut pas le copier ac la routine de blit du sdk ^^

si il est a l'envers, et donc mesure 320 de haut (dailleur pkoi le mettre a 320 ? tant qu'a faire une recopie a la fin sur l'ecran, autt pourvoir scroller facilement) orion a raison, un memcpy est bc mieux qu'un gpbitblt

si le buffer est identique a celui d'une image du sdk (et donc du buffer d'ecran) autt utiliser ta fonction directement sur le buffer d'ecran.

le seul avantage a utiliser ta methode est comme tu le dis pour apliquer des effet sur l'ecran au moment de la recopie du buffer final ds l'ecran
en dehors de ca, elle (a mon avis) ne sert a rien si ce n'est a perdre du temps l'or de la recopie

ta fonction de fill n'est pas comparable ac celle du sdk, déjà rien que le fait d'utiliser un gprectfill pour effacer l'ecran baisse le fps a 49 (ou 47 je c plus)
compare la ac une vrai fct pour effacer l'ecran (style lancement de la copie d'un demi ecran blanc par dma et affichage de l'autre moitié brutalement par des 0xFFFFFFFF)

et au lieu de peter un cable direct, montre nous que tu a raison !

50

Je viens de lire tout le post ca faisait longtemps que j'avais pas pue repasser les petits loups smile

En tout cas c'est assez ammusant toutes les conversations.

l'idée de coderman est pas mauvaise par contre je vous conseillerais de flip les buffers via les adresses memoires sans passer par la fonction du sdk de base.


bon courage a tous pour le code et restez cool.

a+


..:: Old School Coding is the True Way to Light ::..

51

-

52

-

53

bon, je m'excuse d'être partie en sucette tout à l'heure mais bon, quand on voit toutes les conneries que je recois sur les forums des que je poste un message, il y a de quoi !

( Et t'inquiète pas orion, j'ai pas oublié, je reviens juste pour répondre à quelques personnes ici, je reste pas longtemps. )

Je vous donnes les routines de flipping pour tester, vous vous en doutez, l'affichage n'est pas optimisé d'un yota mais c'est pas là le but, la base c'est de remplacer le sdk par des routines graphiques plus personnalisé et plus rapide dans beaucoup de cas. (routine en 8 bits, 16 voir 32 bits pour certain cas)

Une fois, que vous aurez fait vos routines graphiques en asm, croyez moi, c'est déjà assez rapide comme ça. L'affichage optimisez sera encore plus rapide (mais très légérement, faut pas s'imaginez a gagner 5fps!), pour vous dire la vérité, je me suis pas pris la tête avec ca, je prend ça comme un bonus.

u16 VarHardwareScreenSizeX=320;
u8 VarHardwareScreenSizeY=240;
u8 VirtualScreen[76800];

void  InitScreenLibrary()
{
  u8 i;
   GpLcdEnable();
   GpLcdSurfaceGet(&gpDraw[0], 0);   
   GpSurfaceSet(&gpDraw[0]);
   nflip=1;
   for ( i = 0 ; i < 2 ; i++)
   {
        GpLcdSurfaceGet(&gpDraw[i], i); 
   }
}
//-------------------------------------------------------
void ScreenFlipBuffering()
{
		GpSurfaceFlip(&gpDraw[nflip++]);
                nflip %= 2;
}
//-----------------------------------------------
void VirtualScreenToGP32()
{
                GpBitBlt(NULL,
		         &gpDraw[nflip], 
                         0, 0, 
                         VarHardwareScreenSizeX, VarHardwareScreenSizeY, 
                         (unsigned char*)VirtualScreen,
		         0, 0, 
                         320, 240);

}



///----------------------------------------------------------
///----------------------------------------------------------
///----------------------------------------------------------
while(1)
{
/*
.
. Traitement Graphiques
. (ex: Fond/Layers + Sprites + effets spéciaux)
.
*/
VirtualScreenToGP32();
ScreenFlipBuffering();
}


> affichage du sprite de 320x240(la mémoire virtuelle) sur l'ecran avec la routine blt du sdk.
> Donc, la mémoire virtuelle et bien à l'endroit c'est à dire 320x240
si ton ecran virtuel est a l'endroi, on ne peut pas le copier ac la routine de blit du sdk ^^

r043v:
tu as raison, sur le coup de la colère, je me suis mal exprimé, la mémoire vscreen et a l'envers 240x320, c'est ma routine sprite qui se charge de l'inverser. Mais, le principale, c'est que tous se travail en 320x240.
ta fonction de fill n'est pas comparable ac celle du sdk, déjà rien que le fait d'utiliser un gprectfill pour effacer l'ecran baisse le fps a 49 (ou 47 je c plus) compare la ac une vrai fct pour effacer l'ecran (style lancement de la copie d'un demi ecran blanc par dma et affichage de l'autre moitié brutalement par des 0xFFFFFFFF)

Le principe c'est de montrer que cette méthode est très rapide, pour moi, un fillscreen( 32bits/asm ), c'est la base de tout test sur n'importe quel plate-forme.

si ici tu fais 100 ou 1000 fillscreen et que tu regardes le nombres de fps, tu te rend tous de suite du potentielle de cette méthode. Si c'est interessant ou pas. Et après test fait, c'est vraiment très interessant je trouves.
while(1)
{
/*
.
. affichier 100 ou 1000 fois GP32FILLSCREEN (couleur, VirtualScreen) et tester le fps après le ScreenFlipBuffering();
.
*/
VirtualScreenToGP32();
ScreenFlipBuffering();
}

54

-

55

Orion_:sans vouloir être chiant, vu ton code C, j'ai des doutes quant à ta capacité à optimiser.

Coderman:Une fois, que vous aurez fait vos routines graphiques en asm, croyez moi, c'est déjà assez rapide comme ça. L'affichage optimisez sera encore plus rapide (mais très légérement, faut pas s'imaginez a gagner 5fps!), pour vous dire la vérité, je me suis pas pris la tête avec ca
, je prend ça comme un bonus.

J'ai fait ça en 2 seconde 8.

Apprend à lire Orion.
orion_:"Mais, le principale, c'est que tous se travail en 320x240. " c ça qui ralenti, sur GP il faut penser ces algo en 240x320 pour gagner en rapidité.

Coderman: tu as raison, sur le coup de la colère, je me suis mal exprimé, la mémoire vscreen et a l'envers 240x320, c'est ma routine sprite qui se charge de l'inverser
. Mais, le principale, c'est que tous se travail en 320x240.


je confirme, apprend à lire ;-)

56

> si ici tu fais 100 ou 1000 fillscreen et que tu regardes le nombres de fps, tu te rend tous de suite du potentielle de cette méthode. Si c'est interessant ou pas.
> Et après test fait, c'est vraiment très interessant je trouves.

tu va me dire que tu efface 1000 fois l'ecran par frame, en ayant un fps non null ???

57

sans vouloir être chiant, vu ton code C, j'ai des doutes quant à ta capacité à optimiser.

ca c moyen comme remarque. sad
"Mais, le principale, c'est que tous se travail en 320x240. " c ça qui ralenti, sur GP il faut penser ces algo en 240x320 pour gagner en rapidité.

Celle par contre est plus constructive.

Coderman tu as deux solutions en faite sur tes routines asm.
Tu peux soit comme tu fais faire un peu plus de calcul directement et passer en 320*240 soit attaquer directement la zone memoire en utilisant des pointers sur
zone et faire un swap ensuite.
Je pense que la deuxième méthode est vraiment plus rapide.
Déjà tu attauqes tout le long des pointers directs que tu vas manipuler au meme titre que ton tableau et cela t'evite la copie du tableau vue que tu swap simplement
un pointer vers l'ecran.
Par contre ca t'oblige a revoir tes routines en 240*320, c'est pas vraiment plus compliqué et ca va te facilité la vie apres.

58

Je réitaire ma remarque du 240*320 a condition d'attaquer DIRECTEMENT la memoire hard de la machine, sinon pour un tableau classique (mem linéaire) c'est coderman qui est dans le vrai wink

59

comment on fait pour faire pointer l'ecran sur la zone memoire que l'on veut ?

60

r043v :
comment on fait pour faire pointer l'ecran sur la zone memoire que l'on veut ?

Je crois que c'est dans les sources du SDK de MrMirko. Jettes-y un coup d'oeil pour verifier.
void gp_setFramebuffer ( u32 addr, int vsync )