You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.



#1 2011-04-09 07:57:33

xsyarch
Member
Registered: 2011-04-04
Posts: 5

Questions about the texture coordinates, in DeSmuMe.

In DeSmuMe ,RAW coding is following

static void gfx3d_glTexCoord(s32 val)
{
    // Parameter 1, Bit 0-15   S-Coordinate  (X-Coordinate in Texture Source)
    // Parameter 1, Bit 16-31  T-Coordinate (Y-Coordinate in Texture Source)
    // 16bit fixed point = 1bit sign + 11bit integer + 4bit fractional
    _s = ((val<<16)>>16);    // S-Coordinate           Most Significant Bit(MSB)16bit is 0xffff !!!!!!!!!!!!!!!!!!!!!!!!!!
    _t = (val>>16);            // T-Coordinate
                   
     
                                                                                             
Why not  the following:

    _s = (val&0xFFFF);        // S-Coordinate             Most Significant Bit(MSB) 16bit is 0x0000 !!!!!!!!!!!!!!!!!!!!!!!!
    _t = (val>>16)&0xFFFF;    // T-Coordinate

If we use this method, it would be wrong in texture maps。why?Is the Most Significant Bit(MSB)16bit Must be 0xffff ????



Question two :

    if (texCoordinateTransform == 3)
    {

        // Texcoord 16bit fixed point = 1bit sign + 11bit integer + 4bit fractional   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        // matrix     32bit fixed point = 1bit sign + 23bit integer + 12bit fractional   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

        /* =================================================   
        // Texture Coordinates Transformation Mode 3 - Vertex source
        //                                          _              _
        //                                         | m[0]  m[1]  |
          //      ( S' T' )  =  ( Vx  Vy  Vz 1.0 ) * | m[4]  m[5]  |
        //                                         | m[8]  m[9]  |
        //                                          |_S     T    _|              // it is  _S*1.0  and  _T*1.0 .
        //
        // ======================== */
                                            // 12bit frac             12bit frac           == 24bit frac
        last_s    = (s32)(( (s64)s16coord[0] * mtxCurrent[3][0]   
                        + (s64)s16coord[1] * mtxCurrent[3][4]
                        + (s64)s16coord[2] * mtxCurrent[3][8]
                        + (((s64)(_s))<<24)        //      4bit frac <<24       == 28bit frac
                        )>>24                     
                   );


1.  Is (_s<<24)  equal to "28bit fraction" ????
     Is (s16coord[0] * mtxCurrent[3][0])  equal to "24bit fraction" ????

     How to add  ?

Last edited by xsyarch (2011-04-09 10:01:24)

Offline

#2 2011-04-09 18:00:59

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Questions about the texture coordinates, in DeSmuMe.

answer one: because thats just how it is. _s should be signed. the MSB "must be 0xFFFF" only if the value is negative.

answer two: _s is a "4bit fraction" so _s<<24 is a "28bit fraction"
s16coord is a "12bit fraction". mtxCurrent is a "12bit fraction". multiplying them yields a 24-bit fraction.

yeah, youre adding a "24bit fraction" and a "28bit fraction". luckily an adder has no awareness of fractions and doesn't mind.

don't ask how to add them. that's just how it works. it is the programmer's business to choose a correct matrix. why it works this way does not necessarily make sense to you or me. it probably has to do with making sure precision doesn't get--the whole operation gets shifted up by 4 bits, and the programmer must choose a matrix which is shifted up 4 bits to match the texture coordinate.

if you think there is a bug in this code, please tell me which game to see it happen in.

Offline

#3 2011-04-12 09:39:51

xsyarch
Member
Registered: 2011-04-04
Posts: 5

Re: Questions about the texture coordinates, in DeSmuMe.

Thank you for your reply.  I learned a lot of  knowlodge from your answer,

About question two, I can't understand in some place . in follow case, every element  is 28bit fraction in result of multiple. then, that result is shift right 24bit, last_t is 4bit fraction.

Why (texCoordinateTransform == 1) and (texCoordinateTransform == 3) are different in the handing of franctional part ?


    if (texCoordinateTransform == 1)
    {
       
        //dragon quest 4 overworld will test this
        /* ========================================================   
        // Texture Coordinates Transformation Mode 1 - TexCoord source
        //                                          _              _
        //                                         | m[0]  m[1]  |
           //      ( S' T' )  =  ( S  T 1/16 1/16 ) * | m[4]  m[5]  |       
           //                                         | m[8]  m[9]  |        //   
           //                                         |_m[12] m[13]_|       
        //
        // texture scrolling, rotation, or scaling, by setting a translate, rotate, or scale matrix
         ========================================================= */   
                            //        16bit        12bit                   = 28bit
        last_s = (s32)((    (s64)(_s<<12) * mtxCurrent[3][0]                             //28bit
                        +    (s64)(_t<<12) * mtxCurrent[3][4]              //28bit
                        +    ((s64)mtxCurrent[3][8]<<12)            // 28bit
                        +    ((s64)mtxCurrent[3][12]<<12)                // 28bit
                       )>>24                                    // (28bit)-(24bit) = 4bit is frac of last_s   
                      );
        last_t = (s32)((    (s64)(_s<<12) * mtxCurrent[3][1]
                        +    (s64)(_t<<12) * mtxCurrent[3][5]
                        +    ((s64)mtxCurrent[3][9]<<12)
                        +    ((s64)mtxCurrent[3][13]<<12)
                        )>>24
                       );
        // last_s and last_t is : 32bit fixed point = 1bit sign + 27bit integer + 4bit fractional

    }
    else if(texCoordinateTransform == 0)
    {
        last_s=_s;        // 4bit frac
        last_t=_t;
    }

Offline

#4 2011-04-12 11:07:03

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Questions about the texture coordinates, in DeSmuMe.

sometimes things are just weird, man. ask the hardware designers. like i said, its probably got to do with how precision issues work out.

Offline

#5 2011-04-12 11:21:27

xsyarch
Member
Registered: 2011-04-04
Posts: 5

Re: Questions about the texture coordinates, in DeSmuMe.

zeromus wrote:

sometimes things are just weird, man. ask the hardware designers. like i said, its probably got to do with how precision issues work out.

thanks. :>  I am reading DeSmuMe SourceCode. I hope I can help for Debugging .

I wish I could do something for Supportting 3ds in DeSmuMe, But, I do not know where to find documentation about 3ds hardware spec ?

Offline

#6 2011-04-12 11:24:52

xsyarch
Member
Registered: 2011-04-04
Posts: 5

Re: Questions about the texture coordinates, in DeSmuMe.

I am Graphics Architect in a GPU Hardware corp ,so I am focus domian in graphics Hardware Emulation

Last edited by xsyarch (2011-04-12 11:34:14)

Offline

#7 2011-04-12 11:47:51

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Questions about the texture coordinates, in DeSmuMe.

desmume is not going to support 3ds. start a new emulator if that's what you are interested in--but it is way too early for that. give up the dream for a year at least.

do you know a lot about rasterization and interpolation of texture coordinates and sampling rules? some of that is incorrect in desmume and needs rewriting.

the stuff you're looking at in gfx3d.cpp is largely correct.. although anything that is floating point still needs to be reworked to fixed point.

Offline

#8 2011-04-12 13:36:17

xsyarch
Member
Registered: 2011-04-04
Posts: 5

Re: Questions about the texture coordinates, in DeSmuMe.

zeromus wrote:

desmume is not going to support 3ds. start a new emulator if that's what you are interested in--but it is way too early for that. give up the dream for a year at least.

do you know a lot about rasterization and interpolation of texture coordinates and sampling rules? some of that is incorrect in desmume and needs rewriting.

the stuff you're looking at in gfx3d.cpp is largely correct.. although anything that is floating point still needs to be reworked to fixed point.

Yes, My job is about maintain graphics pipeline arch. please give me some game's name to test wrong behavior of rast & interpolation when DeSmuMe are using SoftRasterizor.

Offline

#9 2011-04-12 19:55:01

zeromus
Radical Ninja
Registered: 2009-01-05
Posts: 6,169

Re: Questions about the texture coordinates, in DeSmuMe.

you need to spot those on your own. but ill start listing them as i see them. i guess i'll also start saying some things that need to be fixed.

in general, i think that the shapes are drawn with integer screen coordinates (but i think colors and texcoords are interpolated correctly while screen coordinates are truncated). there is a special case for "1-dot polygons" (search for DISP_1DOT_DEPTH in gbatek). that needs to be done in gfx3d, as 1-dot polys rejected by this don't even go into the polygon list. however, I think that the fractional screen coordinates are not thrown away. they are saved for coverage factors which are used by interpolation. so the 1-dot polygon test is int(x) == int(y) == int(z) where the fractional parts move further into the pipeline.

but, none of the above can happen until more of gfx3d turns into fixed point.

we also need to fix the rasterizer to be able to produce lines. the rasterizer has bad characteristics right now when it comes to thin things (thin triangles may render a little gappy, even). I am pretty sure that the nds rasterizer must use a very simple, discrete, and robust line stepper algorithm. One test of how robust it is: it must just use two of them identically for the left and right edges of polygons, and when they happen to be the same, a pretty line is the result.

remember, this is very old style 3d hardware. like, dark ages. advanced techniques are not likely to be used, and so won't be necessary to get things "exact"--exactness will come from correctly emulating the primitive techniques.

if you really want to help, then you need to use irc to communicate.

Offline

#10 2011-09-13 20:31:49

Exophase
Member
Registered: 2011-09-13
Posts: 1

Re: Questions about the texture coordinates, in DeSmuMe.

I'm very late to this thread, but hopefully this is useful:

1) Fractional data for X/Y is not stored in any capacity that I can see. The screen-space coordinates are truncated (not rounded) and the fractional part doesn't even contribute to the coverage masks. This probably makes coverage calculation simpler, since you can't have the slopes changing in the middle of a pixel.
2) I don't think that the line drawing behavior is an artifact of the rasterizer but done by a dedicated line engine (like on PS1) that's activated when there are only two distinct vertexes. Line drawing wouldn't come out of zero-area polygons if you want adjacent edges to line up correctly. If you try drawing a long, thin triangle you will see that it vanishes before it actually hits the tip. This would also mean dots are special-cased, and would normally not be drawn.. hence why they added that depth limiter.

One of these days in the hopefully not too distant future I hope to get back to reversing this stuff >_> And then I guess if I have anything useful to say I'll drop by IRC.

Offline

Board footer

Powered by FluxBB