Blending polys in the TR list
-
- Insane DCEmu
- Posts: 145
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Blending polys in the TR list
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?
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?
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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.
I'll post back when my new libGL is ready to use.
Re: Blending polys in the TR list
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
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
- BlueCrab
- The Crabby Overlord
- Posts: 5652
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: Blending polys in the TR list
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.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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.
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.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
Oh also the new stuff is in the GL folder, everything outside that is stuff I haven't cleaned up yet or deleted.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
OK so here's a fun one that someone might be able to help me with:
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?
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]);
If I comment out the two matrix multiplication lines, it goes back to 0, 0, 0, 0.
Can anyone see how that's possible?
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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?
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?
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
OK there is definitely something funny about mat_trans_single3_nodiv. If I move the call to a function like this:
And call that, it works fine, however, if I inline that function:
Then the value of the contribution variable gets overwritten despite it not being involved in the call.
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);
Code: Select all
inline void transform_to_eye_space(GLfloat* point) {
_glKosMatrixLoadModelView();
mat_trans_single3_nodiv(point[0], point[1], point[2]);
}
- BlueCrab
- The Crabby Overlord
- Posts: 5652
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: Blending polys in the TR list
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...
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...
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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!
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!
- BlueCrab
- The Crabby Overlord
- Posts: 5652
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: Blending polys in the TR list
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.
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.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Blending polys in the TR list
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.
Thanks for applying the fixes, I'll update my SDK and see if it fixes things.