Jump to content
  • entries
    106
  • comments
    796
  • views
    139,433

Goofy Tech Demo...Applied!

Sign in to follow this  
Guest

1,661 views

INITIALLY I WAS PRETTY disappointed with the goofy tech demo I wrote (see previous post). It was pretty tricky, and a fair amount of work, to get the kernel working. And in the end, it didn't look much better than if I had just multiplexed a single sprite!

 

But I kept playing around with it and I think it might be useful afterall. Maybe.

 

Here's a possible way...look at this demo. At first, a mild-mannered, kinda-weak-looking Demon Attack clone:

blog-6060-1138380301_thumb.jpg

But you hit the fire button and then!

blog-6060-1138380310_thumb.jpg

Demon Attack On Steroids!:lol:

daos.bin

 

EDIT: And you could probably work a halfway decent 1942 (or similar) port out of this engine.

 

EDIT II: New binary; flicker improved somewhat. Turn P0 and P1 on and off to see the difference between this one and the other ROM.

daos.bin

 

EDIT III: New DAOS binary. This one, at least, couldn't be done without a sprite multi-plexor. IMO doesn't look real great, but oh well.

daos.bin

Sign in to follow this  


22 Comments


Recommended Comments

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

Share this comment


Link to comment
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. ;)

Share this comment


Link to comment

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

Share this comment


Link to comment
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?

Share this comment


Link to comment
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

Share this comment


Link to comment
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.

Share this comment


Link to comment
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 ;)

Share this comment


Link to comment

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. ;)

Share this comment


Link to comment

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.

Share this comment


Link to comment

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

Share this comment


Link to comment

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.

Share this comment


Link to comment

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

 

So far I've only done that with one sprite ;)

Share this comment


Link to comment
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! ;)

Share this comment


Link to comment
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.

Share this comment


Link to comment

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 ;)

Share this comment


Link to comment

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.

Share this comment


Link to comment

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

Share this comment


Link to comment
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. :D

 

I'll post a new binary sometime soon.

 

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

Share this comment


Link to comment
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.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...