I'm working on the last major piece in my new GL implementation which is near-Z clipping, and I could use a bit more understanding about perspective division, and the Dreamcast coordinate system. I'm looking at the coordinates generated by libGL after perspective division. What I'd expect is that th...

Yeah that's what I meant

BlueCrab, is it theoretically possible to render to any power-of-two texture size with the PVR (if KOS was extended to support it)? Or is it a limitation of the hardware that it must render at the screen resolution (to a texture at the next power-of-two)

Presumably they simply render the player model once per light to a texture then render an additional pass of the scene with that texture bound. The one thing that puzzles me though is the resolution. The KOS docs say this: "This function currently only supports outputting at the same size as th...

I had no idea the Dreamcast had an accumulation buffer! Nice!

In my OpenGL implementation I instinctively enabled these flags when blending was enabled, but this caused lxdream to start complaining about something being unsupported. Then I realised that libgl doesn't set these flags and blending works fine without enabling them (leaving them zeroed) and that s...

Hi everyone! Over the last few months I've been maintaining a custom fork of libGL, but a few weeks ago I hit a corruption bug that I couldn't solve and decided to essentially tear the whole thing apart and put it back together again :grin: So, now it's *mostly* back together and it lives here: http...

Hi everyone! Over the last few months I've been maintaining a custom fork of libGL, but a few weeks ago I hit a corruption bug that I couldn't solve and decided to essentially tear the whole thing apart and put it back together again :grin: So, now it's *mostly* back together and it lives here: http...

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.

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#Clobbered_Registers_List ht...

OK there is definitely something funny about mat_trans_single3_nodiv. If I move the call to a function like this: 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...

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.

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 contribut...

OK so here's a fun one that someone might be able to help me with: /* 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....

Oh also the new stuff is in the GL folder, everything outside that is stuff I haven't cleaned up yet or deleted.

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/experimental?files=1 Things that aren't implemented yet: multitexture, near z clipping, lighting, fog, framebuffers Immediate mode needs some work, bu...

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.

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. R...

For some reason I can't get any of the mat_trans functions to affect the output... vout.x = (float) *(ptr++); vout.y = (float) *(ptr++); vout.z = (float) (VERTEX_POINTER.size > 2) ? *(ptr++) : 0; mat_load(&MODELVIEW_STACK.top().m); mat_trans_single3_nodiv(vout.x, vout.y, vout.z); printf("%f...

Great minds think alike! https://hub.docker.com/r/kazade/dreamcast-sdk/

Awesome work, building with Docker is definitely the way to go, it makes life so much easier!

Yep it was down to the auto-sorting. I've disabled that now in my libGL fork so that the behaviour is more like traditional OpenGL.