Orion_ :
CoderMan > j'ai rien compris a ton explication
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.
Orion_ :
CoderMan > j'ai rien compris a ton explication
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.
ensuite faire passer ton ecran virtuel pour un sprite au yeux du sdk, c completement debile et lent !
@ 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
yaouank :
Merci, ca va mieux, j'ai compris.
yaouank
:yaouank :
Merci, ca va mieux, j'ai compris.
Je suis mauvais, j'ai du foirer quelque part, ca crash.
Baallrog :
jveux d benchs!
le sdk de mrMirko est plus rapide ke le sdk d'origine non?
sinon bravo yaounak et coderman bon boulot!
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é
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 ^^
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)
while(1) { /* . . affichier 100 ou 1000 fois GP32FILLSCREEN (couleur, VirtualScreen) et tester le fps après le ScreenFlipBuffering(); . */ VirtualScreenToGP32(); ScreenFlipBuffering(); }
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.
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.
sans vouloir être chiant, vu ton code C, j'ai des doutes quant à ta capacité à optimiser.
"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é.
r043v :
comment on fait pour faire pointer l'ecran sur la zone memoire que l'on veut ?