GP32 Mr.mirkos Sdk Replacement

[loki666]

i found a bug in you grafik module...
in 8bpp the LCD's reg setting are wrong...

Thanx for the Hint loki666...

np
maybe CLKVAL should be adjusted too... dont know

 

[mr.mirko]

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

 

[loki666]

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

 

[mr.mirko]

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 :

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 ?

 

[trans]

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);

 

[Rattboi]

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

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

 

[CrazyDesi]

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

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.

 

[Tharo]

Mirko plz use an 12 bit header size.
The 10 bit header slows the mem copy ALOT. Or in other words - 20fps.

 

[mr.mirko]

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...

 

[mr.mirko]

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

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...

 

[Tharo]

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.

 

[Rattboi]

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:

#define fontwidht 1024

should be:

#define fontwidth 1024

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

See yaz

 

[mr.mirko]

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:

#define fontwidht 1024

should be:

#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

 

[mr.mirko]

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.

// 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...

 

[Rattboi]

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

 

[Tharo]

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" ?

 

[mr.mirko]

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

 

[Rattboi]

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

 

[mr.mirko]

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

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.

 

[Tharo]

Yes. Im realy sorry but i found thoose error yesterday by myself :/