I've finished a sprite multiplexing demo, showing the workings of several multiplexing algorythms. It manages till 16 mode 1 sprites that can be moved freely to play with them and test the multiplexing methods. Maybe could be useful to anyone looking for this kind of routines and in need of testing :

Sprite multiplexing demo

Keys used:
-------------
Cursor keys: Selects sprite to move vertically.
Space: Aligns all sprites (not reversible!).
0-4 keys: Selects multiplexing method.

You can find more info in this thread from Karoshi's forum (some little explanations about the algorythms) :

www.msxgamesbox.com/karoshi/index.php?topic=427.0

Although it's in the spanish forum, there're lots of english comments!

Good!

What about cpu time spent?
Could you make a msx2 version taking in account 8 spr x scanline?
Are the source free? Can we get them?

This program in mode 1 (mine) is useful to show the differences
between blue and open msx in the management of the 5th sprite

Simply try to have two lines with 5 or more sprites

As mode 1 splits the SAT accordingly to the S0 value
you'll see that the returned S0 value returned by the
two emulators differ!!

Actually I would like to know what is the real behavour of the HW
and which emulator is'nt accurate (maybe none of them..)

try this configuration of sprites on both emulators and you'll see the differences

http://ragozini.googlepages.com/spriteflick.rar

the avi is very short and recorded on BLUE, but it is sufficient to have a glance on the
configuration that shows the differences and reproduce it on OPEN

@pingpong
my code is on karoshi's website

Quote:

Could you make a msx2 version taking in account 8 spr x scanline?

I think that with very little changes all routines could be adapted to work with 8 sprite planes limit...

Quote:

Are the source free? Can we get them?

Sure!, the full demo source is here :

www.telefonica.net/web2/msxpage/sprflick.asm

It's in asMSX format; but as usual, it can be easily adapted to any other assembler. Feel free to modify to suit your needs...

As ARTRAG says, you'll see the differences between emulators handling the sprite limit. Slowing the emulation speed you'll see also very clearly the inner working of each method.

Quote:

As ARTRAG says, you'll see the differences between emulators handling the sprite limit.

Can you describe the differences between openMSX, blueMSX and the real thing?
And possibly file a bug report for openMSX?

look at the .avi I posted, run the rom reproducing the
same sprite configuration displayed in the .avi
and compare the two emulators
You'll see that the two emulators does not return the same
S0 value in the same sprite configuration
I cannot be sure, but OPEN seems to return the FIRST 5th sprites it finds in the screen
while BLUE seems to return the last 5th sprite it finds in the screen

IMHO the ideal HW should return the highest hidden plane in the screen
but I am not sure of the behaviour of the real HW

If someone can test this on the real HW, we can see what should be the actual implementation.

I will try on a v9938 if i have time last weekend, but i need a .dsk image (or .com)

Me too

Instead a .com, you can try it under MSXDOS as a .rom using ExecROM. Anyway, I'll build a bin->dsk version the next weekend (and if I feel brave I'll modify it for 8 sprites )

True EXECROM works fine with this rom

http://www.alsoftware.com.br/adrianpage/

Experimenting I have found that IMHO openmsx
has the worst behaviour wrt to the 5th plane matter...

In case of a single line of 5 sprites, method 1 must, by
its definition, have all the sprites of that line flickering.....
This doesn't happen on openmsx, and this has to be
a sure bug in openmsx, independently on how the true
HW works.

(BLUE in the same condition works as expected)

It will be interesting to see what the tests on real HW shows. My real MSXes are in boxes atm but I'll see if I can get them up and running next weekend.

I think the plane swapping routine has a bug :/ Sometimes, when I shift sprites up and down, I get the behaviour of mode 0: all sprites beyond number 4 disappear (the overlapping regions). I have seen this behaviour on several occasions and depending on history either got flickering or disappearing sprites for the same sprite constellation!

But... I *do* see differences in behaviour between openMSX and real hw!
[edit]but only after a long time of fiddling and not exaclty doing the same sprite movements on openMSX and real hardware[/edit]

Quote:

I cannot be sure, but OPEN seems to return the FIRST 5th sprites it finds in the screen while BLUE seems to return the last 5th sprite it finds in the screen IMHO the ideal HW should return the highest hidden plane in the screen but I am not sure of the behaviour of the real HW

Huh? The srite limit was designed to keep the 'load' on the VDP low for handling sprites. Returning the *first* 5th sprite seems more logical then, since the VDP can then stop processing sprites for that line. If it wants to return the *last* sprite on the line, it still might need to process all!

After playing for about half an hour with the ROM on both openMSX and real hardware, I can only conclude that openMSX may not be perfect, but at least it's got the same behaviour as the real thing in 99% of all cases...