Mickey Mania emulator comparison

mickagame · Post by **mickagame** » Sat Mar 21, 2009 10:52 pm

During my tests on mickey mania i notice that the "3d levels" have some glitchs on kega fusion. I have the same on the emulator i'm writting.

Here's screenshot from differents emulator :

Fusion / Regen / my emulator (Glitches)

Gens (OK)

Pico (OK)

Does someone can tell if this glitches appear on real hardware?

AamirM · Post by **AamirM** » Sun Mar 22, 2009 2:14 pm

Try running it in Fusion 3.61. I think some timing related changes were made in that and maybe its fixed in it.

As for me, I can't even get to that stage

. (need to cheat

)

mickagame · Post by **mickagame** » Sun Mar 22, 2009 6:44 pm

I have the same glitches with 3.61 with normal and alternate timings.
You have just to wait the third demo of the game to see that.

TascoDLX · Post by **TascoDLX** » Mon Mar 23, 2009 8:14 am

Weird, I didn't notice that until you pointed it out, though it's not easy to see immediately. It's a problem with sprite masking. It seems that it only works if, on the line being drawn, there exists any sprite of higher priority than the masking sprite, or at least Fusion thinks so.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Mar 23, 2009 11:11 am

only problem is that my camera died and its in repair... otherwise I could play that far and take a pic or two...

Stef · Post by **Stef** » Mon Mar 23, 2009 5:26 pm

I meet the problem on ealier gens version, as i used that mickey level a lot to test my emulator i quickly fixed it out though. i m not sure it a simple sprite mask bug, but for sure it s an emulator bug, it doesn t happen on real hardware.

notaz · Post by **notaz** » Mon Mar 23, 2009 9:46 pm

Stef wrote:it doesn t happen on real hardware.

I can confirm that.

Strange PicoDrive got it right, I haven't done anything specific for this. I know that sprite masking section in Charles' genvdp.txt is not entirely correct though, but I can't remember exact details.

Nemesis · Post by **Nemesis** » Tue Mar 24, 2009 5:14 am

You've got a bug in your sprite masking mode 2 implementation. You're not correctly testing the y coordinate of a sprite before testing whether x=1 to enable sprite masking mode 2. For some strange reason, this level in Mickey Mania terminates the sprite list with an entry at x=1,y=1. Your emulator and Kega are both picking this up as a trigger to enable sprite masking mode 2, which is as a result making the mode 1 sprite masks at x=0 no longer function.

Each scanline, the VDP iterates through the sprite list looking for entries which are on the current scanline. This is the first test that's performed on each sprite entry. You're testing for a mode 2 trigger sprite with x=1 before you test if the current sprite entry is actually on the current scanline. Since with y=1, this sprite is off the top of the visible area of the screen, it should never trigger mode 2 sprite masking. Likewise, if you had a mode 2 sprite masking enable trigger which was on a visible scanline, but was itself being masked, either due to a sprite overflow or a mode 1 mask sprite, the mode 2 sprite masking trigger should never be parsed by the VDP, and as such, it should never enable sprite masking mode 2, even if it was on a visible scanline.

There really aren't enough games which do unusual things with the VDP. It's not very hard to find VDP bugs in existing emulators if you look for them.

Eke · Post by **Eke** » Tue Mar 24, 2009 9:51 am

To be more precise, sprite are parsed one line before: the VDP has an internal RAM (not VRAM !) that can store informations for up to 80 sprites (64 in H32 mode). This is in fact a partial copy of the Sprite Attribute Table in VRAM which only store the following attributes:
- yposition
- size
- sprite link
- sprite pattern start address

I recently found a Sega patent that confirms this (note that xpos is NOT stored, which means it is read in VRAM SAT directly when rendering sprite): http://www.google.com/patents?id=E-wdAA ... dq=5411272

This means that you could modify some sprite attributes AFTER sprite parsing has occured but it will not be taken in account until the next line.

Regarding sprite masking mode 2, the description from Charles McDonald is indeed not *entirely* correct but its implementation in genesis plus is right (at least it works with Mickeymania... and Galaxy Force is another game using this):

What it does is simply this, when rendering sprites and for each (and only) sprites that have been previously parsed:

Code: Select all

if(xpos != 0) sol_flag = 1; 
else if(xpos == 0 && sol_flag) return; /* stop rendering sprites */

ob1 · Post by **ob1** » Tue Mar 24, 2009 9:58 am

Great piece of knowledge ... as usual

mickagame · Post by **mickagame** » Tue Mar 24, 2009 1:11 pm

Thank you for your infos Eke but i don't understand the implementation in genesis plus.

Code: Select all

for(count = 0; count < object_index_count; count += 1)
  {
    xpos = object_info[count].xpos & 0x1ff;

    /* sprite masking */
    if(xpos != 0) sol_flag = 1;
    else if(xpos == 0 && sol_flag) return;

When a first sprite with x_pos !=0 is drawed sol_flag is set to 1 and then the next sprite with x_pos !=0 will be the last parsed sprite?
what is the relation between sprite masking 2 and sol_flag?

[/code]

Eke · Post by **Eke** » Tue Mar 24, 2009 2:47 pm

I don't know how sprite masking mode 2 is really working (and if there are even two masking "modes", sega manual only mentions one), just that this implementation works for the few games using it and that the original description in genvdp.txt is not very clear

it does what the code tells you: whenever a sprite with xpos = 0 is detected AND at least one sprite with xpos !=0 has already been detected, VDP stops rendering sprites...

maybe it should be

Code: Select all

xpos == 1

instead of

Code: Select all

xpos != 0

, I really don't know but in the previous code, one of the test is unnecessary (xpos == 0 is always true)

AamirM · Post by **AamirM** » Tue Mar 24, 2009 3:13 pm

Equivalent code from Regen:

Code: Select all

        if(spr_xpos == 0) spr_mask |= 1;
        if(spr_xpos > 0 && spr_xpos < 0x81) spr_mask |= 2;

		  if(spr_mask == 3) return;

This may not be right but I did this after testing many, MANY games that used sprite masking. Shame I don't remember their names now. Maybe a little while later I will......need to see the history file

.

EDIT:
If it is indeed a problem with sprite masking, I am sure increasing the value 0x81 will fix it. I'll get to it.

EDIT2:
It is indeed a problem with sprite masking. If 0x81 is changed to 0x17b, the problem disappears.

mickagame · Post by **mickagame** » Tue Mar 24, 2009 4:41 pm

Yes for me too if i increase the value the problem is gone.
Other thing : mickey mania use sprite masking mode 1 so if i stop rendering sprite when x_pos = 0 (according to description of sprite masking mode 1 made by charles) the problem is gone too.

AamirM · Post by **AamirM** » Tue Mar 24, 2009 4:49 pm

Yes for me too if i increase the value the problem is gone.
Other thing : mickey mania use sprite masking mode 1 so if i stop rendering sprite when x_pos = 0 (according to description of sprite masking mode 1 made by charles) the problem is gone too.

Yes, but according to the docs, if mode two is also enabled then mode 1 becomes invalid.