4 replies to this topic

[CabaretVoltaire]

I am trying to design a kernel where I can have x amount of sprites that can appear anywhere on the screen.

What I want to do is split the screen into rows and then dynamically assign software sprites (player/enemy/item/whatever) to hardware sprites (GRP0,GRP1) depending on how many software sprites appear in a row.

If 1 sprite appears in a row then I just use GRP0 to display it.
If 2 sprites appear in the row then I would use GRP0 and GRP1 to display them.

If more than 2 sprites are in a row then I would flicker between them.. For example if 4 sprites are in the same row then I would do:

1st frame:
GRP0 = sprite1
GRP1 = sprite2

(GRP0 = GRP1, GRP1 = next sprite)
2nd frame
GRP0 = sprite2
GRP1 = sprite3

3rd frame
GRP0 = sprite3
GRP1 = sprite4

(GRP0 = GRP1, GRP1 = first sprite)
4th frame
GRP0 = sprite4
GRP1 = sprite1

5th frame
GRP0 = sprite1
GRP1 = sprite2

...for each row


I have a kernel that splits the screen into sectors/rows of 24 scanlines, and checks if a sector has a sprite in it. If the sector contains no sprite then the next 24 scanlines are free to do whatever. If the sector does contain a sprite then the usual checking takes place.

So what I want to do is extend what I have to draw 2 sprites per sector (which is simple enough), and have some code during vblank or overscan (or during empy sectors!) that does this sorting.

I just can't quite get my head around how to implement this idea assembly.. I've noticed that a few games must use a similar system (dig dug for example) so was hoping that someone here has coded something like this before and could give a few pointers.

One problem is RAM.
I figure that I'd need 2 "arrays", one byte per sector to hold what GRP0 should display in each sector and what GRP1 should display per sector.
Then I would need another array to keep track of what the last item would be (how I would know when to loop around back to "sprite1" in the above example).

It seems like a lot of RAM really.. Then the actual code to do it all might be a bit heavy too.. Just how do games like Dig Dug do this?? (trying to code for the VCS makes you really appreciate the coding behind these games, even though they do often look really primitive like Dig Dug does).

[vdub_bobby]

A couple comments...

First, Dig-Dug has extra RAM in the cart.
Second, check out Manuel's (aka Cybergoth) source to Star Fire; though it isn't exactly what you're looking for, it is probably a good place to start.

[CabaretVoltaire]

vdub_bobby, on Fri Oct 21, 2005 10:11 AM, said:

A couple comments...

First, Dig-Dug has extra RAM in the cart.
Second, check out Manuel's (aka Cybergoth) source to Star Fire; though it isn't exactly what you're looking for, it is probably a good place to start.

Thanks, I'll have a look for Star Fire source code.

I've managed to write a sub routine to do what I want but it needs 27 bytes of RAM (+ 1 byte per sprite to note which sector it is in) and has a bug where if you have more than 2 sprites in a sector (so flickering is on) and then one of them moves out (so flickering is off) GRP1 and GRP0 will both draw the same sprite for one frame. Although it's not that noticable and is just like an extra frame of flickering I guess..

I'm not really happy about using that much RAM for just sprites as I'm sure I'll need more than what's left over to add game logic, sound, etc..

Edited by CabaretVoltaire, Fri Oct 21, 2005 9:28 AM.

[supercat]

CabaretVoltaire, on Fri Oct 21, 2005 8:38 AM, said:

If more than 2 sprites are in a row then I would flicker between them..  For example if 4 sprites are in the same row then I would do:

1st frame:
  GRP0 = sprite1
  GRP1 = sprite2

(GRP0 = GRP1, GRP1 = next sprite)
2nd frame
  GRP0 = sprite2
  GRP1 = sprite3

3rd frame
  GRP0 = sprite3
  GRP1 = sprite4

(GRP0 =  GRP1, GRP1 = first sprite)
4th frame
  GRP0 = sprite4
  GRP1 = sprite1

5th frame
  GRP0 = sprite1
  GRP1 = sprite2

...for each row

Unless you need all those collision-detects available, things will look much better if you flicker at 30Hz showing two sprites on one frame and two sprites on the other. If there are three sprites, show one solidly and flicker the other two at 30Hz.

Beyond that, fully-flexible sprite multiplexing is one of the trickier parts of 2600 coding--not really something for newbies. There are many approaches, each with its own cases where it is or is not the best.

In many cases, the easiest approach will be to multiplex one sprite, have the other one be fixed-function, and then constrain the multiplexed objects so that they never "cross" each other. This approach is used in a many, if not most, 2600 titles. Kernels using this approach tend to be straightforward and efficient.

If objects can cross each other, things become much more difficult. In the non-crossing approach, you can have the objects stored in a fixed sequence; the information about the objects won't move around in memory as the objects move around the screen. When objects are allowed to cross, that changes and you must decide whether to have the information about the objects fixed and copy it before each frame to some other data structure, or whether to shuffle objects around in memory as they move about the screen.

The row-array approach you describe is a good one if you can afford the memory for the array and you don't want to be shuffling objects around. It can be easily adapted for smart 30Hz flicker (though the easiest approaches for that will cause objects to disappear if there are more than five on a line) and it's fairly straightforward to code. The biggest problem with it is memory consumption.

If you want to multiplex two sprites independently, and if all sprites are the same height (or close enough you can regard them as such) it's not too difficult if you have a list of all the sprites that will be displayed on a frame, in Y-coordinate order. The first sprite gets assigned to hardware Player Zero, the second to Player One, the third to Player Zero, then Player One, etc. down the screen. Since sprites will "finish" in the order they start, strict alternation will work fine. Implementing flicker with the list may be tricky, however.

[Cybergoth]

Hi there!

CabaretVoltaire, on Fri Oct 21, 2005 1:38 PM, said:

What I want to do is split the screen into rows and then dynamically assign software sprites (player/enemy/item/whatever) to hardware sprites (GRP0,GRP1) depending on how many software sprites appear in a row.

Oh... there's finally someone porting SonSon?

Greetings,
Manuel