Sega Genesis Dev Kit (SGDK)

[djcouchycouch]

Thank you my rom size went down from 1.1mb to 896kb nice update I already like it and I have been using it for only 5 minutes.

Same here! Goplanes dropped from 384kb to 256kb.

[Stef]

Yeah i finally re-implemented optional big tables so the minimum rom size should reduce to 128 Kb instead of 384 Kb
I add to modify a bit of code but i think it worths it and at some point i also needed it

[Moon-Watcher]

BMP_FF_* functions works in 0.90 and fails in 0.91.

out/src/main.o: In function `main':
main.c:(.text+0x70): undefined reference to `BMP_FF_init'
main.c:(.text+0x9c): undefined reference to `BMP_FF_setPixel'
main.c:(.text+0xb8): undefined reference to `BMP_FF_clear'
main.c:(.text+0x176): undefined reference to `BMP_FF_drawLine'
main.c:(.text+0x1fc): undefined reference to `BMP_FF_flip'
main.c:(.text+0x21c): undefined reference to `BMP_FF_clear'
main.c:(.text+0x2da): undefined reference to `BMP_FF_drawLine'
main.c:(.text+0x360): undefined reference to `BMP_FF_flip'

(Or maybe it's my fault?)

[Stef]

This is due to these "big tables" we were speaking about.
Looks in the config.h file in the include directory, you will see that BMP_FF requires BMP_TABLES to be set to 1.
Modify it in the config.h file then recompile the library (by using the makelib.gen file), that should make it =)

[Moon-Watcher]

Thanks, It works as expected

* The software bitmap engine permit to simulate a 128x160 pixels bitmap screen with doubled X resolution.<br>
* It uses a double buffer so you can draw to buffer while other buffer is currently blitting in video memory.<br>
* Requires ~41 KB of memory which is dynamically allocated.

I assume BMP_* functions calculates dinamically the position and the BMP_FF_* ones uses an array into RAM memory to flip data into VRAM memory. Performance between both function sets is huge.

So the 128x160 pixels screen and doubled X resolution is due to the RAM limit, right?

[Stef]

BMP_FF_xx means Bitmap Fast Fill where BMP_xx is a 'simple' bitmap software engine.
The Fast Fill mode uses plain tile for fast filling, it permits fast clear or fast rectangular region fill... The draw back is that simple pixel or line drawing is slower than with simple bitmap engine. Originally I wanted to do a 3D flat engine with BMP_FF methods but I never completed it...
The 128x160 X doubled resolution is for speed reason (simpler line drawing method), not related to memory

[bioloid]

I get 15fps with this code (using Fusion):

Code: Select all

int main()
{
    VDP_setScreenWidth256();
    VDP_init();
    VDP_setHInterrupt(0);
    VDP_setHilightShadow(0);
    BMP_init(BMP_ENABLE_ASYNCFLIP | BMP_ENABLE_EXTENDEDBLANK | BMP_ENABLE_FPSDISPLAY);
    
    while(1)
    {
        u8* buffer = BMP_getWritePointer(0, 0);
        BMP_flip();
    }
    
    return 0;
}

Did I miss something in config.h or is it expected ?

[Moon-Watcher]

I get 15fps with this code (using Fusion):

Code: Select all

int main()
{
    VDP_setScreenWidth256();
    VDP_init();
    VDP_setHInterrupt(0);
    VDP_setHilightShadow(0);
    BMP_init(BMP_ENABLE_ASYNCFLIP | BMP_ENABLE_EXTENDEDBLANK | BMP_ENABLE_FPSDISPLAY);
    
    while(1)
    {
        u8* buffer = BMP_getWritePointer(0, 0);
        BMP_flip();
    }
    
    return 0;
}

Did I miss something in config.h or is it expected ?

15 fps is the expected using BMP_* functions.

[bioloid]

Ok, I thought I've read it were possible to achieve better somewhere here... Thanks anyway, I'll live with that.

[Stef]

BMP_FF_xx will give you better performance there (simple blit) but again it is optimized for fast filling so using lot of line or point will make performance worst than with BMP_xx...
Also the BMP stuff are software bitmap conversion so yeah it takes sometime, basically almost all CPU time is "waste" in main memory --> VRAM frame buffer transfer.
As explained in the documentation, BMP_ENABLE_EXTENDEDBLANK permit to extend VDP blanking period. This permits to reduce number of needed frame for bitmap frame buffer conversion and transfer to 4 frames (60/4=15 FPS).
Also with this flag the memory transfer is done only during "blanking" period so you can use free CPU time (active period) to fill your bitmap buffer

[bioloid]

Ok, thanks for the clear explanations, I'll downsize the rendering size then, I don't need playable framerate anyway

edit: Ok, got it : I get around 35fps and better when cutting doBlitNorm() a bit, but thats not my current pitfall so I leave it as it for now, looks good

[Stef]

Ok, thanks for the clear explanations, I'll downsize the rendering size then, I don't need playable framerate anyway

edit: Ok, got it : I get around 35fps and better when cutting doBlitNorm() a bit, but thats not my current pitfall so I leave it as it for now, looks good

cutting doBlitNorm() O_o ??
you want to reduce the bitmap resolution ?

[bioloid]

I'll maybe, if required. Have to know/test/make what I want first, optim will come later on.

[bioloid]

Ok, got heightfield with gouraud shading running near 1 fps.
It's the first raw version, final will be in the demo !

[Stef]

He really nice ! I am impatient to see the final result
The megadrive is really not designed to do bitmap drawing so it's always impressive to get that sort of effect out of it.
Did you saw the cube 3D sample ? I initially had a gouraud shaded version of it sometime ago but gouraud shading do not look really good with MD palette so i only keep flat shaded version.