1

NOTE: les sources sont telechargeable en ./3 (je maitrise pas trop yaro, on va faire comme ca)

Ca a l'air de marcher. J'ai le pressentiment qu'il reste un truc qui cloche avec les histoires d'images qui ont des lignes noires en haut
pour faire un multiple de 4 lignes (norme du SDK Gp32 et de GP32Converter.exe)

Alors moi, pour compiler de l'assembleur ARM avec minigp32, je fais comme ca:
- dans le makefile (genere par Visual MinGW), je rajoute mon asm.o a la suite de tous les .o
- je fais un fichier sprite.h contenant la definition de ma fonction
#ifndef SPRITE_H
#define SPRITE_H
extern void GpBitBltASM(GPDRAWSURFACE* screen, int startX, int startY, unsigned char* sprite, int sprite_width, int sprite_height);
#endif

- je fais un fichier asm.s avec le code de ma fonction (Pensez a commenter chaque ligne)
@***void GpBitBltASM(GPDRAWSURFACE * screen, int startX, int startY, unsigned char* sprite, int sprite_width, int sprite_height); ***
.ALIGN
.GLOBAL GpBitBltASM
.TYPE GpBitBltASM, function
.CODE 32

@r0 = screen (structure first then replaced by direct pointer)
@r1 = startX
@r2 = startY
@r3 = sprite

@r4 = sprite_width
@r5 = sprite_height (user value then ASM value being a multiple of 4)

@r6 = screen_width
@r7 = screen_height

@r8 = width copy
@r9 = height copy

@r10 = number of sprite lines after the multiple of 4 before. (if height of sprite is 9 then r10 = 1 because 9%4 = 1)

GpBitBltASM:
	SUB sp,sp,#8			@protect the memory where the params are
	STMFD r13!,{r4-r10}		@save used registers
	LDR r4,[r13,#36]		@then load the 5th and 6th params using ldrs
	LDR r5,[r13,#40]		@2 params + 7 saved registers (4 bytes each)
        				@=> 9 x 4 = 36 bytes from sp (r4), and then 40 for r5

	LDR r6, [r0, #8]		@read screen_width
	LDR r7, [r0, #12]		@read screen_height
	LDR r0, [r0]			@read screen pointer

	ADD r2, r2, r5			@Convert user coordinates to gp32 coordinates (y becomes screen height - (y+sprite_height) )
	SUB r2, r7, r2			@.

					@GP32 height of sprite must be a multiple of 4. If user given height is not a multiple of 4, some pixels are added.
	ANDS r10, r5, #0x0003		@r5%4 -> r10 (check if height is a multiple of 4)
	SUBNE r5, r5, r10		@if modulo if not zero clear last bits (if not ...)
	ADDNE r5, r5, #4		@and add #4  (... replace height by next multiple of 4)

	MOV r8, r4			@first value of Lcopy
	MOV r9, r5			@first value of Hcopy
	
					@those 3 lines were added in order to adapt the function to sprites with lines non multiple of 4.
	CMP r10, #0			@if r10 is not zero (r10 is the number of lines after multiple of 4)
	RSBNE r10, r10, #4		@then number of lines to remove is #4-r10
	SUBNE r9, r9, r10		@and zap last lines of dead pixels by reducing height copy (here because columns have to have a multiple of 4 pixels)
	
					@vertical update of screen and sprite pointers and of copy zone height.
	CMP r2, #0			@if startY is positive
	ADDGT r0, r0, r2		@then add startY to screenPointer
	SUBLT r3, r3, r2		@else remove startY from sprite pointer (=add absolute value of startY to pointer)
	ADDLT r9, r9, r2		@and reduce height of copy zone to correct value.
	
	ADD r2, r2, r5			@precalc (r2+r5+1) = startY + heightSprite-1
	SUB r2, r2, #1			@which is max Y value of sprite
	SUBS r2, r7, r2			@test screenheight - (starty+heightSprite-1). If this is negative, the sprite goes outside the screen (up)
	ADDLT r9, r9, r2		@reduce height of copy and then copy zone stay in the screen.

					@r2 is now free to be used.

					@horizontal update of screen and sprite pointers and of copy zone width
	CMP r1, #0			@if startX is positive
	MULGT r2, r1, r7		@precalc startX*screenHeight and put it in r2
	ADDGT r0, r0, r2		@add startX*screenHeight to screen pointer
	MULLT r2, r1, r5		@else precalc startX*spriteheight and put it in r2
	SUBLT r3, r3, r2		@and remove this value to sprite pointer (=add absolute value)
	ADDLT r8, r8, r1		@and reduce width of copy zone.

	ADD r2, r1, r4			@precalc (r1+r4) = startX + widthSprite
	SUBS r2, r6, r2			@screenwidth - (startX + widthSprite). If this is negative sprite goes outside the screen (right)
	ADDLT r8, r8, r2		@Then reduce width of copy zone to correct value.

					@r1 is now free to be used

	CMP r8, #0			@if width copy <=0
	BLE endGpBitBltASM		@jump to the end of the function
	CMP r9, #0			@if height copy <=0
	BLE endGpBitBltASM		@jump to the end of the function



bigLoop:
	STMFD sp!, {r0, r3}		@Push pointer to screen and to sprite
	STMFD sp!, {r9}			@Save height copy value (r9)
smallLoop:
	LDRB	r1, [r3], #1		@read pixel P2[0] and P2++
	STRB r1, [r0], #1		@write pixel P1[0] and P1++
	SUBS r9, r9, #1			@r9 --
	BNE smallLoop			@loop while r9 != 0 (do every pixels of the column)

	LDMFD sp!, {r9}			@Restore Lcopy value
	LDMFD sp!, {r0, r3}		@Pop pointer to screen and to sprite
	ADD r0, r0, r7			@Next screen column
	ADD r3, r3, r5			@Next sprite line (r5 is corrected height. The one that is a multiple of 4)
	SUBS r8, r8, #1			@Do it widthCopy times
	BNE bigLoop		
	
endGpBitBltASM:
	LDMFD r13!,{r4-r10}		@end of function. Restore register
	ADD sp,sp,#8			@restore stack pointer
	BX lr				@and back to C


4- et je compile comme d'hab
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

2

Vite fait en lien j'ai bookmarke:
- http://www.cs.helsinki.fi/u/jikorhon/condev/gp32/ (=mr spiv) pour les docs
DDI0100E_ARM_ARM.pdf (paragraphe A3 a imprimer, ca liste les commandes ASM. Paragraphes A4 et A5 a avoir sous la main pour les explications)
Progtech.pdf pour apprendre l'assembleur (surtout le paragraphe 4)

- http://www.gp32x.com/board/index.php?showtopic=6655 la page qui m'a servi de base pour commencer

- http://www.gp32x.com/board/index.php?showtopic=7440 pour le passage de parametres (les 4 premiers parametres sont passes en utilisant les 4 premiers registres. Les autres sont empiles dans la pile (=r13)
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

3

Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

4

-

5

Orion_ :
cette routine est clippée ?

Elle l'est.
L'algo vite fait:
- je cale le pointeur du sprite et de l'ecran au premier pixels de la zone de clipping
- je calcule la largeur et la hauteur de la zone clippee.
- Et roule ma poule je remplis mon rectangle!
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

6

-

7

-

8

Tu sais c'est pas forcement parce que c'est ecrit en assembleur que c'est forcement plus rapide.
J'essayerai d'inserer vite fait demain la couleur transparente. Et voir plus tard si il y a moyen de mettre le xmin, ymin, xmax, ymax de la zone du sprite a clipper.

Un autre truc pas mal urgent, c'est de la tester un peu mieux. Voir si ca ne depasse pas en haut, bas, gauche, droite. Que tout s'affiche bien, etc.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

9

Pour le test sur la couleur, il suffit d'inserer un truc genre
LDRB r1, [r3], #1
CMP r1, r11
STRBNE r1, [r0], #1
ADDEQ r0, r0, #1
Et que r11 soit un 7eme parametre (modif au debut et a la fin et dans le .h)
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

10

merci yaouank smile grace a toi je me suis amusé tt la nuit ^^

g essayé de porter ma fonction de blit en asm,
je peut pas tester car le code c veut pas voir ma fonction :/ mais c pas grave g appris pleins de truc

g retrouvé un lien qu'on m'avais passé y a bien 6 mois et que j'avais oublié ^^ http://renan.org/ARM/

sur ce un dernier mlit et zZZ
et la le mec il le pécho par le bras et il lui dit '

11

Le retoure du vampire ?? tongue
-=-=-{}=- avseth -={}-=-=-

12

-

13

Et voila version avec transparence (il faut indiquer la couleur transparente)... @ http://www.cs.helsinki.fi/u/jikorhon/condev/gp32/ docs (DDI0100E_ARM_ARM.pdf and Progtech.pdf) @ http://www.gp32x.com/board/index.php?showtopic=6655     .c / .s @ http://www.gp32x.com/board/index.php?showtopic=7440     multi param @***void GpBitBltASM(GPDRAWSURFACE * screen, int startX, int startY, unsigned char* sprite, int sprite_width, int sprite_height); *** .ALIGN .GLOBAL GpBitBltASM .TYPE GpBitBltASM, function .CODE 32 @r0 = screen (structure first then replaced by direct pointer) @r1 = startX @r2 = startY @r3 = sprite @r4 = sprite_width @r5 = sprite_height (user value then ASM value being a multiple of 4) @r6 = screen_width @r7 = screen_height @r8 = width copy @r9 = height copy @r10 = number of sprite lines after the multiple of 4 before. (if height of sprite is 9 then r10 = 1 because 9%4 = 1) GpBitBltASM:      SUB sp,sp,#8          @protect the memory where the params are      STMFD r13!,{r4-r10}     @save used registers      LDR r4,[r13,#36]          @then load the 5th and 6th params using ldrs      LDR r5,[r13,#40]          @2 params + 7 saved registers (4 bytes each)                             @=> 9 x 4 = 36 bytes from sp (r4), and then 40 for r5      LDR r6, [r0, #8]          @read screen_width      LDR r7, [r0, #12]          @read screen_height      LDR r0, [r0]               @read screen pointer      ADD r2, r2, r5          @Convert user coordinates to gp32 coordinates (y becomes screen height - (y+sprite_height) )      SUB r2, r7, r2          @.                          @GP32 height of sprite must be a multiple of 4. If user given height is not a multiple of 4, some pixels are added.      ANDS r10, r5, #0x0003     @r5%4 -> r10 (check if height is a multiple of 4)      SUBNE r5, r5, r10          @if modulo if not zero clear last bits (if not ...)      ADDNE r5, r5, #4          @and add #4  (... replace height by next multiple of 4)      MOV r8, r4               @first value of Lcopy      MOV r9, r5               @first value of Hcopy                                @those 3 lines were added in order to adapt the function to sprites with lines non multiple of 4.      CMP r10, #0          @if r10 is not zero (r10 is the number of lines after multiple of 4)      RSBNE r10, r10, #4     @then number of lines to remove is #4-r10      SUBNE r9, r9, r10          @and zap last lines of dead pixels by reducing height copy (here because columns have to have a multiple of 4 pixels)                                @vertical update of screen and sprite pointers and of copy zone height.      CMP r2, #0               @if startY is positive      ADDGT r0, r0, r2          @then add startY to screenPointer      SUBLT r3, r3, r2          @else remove startY from sprite pointer (=add absolute value of startY to pointer)      ADDLT r9, r9, r2          @and reduce height of copy zone to correct value.            ADD r2, r2, r5          @precalc (r2+r5+1) = startY + heightSprite-1      SUB r2, r2, #1          @which is max Y value of sprite      SUBS r2, r7, r2          @test screenheight - (starty+heightSprite-1). If this is negative, the sprite goes outside the screen (up)      ADDLT r9, r9, r2          @reduce height of copy and then copy zone stay in the screen.                          @r2 is now free to be used.                          @horizontal update of screen and sprite pointers and of copy zone width      CMP r1, #0               @if startX is positive      MULGT r2, r1, r7          @precalc startX*screenHeight and put it in r2      ADDGT r0, r0, r2          @add startX*screenHeight to screen pointer      MULLT r2, r1, r5          @else precalc startX*spriteheight and put it in r2      SUBLT r3, r3, r2          @and remove this value to sprite pointer (=add absolute value)      ADDLT r8, r8, r1          @and reduce width of copy zone.      ADD r2, r1, r4          @precalc (r1+r4) = startX + widthSprite      SUBS r2, r6, r2          @screenwidth - (startX + widthSprite). If this is negative sprite goes outside the screen (right)      ADDLT r8, r8, r2          @Then reduc width of copy zone to correct value.                          @r1 is now free to be used      CMP r8, #0               @if width copy <=0      BLE endGpBitBltASM     @jump to the end of the function      CMP r9, #0               @if height copy <=0      BLE endGpBitBltASM     @jump to the end of the function bigLoopGpBitBltASM:      STMFD sp!, {r0, r3}     @Push pointer to screen and to sprite      STMFD sp!, {r9}          @Save height copy value (r9) smallLoopGpBitBltASM:      LDRB     r1, [r3], #1          @read pixel P2[0] and P2++      STRB r1, [r0], #1          @write pixel P1[0] and P1++      SUBS r9, r9, #1          @r9 --      BNE smallLoopGpBitBltASM @loop while r9 != 0 (do every pixels of the column)      LDMFD sp!, {r9}          @Restore Lcopy value      LDMFD sp!, {r0, r3}     @Pop pointer to screen and to sprite      ADD r0, r0, r7          @Next screen column      ADD r3, r3, r5          @Next sprite line (r5 is corrected height. The one that is a multiple of 4)      SUBS r8, r8, #1          @Do it widthCopy times      BNE bigLoopGpBitBltASM            endGpBitBltASM:      LDMFD r13!,{r4-r10}     @end of function. Restore register      ADD sp,sp,#8          @restore stack pointer      BX lr                    @and back to C @***void GpTransBltASM(GPDRAWSURFACE * screen, int startX, int startY, unsigned char* sprite, int sprite_width, int sprite_height, unsigned char trans); *** .ALIGN .GLOBAL GpTransBltASM .TYPE GpTransBltASM, function .CODE 32 @ Roughtly it is GpBitBltASM with one more argument r11 (differences in start and end during saving/restoring all registers) @ and copy loop is a bit different because of the color test. @r0 = screen (structure first then replaced by direct pointer) @r1 = startX @r2 = startY @r3 = sprite @r4 = sprite_width @r5 = sprite_height (user value then ASM value being a multiple of 4) @r6 = screen_width @r7 = screen_height @r8 = width copy @r9 = height copy @r10 = number of sprite lines after the multiple of 4 before. (if height of sprite is 9 then r10 = 1 because 9%4 = 1) @r11 = transparent color GpTransBltASM:      SUB sp,sp,#8          @protect the memory where the params are      STMFD r13!,{r4-r11}     @save used registers      LDR r4,[r13,#40]          @then load the 5th and 6th params using ldrs      LDR r5,[r13,#44]          @2 params + 8 saved registers (4 bytes each)                             @=> 10 x 4 = 40 bytes from sp (r4), and then 44 for r5      LDRB r11,[r13,#48]     @and then 48 for r11      LDR r6, [r0, #8]          @read screen_width      LDR r7, [r0, #12]          @read screen_height      LDR r0, [r0]               @read screen pointer      ADD r2, r2, r5          @Convert user coordinates to gp32 coordinates (y becomes screen height - (y+sprite_height) )      SUB r2, r7, r2          @.                          @GP32 height of sprite must be a multiple of 4. If user given height is not a multiple of 4, some pixels are added.      ANDS r10, r5, #0x0003     @r5%4 -> r10 (check if height is a multiple of 4)      SUBNE r5, r5, r10          @if modulo if not zero clear last bits (if not ...)      ADDNE r5, r5, #4          @and add #4  (... replace height by next multiple of 4)      MOV r8, r4               @first value of Lcopy      MOV r9, r5               @first value of Hcopy                                @those 3 lines were added in order to adapt the function to sprites with lines non multiple of 4.      CMP r10, #0          @if r10 is not zero (r10 is the number of lines after multiple of 4)      RSBNE r10, r10, #4     @then number of lines to remove is #4-r10      SUBNE r9, r9, r10          @and zap last lines of dead pixels by reducing height copy (here because columns have to have a multiple of 4 pixels)                                @vertical update of screen and sprite pointers and of copy zone height.      CMP r2, #0               @if startY is positive      ADDGT r0, r0, r2          @then add startY to screenPointer      SUBLT r3, r3, r2          @else remove startY from sprite pointer (=add absolute value of startY to pointer)      ADDLT r9, r9, r2          @and reduce height of copy zone to correct value.            ADD r2, r2, r5          @precalc (r2+r5+1) = startY + heightSprite-1      SUB r2, r2, #1          @which is max Y value of sprite      SUBS r2, r7, r2          @test screenheight - (starty+heightSprite-1). If this is negative, the sprite goes outside the screen (up)      ADDLT r9, r9, r2          @reduce height of copy and then copy zone stay in the screen.                          @r2 is now free to be used.                          @horizontal update of screen and sprite pointers and of copy zone width      CMP r1, #0               @if startX is positive      MULGT r2, r1, r7          @precalc startX*screenHeight and put it in r2      ADDGT r0, r0, r2          @add startX*screenHeight to screen pointer      MULLT r2, r1, r5          @else precalc startX*spriteheight and put it in r2      SUBLT r3, r3, r2          @and remove this value to sprite pointer (=add absolute value)      ADDLT r8, r8, r1          @and reduce width of copy zone.      ADD r2, r1, r4          @precalc (r1+r4) = startX + widthSprite      SUBS r2, r6, r2          @screenwidth - (startX + widthSprite). If this is negative sprite goes outside the screen (right)      ADDLT r8, r8, r2          @Then reduc width of copy zone to correct value.                          @r1 is now free to be used      CMP r8, #0               @if width copy <=0      BLE endGpBitBltASM     @jump to the end of the function      CMP r9, #0               @if height copy <=0      BLE endGpBitBltASM     @jump to the end of the function bigLoopGpTransBltASM:      STMFD sp!, {r0, r3}     @Push pointer to screen and to sprite      STMFD sp!, {r9}          @Save height copy value (r9) smallLoopGpTransBltASM:      LDRB     r1, [r3], #1          @read pixel P2[0] and P2++      CMP r1, r11               @check if color is transparent      STRNEB r1, [r0], #1     @write pixel P1[0] and P1++ if the color isn't transparent      ADDEQ r0, r0, #1          @else just point to next pixel      SUBS r9, r9, #1          @r9 --      BNE smallLoopGpTransBltASM @loop while r9 != 0 (do every pixels of the column)      LDMFD sp!, {r9}          @Restore Lcopy value      LDMFD sp!, {r0, r3}     @Pop pointer to screen and to sprite      ADD r0, r0, r7          @Next screen column      ADD r3, r3, r5          @Next sprite line (r5 is corrected height. The one that is a multiple of 4)      SUBS r8, r8, #1          @Do it widthCopy times      BNE bigLoopGpTransBltASM            endGpTransBltASM:      LDMFD r13!,{r4-r11}     @end of function. Restore register      ADD sp,sp,#8          @restore stack pointer      BX lr                    @and back to C

J'ai fait ce que j'ai dit. Un copier coller de la fonction sans transparence, l'ajout d'un parametre, et test de la couleur dans la boucle.

au fait il semble que l'assembleur veule STRNEB et non STRBNE . Ca me semble moins logique mais bon, pourquoi pas.

Orion: oui, si la couleur transparente c'est 0, on gagne une instruction. Mais il faut alors convertir ses sprites pour que la couleur transparente soit 0. Perso, je prefere faire un code un poil plus long mais plus rapidement reutilisable.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

14

-

15

Voulant savoir ce que valait mon code j'ai compare ca vite fait avec les 2 afficheurs du SDK (transparent et pas transparent. 8 bits)
J'ai affiche 20000 sprites a 60 MHz. D'abord un peu partout, ensuite a l'offset (5,5) ensuite a l'offset (32,32) et j'ai compte les "ticks"
l'ordre des resultats est [move / (5,5) / (32,32) ]
GpBitBlt (SDK) : 1085 / 1246 / 773
GPTransBlt (SDK) : 2573 / 2547 / 2270
GpBitBltASM (moi) : 2426 / 2423 / 2422
GpTransBltASM (moi) : 3063 / 3069 / 3068

Conclusion:
- Je vais moins vite que le SDK.
- le SDK est optimise pour l'affichage sans transparence. Copie des pixels 4 par 4 (on voit ca a la difference enorme entre l'affichage 5,5 et celui en 32,32)
- le SDK n'est pas trop optimise pour l'affichage avec transparence. Copie des pixels 1 par 1
- mon test de transparence rend ma fonction 20% plus lente. (la difference est plus violente du cote du SDK du fait du travail sur l'optimisation de l'affichage sans transparence)

P.S: tests fait sur la GP32 et non sur l'emulateur. Compiles avec minigp32 v1.

mon source (10ko, projet minigp32 sous visual-mingw. makefile inclus) http://yn1.free.fr/up/sprite.zip
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

16

Au fait pour avoir un equivalent sprite / seconde, etc.
200.000 sprites qui bougent en GpTransBltASM font 30631 ticks ou 32 secondes

Vite fait ca fait 1000 ticks = 1s.
30Hz -> 1 frame = 33 ticks.

Donc en gros GpBitBlt peut gerer 600 sprites 32x32
et GpTransBltAsm peut en gerer 200.

Mais c'est sans compter le fond, sans compter le moteur de deplacement/collision, sans compter les sprites de taille differente. Etc.

EDIT: j'ai voulu tenter de compiler ce code avec MrMirko. C'est trop la misere, j'ai l'impression de porter un jeu DOS sous gp32 tellement les fonctions sont pas les memes. Si ca amuse quelqu'un de le faire... moi pas.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

17

heu.. et faut pas oublier le son smile

18

-

19

-

20

Orion_
:
yaouank :
30Hz -> 1 frame

ou ta a vu ça ?

Avec plein de lettres ca donne: pour un affichage a 30 hertz (et un processeur a 60Hz), une frame vaut environ 33 ticks.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

21

-

22

Orion_ :
ça veut dire quoi un affichage a 30hertz ? o_O
l'ecran est rafraichis 53 fois par secondes a ce qu'on m'a dit.

30fps, c'etait une base pour avoir une animation pas trop saccadee. J'ai pris ca un peu au pif pour avoir une idee du nombre max de sprites.
Si je mets 1/30 s a calculer mon image, ca veut dire que sur ces 53 balayage d'ecran par seconde, environ un coup sur deux le double buffering n'aura pas change de buffer.

En exagerant, rien ne t'empeche de faire une animation a 1 image par seconde sur la gp32. 52 fois ca balayera la meme image et au 53eme balayage, hop, changement de buffer, changement d'image.
"Qui peut le plus peut le moins" s'applique parfaitement dans ce cas.

Non ?

P.S: quant au taux de refresh, si tu veux jouer avec, Mr Mirko ( http://www.mirkoroller.de/gp32 ) propose short gp_initFramebuffer ( u32 addr, u16 bitmode, u16 refreshrate ) qui permet de le fixer de 50Hz a 120Hz.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

23

P.S: quant au taux de refresh, si tu veux jouer avec, Mr Mirko ( http://www.mirkoroller.de/gp32 ) propose short gp_initFramebuffer ( u32 addr, u16 bitmode, u16 refreshrate ) qui permet de le fixer de 50Hz a 120Hz.

Avec cette fonction il est possible d'augmenter la vitesse de rafraichissement de l'écran ? Si j'ai bien compris, ça veut dire que l'on peut faire des jeux plus fluide étant donné qu'il y a moins besoin d'attendre l'écran ?!
www.wikio.fr/user1921&info=comments

24

Orion_ :
ça veut dire quoi un affichage a 30hertz ? o_O
l'ecran est rafraichis 53 fois par secondes a ce qu'on m'a dit.

Oups, t'as bon.
donc ton ecran a 53Hz, ca fait un affichage a 53Hz - 27Hz - 17Hz - 13 Hz - 6 Hz - etc. (bref divise par 2, 3, 4, 5, 6, etc.)
Il faut remplacer mon 30 par un 27.5 mais ca doit donner plus ou moins les memes resultats.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

25

Raphaël
:
P.S: quant au taux de refresh, si tu veux jouer avec, Mr Mirko ( http://www.mirkoroller.de/gp32 ) propose short gp_initFramebuffer ( u32 addr, u16 bitmode, u16 refreshrate ) qui permet de le fixer de 50Hz a 120Hz.

Avec cette fonction il est possible d'augmenter la vitesse de rafraichissement de l'écran ? Si j'ai bien compris, ça veut dire que l'on peut faire des jeux plus fluide étant donné qu'il y a moins besoin d'attendre l'écran ?!

Jamais utilise. Mais a 53Hz, t'attends jamais l'ecran tres longtemps.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com

26

heu...
Ca vous dit d'avoir des sprites 3 à 4 fois plus rapides que le sdk avec un procédé totalement différent qui donne de multiple avantage comme la manipulation par pixel de l'ecran ou du sprite (effet de distortion, de rotation, zoom, goute d'eau, etc)
Suffit juste de travailler avec une memoire virtuelle de 76800 octets ( la taille de l'ecran), puis faire passer celle ci pour un sprite compatible gp32 pour effectué l'affichage sur l'écran de la gp32 avec les routines du sdk.

Memoire virtuelle ---> traitement de tous les sprites sur la mémoire virtuelle ----> affichage du sprite de 320x240(la mémoire virtuelle) sur l'ecran avec la routine blt du sdk.

l'avantage?

travailler uniquement en toute liberté sur cette mémoire et manipuler au pixel près tous se qu'il se passe sur l'écran. l'assembleur et l'idéal pour ce genre de chose.

comme je suis sympa, j'ai travaillé un peu ces dernier temps la dessus et je vous donne mon code source de la routine en assembleur d'un sprite transparent (sur la couleur 0) avec les clipping.
cette routine fait une rotation automatique car l'ecran de la gp32 travaille à l'envers c'est a dire 240x320 ^^; Donc, la mémoire virtuelle et bien à l'endroit c'est à dire 320x240

pour le sprite les 2 premiers octets sont pour la taille du sprite X et Y, donc un sprite ne peut pas dépasser 256x256

@ CODERMAN GRAPHICS ROUTINE
@--------------------------------------------------------------------------------------------------------
@ Reference it from C by using:
@  extern void GP32SpriteFxClip (s16 X, s16 Y,unsigned char *spritedata ,unsigned char *vscreen,u32 Sproffset);
@
@ Entry:
@  r0 = X, r1 = Y, r2= SpriteDATA, r3 = Vscreen, r4=Sproffset
@
        .ALIGN
        .GLOBAL GP32SpriteFxClip
        .TYPE   GP32SpriteFxClip, function

GP32SpriteFxClip:
		MOV r12, sp
    		stmfd sp!, {r4-r11,lr}
		ldr  r4, [r12]
		add  r2, r2, r4 	@ Sprite+Sproffset
              	ldrb r5, [r2],#1        @ R5(SX) = HEADER 0
              	ldrb r6, [r2],#1        @ R6(SY) = HEADER 1
		mov  r8,#0
		mov  r9,r8
		mov  r4,r8
		rsbs r7, r5, #0		@
		sub  r0, r0, #2
		Cmp  r0, r7			@ if (x-2<ABS(sy))
		blt  GP32SpriteFxClip_endfunc
		add  r0, r0, #2
		rsbs r7, r6, #0
		sub  r1, r1, #2
		Cmp  r1, r7			@ if (y<ABS(sx))
		blt  GP32SpriteFxClip_endfunc
		add  r1, r1, #2
		mov  r7, #320
		cmp  r0, r7
		bge  GP32SpriteFxClip_endfunc
		mov  r7, #240
		cmp  r1, r7
		bge  GP32SpriteFxClip_endfunc

		mov  r7, #0
		cmp  r0, r7
		bge  GP32SpriteFxClip_boucle01
		mul  r7, r0, r6
		sub  r2, r2, r7			@ R2=R2-(R0*R6) T=T-(X*SX)
		add  r5, r5, r0			@ R5=R5+R0      SX=SX+X
		mov  r0, #0			@ R0=0		X = 0
GP32SpriteFxClip_boucle01:
		mov  r7, #0
		cmp  r1, r7
		bge  GP32SpriteFxClip_boucle02
		add  r6, r6, r1			@ R6=R6+R1	SY=SY+Y
		rsbs r8, r1, #0			@ R8=-R1	MY=-Y
		mov  r1, #0
GP32SpriteFxClip_boucle02:
		add  r7, r0, r5			@ R7=R0+R5	R7=X+SX
		mov  r10, #320
		cmp  r7, r10
		blt  GP32SpriteFxClip_boucle03
		sub  r9, r7, r10		@ R9=R7-R9	ZY=(x+SX)-320
		sub  r5, r5, r9			@ R5=R5-R9	SX=SX-ZY
		mov  r9, #0			@ R9=0		ZY=0
GP32SpriteFxClip_boucle03:
		add  r7, r1, r6			@ R7=R1+R6	R7=Y+SY
		mov  r10, #240			@
		cmp  r7, r10
		blt  GP32SpriteFxClip_boucle04
		sub  r9, r7, r10		@ R9=R7-R10	ZY=(y+sy)-240
		sub  r6, r6, r9
		mov  r4, r9
		mov  r9, #0

GP32SpriteFxClip_boucle04:
		mov  r7, r0			@ R7=R0		R7=X
		mov  r10, #240			@
		sub  r0, r10, r1		@ R0=(240-R1)	X=240-Y
		mov  r1, r7			@ R1=R7		Y=R7

		add  r2, r2, r9
		add  r2, r2, r4
		mla  r7, r10,r1,r0		@ R7=(R10*R1)+R0  R7=(240*Y)+X
		sub  r7, r7, r6			@ R7=R7-R6	  R7=R7-SY
		add  r7, r7, r9			@ R7=R7+R9	  R7=R7+ZY
		add  r3, r3, r7			@ R3=R3+R7	 Vscreen+R7
		sub  r6, r6, r9			@ R6=R6-R9	  SY=SY-ZY
GP32SpriteFxClip_boucleY:
		mov  r10, r6			@ R10=R6	  R10=SY-ZY
GP32SpriteFxClip_boucleX:


		ldrb r7,[r2],#1
  	        orrs r7,R7,#0
                strneb r7,[r3]
	        add  r3,r3,#1
		subs r10,r10,#1
		bne GP32SpriteFxClip_boucleX
		add  r7, r9, r8
		add  r2, r2, r7
		add  r2, r2, r4
		add  r3, r3, #240
		sub  r3, r3, r6
		add  r3, r3, r9
		subs r5, r5, #1
		bne GP32SpriteFxClip_boucleY
GP32SpriteFxClip_endfunc:
                ldmfd sp!, {r4-r11,pc}

        bx lr
.fend5:
        .SIZE GP32SpriteFxClip, .fend5-GP32SpriteFxClip



bien sur après, je vous laisse imaginez toute les possibilitées de manipulations du style FlipX ou FlipY, voir même créer des sprites sans transparance et optimisé 32bits pour un affichage de l'ordre de 2 à 4 fois plus rapide(oui encore) (idéal pour les images de fond qui ne bouge pas)

27

jveux d benchs!
le sdk de mrMirko est plus rapide ke le sdk d'origine non?
sinon bravo yaounak et coderman bon boulot!
C'est pas l'trou,
mais l'tempax
sur ce j'vous lèche!!

28

-

29

Orion_: ta pas compris quoi? c'est facile pourtant, il y a rien de compliquer

-Tu fais tout tes traitements sur une mémoire virtuelle de 76800 la taille de l'écran.
-"Exit" toute les routines graphiques du SDK, ca ne marche pas avec cette méthode, si tu veux des routines, tu dois les créer toi même (voir code en assembleur)
-l'avantage c'est que c'est 3 à 4 fois plus rapide (pour un sprite transparant avec clipping)
-l'autre gros avantage c'est que tu peux manipuler au pixel près et faire se que tu veux avec ( bien sur, en asm si tu veux que ca soit très fluide)
-tu peux même créer des routines sans transparance et sans clipping, histoire que ca soit encore plus rapide
-tu peux même encore pousser plus loin et faire des routines graphiques en 16 ou en 32bits, si tu veux mettre un décore de fond stable.

Une fois que tu as fait tous ton traitement comme il faut, tu fait passer la mémoire virtuelle en temps que sprite de 320x240 du SDK pour l'afficher sur l'écran (et histoire de ne pas se prendre la tête ou d'inclure si besoin est, les fonts standards en coréen, par exemple )

Mais pour que ca soit fluide, il faut impérativement que les routines soit crée en "assembleur" c'est le but de cette manoeuvre.

Ca va, j'ai bien expliqué?, je vais pas non plus faire un schéma graphique ^^;

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.
Le pouvoir aux loutres !!!
(et aussi, vive le rose !)
mes petits programmes GP32: http://yaouank.gp32news.com