Jump to content
IGNORED

Need opinions on multisprite kernel


batari

Which compromise is better?  

20 members have voted

  1. 1. Which compromise is better?

    • Reduce the number of sprites from 6 to 5, or possibly even 4
      5
    • Move the playfield to ROM
      15

  • Please sign in to vote in this poll.

Recommended Posts

It's not working 100% under Stella.  Depending on where the sprite is, it makes other copies disappear completely rather than flicker.

995118[/snapback]

 

If I remember correctly, it did the same thing in z26. I didn't report the behavior, because batari had said up front that there was still some work he needed to do on it, mostly cleanup, and that bad things could happen in certain situations. Anyway, it isn't an emulator-related problem, the kernel was still a little buggy when batari posted that demo.

 

Michael Rideout

Link to comment
Share on other sites

It's not working 100% under Stella.  Depending on where the sprite is, it makes other copies disappear completely rather than flicker.

995118[/snapback]

 

If I remember correctly, it did the same thing in z26. I didn't report the behavior, because batari had said up front that there was still some work he needed to do on it, mostly cleanup, and that bad things could happen in certain situations. Anyway, it isn't an emulator-related problem, the kernel was still a little buggy when batari posted that demo.

 

Michael Rideout

995213[/snapback]

Yes, it's not an emulator issue. The flicker engine is handled in VBLANK and only allows two overlapping sprites (plus you need a few scanlines of buffer between them for repositioning.)

 

If you try >2 or two sets of 2, sprites may completely disappear or get cut off. But getting it this far was much harder than I thought it would be, so I don't know how much further I will be able to take this before release, which I want to do soon.

 

That said, the next release will be designated 0.99 beta. I expect that there may be nasty bugs (as there were with 0.30) that will need fixing quickly. So what I hope people will do is play with 0.99b and see what they can do with it, while some brave soul improves the flicker engine for me. Or looks into the source and suggests a good algorithm that will work with the kernel.

Link to comment
Share on other sites

But getting it this far was much harder than I thought it would be, so I don't know how much further I will be able to take this before release, which I want to do soon.

 

That said, the next release will be designated 0.99 beta.  I expect that there may be nasty bugs (as there were with 0.30) that will need fixing quickly.  So what I hope people will do is play with 0.99b and see what they can do with it, while some brave soul improves the flicker engine for me.  Or looks into the source and suggests a good algorithm that will work with the kernel.

995360[/snapback]

 

That sounds like a plan! :)

 

Michael Rideout

Link to comment
Share on other sites

It's not working 100% under Stella.  Depending on where the sprite is, it makes other copies disappear completely rather than flicker.

995118[/snapback]

 

If I remember correctly, it did the same thing in z26. I didn't report the behavior, because batari had said up front that there was still some work he needed to do on it, mostly cleanup, and that bad things could happen in certain situations. Anyway, it isn't an emulator-related problem, the kernel was still a little buggy when batari posted that demo.

 

Michael Rideout

995213[/snapback]

Yes, it's not an emulator issue. The flicker engine is handled in VBLANK and only allows two overlapping sprites (plus you need a few scanlines of buffer between them for repositioning.)

 

If you try >2 or two sets of 2, sprites may completely disappear or get cut off. But getting it this far was much harder than I thought it would be, so I don't know how much further I will be able to take this before release, which I want to do soon.

 

That said, the next release will be designated 0.99 beta. I expect that there may be nasty bugs (as there were with 0.30) that will need fixing quickly. So what I hope people will do is play with 0.99b and see what they can do with it, while some brave soul improves the flicker engine for me. Or looks into the source and suggests a good algorithm that will work with the kernel.

995360[/snapback]

 

 

Bob Colbert had a general purpose multisprite demo in the Stella archives.

 

Also, Manuel's Star Fire kernel is pretty flexible. Have you thought about these?

Link to comment
Share on other sites

Bob Colbert had a general purpose multisprite demo in the Stella archives.

 

Also, Manuel's Star Fire kernel is pretty flexible.  Have you thought about these?

995678[/snapback]

While it is true that a kernel needs to be written a certain way to support intelligent flicker, this kernel already is. Besides, those kernels are still too specialized. I don't see a lot of playfield in either kernel, and I doubt that they support both missiles and the ball and sprites of any height and do so without any HMOVE blanks. Furthermore, it makes much more sense to start from scratch than to adapt a kernel written for a particular game (and many kernels are not adaptable at all.) This is why this kernel was written just for bB.

 

Regardless, the flickering is not done in the kernel anyway - the sprites that are displayed in each frame are predetermined before the kernel is even run. So to say that the problem is with the kernel itself is incorrect. The kernel itself is basically done. The existing flicker engine resides 100% in VBLANK.

 

This is how the current flicker engine works. Each sprite has its y-value and height in fixed RAM locations. 5 indices are kept that hold the order in which we should display the sprites. The indices starts out holding 1, 2, 3, 4, 5 in the demo, telling the kernel to display the sprites that order.

 

Now let's say we move sprite 3 on top of sprite 4. The engine detects the overlap, and tells the kernel to start with the 2nd sprite (thus displaying 4 sprites per frame.) So the new indices are: 3 1 2 4 5 and 4 1 2 3 5, alternated every frame. We continue to swap the 3 and 4 every frame as long as there is still overlap. If there is no more overlap, the sprites are then sorted by y-value and all 5 sprites are displayed once again.

 

A better flicker engine might just be an expansion of this idea (i.e. for 3 sprites, start on the 3rd sprite and rotate the 3 indices into the sprites to be displayed.) So the problem is not HOW to do it, but how to generalize for X sprites or two sets of overlapping sprites. I'm hesitant to write code for every possible overlap case (it will be big and messy.) I'm sure there is a better, simple, straightforward way. So I am in search of an algorithm or a talented coder.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...