The hunt for slowdown

[LordKraken]

Happy to hear that you could dramatically increase the speed, that was really the only hiccup from your gemtos demo. Now I think you really have no other choice than finishing that game because the presentation was great and we all want a bubble bobble here

Edited May 15 by LordKraken

[Fadest]

It's not a bubble bobble but a puzzle bobble.

While I also would really like & Bubble Bobble like on Lynx.

Edited May 15 by Fadest

[LordKraken]

that's obviously what I meant, I'm just the 57295965th in person in the history of mankind to confuse the names 

 

At some point we should reaaally switch to "bust-a-move"

Edited May 15 by LordKraken

[laoo]

Few words from me regarding optimization of drawing sprites on Lynx.

In my opinion looping in C to update spite positions in a table of a hundred sprites is a big waste of CPU cycles. Compiled code does it very inefficiently and using linked list of SCBs does not outweigh the cost of it (I did not measure it though). CPU and Suzy does not run concurrently so drawing one sprite at a time is not that much slower. I haven't done any linked draw in ANY of our games or demos.

If you would have five tables: one table to decide whether to draw particular sprite, two tables of values of (160-horizontal) and (102-vertical) positions and two tables for low and high addresses of each SCB you could make a fast loop in assembly updating SCBNEXT for each SCB and HOFF and VOFF register to move Suzy's drawing window around (the X and Y positions in SCBs should be at the low right corner of screen (160,102), so that drawing a sprite at upper left corner requires setting HOFF to 160 and VOFF to 102) and issuing a draw. Namely something like:

 

    ldx #COUNT-1
loop:
    lda IS_DRAWN,x
    beq skip
    lda SCBL,x
    sta SCBNEXT
    lda SCBH,x
    sta SCBNEXT+1
    lda XPOS,x
    sta HOFF
    lda YPOS,x
    sta VOFF
    lda #SPRITE_GO
    sta SPRGO
l   stz CPUSLEEP
    lda SPRSYS
    and #SPRITEWORKING
    bne l 
    stz SDONEACK
skip
    dex
    bpl loop

 

 

Edited May 17 by laoo

[42bs]

	lda #1
	STA SPRGO
	STZ SDONEACK
.WAIT	STZ CPUSLEEP
	bit SPRSYS
	bne .WAIT
	STZ SDONEACK

 

[laoo]

3 minutes ago, 42bs said:

	lda #1
	STA SPRGO
	STZ SDONEACK
.WAIT	STZ CPUSLEEP
	bit SPRSYS
	bne .WAIT
	STZ SDONEACK

 

Yes. Waiting should be optimal too

[KanedaFr]

Looping on hundred of sprites is what slow down my game, you're right.

but because I think i didn't optimize it, yet....

 

for exemple, actually, I do

for(i=0; i<100; ++i)
 {
    sprPtr=&mySprites[i];
    sprPtr->hpos += XXX;
  }

 

which, like you said, result in a very bad/not optimized code.

 

I start to understand you need to drive (a lot) CC65 to produce 'better' code.

What I could do to help it on this case for exemple is

 

sprPtr=&mySprites[0];

for(i=0; i<100; ++i)
{
 	sprPtr->hpos += x;
    *sprPtr += size_of_scb_used;
}

(code probably wrong since I'm very bad at playing with pointers, even after almost 20years dealing with them)

 

this *should* produce a better.

 

Of course, nothing will beat an optimized asm code but  I'm more able to produce not optimized asm code than optimized C code

 

[obschan]

Quote

Of course, nothing will beat an optimized asm code but  I'm more able to produce not optimized asm code than optimized C code 

You can add --add-source to cc65 to help you understand what it is doing, if you stick to C and want to optimize you should use it. What you think is an optimization may be even worse.

 

On a side note I believe pointers on struct are a disaster in cc65.(at least the version on bitbucket)

sprPtr->hpos += x;

If you only change hpos, your pointer can be on hpos directly.

Edited May 17 by obschan

[LordKraken]

The real question in your last example is not of C vs asm  but of why do you want to loop through all your bubble when a maximum of one is going up? (fair enough there is also the only moment where all the bubble are going down as time malus - but your usual use case is just one bubble up)

[KanedaFr]

9 hours ago, obschan said:

ou can add --add-source to cc65 to help you understand what it is doing,

yes, it's what I did to optimize most of the loops...well to be sure I was "really" optimizing it.

--add-source and --listing are now the default option on my makefile

 

9 hours ago, obschan said:

I believe pointers on struct are a disaster in cc65

yes, it should be better to have arrays than struct, but SCB are structs ...and ever worst, of integer not char...so I have to deal with it

 

9 hours ago, obschan said:

If you only change hpos, your pointer can be on hpos directly.

oh yes! you're right! even better!

 

2 hours ago, LordKraken said:

why do you want to loop through all your bubble when a maximum of one is going up?

? the last slow loop I have to deal with is not with ONE bubble.

This case, with glue/collision stuff, is now fast enough.

The last loop I have to deal with is the "shake" effect, when every bubble slides left/right, just before they all scroll down by 1 row.

So I have to loop on a lot of bubbles, only to change their vpos (and not hpos like I said before, since we're in portrait mode).

I'm finishing the auto shoot stuff and I'll try to optimize this loop with pointers

 

Edited May 18 by KanedaFr

[obschan]

2 hours ago, KanedaFr said:

and ever worst, of integer not char...so I have to deal with it

If it's your coordinates, just initialize them at 0 and cast them to char when you use them. Still a few cycles won...

[Nop90]

4 hours ago, KanedaFr said:

The last loop I have to deal with is the "shake" effect, when every bubble slides left/right, just before they all scroll down by 1 row.

Keep them steady, shake the opposite direction all the other sprites on the screen and adjust the suzy offsets to compensate.

 

 

Edited May 18 by Nop90