From: Brian P. <bri...@tu...> - 2004-09-17 01:42:11
|
James Amendolagine wrote: > On Thu, 2004-09-16 at 13:41, Mike Houston wrote: > >>I don't think anyone is currently working on this, but the extensions >>should be easy to add if you were so inclined. You can pretty much just >>replicate the floating point versions and use the new types. >> >>The EGS stuff looks to be more tricky... > > Actually I believe it's EGL.. > > > By the way, I've just started working with Chromium (a couple of weeks > ago), and I'm very impressed. > > > So if no-one has done this before, I'll just jump in and do it myself. > > > I don't understand the internals well enough yet to have a very useful > opinion, but one of my concerns with adding the calls as extensions is > will the SPU's still work? ie will the state tracking still be valid? > > > When any of the OpenGL version of these ES calls are made: > glClearColorx > glClearDepthf > glClearDepthx > glColor4x > glDepthRangef > glDepthRangex > > I imagine that chromium records the state. I guess that I could just > replicate the state management that is being done within the associated > OpenGL Chromium call. > > so I add a call glClearColorx, and look at the origional glClearColor, > and just replicate most of the function... > > It looks like this would be done in state_tracker/state_buffer.c Would it be feasible to simply translate the glFoox functions into the corresponding conventional OpenGL functions at the dispatch layer? That is: void glClearDepthx(GLclampx value) { glClearDepth(FixedToDouble(value)); } That could be implemented in the opengl_stub/* files fairly easily, I think, without having to touch the rest of the system. I haven't looked at the ES functions closely enough to know if there's any potential pitfalls. -Brian |