Bob's Blog

Hi there!

 

No, that's the wrong game. For that effect you'd just shift a missle around, without having to flicker anything

 

Greetings,

Manuel

No, that's the wrong game. For that effect you'd just shift a missle around, without having to flicker anything

Yeah, I know, but it was the first thing that came to mind.

What do you actually think is wrong with the other demo? I thought it looked pretty good. It sure could do an pretty good Ufo port.

 

Also your technique should come to full effect with 4 sprites in a row. Compare that to a 1 sprite engine!

 

Try Zookeeper!

 

Greetings,

Manuel

What do you actually think is wrong with the other demo? I thought it looked pretty good. It sure could do an pretty good Ufo port.

What I thought was wrong with it is that it looked, to me, hardly better than a 1-sprite multiplexor.

Also your technique should come to full effect with 4 sprites in a row. Compare that  to a 1 sprite engine!

Part of the problem was that I could never figure out a good sorting algorithm. Anybody have any ideas?

Part of the problem was that I could never figure out a good sorting algorithm.  Anybody have any ideas?

 

For two sprites I'd try two iterations of my Flickersort

 

Greetings,

Manuel

For two sprites I'd try two iterations of my Flickersort

I'm pretty sure that won't work.

 

In fact, I'm pretty sure that would be worse than a single iteration.

 

Or maybe...hmmmm.

For two sprites I'd try two iterations of my Flickersort

I'm pretty sure that won't work.

 

In fact, I'm pretty sure that would be worse than a single iteration.

 

Or maybe...hmmmm.

 

Let's see... displayed are always the first 2 sprites:

 

3 overlapping sprites: 123, 312, 231, 123

=> Works (Each sprite goes on/on/off)

4 overlapping sprites: 1234, 3412, 1234

=> Works (Each sprite goes on/off/on/off)

5 overlapping sprites: 12345, 34512, 51234, 23451, 45123, 12345

=> Works (Each sprite goes on/off/on/off/off)

6 overlapping sprites: 123456, 345612, 561234, 123456

=> Works (Each sprite goes on/off/off/on/off/off)

 

...always even distribution of "on" time for any sprite it seems

 

The improvement of 2 sort iterations over one is most noticable with four sprites:

 

on/off/on/off is 30Hz

while

on/on/off/off is 15 Hz

I'm going to do some tests but, assuming you're right...

 

Where am I going to get the time!

 

I might have to switch to PAL just for the extra time.

Ok, here's the issue with running FlickerSort twice:

 

The first two sprites are displayed only if *they* are sorted!

 

So three sprites with Y values:

Sprite A: 100

Sprite B: 98

Sprite C: 96

 

They all overlap.

 

Assume they start sorted.

 

Then 1st iteration leaves:

CAB. Only C will show, since the kernel won't check for A or B until it has begun drawing C and by that time it has already passed A and B!

Next iteration:

BCA. B and C will show.

Next iteration:

ABC. A and B will show.

So

C goes on/on/off

B goes off/on/on

A goes off/off/on

 

Which isn't terrible, but isn't optimal either.

 

The real kicker is the case of just two!

Each iteration (of two flickersorts) will leave them in the same order.

So if they start out sorted, that's ok:

AB. Both show.

But if not...only one will show! The other one will never show.

BA. Only B.

 

And a further problem is that the engine requires a few lines to set up a sprite, during which time it cannot set up another sprite. So if two sprites have the exact same Y value, only 1 will be shown that frame. Which makes the double-flicker-sort even worse.

 

I'm not sure what the solution is...I played around with a bunch of stuff that seemed to help a little, but it took too long for more than 10 sprites.

Hi there!

 

Well, you can speedup the sorting - at the cost of RAM and possibly kernel cycles - if you create an index table and only sort that

 

So three sprites with Y values:

Sprite A: 100

Sprite B: 98

Sprite C: 96

 

They all overlap.

 

Assume they start sorted.

 

Then 1st iteration leaves:

CAB.  Only C will show, since the kernel won't check for A or B until it has begun drawing C and by that time it has already passed A and B!

 

Eh, now that is suboptimal!

 

- Assume both sprites are already positioned outside the kernel to the first two list entries.

- Whenever one sprite finished drawing, immediately reposition it.

- Then just wait until you meet it's starting position and draw it then.

- Repeat procedure.

 

In your CAB example. Consider C and A are both already positioned *before* line 96. Both are displayed and B is skipped this frame, because both sprites are busy.

 

Greetings,

Manuel

I wonder...there might be time in the kernel to check for the next TWO sprites, simultaneously, at least while I'm not drawing anything.

See above

Eh...another rewrite.

 

 

 

 

I'll see what I can do. I've got the weekend, I guess.

Uhm... beware though... I'm not granting that it's really possible...

 

So far I've only done that with one sprite

Uhm... beware though... I'm not granting that it's really possible...

 

So far I've only done that with one sprite

Sure it is! I'll make it work!

Well, you can speedup the sorting - at the cost of RAM and possibly kernel cycles - if you create an index table and only sort that

 

Another approach is to use a radix sort. Divide the screen into zones, and use two bytes for each zone to keep track of what sprites should be shown there. On half the frames, set all zonestat values to 255 and do something like (assuming 12 zones of 16 scan lines each, and assuming most sprites will straddle two zones)

 ldy #1
.lp:
 lda spriteypos-1,y
 lsr
 lsr
 lsr
 and #$FE
 tax
 lda zonestat1,x
 and zonestat1+1,x
 bmi .zone_ok
 lda zonestat2,x
 and zonestat2+1,x
 bpl .zonesfull
 txa
 sbx #[zonestat2-zonestat1]
.zone_ok:
 sty zonestat1,x
 ldy #0
 sty zonestat1+1,x
.zonesfull:
 iny
 cpy #num_sprites+1
 bne .lp

On the other half of the frames, do basically the same thing but have y count from num_sprites downto zero.

 

If there are one or two sprites in a zone, they will be displayed solid. If three, one will be solid and the other two will flicker 30Hz. If four, all will flicker 30Hz. If more than four, some disappear Note that this routine will never half-flicker a sprite; whether half-flickering is good or bad is an aesthetic judgement.

 

An alternative approach which should always produce good results if you can afford the time would be to have each sprite tagged with a "has been shown recently" flag. Start by running a loop like the above but ONLY placing the sprites that have NOT been shown recently (set the flag on any sprite that is placed). If any zone is not full, clear the "has been shown recently" flag for all sprites in that zone and repeat.

Those are some pretty good ideas. I think it comes down to the game you're actually doing then, to find the best mechanism.

 

- How many sprites are tracked by the engine?

- Which movement patterns do they have?

 

The first is most essential. Tracking 24 objects, the engine can't use more than 3 bytes per object or you're busted for example.

 

Also, don't underestimate the object-handler. From all my experiences can it easily consume more cycles than the sorting

Right now I've upped it to 4 bytes per object and it is running 22 objects; 88 bytes.

 

RAM and time to sort are the main limiting factors here. I think I can, just barely, make a game using only 4 bytes per sprite (X, Y, type, and something to control it's movement). And with ~20 sprites there is, again, just barely time to sort and process all those sprites. Barely.

Hi Bob!

 

That is definitely an improvement now!

 

It still seems to be a bit buggy, though. If you're not moving the ship, it seems like there's some blind spots where never a shot is shown. They just seem to jump over it. I thought with an even flicker distribution you should be able to see shots on any vertical position eventually, no?

 

Greetings,

Manuel

That is definitely an improvement now!

Get some glasses, Manuel; I didn't post a new binary!

It still seems to be a bit buggy, though. If you're not moving the ship, it seems like there's some blind spots where never a shot is shown. They just seem to jump over it. I thought with an even flicker distribution you should be able to see shots on any vertical position eventually, no?

Yeah, well, "with an even flicker distribution" being the key here.

 

I haven't changed the kernel; I didn't have a lot of time over the weekend to play with the kernel...well, plus I was a bit distracted reading The Ringworld Engineers.

 

I'll post a new binary sometime soon.

 

EDIT: I'll post the last binary of DAOS right now.

Ooopsa. Guess I just noticed "Edit II" today, when reading message 18

Ooopsa. Guess I just noticed "Edit II" today, when reading message 18

Oh. In that case, you don't need glasses.

 

Glad you think it looks better...I thought it was a little better, but not much.