EricBall's Tech Projects

Why can't you squeeze in STA REFPn?

Why can't you squeeze in STA REFPn?

Right now the kernel is pretty stuffed. There's a critical 3 line section (eigth line of a row, sprite reposition line, first line of the next row) which is really tight for cycles, both in number and timing. Perhaps after I get a chunk of the glue logic working I'll see if there's 3 cycles available to squeeze the STA REFPn into. And, unfortunately, since REFPn is bit 3, I'll probably also need 4 cycles for the LDA ABS,Y to retrieve the value.

Hi there!

 

Why do you actually need to set it *inside* the kernel?

 

Greetings,

Manuel

Why do you actually need to set it *inside* the kernel?

Because I reuse sprites. Every 8 lines the kernel reuses one of the two sprites (alternating). So multiple sprites on separate rows (or two sprites on the same row) won't flicker. Important when you have 5 fully independent sprites (player + 4 enemies).

 

If there are >2 sprites on a single row, then there is an "intelligent" flicker routine. Actually, I think I stole your idea (from Starfire?) where I do two loops through a bubble-sort routine, sorting the sprites by which has been skipped for the most frames. So 3 sprites will cycle through on-on-off, and four will cycle on-off-on-off (in theory). It actually can be more complex than that, since the re-use alternates between rows plus falling/climbing sprites have only one choice while others have two choices.

 

It's a little confusing, but also one of the breakthrough ideas I had (with some helpful suggestions) at the beginning of the project. Back in April 2003, according to my original development blog.

Hi there!

 

Because I reuse sprites.  Every 8 lines the kernel reuses one of the two sprites (alternating).  So multiple sprites on separate rows (or two sprites on the same row) won't flicker.  Important when you have 5 fully independent sprites (player + 4 enemies).

 

Hm... for 5 or 6 sprites, the Venture engine is also pretty good. It does constant 30Hz flicker on all 6 sprites though.

 

If there are >2 sprites on a single row, then there is an "intelligent" flicker routine.  Actually, I think I stole your idea (from Starfire?) where I do two loops through a bubble-sort routine, sorting the sprites by which has been skipped for the most frames.

So 3 sprites will cycle through on-on-off, and four will cycle on-off-on-off (in theory).  It actually can be more complex than that, since the re-use alternates between rows plus falling/climbing sprites have only one choice while others have two choices.

 

Star Fire does only 1 bubble sort iteration, the idea of doing 2 was a rather recent one. Even C7 does only 1, because I think overlapping sprites will be pretty rare in the end and it will never have 4 sprites overlapping at once

 

If you based the code on Star Fire, I found a little bug in the sorting code since, the branching should be

 

BCS DontSwap

 

rather than

 

BPL DontSwap

 

The later only works if your kernels line count is less than 128

(which it isn't anymore in C7 )

 

Also, if you based the sprite skipping code on the one from Star Fire, this can be done much more efficient for your game, since your sprites positions can only be on the visible part of the screen. There's much fuss involved for the Star Fire *universe* being *open* to all sides

 

Greetings,

Manuel

I simply used the concept of doing a partial sort rather than the actual code. I do 2 passes on the logic that if all sprites are on the same row, then 2 will be displayed, so they need to bubble to the bottom of the priority list. (The pattern in this case would be on-off-on-off-off, or 12-34-51-23-45.)