Mickey Mania emulator comparison
Moderator: BigEvilCorporation
Mickey Mania emulator comparison
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?
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?
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
only problem is that my camera died and its in repair... otherwise I could play that far and take a pic or two...
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
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.
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.
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:
- 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 */
Thank you for your infos Eke but i don't understand the implementation in genesis plus.
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]
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;
what is the relation between sprite masking 2 and sol_flag?
[/code]
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 instead of , I really don't know but in the previous code, one of the test is unnecessary (xpos == 0 is always true)
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
Code: Select all
xpos != 0
Last edited by Eke on Tue Mar 24, 2009 4:08 pm, edited 2 times in total.
Equivalent code from Regen:
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.
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;
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.
Yes, but according to the docs, if mode two is also enabled then mode 1 becomes invalid.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.