search

frozn2hu / 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

Original comment by mudl...@tpg.com.au on 6 Dec 2009 at 11:28

GoogleCodeExporter commented 8 years ago

Original comment by gon...@ngs.ru on 9 Dec 2009 at 7:15

GoogleCodeExporter commented 8 years ago 
if you specify "stipple_mode = 0" for F1 Pole Position, it will fix the text at 
the title menu and display without dither alpha.

Original comment by pokefan0...@gmail.com on 27 Jul 2010 at 4:44

GoogleCodeExporter commented 8 years ago 
Maybe should set the default to "stipple_mode = 0" and let the codes detect if 
dither alpha is required.

Original comment by pokefan0...@gmail.com on 27 Jul 2010 at 6:32

GoogleCodeExporter commented 8 years ago 
"stipple_mode = 0" just kills dither alpha emulation. Thus it must NOT be 
default.
Right solution is to find, why dithered alpha detected in wrong places.

Original comment by gon...@ngs.ru on 12 Aug 2010 at 11:56

GoogleCodeExporter commented 8 years ago 
agreed.

Original comment by pokefan0...@gmail.com on 12 Aug 2010 at 12:46

GoogleCodeExporter commented 8 years ago 
Do you emulate the fact that dither_alpha_en bit is (despite its name) 
completely unrelated to alpha dithering and only influences alpha compares? 
Alpha dithering depends only on alpha_dither_sel and should be off in these 
games since these two bits = 3 in both games.
See RDP_COMMANDS.pdf and my source code for reference.

angrylion

Original comment by spovali...@gmail.com on 13 Aug 2010 at 4:20

GoogleCodeExporter commented 8 years ago 
Yes, I did not check alpha_dither_sel bits. Thanks for the hint! However, this 
check does not fix the problem – these bits are always 0 for me. 
rgb_dither_sel bits are set to 3 indeed, but not alpha_dither_sel bits. I 
checked your source code to be sure that I read these bits right – it's the 
same. I can't understand, what's wrong and why all other othermode bits are set 
as expected, but not these.

Original comment by gon...@ngs.ru on 21 Aug 2010 at 5:22

GoogleCodeExporter commented 8 years ago 
I fancy that even with wrong alpha_dither_sel bits we shouldn't be seeing these 
artefacts as they are.
Firstly, I don't even think there can be alpha dithering in copy mode, because 
the alpha dithering circuitry is a part of the (bypassed?) CC unit according to 
the docs I have.
Now let's suppose that alpha dithering can happen in copy mode. We won't 
actually see the dithering effect then, because in copy mode alpha is only used 
for alpha compares and doesn't affect RGB values that are output. 
It's true that alpha dithering can alter results of alpha comparison for a 
given pixel. However, Ziggy's debugger shows that the texrects in question 
feature maximum alpha, and alpha dithering on the RDP can only add to combined 
alpha, not decrease it, so the chances to see pixels failing the alpha compare 
test are very low.

Original comment by spovali...@gmail.com on 21 Aug 2010 at 8:22

GoogleCodeExporter commented 8 years ago 
So, checks for alpha_dither_sel and cycle mode should be enough to avoid alpha 
dither in wrong places. I'll check it. Thanks!

Original comment by gon...@ngs.ru on 23 Aug 2010 at 6:16

GoogleCodeExporter commented 8 years ago 
I don't have the technical knowledge but based on my testing, I think you are 
going to have more wrong dithering simply checking alpha_dither_sel and cycle 
mode.

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 6:28

GoogleCodeExporter commented 8 years ago 
Please give examples that show 'wrong dithering' if we ignore dither_alpha_en 
bit for purposes of alpha dithering and/or inhibit alpha dithering in copy 
mode. I'd like to know.

Original comment by spovali...@gmail.com on 23 Aug 2010 at 8:02

GoogleCodeExporter commented 8 years ago 
@ Gonetz:
Yeah, but optimally you should also check if the current blender equation uses 
the combined alpha, because otherwise the source of alpha's entropy is lost, 
right?

Original comment by spovali...@gmail.com on 23 Aug 2010 at 9:01

GoogleCodeExporter commented 8 years ago 
I did not note down for copy mode except for F1 but I have seen many cases of 
sel bit set to 0 or 2 with cycle_mode < 2 but dither_alpha_en bit is 0.  If you 
ignore this check then many cases will be treated as dithering??

Based on my test cases, see below:
            adit    dith    rgb xalpha  cvgsel  BL  Type
Paper Mario     1   2-y 3   OFF OFF OFF 0
MarioKart 64        1   0   3   OFF OFF ON  0
Command&Conquer     1   0   3   OFF OFF ON  0
-----------------------------------------------------------------------------
Body Harvest        1   0   0-x OFF OFF ON  0
F1 Pole Position 64 1   0   3   OFF OFF OFF 2-x
            0-x 0   3   OFF OFF ON  0
Bomberman64U        1   3-x 0   ON  OFF OFF 0
ISS 2000        1   3-x 3   OFF OFF ON  0

dither_alpha_en :   rdp.adit
rgb_dither_sel  :   rdp.rgb
alpha_dither_sel:   rdp.dith
cycle_type  :   rdp.cycle_mode

I find that checking dither_alpha_en is essential and came up with the below 
check criteria:

if(rdp.adit == 1 && rdp.cycle_mode < 2 && grStippleModeExt)
{
  if (rdp.dith == 2 || rdp.rgb == 2 || (rdp.dith == 0  && rdp.rgb == 3))

Altho' I did not have a cycle_mode=1 test case, I included it nonetheless(same 
as rgb=2 which I assume same as dith=2).

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 9:57

GoogleCodeExporter commented 8 years ago 
>If you ignore this check then many cases will be treated as dithering??
Yeah, I do that in my plugin.

Although I suppose that all cases of improper alpha dithering that might arise 
are due to Glide64 not fully emulating setothermode RDP commands included in 
respective GBI commands, I'd still ask you to post a few images with visible 
improper dithering, because I can't figure from your chart where in these games 
these glitched primitives may be located.

Original comment by spovali...@gmail.com on 23 Aug 2010 at 10:15

GoogleCodeExporter commented 8 years ago 
see issue#122

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

GoogleCodeExporter commented 8 years ago 
So you posted screenshots of 4 games where you deemed alpha dithering improper, 
and my plugin shows alpha_dither_sel = 3 in all four, so no alpha dithering is 
applied. That means that Glide64 has problems with some GBI commands, because 
it's not even productive in this case to question accuracy of my RSP plugin, 
which emulates every RSP opcode and has no problems with T&L whatsoever.

Original comment by spovali...@gmail.com on 23 Aug 2010 at 11:05

Attachments:

GoogleCodeExporter commented 8 years ago 
I don't understand your statement.  I have never questioned the accuracy of 
your RSP plugin.  I was reporting bug(dithering in this case) that I found in 
those games using Glide64 - I have no access to your plugin.

I don't have any debugging tool, like you, and my basic "debugging" from my own 
simple coding tells me ISS2000, Body Harvest, F1 and Bomberman64U should not 
have the dithering it is displaying.

Paper Mario, Command&Conquer & MarioKart should have dithering unless my check 
is wrong(which I stated in issue#122 as a possibility).  If you have different 
value from mine, you are probably correct considering the fact that I do not 
know C++, window or Glide programming.

Do not take it that I am challenging your RSP plugin - that is never the case.  
What I have done serve my own purpose until a proper fix is made available for 
the games bug.  If my posts "bug" you guys that much, I will stop posting.

Thanks

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 12:02

GoogleCodeExporter commented 8 years ago 
Your MarioKart test is wrong.  It should be with the "Stars" effect and not 
"mushroom" speed boost.  The point of your Body Harvest test may not be at the 
same point as well and my sel value for ISS2000 and Bomberman64U is 3 as well 
which is the same as yours.

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

GoogleCodeExporter commented 8 years ago 
My last comment.  I created issue#122 for my dithering finding because I do not 
want to get involve in someone else post but made a mistake by posting a 
comment to Gonetz after your reply in this post.

You probably take it that I am questioning your RSP plugin and its accuracy.  
Anyway, to avoid further misunderstanding, I will stop making further 
comment/posting.

Feel free to close all my bug posts.  Thanks for your time.

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

GoogleCodeExporter commented 8 years ago 
>If my posts "bug" you guys that much, I will stop posting.
No, please continue posting. I fixed a bug in my plugin thanks to one of your 
earlier posts. Thank you for tracking bugs!

>Your MarioKart test is wrong.
Sorry. I re-tested and got the same result.

>The point of your Body Harvest test may not be at the same point as well
I don't think so, I followed your instructions and got that fade-out effect.

>Command&Conquer 
Alpha_dither_sel = 3 in my plugin.

>Paper Mario
Please provide a screenshot.

Original comment by spovali...@gmail.com on 23 Aug 2010 at 1:10

Attachments:

GoogleCodeExporter commented 8 years ago 
>You probably take it that I am questioning your RSP plugin and its accuracy. 
No, I was more referring to the fact that it's highly unlikely for a HLE plugin 
to have more correct othermodes bits than a LLE plugin.

>Anyway, to avoid further misunderstanding, I will stop making further 
comment/posting.
Seriously, please continue posting.

Command & Conquer actually has dither-like effect, but it doesn't use RDP's 
dithering facilities. It uses an animated texture. Here's a screenshot from my 
RDP plugin with alpha dithering hardcoded to be off(previous screenshots were 
taken from Ziggy's debugger, because I don't have my own graphical debugger):

Original comment by spovali...@gmail.com on 23 Aug 2010 at 1:22

Attachments:

GoogleCodeExporter commented 8 years ago 
The only reason that your value is different from mine is that my coding is 
wrong, see below:
  if (mask & 0x00000030)  // alpha_dither_sel
  {
    rdp.dith = (rdp.othermode_h & 0x00000030) >> 4;
  }

  if (mask & 0x000000C0)  // rgb_dither_sel
  {
    rdp.rgb = (rdp.othermode_h & 0x000000C0) >> 6;
  }

  if (mask & 0x00000002)  // dither_alpha_en
  {
    rdp.adit = (rdp.othermode_l & 0x00000002) >> 1;
  }

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

GoogleCodeExporter commented 8 years ago 
If my coding is wrong, then there is no need for further discussion, just 
ignore my post on dithering.  

If my coding is correct then I suggest you test using glide64 plugin instead of 
your RSP plugin to get the same dithering as mine before extracting out these 
values for comparison.

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 1:29

GoogleCodeExporter commented 8 years ago 
As per your request.

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 1:41

Attachments:

GoogleCodeExporter commented 8 years ago 
Your formulas are correct.

>The only reason that your value is different from mine is that my coding is 
wrong,

No, that's not the only possible reason. The reason, as I said, is that, being 
a HLE emulator, Glide64 doesn't properly emulate all hardware setothermodes RDP 
commands that are wrapped around by high-level GBI commands. To emulate them 
all one should reverse-engineer GBI commands from the ground up, from the level 
of RSP opcodes.

>If my coding is correct then I suggest you test using glide64 plugin instead 
of your RSP plugin to get the same dithering as mine before extracting out 
these values for comparison.

Why not the other way around? I have zero problems related to alpha-dithering, 
as far as I know. My RSP plugin was published in 2008 and you can use it with 
Ziggy's debugging plugin that was published in 2007:
http://emutalk.net/showpost.php?p=394975&postcount=354

Original comment by spovali...@gmail.com on 23 Aug 2010 at 1:44

GoogleCodeExporter commented 8 years ago 
Thanks. Could you please also upload the savestate for Paper Mario?

Original comment by spovali...@gmail.com on 23 Aug 2010 at 1:49

GoogleCodeExporter commented 8 years ago 
Can't download from your link. Can't see the 2 words to type for download.
My savestate is from 1964mod - hope you can use it.
Will upload in couple of minutes.

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 1:58

GoogleCodeExporter commented 8 years ago 
same savestate in 1964 & PJ64 format

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 2:14

Attachments:

GoogleCodeExporter commented 8 years ago 
alpha_dither_sel = 2 for me in Paper Mario.

Original comment by spovali...@gmail.com on 23 Aug 2010 at 2:26

Attachments:

GoogleCodeExporter commented 8 years ago 
I can't download from that link - give up trying.
Since you are confident that your RSP plugin is correct over HLE emu then just 
ignore my posts.
I am just happy using Glide64.

Original comment by pokefan0...@gmail.com on 23 Aug 2010 at 2:40

GoogleCodeExporter commented 8 years ago 
Download works for the rsp

Original comment by WC-Preda...@web.de on 23 Aug 2010 at 3:06

GoogleCodeExporter commented 8 years ago 
>Yeah, but optimally you should also check if the current blender equation uses 
the >combined alpha, because otherwise the source of alpha's entropy is lost, 
right?
Not an easy task for my primitive blending function. Dirty solution is to check 
all bits, which can be set to combined alpha. May be I'll find something better 
someday.

Original comment by gon...@ngs.ru on 23 Aug 2010 at 3:30

GoogleCodeExporter commented 8 years ago 
if (rdp.acmp == 3 && rdp.alpha_dither_mode != 3 && rdp.cycle_mode < 2)
{

If this serves as a condition for applying alpha dithering, that's not how the 
hardware works, rdp.acmp is irrelevant for that purpose. Sun flares in StarFox 
64's intro are a primary example.
Of course, it's fine by me if it was your decision to leave that additional 
condition:)

Original comment by spovali...@gmail.com on 23 Aug 2010 at 4:55

GoogleCodeExporter commented 8 years ago 
I would use dither_alpha_en over acmp and add additional rgb check but I don't 
see issue with Starfox.  Can you post screenshot of that Sun flares?

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

GoogleCodeExporter commented 8 years ago 
You can use whatever you want, but dither_alpha_en and alpha_compare_en have 
nothing to do with alpha ditheing. Have you read relevant sections in N64 
Programming Manual and RDP_COMMANDS.pdf?
Star Fox 64 (dither_alpha_en = alpha_compare_en = 0 here):

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

Attachments:

GoogleCodeExporter commented 8 years ago 
No - have not found N64 Programming Manual
Yes - found RDP_COMMANDS.pdf & read a bit

I have adjusted my check based on r165 and StarFox64 intro is taken care of(see 
image1-3).

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

Attachments:

GoogleCodeExporter commented 8 years ago 
How is it possible? Glide64 r164 shows acomp = 0 in debugging mode, just like 
my plugin.

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

GoogleCodeExporter commented 8 years ago 
I assume what you said is correct.
1.  LLE is correct over HLE emu
2.  your findings is correct over HLE findings
3.  based on my test cases

Based on the above, only Paper Mario & StarFox64 have valid dithering and it 
simplify matter for me(at least).  So, I code the following:

if (rdp.cycle_mode < 2 && rdp.alpha_dither_mode == 2 && (rdp.othermode_l & 
0x300) == 0x300)

I know you are going to tell me N64 doc/ hardware says this & that but assuming 
HLE emu is not capable of getting correct bits etc, then I still have to find 
the best check criteria to get the most correct result for 
dithering(irregardless of theoretical correctness).

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

GoogleCodeExporter commented 8 years ago 
The only thing I am not convinced is that Command&Conquer is plain grey instead 
of dithered pattern grey.  Unless someone care to verify on hardware.

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

GoogleCodeExporter commented 8 years ago 
>HLE emu is not capable of getting correct bits etc

That's possible, but requires a lot of work. And that's the way to go unless 
you want to create hacks for every game.

if (rdp.cycle_mode < 2 && rdp.alpha_dither_mode == 2 && (rdp.othermode_l & 
0x300) == 0x300)

Wow, you even involve cvg_dest bits in your hackery, if I'm not mistaken.
Btw, this condition doesn't include rdp.acmp, so it's not exactly "based on 
r165".

Command & Conquer 64 hardware video:
http://www.youtube.com/watch?v=GYx0A6Zzv_o

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

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
>If this serves as a condition for applying alpha dithering, that's not how the 
>hardware works, rdp.acmp is irrelevant for that purpose.
rdp.acmp == 3 means that alpha compare is true and dither_alpha_en is true.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 10:38

GoogleCodeExporter commented 8 years ago 
Yeah, I know, what I wanted to say is that alpha dithering doesn't depend on 
these bits on hardware.

Original comment by spovali...@gmail.com on 24 Aug 2010 at 10:43

GoogleCodeExporter commented 8 years ago 
For me, I will stick to the following:
if (rdp.cycle_mode < 2 && rdp.alpha_dither_mode == 2 && !(rdp.othermode_l & 

0x10) && !(rdp.othermode_l & 0x20) && !(rdp.othermode_l & 0x80) && 

(rdp.othermode_l & 0x300) == 0x300)
      {
        if (grStippleModeExt && (rdp.adit == 1 || (rdp.adit == 0 && rdp.rgb != 

3)))

So far, no wrong dithering found - found dithering in Paper Mario, StarFox64 & 
Mario Tennis.
From the video, it doesn't look like dithering to me.

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

GoogleCodeExporter commented 8 years ago 
Since I can't get correct alpha_dither_sel (rdp.alpha_dither_mode is never set 
and 0 by default), rdp.acmp == 3 is the only way for me to detect alpha dither 
usage. If I remove it, there will be no other flags to signal me about alpha 
dithering.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 11:23

GoogleCodeExporter commented 8 years ago 
>>For me, I will stick to the following:
if (rdp.cycle_mode < 2 && rdp.alpha_dither_mode == 2 && !(rdp.othermode_l &
You will just kill alpha_dither emulation - rdp.alpha_dither_mode is never set 
and set to 0 by default.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 11:27

GoogleCodeExporter commented 8 years ago 
What do you mean?
The Sun flare in StarFox64 & dithered text in Paper Mario are displayed with 
this check.
Also, the other games that are not supposed to show dithering is no longer 
showing dithering.

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

GoogleCodeExporter commented 8 years ago 
Very strange. As I said, rdp.alpha_dither_mode is not set (never saw these bits 
in setothermode_h), so condition rdp.alpha_dither_mode == 2 is always false. 
I'll check dithered text in Paper Mario, but for Super Mario 64 it's not set.

Original comment by gon...@ngs.ru on 24 Aug 2010 at 11:39

GoogleCodeExporter commented 8 years ago 
If I use your condition check then Command&Conquer, MarioKart & Body Harvest 
are supposed to have dithering but verified in LLE as no dithering.  Also, 
StarFox64 does not display the Sun flare.

Actually I don't quite understand by "rdp.alpha_dither_mode is not set" because 
I see value ranging from 0-3 when checking for dithering.

Original comment by pokefan0...@gmail.com on 24 Aug 2010 at 12:32