I've used the 'weird' sprite multiplex technique in the past for some demoparts. That way multiplexing really became a breeze.

notice btw that it doesn't cost _that_ many extra spriteimages if your objects are only 2 sprites high (in that case you need 3 sprite images).

You'll start to get problems if your objects are a lot higher, as in that case memory usage almost doubles (for 10 sprites high, you need 19 images f.e.)

I'd say : hail to easy coding and go for this

does anyone know where I can get an example of a multiplexor that doesn't have a "gap" between two of the same sprites stacked?

Double Dragon 3 is a fair example. Have a look to its IRQ code, it's quite easy to understand.

an example.

situation : you have 2 sprites on top of eachother, say sprite 1 is at y-position 0 and sprite 2 is at position 21.

this is what you do.

-before position 0, you write the position of sprite 1 to the sprite register and the correct sprite image.

-between position 11 and 20, you write the position of sprite 2 to the sprite register, and swap the sprite-image to the extra inbetween sprite image.

-between position 21 and 31 you swap the sprite image to the complete bottom sprite image.

that's it.

now, if your 2 sprites look like

sprite 1 :

AB
CD

sprite 2 :

EF
GH

your inbetween sprite has to look like :

EF
CD

good luck

I see what you mean but I was hoping to do it with just one sprite.

A = sprite 1
B = sprite 2

A
B
A
B

I can do that all day long and create very tall sprites. What I want to do is:

A
A
A
A

with no gaps. I don't think it is even possible.

cbmeeks: Learn some coding before you start drawing conclusions about what's possible or not. There's absolutely no reason why this wouldn't be possible, except that you're not good enough at coding to be able to implement it.

For the Metroid game you'd probably need nothing more than ABCDEFGHABCDEFGH reusage (ie. go round and round).

You can do gapless sprites without tricks, by timing the writes precisely. But stupid gamecoders like to avoid situations where precise timing is necessary, 'cos the situations are dynamically created and always changing..

i second that, puterman. theres a lot of examples that you can multiplex the same sprite vertically over and over again without gaps. best example might be old ESCOS demos, which cover the entire screen with sprites and multiplex EVERY sprite this way.

@cbmeeks :

with sprite1 and sprite2, i do mean the same physical sprite, just different sprite images...

Well, it might be beneficial to make some bullets etc. with chars instead of sprites.

"just about any sprite in Metroid can be all over the screen at any time" to me, that's precisely the reason to use a general round & round plex. Zone split (reuse of one sprite) -style solutions are better for more narrowly defined cases, like the fighting games discussed.

For a lot of sprites with a general plex, see for example Ikari Warriors, or even (god forbid) Commando.. that's a lot of activity without (much) flickering.

And if you find it difficult .. look at my rants & example code

cbmeeks: The discussion was about sprite multiplexing, not general programming, right? So you should interpret my statement as "learn a bit about coding sprite multiplexers before you start drawing conclusions about what's possible or not with sprite multiplexers".

As for me growing up, hehe, no way!

puterman: Well, it sounded pretty harsh to me...anyway, no harm no foul...