7 replies to this topic

[GodOfCows]

I've been wanting to make more complicated games, but it requires better and faster graphics to accomplish this. I've made a function which does what I want, draws a sprite to the screen. However, it is awfully slow. Does anyone have a solution to this problem?
 

void sprite_draw(unsigned char x, unsigned char y, unsigned char *src)

{
    /*
        Example:

        const unsigned char enemy2[] = {
            10, //how big the image is, 10 = 10x10, 8 = 8x8 ect


            // This is the actual image, one = pixel on and 0 = pixel off
            0,0,0,0,0,0,0,0,0,0,
            0,0,0,0,0,0,0,0,0,0,
            0,0,1,0,0,0,0,1,0,0,
            0,0,0,1,0,0,1,0,0,0,
            0,0,1,1,1,1,1,1,0,0,
            0,1,1,0,1,1,0,1,1,0,
            1,1,1,1,1,1,1,1,1,1,
            1,0,1,1,1,1,1,1,0,1,
            1,0,1,0,0,0,0,1,0,1,
            0,0,0,1,0,0,1,0,0,0
        };


    */

    unsigned char a,b;
    unsigned short i;
    a = b = 0;


    for (i = 1; i <= src[0]*src[0]; i++)
    {


        if (a >= src[0])
        {
            b++;
            a = 0;
        }


        if (src[i])
            Bdisp_SetPoint_VRAM(x+a,y+b,1);


        a++;
    }
}

Edited by SopaXorzTaker, 27 August 2018 - 10:23 AM.
Reformatted the code

[LBPHacker]

I'm missing out on a lot of context here but I assume you have a good optimising compiler. I'd say it's not possible to get anything better than this unless we know what Bdisp_SetPoint_VRAM expands to (assuming it's a macro). If it's some sort of bitwise hackery, the performance can probably be improved a lot. And I dig the invader.

[GodOfCows]

Thanks for the reply. For context, when drawing lots of images to the screen, in rapid succession, it is too slow. It fades in and out, it is just too slow.

 

I edited the code to fix it (it was missing some important code)

[LBPHacker]

Well, that still doesn't explain what Bdisp_SetPoint_VRAM is, so I chose the hard way and tried to figure it out on my own. I managed to find out that 1) it's a syscall, so no wonder it's slow, and also that it's better to bit-bang the VRAM directly, and 2) fxcg/display.h already has sprite functions that bit-bang the VRAM for you (declarations, definitions).

 

Note that I have no idea what the heck I'm looking at exactly and just relying on intuition. I've never once seen this library before.

 

EDIT: I just realized that you want transparent sprites (and also I assume Bdisp_SetPoint_VRAM sets the pixels to white?). That means you'll have to roll your own VRAM bit-banging function which would be similar to the ones linked above.

Edited by LBPHacker, 26 August 2018 - 06:34 PM.

[GodOfCows]

Whoops, I thought you wanted to know my specific problem in my program was. I defiantly see my problem, and I'll have to use a better library. (Or use ASM, but we're not cavemen.) Also, thanks for the reply's.

[Viliami]

Have you tried using the  Bdisp_WriteGraph_VRAM function?

 

It copies a bitmap to the vram which should be faster than going through bit by bit with Bdisp_SetPoint_VRAM

[Viliami]

There's some sample code for the Bdisp_WriteGraph_VRAM function in this thread: https://community.ca...tegraph-ddvram/

 

Also, the docs for this function can be found in the fx-9860G Libraries.pdf file. Available for download on the casio website: https://edu.casio.co...greement.html#2 Click SDK then fx-9860G SDK Manuals (compressed file)

[GodOfCows]

Thanks for the reply. I'm unsure if that will help me. All syscalls seem to be much slower than a user created library. I've stumbled across Monochromelib, which seems to currently be the fastest for drawing. I'll try to make the game with and without the library to see how drastic the improvement is. For the default library, I'll most likely have to erase only parts of the screen that needs to be erased, instead of removing the entire screen and displaying the next 'frame'. I'll make two versions of the game using the default fxlib and the newer monochromelib and see how they look.