GP32 Mr.mirkos Sdk Replacement


mr.mirko posted on May 21 2004 at 11:41 PM said:
Hi,

just a small update:

- updated bmp2raw to fit the new sprite header
- updated example.sprite to fit the new sprite header
- updated gp_grafik.c, now works in all modes with correct calculated refresharte ( thanx loki666 for the hint )
- updated asm screen clear.

get it here: http://mirkoroller.de/gp32
or here :
http://www.project-io.org/project-io.beta/...GP32/SDK081.bz2
mmmh, i dont like the static vidmode variable...
maybe it would be time to define a struct to handle LDC infos, we could use other features like hardware scrolling and clipping...(using a buffer bigger than the screen res), we could save info like the bpp and the LDC regs like LCDBASEL, LCDBASEU and PAGEWIDTH, and maybe more for hardware scrolling...
what do you think? the framework would result cleaner i'm sure (no more two functions one for 8bit and one for 16bit, one would be enough)
take a look at mr.spiv's compiled sprite sample
 
Last edited by a moderator:
loki666 posted on May 22 2004 at 01:31 PM said:
mr.mirko posted on May 21 2004 at 11:41 PM said:
Hi,

just a small update:

- updated bmp2raw to fit the new sprite header
- updated example.sprite to fit the new sprite header
- updated gp_grafik.c, now works in all modes with correct calculated refresharte ( thanx loki666 for the hint )
- updated asm screen clear.

get it here: http://mirkoroller.de/gp32
or here :
http://www.project-io.org/project-io.beta/...GP32/SDK081.bz2
mmmh, i dont like the static vidmode variable...
maybe it would be time to define a struct to handle LDC infos, we could use other features like hardware scrolling and clipping...(using a buffer bigger than the screen res), we could save info like the bpp and the LDC regs like LCDBASEL, LCDBASEU and PAGEWIDTH, and maybe more for hardware scrolling...
what do you think? the framework would result cleaner i'm sure (no more two functions one for 8bit and one for 16bit, one would be enough)
take a look at mr.spiv's compiled sprite sample
Mhh, i also dont like (static) global variables, but in this case
it results in fast, and small code.

I tryed this code :

Code:
void gp_setFramebuffer(u32 addr,int vsync) {
   u32 LCDBANK  =  addr >> 22;
   u32 LCDBASEU = (addr & 0x3FFFFF) >> 1;
   u32 LCDBASEL;
   u16 OFFSIZE = 0;
   u16 PAGEWIDTH;
   u16 vidmode = ((rLCDCON1>>1) & 15)-8;   // result in 0,1,2,3,4
   const u8 faktor[]= {15,30,60,120,240};

   LCDBASEL  = LCDBASEU + 320*faktor[vidmode];
   PAGEWIDTH = faktor[vidmode];

   (u32*) rLCDSADDR1 = (LCDBANK<<21) | (LCDBASEU<<0);
   (u32*) rLCDSADDR2 = (LCDBASEL<<0);
   (u32*) rLCDSADDR3 = (OFFSIZE<<11) | (PAGEWIDTH<<0);
   if (vsync) gp_waitVsync();
}


Also supporting all modes is very usefull, if someone wants 16color modes :)
It only takes ~10 bytes...

I looked to the sprite code, and i find it very difficult to program.
The way its now programmed, is easy to understand, and you can see on one
view, whats going on. Using structs to store the lcd registers is not usefull, in my eyes, couse we only use the registers once, at user program start.
And for the 0.1% of users who really want to use the clipping feature ( of the lcd hardware). Its not more then a Framebuffer setting, and can also be made with a setFramebuffer. So why complicate/blow up, the things ?
 
Last edited by a moderator:
mr.mirko posted on May 21 2004 at 10:41 PM said:
Hi at

just a small update:

[..]
[/URL]
here is a small gp_stdio.h (fileio) addon for the great mirko sdk.

http://gp32sdk.ath.cx (manual)
http://gp32sdk.ath.cx/addon/smfs_23052004.zip

This api uses the linux path style like "/.././game"

example:

SMC_FILE* handle;

smc_chdir("/gpmm/.././gpmm"); // set ur workpath
handle = smc_fopen("./test.txt","r");
smc_close(handle);
 
Last edited by a moderator:
Another thing that really really should be changed in Mirko's SDK is the button constant names.

The current BA, BB, BL, BRIGHT, etc is just not good naming, plus I'm trying to move my emulator over to Mirko SDK, and BL was conflicting with my cpu core :p

I recommend KEY_A, KEY_B, KEY_RIGHT, KEY_START. That's what I changed it to in my version.

Please please do this in the next version.

Please

Rattboi
 
Rattboi posted on May 24 2004 at 01:53 AM said:
Another thing that really really should be changed in Mirko's SDK is the button constant names.

The current BA, BB, BL, BRIGHT, etc is just not good naming, plus I'm trying to move my emulator over to Mirko SDK, and BL was conflicting with my cpu core :p

I recommend KEY_A, KEY_B, KEY_RIGHT, KEY_START. That's what I changed it to in my version.

Please please do this in the next version.

Please

Rattboi
I agree. The easier the keys are to understand the less you have to worry about. So this would be of great help.
 
Last edited by a moderator:
Mirko plz use an 12 bit header size.
The 10 bit header slows the mem copy ALOT. Or in other words - 20fps.
 
Tharo posted on May 24 2004 at 02:04 PM said:
Mirko plz use an 12 bit header size.
The 10 bit header slows the mem copy ALOT. Or in other words - 20fps.
a typedef of a header can not slow down something...

i check it...
 
Last edited by a moderator:
Rattboi posted on May 24 2004 at 01:53 AM said:
Another thing that really really should be changed in Mirko's SDK is the button constant names.

The current BA, BB, BL, BRIGHT, etc is just not good naming, plus I'm trying to move my emulator over to Mirko SDK, and BL was conflicting with my cpu core :p

I recommend KEY_A, KEY_B, KEY_RIGHT, KEY_START. That's what I changed it to in my version.

Please please do this in the next version.

Please

Rattboi
a good idear, i change it...
 
Last edited by a moderator:
it is not the typedef. it is the fact that memcpy only works with half-words if you use an pointer adress that is not div. with 4. And this kills around 30% of the perfomace.
 
Bug found. Well, not so much a bug, but a typo. I realize it's not high on the priorities, but it MUST be mentioned anyways.

In file gp_setfont.c:

Code:
#define fontwidht 1024

should be:

Code:
#define fontwidth 1024

It's totally internal, so it affects absolutely nothing, but like I said, it MUST be mentioned.

See yaz
 
Rattboi posted on May 24 2004 at 08:58 PM said:
Bug found. Well, not so much a bug, but a typo. I realize it's not high on the priorities, but it MUST be mentioned anyways.

In file gp_setfont.c:

Code:
#define fontwidht 1024

should be:

Code:
#define fontwidth 1024

It's totally internal, so it affects absolutely nothing, but like I said, it MUST be mentioned.

See yaz
hehe...

i think its not a typo, it results on my bad english knowlege :)


:p
 
Last edited by a moderator:
Tharo posted on May 24 2004 at 06:52 PM said:
it is not the typedef. it is the fact that memcpy only works with half-words if you use an pointer adress that is not div. with 4. And this kills around 30% of the perfomace.
I wrote my own alpha blending now, to check this,
and cant see any speed improvement, by using a 10 byte or 12 byte header.

Code:
// alpha 0-31
void gp_drawSpriteHTB( u16 *sprite, short put_x, short put_y, u16 *framebuffer, u16 trans,u8 alpha) {
     int xx,yy;
     SHEADER *sheader;
     u16   *spriteraw;
     u16   color;
     u16   SR,SG,SB;
     u16   DR,DG,DB;

     (u16*) sheader = sprite;
     spriteraw = sprite + 5;
     for (yy=0; yy<(sheader->size_y); yy++)
        for (xx=0; xx<(sheader->size_x); xx++) {
           color = *(spriteraw++);
           if ( color != trans ) {
              int x,y;
              x=put_x+xx;
              y=put_y+yy;
              if ( !((x<0) || (x>319) || (y<0) || (y>239)) ) {
                 SB=(color>> 1)&31;
                 SG=(color>> 6)&31;
                 SR=(color>>11)&31;
                 color = *(framebuffer +(239-y)+(240*x) );
                 DB=(color>> 1)&31;
                 DG=(color>> 6)&31;
                 DR=(color>>11)&31;
                 color = ( (((alpha*(SR-DR))>>5)+DR)<<11 ) | ((((alpha*(SG-DG))>>5)+DG)<<6) | ((((alpha*(SB-DB))>>5)+DB)<<1);
                 *(framebuffer +(239-y)+(240*x) ) = color;
              }
           }
        }
}

As you can see, iam not using memcpy...
This AlphaBlending, gives me on 2 Sprites with 150x150 Pixel each, and 50% alpha with background, about ~50 fps...
 
Last edited by a moderator:
Is there a function that will return the amount of free memory?

I really need access to something like GpAvailableMem(), but I haven't seen it anywhere in Mirko SDK. Can this be rectified?

Thanx
 
50fps at what? 100MHz?
However.
Yes. as i see you dont use memcopy and thats why you still dont saw what i told. gnaa! <_<
Just try the difference between a

memcpy(buffer,Picture+5,0x25800); // current header
and
memcpy(buffer,Picture+6,0x25800); // bedder version

to see how big is the difference. gp32_console


Rattboi, why you not using "allcocate" and "free" ?
 
Tharo posted on May 25 2004 at 06:49 AM said:
50fps at what? 100MHz?
However.
Yes. as i see you dont use memcopy and thats why you still dont saw what i told. gnaa! <_<
Just try the difference between a

memcpy(buffer,Picture+5,0x25800); // current header
and
memcpy(buffer,Picture+6,0x25800); // bedder version

to see how big is the difference. gp32_console


Rattboi, why you not using "allcocate" and "free" ?
Hey, you there the person who told me, changing the sprite header
to the way, it is now ...

I must rewrite the bmp2sprite programm (again)
All users now using it in 0.80 and 081 version are then incompatible (again),
rewrite sprite example, manual, check all.

typedef struct {
char magic[4];
u16 size_x;
u16 size_y;
u16 info;
u16 alpha;
} SHEADER;

info:
format :[0-3]
0000 RGB 16 Format RRRRRGGGGGBBBBB- normal sprite data
0001 RGB 16 Format RRRRRGGGGGBBBBB- normal sprite data + alpha in alpha (5 bit alpha)
0010 ARGB 32 Format -----------AAAAARRRRRGGGGGBBBBB-
0011 ...

reserved:[4-5]
00 reserved (always zero)

rotate:6
0 Sprite is rotated ( 90 deg clockwise )
1 Sprite is not rotated

alpha:7
0 Alpha/Blend disable
1 Alpha/Blend enabled
 
Last edited by a moderator:
In my emulator, there was a little thing at the bottom that showed free RAM amount, but you can't do that with calloc/free :p
 
Rattboi posted on May 25 2004 at 10:25 AM said:
In my emulator, there was a little thing at the bottom that showed free RAM amount, but you can't do that with calloc/free :p
There is no easy way, finding out the free ram.

You can do this trick,

malloc a lot memory in 64kb steps,
count the mallocs, until a error occours,
free the malloc memory.

Now you get the free ram.
 
Last edited by a moderator:
Back
Top