Mickey Mania emulator comparison

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Mar 24, 2009 5:07 pm

Nemesis says :
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
So sprite masking mode 2 must be enabled after testing y coordinates.
Mickey mania has not sprite masking mode 2. For a strange reason the last sprite entry is x=1,y=1 but hasn't to be taked in account because of the y value.

that's i have understood ...

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Tue Mar 24, 2009 5:23 pm

Mickey mania is ok now for me.

I have a flag spr_mask_m2.
this flag is set to 0 at each start of frame.
When i'm rendering sprite i make this :

Code: Select all

       /* sprite masking mode 1 */
        if(xpos == 0 && !vdp->spr_mask_m2)
            return;

        /* sprite masking mode 2 */
        if(xpos == 1)
            vdp->spr_mask_m2 = 1;
Image

I would be interested to have name of games using sprite masking mode 2 to do tests.

EDIT: Galaxy 2 is ok now too !!! before the menu wasn't shown fully

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Tue Mar 24, 2009 6:52 pm

I would be interested to have name of games using sprite masking mode 2 to do tests.
Here are some which I can remember now:

Vectorman 2 (the start)
Castle of Illusions (Ghost stage)
Sonic 2 title screen
Mercs Level 1 boss

These are all the ones I can remember right now.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Tue Mar 24, 2009 8:16 pm

Now I get it. :D

Out of curiousity, I checked Gens and here's what it does: it starts checking for masking sprites (x=0) *after* the first sprite it meets on the line, then when it meets a masking sprite, it stops.

Since Mickey Mania duplicates each of its masking sprites five times in the sprite list, it always stops no later than the second masking sprite. If masking sprites aren't considered in the first test, then masking won't work correctly (hence, the bug). If this is true, then having a masking sprite at highest priority on a line shouldn't have any real effect (unless there's another masking sprite following it).

As far as x=1 is concerned, I believe that's just a way to get a sprite on the line so the masking can be enabled. Theoretically, x could be any value. So, I highly doubt there exists a "mode 2".

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Tue Mar 24, 2009 10:11 pm

TascoDLX wrote:Now I get it. :D

Out of curiousity, I checked Gens and here's what it does: it starts checking for masking sprites (x=0) *after* the first sprite it meets on the line, then when it meets a masking sprite, it stops.

Since Mickey Mania duplicates each of its masking sprites five times in the sprite list, it always stops no later than the second masking sprite. If masking sprites aren't considered in the first test, then masking won't work correctly (hence, the bug). If this is true, then having a masking sprite at highest priority on a line shouldn't have any real effect (unless there's another masking sprite following it).

As far as x=1 is concerned, I believe that's just a way to get a sprite on the line so the masking can be enabled. Theoretically, x could be any value. So, I highly doubt there exists a "mode 2".
An interesting theory! I've always thought there was more to the supposed sprite masking mode 2 than was in genvdp.txt, but this is the first implementation I've heard which makes sense. I'll definitely have to test this on hardware.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Tue Mar 24, 2009 11:14 pm

Here's something I threw together (for no good reason):

Mickey Mania (U) Fusion Fix (IPS patch)

I'm guessing this'll be fixed in the next version.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Mar 25, 2009 8:10 am

TascoDLX wrote:As far as x=1 is concerned, I believe that's just a way to get a sprite on the line so the masking can be enabled. Theoretically, x could be any value. So, I highly doubt there exists a "mode 2".
yep, that's what I thought too... and this is how Charles implemented it in Genesis Plus so he probably did some additional tests after writing genvdp.txt :wink:

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Wed Mar 25, 2009 9:07 am

Code: Select all

if(xpos != 0) sol_flag = 1;
else if(xpos == 0 && sol_flag) return; /* stop rendering sprites */
Very strange. This implementation doesn't work for me.
If i stop rendering at the first sprite with x_pos = 0 it works but if i consider at least one sprite with xpos !=0 has already been rendered it doesn't work.
It's like the sprite with x_pos = 0 is the first sprite of the list...

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Mar 25, 2009 4:49 pm

mickagame wrote:It's like the sprite with x_pos = 0 is the first sprite of the list...
Yes, indeed it is (and, in this case, the second, third, fourth, and fifth as well). Any sprite, no matter what the x_pos, should set the sol_flag. Therefore, it should look like this:

Code: Select all

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

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Wed Mar 25, 2009 5:23 pm

Yes it ot works ...

But i am suspicious.
Why don't return on first sprite with xpos = 0?
I don't see the reason to render 1 sprite before considering sprite masking ...
It doesn't seem very logical ...

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Wed Mar 25, 2009 9:02 pm

Consider the way Galaxy Force 2 uses sprite masking. It must be able to mask out a single line. But, the smallest possible sprite covers eight lines. So, if it stopped on the first sprite (xpos = 0), it couldn't mask less than eight consecutive lines at a time.

Not checking the first sprite for xpos = 0 allows for the possibility of an overlap where only one line of an off-screen sprite (xpos = 1) is processed before that of the masking sprite (xpos = 0). It's certainly not the most versatile system but it allows for that kind of detail while keeping things relatively simple.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Wed Mar 25, 2009 10:36 pm

It's not as simple as the first sprite being ignored for sprite masking. I've started writing a "Sprite masking/overflow test rom", and I'm currently debugging it on the hardware. Yes, if you have a masking sprite at x=0 as the first sprite on a line, then follow it by a visible sprite, the masking sprite will not take effect, and the second sprite will be visible. It's not only the first sprite that causes this however. According to tests I did last night, if you have two masking sprites at x=0 at the start of a line, masking still doesn't take effect. We know that masking does take effect with 5 masking sprites at the start of a line however, as this is what Mickey Mania uses, and we know that if you have a sprite with x=1 (or probably anything that's not 0) at the start of the line, and follow it by a sprite with x=0, masking does take effect, as this is what Galaxy Force II does (I've confirmed there's no switch to a "mode 2" sprite masking for the remainder of the frame).

I don't think any of the current implementations of sprite masking are fully emulating the behaviour of the hardware. I'll be doing more tests today.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Wed Mar 25, 2009 11:16 pm

Very interesting Nemesis :-)

Snake
Very interested
Posts: 206
Joined: Sat Sep 13, 2008 1:01 am

Post by Snake » Thu Mar 26, 2009 2:44 am

TascoDLX wrote:So, I highly doubt there exists a "mode 2".
No, there doesn't. It's much simpler than Charles describes.

Never seen this problem before - and looking at the shots, and the description of what it's doing/what's happening... I have no idea at all why this wouldn't work in Fusion already. It must be a very silly bug. When I actually get a chance to look at my code (:cry:) I'll see what's going on...

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Thu Mar 26, 2009 5:51 am

Nemesis wrote:It's not as simple as the first sprite being ignored for sprite masking.
I kinda figured there was more to it. I haven't a clue why Mickey Mania uses the five masking sprites instead of just masking the normal way (as it appears to do for the top border).
Nemesis wrote:I don't think any of the current implementations of sprite masking are fully emulating the behaviour of the hardware. I'll be doing more tests today.
I hope your tests end better than mine did, though I am very limited in my setup. The only thing I managed to find is that the horizontal size of the masking sprite likely gets added to the pixel count of the line (I didn't get a chance to confirm that). Other than that, I couldn't get hardware to do anything different than Fusion does, so I don't know why Mickey Mania works right.

Post Reply