search

fourks / glidehqplusglitch64

Automatically exported from code.google.com/p/glidehqplusglitch64
0 stars 0 forks source link

wrong use of dither alpha in F-1 Pole Position 64/Pro Mahjong Kiwame 64 #7

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
in the menus of F-1 Pole Position 64 and title menu of Pro Mahjong Kiwame
64, dither alpha is used when it should not.

it was checked on real N64 and it works with Angrylion plugin correctly.

glide64 15/11/2009

Original issue reported on code.google.com by oliviery...@yahoo.fr on 6 Dec 2009 at 3:37

GoogleCodeExporter commented 8 years ago 
Could you tell me what's alpha-dithered in Super Mario 64?
I know that tha hair of Peach, Lakitu's cloud and the dust raised by Mario 
running are all rgb-dithered, not alpha-dithered.

>rdp.acmp == 3 is the only way for me to detect alpha dither usage

OK, but that is a coincidence and won't work for Star Fox. But you know that, 
so again, it's fine by me, I'm not going to push my idea.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 12:35

GoogleCodeExporter commented 8 years ago 
Does your LLE emu detect noise dithering(2) for rgb_dither_sel & 
alpha_dither_sel in Mario Tennis? Glide64 detect it throughout the replay after 
you win/lose a point but I could not visualize it onscreen.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 1:44

GoogleCodeExporter commented 8 years ago 
Could you provide a savestate?

Original comment by spovali...@gmail.com on 24 Aug 2010 at 1:50

GoogleCodeExporter commented 8 years ago 
see attached - I think it is the same scenario as StarFox64.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 2:38

Attachments:

GoogleCodeExporter commented 8 years ago 
Yes, I have alpha_dither_sel = rgb_dither_sel = 2 in this case.
dither_alpha_en = alpha_compare_en = 0, so the condition used in r165 will not 
work, too.
Funnily enough, dithering is applied to the whole scene by transparent texrects.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 2:55

Attachments:

GoogleCodeExporter commented 8 years ago 
True. It is not very visible unless you slow down the frame speed.  Anyway, the 
dithering effect is not very useful.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 3:05

GoogleCodeExporter commented 8 years ago 
I tested dithered text in Paper Mario. I was wrong that alpha_dither_sel bits 
are never set.
Paper Mario DO set them:
(c0:e3001a01, c1:00000020): uc0:setothermode_h: alpha dither mode: Noise
 (c0:e2001e01, c1:00000003): uc0:setothermode_l alpha compare DITHER
However,  alpha dither also used Super Mario 64 dissolve effect (see my screen 
shot), and this game sets only dither_alpha_en bit:
(c0:b9000002, c1:00000003): uc0:setothermode_l alpha compare DITHER
I don’t know, how it looks on LLE level, but HLE looks like this. The 
question is: what can I do with that? rdp.alpha_dither_mode==2 will kill 
dissolve effect in SM64 and probably will broke such effects in other games. 
Without this check alpha dither emulation is incomplete and can be used in 
wrong places.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 3:25

Attachments:

GoogleCodeExporter commented 8 years ago 
Could you attach a savestate for Super Mario 64?

Original comment by spovali...@gmail.com on 24 Aug 2010 at 3:33

GoogleCodeExporter commented 8 years ago 
Attached is 1964 save. 
Jump to hit the blue block and take the cap.
Your plugin shows alpha dither here.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 4:17

Attachments:

GoogleCodeExporter commented 8 years ago 
My test shows that there is no alpha dithering(see attached).
My condition check will prevent alpha dithering in this case.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 4:58

Attachments:

GoogleCodeExporter commented 8 years ago 
That's not the alpha dithering in play here, it's a case of alpha comparison 
with dither_alpha_en bit set. On top of normal Mario they put transparent 
triangles with alpha hardcoded to 0x80, that, due to the meaning of 
dither_alpha_en, have exactly 50% chance to blend Mario's pixels with their 
zero-value RGB pixels in 50/50 proportion (see the blender equation), hence the 
dithering-like looks.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 5:06

Attachments:

GoogleCodeExporter commented 8 years ago 
I erred in the previous statement a bit. 
They draw a normal Mario but assign 0x80 alpha to its pixels, so, due to the 
conditions explained above, pixels have exactly 50% chance to blend with the 
framebuffer.
Anyway, alpha_dither_sel = 3, so no alpha dithering, only a clever use of alpha 
compares.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 5:14

GoogleCodeExporter commented 8 years ago 
I guess my condition check is good enough for me since it has passed my test 
cases for valid & invalid dithering.
I am done with dithering.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 5:16

GoogleCodeExporter commented 8 years ago 
@Gonetz:
It would be best to split these two unrelated things: 
1. alpha dithering (affects combined alpha andhappens after alpha_cvg_select 
and cvg_times_alpha had affected it) and 
2. common/special case of alpha compares(alpha compares happen right after 
alpha dithering).
If it's impossible I'd suggest the following, which is actually quite 
inaccurate but may be enough for your purposes:

if (rdp.acmp == 3 || (rdp.alpha_dither_mode != 3 && rdp.cycle_mode < 2 && 
does_blender_use_combined_alpha()))

BUT in that case you should also make alpha_dither_sel computation consistent 
with the RSP plugin (Ziggy's debugger may help) to avoid problems with games 
like Mario Kart.

Otherwise, feel free to resort to more elaborate hacks.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 5:45

GoogleCodeExporter commented 8 years ago 
It's also not so good to keep these two effects merged, because on hardware 
they look very differently:
- dither_alpha_en (with alpha compares on) just rejects pixels at random, but 
the percentage of rejection greatly depends on the value of combined, possibly 
dithered alpha;
- alpha_dither_sel adds random values to combined alpha, which, depending on 
the blender equation, may or may not create an effect of "randomized degree of 
transparency" for a primitive.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 5:57

GoogleCodeExporter commented 8 years ago 
Do you have a link to ziggy graphics debugger?
Or is it meant for developer only.
It would be very useful if there is a download link.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 6:02

GoogleCodeExporter commented 8 years ago 
http://www.emutalk.net/showpost.php?p=380602&postcount=226

Read that thread at emutalk for usage tips.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 6:05

GoogleCodeExporter commented 8 years ago 
Thanks

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 6:10

GoogleCodeExporter commented 8 years ago 
@Gonetz:
As you understand, my condition from comment #64 will break F1 PP64/ Pro 
Mahjong K., even if you manage to fix alpha_dither_sel computation, because, 
1. although they undergo a special case of alpha compares, they will never fail 
alpha compare test, since they feature maximum alpha;
2. alpha compares are valid in copy mode.

This problem is largely unsolvable with hardware rendering, because you have to 
check individual combined alpha values before applying a per-primitive stipple 
effect. 

You actually fixed these two games in r165 by making the inaccurate condition 
for that generic 'stipple' effect inaccurate in a different way.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 6:29

GoogleCodeExporter commented 8 years ago 
*before deciding whether you should apply a per-primitive stipple effect for 
that primitive.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 6:31

GoogleCodeExporter commented 8 years ago 
Another important fact:
all differences between my plugin and Glide64 in regard to alpha_dither_sel 
bits are the same: I have 3 where Gonetz has 0.
That means that Gonetz just didn't insert setothermodes commands that turn off 
alpha dithering into GBI commands that seem to do that.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 7:22

GoogleCodeExporter commented 8 years ago 
>Anyway, alpha_dither_sel = 3, so no alpha dithering, only a clever use of 
alpha compares. 

alpha_dither_sel is 0 on your Debug Values screen shot.

Original comment by gon...@ngs.ru on 25 Aug 2010 at 3:42

GoogleCodeExporter commented 8 years ago 
To summarise:
- I have only one way to randomise pixel pipeline output: use 'stipple' 
command, which reject pixels from a polygon using random pattern.
Other hardware solutions require using of shaders, which currently is not an 
option.

With stipple I can more-less correct emulate the case:
"- dither_alpha_en (with alpha compares on) just rejects pixels at random, but 
the percentage of rejection greatly depends on the value of combined, possibly 
dithered alpha;" Example: Super Mario 64 dissolve effect looks exactly as on 
the hardware.

The second case, 
"- alpha_dither_sel adds random values to combined alpha, which, depending on 
the blender equation, may or may not create an effect of "randomized degree of 
transparency" for a primitive."
can't be correctly emulated. However, with stipple it may look better than 
without any randomising. Example: Star Fox intro.
Thus, condition "rdp.alpha_dither_mode == 2 && 
does_blender_use_combined_alpha()" may help to detect this case. 

Both conditions: "rdp.acmp == 3" and "rdp.alpha_dither_mode == 2 && 
does_blender_use_combined_alpha()" can cause incorrect use of stipple, just 
because actual use of randomising must depend on polygon's alpha and blending 
equation.
Thus, where it looks wrong, just set dither alpha emulation off in the ini 
file. I guess it's the best I can do for now.

Original comment by gon...@ngs.ru on 25 Aug 2010 at 4:40

GoogleCodeExporter commented 8 years ago 
>alpha_dither_sel is 0 on your Debug Values screen shot.

No, that's pokefan's screenshot that shows the state of Glide64. I have 3 here, 
as shown on the image attached to comment #61.

>Thus, condition "rdp.alpha_dither_mode == 2 && 
does_blender_use_combined_alpha()" may help to detect this case.

The more correct condition is
(rdp.alpha_dither_mode != 3 && rdp.cycle_mode < 2 && 
does_blender_use_combined_alpha()))

,but, if you don't want to mess with alpha_dither_sel computation, you can use
(rdp.alpha_dither_mode == 2 && rdp.cycle_mode < 2 && 
does_blender_use_combined_alpha()))

,which will work for some games.

Original comment by spovali...@gmail.com on 25 Aug 2010 at 6:04

GoogleCodeExporter commented 8 years ago 
>if you don't want to mess with alpha_dither_sel computation
Don't get it. rdp.alpha_dither_mode = (rdp.othermode_h >> 4) & 0x3; that is it 
is equal to alpha_dither_sel bits. alpha_dither_sel = 2 in case of alpha 
dither, so rdp.alpha_dither_mode == 2 is the correct condition.

Original comment by gon...@ngs.ru on 25 Aug 2010 at 6:33

GoogleCodeExporter commented 8 years ago 
Alpha dithering is perfrormed on hardware if alpha_dither_sel == 0, 1, or 2. 
Not only if it equals 2.
You're getting 0 where I have 3 in many games. So I meant, if you don't want to 
fix this discrepancy, you can use

(rdp.alpha_dither_mode == 2 && rdp.cycle_mode < 2 && 
does_blender_use_combined_alpha()))

, which will work for Paper Mario, Mario Tennis, maybe some other cases.

Original comment by spovali...@gmail.com on 25 Aug 2010 at 6:44

GoogleCodeExporter commented 8 years ago 
>Alpha dithering is perfrormed on hardware if alpha_dither_sel == 0, 1, or 2
What the difference between them then? What is the "pattern"? Just curious.

Original comment by gon...@ngs.ru on 25 Aug 2010 at 7:47

GoogleCodeExporter commented 8 years ago 
It's all explained in my source code and U.S. patent no. 5699079 assigned to 
Silicon Graphics.
'Pattern' means: add the same 3-bit value to combined alpha before 
right-shifting by 3 for blending, that (rgb_dither_sel & 1) would add to r, g, 
b.
'~Pattern' means an inverse of that value.
'Noise' means pseudo-random 3-bit value.

Original comment by spovali...@gmail.com on 25 Aug 2010 at 7:54

GoogleCodeExporter commented 8 years ago 
>However, with stipple it may look better than without any randomising. 
Example: Star Fox intro.

Actually, I think, comparing screenshots from comments #36 and #37, stipple 
effect doesn't look very correct or beautiful in Star Fox.
Maybe you can save yourself some time and just don't emulate alpha_dither_sel 
bits.
Instead, you could create an ini setting to discriminate between two cases:

1. Super Mario 64 (special alpha compares should be emulated, because combined 
alpha is much less than maximum);

2. F1 PP64, etc. (special alpha compares must be ignored, because combined 
alpha is maximum or close to it).

Original comment by spovali...@gmail.com on 25 Aug 2010 at 8:36

GoogleCodeExporter commented 8 years ago 
Even Conker has the same dithering as StarFox64 & Mario Tennis(image1-2).
Not sure why there is dithering on the logo and hand(star, maybe).

Original comment by pokefan0...@gmail.com on 25 Aug 2010 at 10:05

Attachments:

GoogleCodeExporter commented 8 years ago 
The dithering effect on StarFox64 actually looks nice onscreen rather than 
screenshoot(color blotches issue for screenshot).
The dithering on Mario Tennis and Conker is a bit weird and ugly.

Original comment by pokefan0...@gmail.com on 25 Aug 2010 at 10:10

GoogleCodeExporter commented 8 years ago 
Actually Conker dithering is quite good when running at normal speed.  
I slowed it down to frame by frame to watch the dithering which makes it look 
bad(just like screenshot).

I change my condition check to !=3 and everything is showing up correctly but I 
have yet to see a dithering effect other than 2.  Anyone of you have a test 
case, I would like to try it out.

Original comment by pokefan0...@gmail.com on 25 Aug 2010 at 10:55

GoogleCodeExporter commented 8 years ago 
The stipple mode on Conker's gleams looks awful, to the point that an observer 
is not quite sure that it's the logo gleaming, much like these 'holes in the 
star' in Star Fox.
Compare that to the proper alpha dithering in my plugin as attached.
In Mario Tennis the texrects that have alpha_dither_sel = 2 are transparent and 
blended with the framebuffer in approximately 35/220 ratio (as seen in Ziggy's 
debugger), that's why the stipple mode looks more or less acceptable.

I'd say don't bother emulating the effect of alpha_dither_sel bits by using the 
stipple mode.

Original comment by spovali...@gmail.com on 25 Aug 2010 at 11:45

Attachments:

GoogleCodeExporter commented 8 years ago 
I suppose HLE emu cannot do proper job compared to your LLE emu but it is 
always better to have something than nothing.  And it does look awful if the 
gleam comes from a solid white star, not that the dithering star looks 
better(just a different kind of sparkle).

As for StarFox64, I would rather have that dithering looks than your 
screenshot(can't make out a thing from it).  The dithering in Mario Tennis is 
hardly visible playing at normal speed(dither or not doesn't make much of a 
difference). Also, the dithering text looks awful in Paper Mario(too much black 
- doesn't have that heavenly sparkle).

Anyway, it boils down to choice & preference.  If it can be emulated in HLE 
emu, why take it out unless emulating it will ruin the whole game(I can't see 
why it would).

Original comment by pokefan0...@gmail.com on 25 Aug 2010 at 1:13

GoogleCodeExporter commented 8 years ago 
>I suppose HLE emu cannot do proper job compared to your LLE emu but

It's not an HLE problem, it's a problem of hardware rendering and Glide API, it 
can be done properly with the software rendering HLE.

>And it does look awful if the gleam comes from a solid white star, not that 
the dithering star looks better(just a different kind of sparkle).
As for StarFox64, I would rather have that dithering looks than your 
screenshot(can't make out a thing from it).  The dithering in Mario Tennis is 
hardly visible playing at normal speed(dither or not doesn't make much of a 
difference). Also, the dithering text looks awful in Paper Mario(too much black 
- doesn't have that heavenly sparkle).

Sure, you can have different tastes, but not emulating this effect looks much 
closer to the real hardware than 'emulating' it by means of the stipple mode. 
The hardware *does not* reject any pixels in these games, it just randomizes 
their transparency a bit.
By the way, the star in Conkers *is* alpha-dithered on my screenshot. What you 
called "the dithering star" is actually, so to speak, a partially rejected star.

Original comment by spovali...@gmail.com on 25 Aug 2010 at 1:54

GoogleCodeExporter commented 8 years ago 
I don't think not emulating it will make StarFox64 sunflare closer to real 
hardware(which looks horrible), it will even look better but add dithering to 
it makes it more "realistic".

I would remove Paper Mario dithering text because it looks horrible on a solid 
white bubble.  Anyway, it is Gonetz choice.

Original comment by pokefan0...@gmail.com on 25 Aug 2010 at 3:31

GoogleCodeExporter commented 8 years ago 
I think it is sufficient to check for rdp.cycle_mode=0 (no test case for 1).  
But setting 1 will get a hit in extremeg 1st screen after watching cutscene 
which is highly unlikely (same values as Starfox64) except cycle_mode=1.

Original comment by pokefan0...@gmail.com on 26 Aug 2010 at 7:36

GoogleCodeExporter commented 8 years ago 
No, Extreme-G is alpha-dithered on hardware:
http://www.youtube.com/watch?v=UxVdOQcS52A

Original comment by spovali...@gmail.com on 26 Aug 2010 at 9:46

GoogleCodeExporter commented 8 years ago 
From the video, it looks exactly as my display without dithering.  Anyway, I 
include cycle_mode=1 and tweak my condition a little.  Conker, without 
dithering, will get back its solid star sparkle(image1-2 - ignore screenshot 
color blotches).

So, Conker should be without dithering to match hardware display(same for 
extremeg).

Original comment by pokefan0...@gmail.com on 26 Aug 2010 at 11:11

Attachments:

GoogleCodeExporter commented 8 years ago 
>From the video, it looks exactly as my display without dithering. 

Of course, it doesn't look like the stipple mode used by Glide64. However, it 
looks exactly like my proper implementation of alpha dithering.

Original comment by spovali...@gmail.com on 26 Aug 2010 at 11:55

GoogleCodeExporter commented 8 years ago 
From my testing, I find that alpha dithering with acmp=0 has many different 
cases that includes ugly dithering and good ones.  XG2 intro cutscene is a good 
example and just need to filter out all these ugly dithering.  Also, I have yet 
to find any alpha dithering that is 0 or 1, maybe a good start to stay with 2 
for acmp=3 & acmp=0.

So far, it looks good for all the cases that I have tested using my own 
filtered condition checking. Can LLE really check alpha_dither_sel only without 
further filtering to determine if alpha dithering is valid or invalid for all 
test cases?

Original comment by pokefan0...@gmail.com on 26 Aug 2010 at 3:21

GoogleCodeExporter commented 8 years ago 
>Can LLE really check alpha_dither_sel only without further filtering to 
determine if alpha dithering is valid or invalid for all test cases?

Alpha dithering is applied whenever alpha_dither_sel < 3, on hardware and in my 
plugin, without further conditions. I don't think that I have errors in this 
respect.

Original comment by spovali...@gmail.com on 26 Aug 2010 at 4:16

GoogleCodeExporter commented 8 years ago 
If the ugly dithering is a by-product of stipple, then the only way is to 
filter them out from the good ones. I guess I have to stick to my filtered 
condition checking unless there is better way to apply alpha dithering using 
glide64.

Original comment by pokefan0...@gmail.com on 26 Aug 2010 at 4:27

GoogleCodeExporter commented 8 years ago 
Should be this issue closed?

Original comment by oliviery...@yahoo.fr on 6 Oct 2010 at 5:36

GoogleCodeExporter commented 8 years ago 
Well, the reposted issue is fixed, but alpha dithering emulation is not 
complete yet.

Original comment by gon...@ngs.ru on 11 Oct 2010 at 6:01