Reduce number of static sprites to draw thanks to 3rd buffer ?

[KanedaFr]

While working on a puzzle game, I was looking for a way to speed up sprite rendering.

I have 100s sprites to draw and it clearly slows down the game (seen on the few animations I have)

 

75% of these sprites are statics or change every 5 seconds or more.

Looking at cc65 source code to learn how sprite-to-screen is done, I learnt about FC08/9, how double buffering works, etc....

So I came with an idea..but before I spent time and lost my mind on asm coding, I'd like to hear your inputs about it

 

Let's say I have 3 sprites : bottom/middle/top

These 3 sprites never change

So I allocate a sprite-buffer of the needed size (ie based on sizes and positions of the 3 sprites)

Set FC08/9 to the address of this sprite-buffer

Draw the sprite at 0,0 -> it will be drawn at sprite-buffer address

Switch back FC08/9 to drawing screen buffer

on game loop, draw one and only sprite which data = sprite-buffer

 

while it requires more of the precious 64K memory, will it works ?

 

If I go further, could it be used to simulated a tiled map ? (yes a full screen sized sprite!)

 

note: of course, I could also copy sprites' raw data to buffer without using sprite rendering, like text drawing is done on cc65, but I won't be able to use scale, stretch and others useful sprite properties

 

[Nop90]

I don't get the point.

 

If you draw several sprite in memory you obtain a large bitmap , not a large sprite that you can draw using Suzy. Literal sprites have additional data at the beginning and at the end of every row.

[KanedaFr]

🥵

It's what you call a total failure...

sorry about that =(

[laoo]

1 hour ago, KanedaFr said:

before I spent time and lost my mind on asm coding

I don't understand this "asm-phobia". 

6502 is so simple, whereas cc65 is sooo slooow, especially wrt repetitive tasks like manipulating SCB to draw sprites... I sometimes almost cry when I see Lynx games with beautiful graphics and gameplay but ruined by awful framerate of 15 fps... It's a shame. Really.

Edited March 6 by laoo

[42bs]

1 hour ago, KanedaFr said:

Let's say I have 3 sprites : bottom/middle/top

These 3 sprites never change

So I allocate a sprite-buffer of the needed size (ie based on sizes and positions of the 3 sprites)

Set FC08/9 to the address of this sprite-buffer

Draw the sprite at 0,0 -> it will be drawn at sprite-buffer address

Switch back FC08/9 to drawing screen buffer

on game loop, draw one and only sprite which data = sprite-buffer

 

 

This is a common technique, I use it in PITS, Dracula uses it for the texts.

Only remember, SUZY excpects an 80byte wide screen, so your big-sprite has only 79 data bytes, as 1 byte is needed for line size.

_BUT_ drawing these three sprites in a chain will take no more time than drawing one big sprite.

 

I use it for text drawing. Printing a large text into a sprite and then draw this sprite.

Edited March 6 by 42bs

[Nop90]

39 minutes ago, 42bs said:

I use it for text drawing. Printing a large text into a sprite and then draw this sprite.

I suppose you setup an empty sprite data structure, than you use suzy to blit data in it, taking care to not change the data ad the beginning and at the end of every row. Is this correct?

 

 

[+karri]

On Solitaire I had the problem of having most of the screen static while I only wanted to move one pile of cards.  So the solution was to draw the static screen to drawpage 0. During every animation cycle I memcpy drawpage 0 to drawpage 1. Then I draw the moving sprites on top of drawpage 1. The showpage is kept as 1 all the time.

[42bs]

2 hours ago, Nop90 said:

I suppose you setup an empty sprite data structure, than you use suzy to blit data in it, taking care to not change the data ad the beginning and at the end of every row. Is this correct?

 

 

Either this, or a sprite that draws 5 at x==0

[42bs]

2 hours ago, karri said:

On Solitaire I had the problem of having most of the screen static while I only wanted to move one pile of cards.  So the solution was to draw the static screen to drawpage 0. During every animation cycle I memcpy drawpage 0 to drawpage 1. Then I draw the moving sprites on top of drawpage 1. The showpage is kept as 1 all the time.

Ouch, SUZY is the better memcpy, it does DMA

[KanedaFr]

2 hours ago, 42bs said:

Ouch, SUZY is the better memcpy, it does DMA

oh ?! I'm interested....
How do you launch a DMA Copy ?! I read something about the "video DMA circuit" but I don't know what it is...

 

4 hours ago, karri said:

On Solitaire I had the problem of having most of the screen static while I only wanted to move one pile of cards.  So the solution was to draw the static screen to drawpage 0. During every animation cycle I memcpy drawpage 0 to drawpage 1. Then I draw the moving sprites on top of drawpage 1. The showpage is kept as 1 all the time.

It was my second idea but with the flop of the 1st, i kept it for myself to try first
 

But isn"t a memcpy (by Mikey?) slower than a chained sprite draw (by Suzy) ?

[KanedaFr]

5 hours ago, 42bs said:

 

This is a common technique, I use it in PITS, Dracula uses it for the texts.

Only remember, SUZY excpects an 80byte wide screen, so your big-sprite has only 79 data bytes, as 1 byte is needed for line size.

_BUT_ drawing these three sprites in a chain will take no more time than drawing one big sprite.

I said 3 there as an example, but on my puzzle game, it is 0 to 110  (with 30-40 most of the time)

 

so 1 big of 44x120 vs 40 of 11x12 ?

 

 

[42bs]

7 hours ago, KanedaFr said:

oh ?! I'm interested....
How do you launch a DMA Copy ?! I read something about the "video DMA circuit" but I don't know what it is...

 

Sorry, no there is no hidden DMA copy. I meant your idea of using a big sprite.

 

[42bs]

6 hours ago, KanedaFr said:

I said 3 there as an example, but on my puzzle game, it is 0 to 110  (with 30-40 most of the time)

 

so 1 big of 44x120 vs 40 of 11x12 ?

 

 

This should give a performance boost.

[42bs]

7 hours ago, KanedaFr said:

But isn"t a memcpy (by Mikey?) slower than a chained sprite draw (by Suzy) ?

This can't be answered with a clear YES or NO. It depends. An unrolled memcpy might be quicker.

[+karri]

Here is the relevant code for copying the background screen.

 

void bgcopy()
{
    asm("sei");
    asm("lda #$0f");
    asm("sta $fff9");
    memcpy(0xc038, 0xe018, 8160);
    asm("lda #$0c");
    asm("sta $fff9");
    asm("cli");
}

void startupgame()
{
    gamenumber = rand();
    check_music(true);
    while (tgi_busy())
        ;
    tgi_setviewpage(1);
    tgi_setdrawpage(1);
}

 

The asm stuff is because the cpu needs to see the ram under the rom when doing the copy operation.

 

And of course you don't use tgi_busy() or tgi_updatedisplay() as you need to micromanage these things yourself by using tgi_setviewpage() and tgi_setdrawpage().

[42bs]

@karri did you some time measure on the memcpy(), I guess it takes at least half a frame.

[+karri]

36 minutes ago, 42bs said:

@karri did you some time measure on the memcpy(), I guess it takes at least half a frame.

No I did not measure it. For card games having a single buffer was kind of cute. When you deal the cards you show the background buffer. After that you switch the display buffer to the front and keep repeating bgcopy and draw pile when the pile of the cards are moving. It was not super fast but nice.