Blending polys in the TR list

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Blending polys in the TR list

Post by kazade » Sat May 12, 2018 2:57 pm

Hi!

I've been busy refactoring libGL in my custom fork, and I'm experiencing a blending issue which also occurred in the upstream version, and I'm not sure I understand what's happening.

Basically I have the following set of rendering steps:

1. Render a textured cube with alpha blending enabled
2. Render the cube again, untextured with additive blending (GL_ONE, GL_ONE), with a colour of 0.2, 0.2, 0.2, 0.0

On Desktop GL, this renders the textured cube with a red tint. On DC-GL I'm seeing just the red cube with no sign of the underlying textured cube.

Does the PVR not do blending between polys on the TR list?
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Sun May 13, 2018 3:01 am

OK ignore me, it's because diffuse colour should be ignored when GL_LIGHTING is enabled (unless GL_COLOR_MATERIAL is involved). I've fixed that and now everything works.

I'll post back when my new libGL is ready to use.
Kannagi
DCEmu Cool Newbie
DCEmu Cool Newbie
Posts: 15
Joined: Mon Jul 28, 2014 3:24 pm

Re: Blending polys in the TR list

Post by Kannagi » Sun May 13, 2018 10:12 am

I don't think the lib pvr has such a bug (well, from what I've seen, it correctly returns colors).
Are you sure that the error does not come from the way you configure TA_TSP_SRCALPHA and TA_TSP_DSTALPHA?

For my part I put 1 and 0 for polygon and 1 and 5 for sprites.

I did not read the second post, so much so that your problem is solved so :)
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5264
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Blending polys in the TR list

Post by BlueCrab » Sun May 13, 2018 5:55 pm

kazade wrote:
Sun May 13, 2018 3:01 am
I'll post back when my new libGL is ready to use.
By the way, if you're doing serious work on libgl and want to get it included in KOS, let me know as you get closer to being done with your work. Sadly, the libgl in KOS is without a maintainer since PH3NOM stopped working on Dreamcast stuff. :(
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Mon May 14, 2018 12:53 am

Ok cool!

In the meantime if anyone wants to test it or help me out, I'm working in the experimental branch here: https://github.com/Kazade/libgl/tree/ex ... al?files=1

Things that aren't implemented yet: multitexture, near z clipping, lighting, fog, framebuffers

Immediate mode needs some work, but glDrawElements/Arrays and texturing are working much more reliably than the original libgl and the baseline memory usage is basically nothing.

I've swapped glutSwapBuffers with a glKosSwapBuffers, and I'll working towards a clean gl.h with Kos extensions in glkos.h.
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Mon May 14, 2018 1:21 am

Oh also the new stuff is in the GL folder, everything outside that is stuff I haven't cleaned up yet or deleted.
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Mon May 14, 2018 11:39 am

OK so here's a fun one that someone might be able to help me with:

Code: Select all

            /* We ignore diffuse colour when lighting is enabled. If GL_COLOR_MATERIAL is enabled
             * then the lighting calculation should possibly take it into account */
            GLfloat contribution [] = {0.0f, 0.0f, 0.0f, 0.0f};
            GLfloat to_add [] = {0.0f, 0.0f, 0.0f, 0.0f};

            /* Transform the vertex and normal into eye-space */
            struct vec3f eye_p, N;

            _glKosMatrixLoadModelView();
            mat_trans_single3_nodiv_nomod(vertex->x, vertex->y, vertex->z, eye_p.x, eye_p.y, eye_p.z);

            _glKosMatrixLoadModelRot();
            mat_trans_normal3_nomod(normal[0], normal[1], normal[2], N.x, N.y, N.z);

            GLubyte j;
            for(j = 0; j < MAX_LIGHTS; ++j) {
                if(isLightEnabled(i)) {
                    calculateLightingContribution(j, &eye_p.x, &N.x, to_add);

                    fprintf(stderr, "- %f, %f, %f, %f\n", to_add[0], to_add[1], to_add[2], to_add[3]);

                    contribution[0] += to_add[0];
                    contribution[1] += to_add[1];
                    contribution[2] += to_add[2];
                    contribution[3] += to_add[3];
                }
            }

            fprintf(stderr, "%f, %f, %f, %f\n", contribution[0], contribution[1], contribution[2], contribution[3]);
            vertex->argb = PVR_PACK_COLOR(contribution[3], contribution[0], contribution[1], contribution[2]);
The calculateLightingContribution function does nothing except set the final array param to 0, 0, 0, 0. However, if I run this code, the first logging statement correctly logs 0,0,0,0, but "contribution" ends up set to 1, 1, 1, 1.

If I comment out the two matrix multiplication lines, it goes back to 0, 0, 0, 0.

Can anyone see how that's possible?
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Mon May 14, 2018 1:31 pm

OK so I've narrowed it down to mat_trans_single3_nodiv_nomod.

If I comment that line out, everything works as expected. If I replace it with mat_trans_single3_nodiv, or mat_trans_single3_nodivw it's still broken (contribution == 1,1,1,1) , but if I switch it with mat_trans_single4 then the contribution goes back to 0, 0, 0, 0.

Any SH4 gurus out there who can tell me what's going on here?
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Mon May 14, 2018 1:34 pm

OK the weirdness continues... I can comment out either mat_trans_single4_nodiv *OR* the call to calculateLightingContribution, and the result goes back to the correct 0,0,0,0.

:(
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Tue May 15, 2018 10:45 am

OK there is definitely something funny about mat_trans_single3_nodiv. If I move the call to a function like this:

Code: Select all

void transform_to_eye_space(GLfloat* point) {
    _glKosMatrixLoadModelView();
    mat_trans_single3_nodiv(point[0], point[1], point[2]);
}

...snip...

            GLfloat contribution [] = {0.0f, 0.0f, 0.0f, 0.0f};
            GLfloat to_add [] = {0.0f, 0.0f, 0.0f, 0.0f};

            /* Transform the vertex and normal into eye-space */
            eye_P[0] = vertex->x;
            eye_P[1] = vertex->y;
            eye_P[2] = vertex->z;

            transform_to_eye_space(eye_P);
And call that, it works fine, however, if I inline that function:

Code: Select all

inline void transform_to_eye_space(GLfloat* point) {
    _glKosMatrixLoadModelView();
    mat_trans_single3_nodiv(point[0], point[1], point[2]);
}
Then the value of the contribution variable gets overwritten despite it not being involved in the call.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5264
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Blending polys in the TR list

Post by BlueCrab » Tue May 15, 2018 10:44 pm

Ugh... I really hate to say this, but it honestly sounds like some sort of weird compiler breakage...

Effectively, what's probably happening is that contribution ends up in the fr12-fr14 registers, and GCC doesn't realize that those get overwritten by the mat_trans_single3_nodiv() macro... Now, why that is, I really can't say for sure. Perhaps that macro is doing something that is inherently not supported the way that it was intended to work by PH3NOM when he added that code...

I'm curious whether changing that to use fr0-fr2 and the assembly of the code to use fr3 and fv0 (to correspond) would fix that or not... I'm not sure why PH3NOM picked those particular registers for that code, but they're probably supposed to be call-preserved registers. If you want to try, the macro itself is in kernel/arch/dreamcast/include/dc/matrix.h about halfway down the file.

EDIT: fr12-fr15 are definitely supposed to be preserved across calls (according to the normal calling convention on SH4), so I'm gonna go ahead and say that those macros are potentially unsafe for what they're doing. That said, GCC should notice the use of those registers and handle it (i.e, save the registers), but I guess it doesn't in this case. If you try changing it to fr0-fr3 (and fv0, of course) and it works, please let me know and I'll go ahead and modify that code in KOS...
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Wed May 16, 2018 9:10 am

I'll give that a go, but FWIW I'm 90% sure it'll work because mat_trans_single4 worked and that uses fr0-fr4.

I wonder why there's such a mixture between the two sets of registers in those macros...

EDIT: I think this is the problem!

https://wiki.osdev.org/Inline_Assembly# ... sters_List
https://www.ibiblio.org/gferg/ldp/GCC-I ... html#ss5.3

mat_trans_single3_nodiv_nomod and mat_trans_single3_nodiv aren't specifying fr15 in the clobber list!
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5264
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Blending polys in the TR list

Post by BlueCrab » Wed May 16, 2018 10:13 pm

Well, yes, that is indeed a problem, which can certainly easily be fixed.

That said, I thought you also said that it was changing other parts of the variables (not just the last coordinate)? If it was only changing the last coordinate, I'd agree that that is the only problem, but you definitely said earlier that it changed all the values of contribution...

As for why the macros use different sets of registers... Only PH3NOM would probably know. If I had to guess, I'd only be able to say that maybe that's just where the values he fed into them tended to end up in the registers in libgl?

EDIT: Fixed the clobber list issues (and a few other things I noticed in there too) in changeset 832ea6.
kazade
DCEmu Freak
DCEmu Freak
Posts: 60
Joined: Tue May 02, 2017 3:11 pm

Re: Blending polys in the TR list

Post by kazade » Thu May 17, 2018 12:45 am

Yeah that's true, I can't explain why all the values got set to 1.0f, but it only happened when I tested with those two macros so I imagine it's related.

Thanks for applying the fixes, I'll update my SDK and see if it fixes things.
Post Reply