search

ccgreen13 / mupen64plus

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

Goldeneye texture of glasses in FILTER_LINEAR becomes FILTER_POINT when changing weapon #314

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Describe your system:
 - Linux distribution: Win7
 - Machine type: 64-bit
 - Mupen64Plus version: 1.99.2 MSVC
 - Plugins used: RICE

For visual artifacts, give:
 - Goldeneye (E) [!]
 - MD5: CFF69B70A8AD674A0EFE5558765855C9
 - CRC: 414ca61 2e57b8aa

Look at the glass on goldeneye001Linear

I change my weapon, and for 2-3 frame there the glass is "FILTER_POINT":
goldeneye002point

In Render.cpp: SetTextureFilter:

    if( options.forceTextureFilter == FORCE_DEFAULT_FILTER )
    {
        switch(dwFilter)
        {
            case RDP_TFILTER_AVERAGE:   //?
            case RDP_TFILTER_BILERP:
                m_dwMinFilter = m_dwMagFilter = FILTER_LINEAR;
                break;
            case RDP_TFILTER_POINT:
                m_dwMinFilter = m_dwMagFilter = FILTER_LINEAR; //force linear
                break;
            default:
                break;
        }
    }
    else

And linear filter work during the weapon change!

Currently I'm there (RSP_Parser.cpp):

    if( gRDP.otherModeH != ((gfx->words.w0) & 0x0FFFFFFF) )
    {
        gRDP.otherModeH = ((gfx->words.w0) & 0x0FFFFFFF);

        uint32 dwTextFilt  =
(gRDP.otherModeH>>RSP_SETOTHERMODE_SHIFT_TEXTFILT)&0x3; //what is that???

CRender::g_pRender->SetTextureFilter(dwTextFilt<<RSP_SETOTHERMODE_SHIFT_TEXTFILT
);
    }

I don't know and understand why "dwTextFilt" seems to have a
RDP_TFILTER_POINT in it.

I've send a st0 file just behind the glass.

Is the bug exist on linux?

I suppose there is a disync between array of texture and the array of
filter.... (As usual, I say that wich luck...)

Original issue reported on code.google.com by dorian.f...@gmail.com on 14 Jan 2010 at 3:09

Attachments:

GoogleCodeExporter commented 9 years ago 
OGLRender::ApplyTextureFilter() seems to be deprecated.
Maybe because of the OGLExtRender extension.

Original comment by dorian.f...@gmail.com on 14 Jan 2010 at 5:34

GoogleCodeExporter commented 9 years ago 
Another pic very... strange...

Actually, There is only one glass wich is "Pixelized":

Original comment by dorian.f...@gmail.com on 14 Jan 2010 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago 
lol anothers with save state:
1)With gun
2)Change weapon (for mines)

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 9:41

Attachments:

GoogleCodeExporter commented 9 years ago 
I have the impression that it also depend of the angle...
I know, it's a lot of screen but if someone can have a idea from wich part of 
the
code this could happen because I can not find the problem... :(

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 9:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Interesting...

In RSP_GBI0.h

void RSP_GBI0_Tri4(Gfx *gfx)
{
[...]
            //bVisible = IsTriangleVisible(v0, v2, v1);
            bVisible = 1; //force to think all tri are visible
[...]

And now, I don't have "unfiltered texture". No prob...

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 11:55

GoogleCodeExporter commented 9 years ago 
In RenderBase.cpp

bool IsTriangleVisible(uint32 dwV0, uint32 dwV1, uint32 dwV2)
{
[...]
#ifdef ENABLE_CLIP_TRI
    //if( gRSP.bRejectVtx && (g_clipFlag[dwV0]|g_clipFlag[dwV1]|g_clipFlag[dwV2]) ) 
    //  return;
    if( g_clipFlag2[dwV0]&g_clipFlag2[dwV1]&g_clipFlag2[dwV2] )
    {
        //DebuggerAppendMsg("Clipped");
        //return false;
        return true; //force this to return true
    }
#endif
[...]

It work when I force this, I have no "unfiltered textures"...

Very stange. That would mean Renderer render textures even if there are 
considered as
invisible but not filter them?

I go back to my last code and make a test:
RSp_GBIO.h
//bVisible = IsTriangleVisible(v0, v2, v1);
bVisible = 0;

/*See picture*/

No It's ok, not perfect but ok.

So, the:
if( g_clipFlag2[dwV0]&g_clipFlag2[dwV1]&g_clipFlag2[dwV2] )
Could the prob...

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 12:07

Attachments:

GoogleCodeExporter commented 9 years ago 
    if( g_clipFlag2[dwV0]&g_clipFlag2[dwV1]&g_clipFlag2[dwV2] )
    {
        //DebuggerAppendMsg("Clipped");
        return false;
    }

If I understand well, if any of the vertex is on screenspace, it return 
(isVisible)
false? o_O

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 3:05

GoogleCodeExporter commented 9 years ago 
After tests, this prob seems to only happen when you load a save state...

Original comment by dorian.f...@gmail.com on 15 Jan 2010 at 4:35

GoogleCodeExporter commented 9 years ago 
What exactly is the problem here?  Is this a visual artifact?

Original comment by richard...@gmail.com on 19 Jan 2010 at 3:22

GoogleCodeExporter commented 9 years ago 
I've got this:
goldeneye004another.png
I change weapon and I've got this:
goldeneye005another.png
(A texture is not filtered, visual artefact).

Another:
I've got this:
goldeneye006angle.png
(Texture is filtered)
I rotate the player a little and I've got this:
goldeneye007angle.png
(The texture is not filtered, visual artefact)

I hope it can help you.

I'd try to debug it but can't. Don't know where in the code it can append.

Dorian

Original comment by dorian.f...@gmail.com on 20 Jan 2010 at 10:01