GP32 Speed Problem With Sprites

[digitaljez]

The warning means that you are not pointing to a structure of type tSprite. i.e. explo1 it not of type tSprite. I do not use mirko but I assume tSprite is part of his sdk. I imagine this structure should be pointing to the actual bmp data. Check the declaration of explo1.

 

[0-bake]

this is from my original code (the names liek tSprite were just chosen to talk easier about...):

Spr_Ex1 is from a bitmap, i included.
the Spr_Ex1.h contains:

extern const u32 Spr_Ex1_end[];
extern const u8 Spr_Ex1[];
extern const u32 Spr_Ex1_size[];

so i guess, the picture information is u8 Spr_Ex1[];

my original code is:

include "Spr_Ex1.h"

u8 *Explosion[10];

and in main()

Explosion[0]=&Spr_Ex1;

or am i doing something asically wrong?

 

[digitaljez]

I would guess that extern const u8 Spr_Ex1[]; is the bit map data and the only reason it is complaing is that it is defined as a 'const u8' and your Explosion variable is a pointer to a 'u8'. Try sticking const in front of u8 *Explosion[10];

 

[0-bake]

hm, it changed nothing. i don't get it. isn't there any way to see what kind of variable Spr_Ex1 is?
but thanks anyways

edit:

i convert the bitmaps with bmp2bin -x (the sprite-header command)
and i have absolutely no idea, what is happening by saying #include "Spr_Ex1.h"

in the Spr_Ex1.h theres:

extern const u32 Spr_Ex1_end[];
extern const u8 Spr_Ex1[];
extern const u32 Spr_Ex1_size[];

and in my program, the variable Spr_Ex1 is a sprite. so it's like the three variables from the included .h file are all in Spr_Ex1.
i don't know what that means....

 

[digitaljez]

I am not familiar with bmp2bin. What are the parameters you are using exactly? I imagine it will be > bmp2bin -x somename.bmp somename.h. In your case the name of the explosion.bmp and Spr_Ex1.h . Are the externs the only entries in the header file ? Extern is saying the actual data is off in some other file. The kind of variable (again I don't use mirko and it seems he has redefined the c type names) I would guess is a constant unsigned 8 bit - i.e. const unsigned char. My compiler is very unhappy with the code as it is. It gives an error - not just a warning. - but if I remove the & from Explosion[0]=&Spr_Ex1; to give Explosion[0]=Spr_Ex1; it doesn't complain. This is just a compile test and does not produce any code I can test to see if the result is correct. I have had to replace const u8 with const unsigned char as I dont have it redefined.

 

[0-bake]

i tested it with unsigned char, of course. i even tried it with and without the "&", but it always gets a warning or an error. i have no idea, what the prolem is.

and yes, these extern entries are the only thing in the .h file. in the same directory of the .h file, there's also a .o file, which contains raw data.

 

[digitaljez]

I've just tried the following and get no errors and it displays the bitmap :

It's the gamepark sdk unfortunately but may be of help

#include "gpfont.h"
#include "gpgraphic.h"

#include "graphics\mrcfseq.h"

GPDRAWSURFACE gpDraw[4]; // screen buffers

int iscreenflip; // keeps track of display buffer

const unsigned char *Explosion[10]; //<<<<<<<<<<<<<<<



void GpMain(void *argv)
{
int i;

Explosion[0]=mrcfseq; //<<<<<<<<<<<<<<<

// initialise screen-flipper
iscreenflip = 1;

i = GpGraphicModeSet(8, NULL);

for(i = 0; i < 4 ; i++)
{
GpLcdSurfaceGet(&gpDraw, i);
GpSurfaceSet(&gpDraw);
}
GpLcdEnable();


for(i = 0; i < 4 ; i++)
{
GpRectFill(NULL, &gpDraw, 0, 0, 320, 240, 0);
}
GpSurfaceFlip(&gpDraw[0]);

// gamepark transparent blit function
GpTransBlt(NULL, &gpDraw[iscreenflip], 0, 0, 256,
44,(unsigned char*) Explosion[0], //<<<<<<<<<<<<<<<
0, 0,
256, 44, 247);
GpSurfaceFlip(&gpDraw[iscreenflip++]);
iscreenflip &= 0x01;

// wait for key
while(GpKeyGet() == 0);
while(GpKeyGet() != 0);

}

mrcfseq is the bitmap data and is defined in mrcfseq.h thus :

#define mrcfseq_width 256
#define mrcfseq_height 44

const unsigned char mrcfseq[11264] = { ... lots of hex data ....};

this displays a 256 x 44 bitmap across the top of the screen.
mrcfseq.h was generated using gp32converter.exe ( coded by Edorul )
I've added some pointy things to highlight the relevant bits.

 

[0-bake]

thats very nice, but i never doubted that there's a way of doing it without compiler warnings.
but i won't change from the mirko-libraries, just because i can't fix a problem. i prefer to find the solution for the problem, even if it's hard

 

[digitaljez]

That was just to show the assigning of the 'const unsigned char ' - which should be independant of the sdk.
I don't understand where bmp2bin has put the actual bitmap data.
Does -x mean generate a header or don't generate a header ?
Does the Spr_Ex1.h have #include statement(s) in it ? I can only imagine it includes the image data or you would be getting errors relating to it at link time.
I wouldn't ecpect you to change libraries - sometimes I think it would be interesting to try mirko - but deep down I know I just can't be arsed to bother looking into it - it was enough hassle setting up my current environment

 

[0-bake]

the -x command generates a header for mirkos sprites. and the .h-file just contains the three lines i posted.
anyways, i just tried to optimize the tile-based version, i posted in my first post, because except of the speed problems, it was working fine.

but my tiled version is dog-slow, directly compared to mirkos gp_drawSpriteHT function, but i don't see any reason why. here are both versions:

mirko's (original) version:

void setpixel(short x, short y, u16 color, u16 *framebuffer ) {
     if ( !((x<0) || (x>319) || (y<0) || (y>239)) )
       gp_drawPixel16(x,y,color,framebuffer);
}

void gp_drawSpriteHT( u16 *sprite, short put_x, short put_y, u16 *framebuffer, u16 trans) {
     int xx,yy,i=0;
     SHEADER *sheader;
     u16   color;

     sheader = (SHEADER*) sprite;
     for (yy=0; yy<(sheader->size_y); yy++)
        for (xx=0; xx<(sheader->size_x); xx++) {
           color = sprite[6+i++];
           if ( color != trans ) 
             setpixel(put_x+xx,put_y+yy,color,framebuffer);
        }
}

my version:

typedef struct {
 u16 *source_img;
 short source_x;
 short source_y;
 u16 width;
 u16 height;
 u16 trans;
} tSprite;

void setpixel(short x, short y, u16 color, u16 *framebuffer ) {
     if ( !((x<0) || (x>319) || (y<0) || (y>239)) )
       gp_drawPixel16(x,y,color,framebuffer);
}

void SetSprite(tSprite *sprite,u16 *source_img,u16 trans,short source_x,short source_y,short width,short height)
{
 sprite->source_img=source_img;
 sprite->source_x=source_x;
 sprite->source_y=source_y;
 sprite->width=width;
 sprite->height=height;
 sprite->trans=trans;
}

void PutSprite(tSprite sprite,float plotx, float ploty,u16 *framebuffer)
{
 int y,x;
 for (y=sprite.source_y;y<sprite.height+sprite.source_y;y++)
 for (x=sprite.source_x;x<sprite.width+sprite.source_x;x++) 
 {
   if (sprite.source_img[6+x+(y*320)] != sprite.trans) setpixel(x-sprite.source_x+plotx,y-sprite.source_y+ploty, sprite.source_img[6+x+(y*320)], framebuffer);
 }
}

i don't see any big difference between the two PutSprite-functions, but my one is unusable slow.

 

[digitaljez]

I guess the calculations will slow it down somewhat. Also you are accessing data within a structure. The compiler will try to assign variables to registers where possible but if you are accessing data then the code has to do actual memory fetches instead of just fiddling around with its registers. This of course involves more( and probably slower) arm instructions.

 

[JyCet]

1-include your bmp with all your caracter in one line.
Generaly you have a 1d array for each BMP file.
2-in your prg convert this BMP in 2d array example:
caractere[NUM_TOTAL][SIZE]=...
if your caractere have 8*8 SIZE=64
if you have 50 caracteres in your BMP then NUM_TOTAL=50

how to convert ?
for (i=0;i<NUM_TOTAL;++i)
for (j=0;j<SIZE;++j)
caractere[j]=your_bmp[(i*SIZE)+j];

you can display each caractere like a simple sprite with a 2d array.

 

[0-bake]

@JyCet:

i thought of something like this, but then i use 2*times the memory. one time for the included bitmap and 2nd time for the new array.
and i want to include my bmp's, because i want to have just one single .fxe at the end.

but maybe i use this method anyways, because i never can fill the whole 8mb of ram

 

[pea]

And you can free the original BMP after you have copied it to the 2D array, so you don't really double the mem.

 

[0-bake]

but how can i copy the data into a new sprite?
i posted my version here: http://www.rafb.net/paste/results/3wRaBQ85.html

but as i said there already, it just produces errors

i even tried it with

typedef struct {
u16 *data;
u16 width;
u16 height;
u16 trans;
} tSprite;

 

[Squidge]

the 'data' element in your structure needs to be big enough to support the largest sprite you will ever place there, or needs to be dynamically allocated. You seem to be trying to place all the data into a single character, or placing it into a unallocated buffer.

For example, something like the following:

tSprite spr;

spr.width ...
spr.height ...
spr.data = (u16 *)malloc((spr.height * spr.width) * sizeof (u16));
spr.data[x] = ...data...

 

[0-bake]

ahh, thanks Squidge.
that really works, great!

hm...some graphical errors, but i have to look at it closer, thx!