GP32 8 Bit Sprites In Mr. Mirko's Sdk?


Puck2099

Certified Guru
Joined
Oct 22, 2004
Messages
422
Location
Madrid, Spain
Website
www.gp32wip.com
Hello,

I am writing a "lady killer" remake for the GP32 and although I started to do it using Game Park's SDK, I am already trying to do it with Mr. Mirko's SDK.

I have to show on screen a lot of sprites (>50) and 16 bit mode is too slow (<15 FPS) so I have thoght to do it in 8 bit mode but as I can see there is not any function to draw sprites in this mode.

Do you know if there is any way to do it using Mr. Mirko's SDK or must I come back to Game Park's one?, do you know if Mr. Mirko has thought on including that kind of functions?

I am sorry very much for my bad English.

Thanks.
 
There are functions to blit 8 bit sprites with the official sdk. GpTransBlt for example will blit a sprite with a transparent color.
 
There are functions to blit 8 bit sprites with the official sdk. GpTransBlt for example will blit a sprite with a transparent color.

Yes, I had it working with the official SDK but I would like to know if there is any way to make the same with Mr. Mirko's one because it has very interesting functions (as the related to chatboard) that the official lacks.

Thanks for your help.
 
Actually I have some functions written in asm that could help you. But I don't know if there are 8 bit blitting functions in Mirko's sdk.
 
Puck2099 posted on Oct 22 2004 at 10:54 PM said:
There are functions to blit 8 bit sprites with the official sdk. GpTransBlt for example will blit a sprite with a transparent color.

Yes, I had it working with the official SDK but I would like to know if there is any way to make the same with Mr. Mirko's one because it has very interesting functions (as the related to chatboard) that the official lacks.

Thanks for your help.
Mirko's chatboard is based on Spiv's code, which works with the official sdk.
 
Last edited by a moderator:
At least the latest non-GPL version did not have 8bit Blit functionality, but it would be piece of cake to modify the 16bit ones (source available in lib.src, it's really frickin' easy).
 
I'd just write my own sprite code. Like I said in an earlier topic, make sure you order the sprite data like the lfb, meaning rotated 90 degrees anti clockwise. If you don't you'll have a cache miss on every pixel, making the thing fecking slow.

Mirko is a great programmer, but I doubt he took the cache into account when writing those routines ;)
 
Actually I have some functions written in asm that could help you. But I don't know if there are 8 bit blitting functions in Mirko's sdk.

I would be pleased if you can share them with me. :)

At least the latest non-GPL version did not have 8bit Blit functionality, but it would be piece of cake to modify the 16bit ones (source available in lib.src, it's really frickin' easy).

Well, I will try to modify them but I am not an expert programmer so I don't know if I will be able to do it correctly.

I'd just write my own sprite code. Like I said in an earlier topic, make sure you order the sprite data like the lfb, meaning rotated 90 degrees anti clockwise. If you don't you'll have a cache miss on every pixel, making the thing fecking slow.

Uhm, do you know if there is any tool to order the sprite data like you say? Must I rotate the bmp (for example using the Gimp) and then use bmp2raw or must I do it in another way?

Thanks to all for your help
 
you can write a piece of code that re-orders the thing. You'd have to write your own sprite code too, ofcourse.
 
Well, my routines use 90° rotated pictures (as the official sdk's functions). But getting rotated pictures is not that hard, for example GP32converter 1.3 (by edorul) will rotate the pictures.
 
Well, my routines use 90° rotated pictures (as the official sdk's functions). But getting rotated pictures is not that hard, for example GP32converter 1.3 (by edorul) will rotate the pictures.

Are your routines compatible with Mirko's SDK? In that case, could you give me them?

Thanks a lot.
 
don posted on Oct 22 2004 at 11:54 PM said:
At least the latest non-GPL version did not have 8bit Blit functionality, but it would be piece of cake to modify the 16bit ones (source available in lib.src, it's really frickin' easy).

I experienced that effect when switching to MirkoSDK (did not know of that cache issue)... Are you willing to share your code with us? maybe they could replace the old ones someday...
 
Last edited by a moderator:
Actually, I already sent him some of my routines. But anyway, here's the mail I sent to Puck2099:

The way I use my routines is weird but efficient and simple. Here is the
code:

.EQU maxh, 240

@ ******** ASMFastTransBlit(unsigned char *src4, unsigned char *dst4, int
nbx, int nby, int height2, int trans) ********

.ALIGN
.GLOBAL ASMFastTransBlit
.TYPE ASMFastTransBlit, function
.CODE 32

@r0 = src4
@r1 = dst4
@r2 = nbx
@r3 = nby

@r4 = height2
@r5 = trans
@r6 = tmp
@r7 = tmpnby

ASMFastTransBlit:

sub sp,sp,#8
stmfd r13!,{r4-r7}
ldr r4,[r13,#24]
ldr r5,[r13,#28]

_bx7:
MOV r7,r3

.REPT maxh
LDRB r6,[r0,+r7]
TEQ r6,r5
STRNEB r6,[r1,+r7]
SUBS r7,r7,#1
BMI _sauty2
.ENDR

_sauty2:
SUB r0,r0,r4
SUB r1,r1,#240
SUBS r2,r2,#1
BPL _bx7

ldmfd r13!,{r4-r7}
add sp,sp,#8
bx lr

.EQU works like #define for c, and defines a constant.
src4 point to the beginning of the picture data to be blitted.
dst4 is the destination bitmap, so this is more flexible than the blitting
functions from the sdk.

The thing that makes this function fast, is that it is unrolled (.REPT maxh
will assemble the loop with 240 times the things between .REPT and .ENDR.

Assemble that using AS, then include your .o file in your makefile, and add
this to your c code:
extern void ASMFastTransBlit(unsigned char *src4, unsigned char *dst4, int
nbx, int nby, int height2, int trans);

So now, we have to clip the bitmap. Here it is:

void FastTransBlit(int numsurface, int dx, int dy, int width, int height,
unsigned char *src, int trans) {
int xmin = 0;
int ymin = 0;
int xmax = width - 1;
int ymax = height - 1;
int height2 = ( (height + 3) >> 2) << 2;
int decaly = screen_height - height - dy;

if(dx < 0) {
xmin = -dx;
} else if( (dx + width) > play_width) xmax = play_width - dx - 1;
if(dy < 0) {
ymax = height + dy - 1;
} else if( (dy + height) > screen_height) ymin = dy + height -
screen_height;
if(xmin > xmax) return;
if(ymin > ymax) return;
unsigned char *dst4 = gpDraw[numsurface].ptbuffer + (dx + xmax) *
screen_height + decaly + ymin;
src += (xmax * height2 + ymin);
ASMFastTransBlit(src, dst4, xmax - xmin, ymax - ymin, height2, trans);
}

Be careful, as I don't control if the picture is too large and goes out of
the screen on both sides (up and down, or left and right). So you should
blit only <320,<240 sized bitmaps. Or you can easily fix that removing the
else statements making the tests independant. Note that this routine clips
the bitmap, but receives a surface number to blit on.
unsigned char *dst4 = gpDraw[numsurface].ptbuffer + (dx + xmax) *
screen_height + decaly + ymin;
Change that line to point to your bitmap in memory if you use Mirko's sdk.
Also here, the picture must be stored rotated 90° anti-clockwise, with its
height rounded to the next word (int height2 = ( (height + 3) >> 2) << 2;).
This is the same as the sdk, and GP32converter will produce correct c code.
But I can also send you a bitmap loading routine (8bit only) if you want to.

Hope that helps.

I also have some fast zoom blit routines, tell me if you're interested.
 
mATkEUpON, I send you an email but I am having some mails problems so I don't know if you have received it.

Could you tell me what arguments must I use with AS to compile your code for the GP32? Although I have programmed in various assemblers for some machines (M68000, PIC116F8x...) I have never used AS to do it.

Thanks a lot.
 
Oh sorry !

I did receive the email, but with the 16days compo, I didn't really had much time lately...

AS is the assembler from gcc. But I didn't remember, the command is arm-elf-as.

So to compile this source, you have to type:

Code:
arm-elf-as -o asmsource.o asmsource.s
 
Back
Top