Re: ? JOGL Rendering Issues - Different for v1.1.1 and v2.0 and with Laptop docked vs not ?
Posted by
elect on
Mar 11, 2016; 3:44pm
URL: https://forum.jogamp.org/JOGL-Rendering-Issues-Different-for-v1-1-1-and-v2-0-and-with-Laptop-docked-vs-not-tp4036458p4036475.html
Z-Knight wrote
I agree that the I should move to the latest based OpenGL API, but I'm kind of stuck with this immediate mode and display list stuff because I was developing for older hardware that did not support shaders. So it would take a very large effort to now move to shaders - I'm guessing that's what you mean. I'm not trying to make excuses but I think I'd get fired if I started over right now - I couldn't justify that much redevelopment, so for now I have to continue with what I started even though we do have better hardware now. Original development was for Redhat linux 4 (I believe) and didn't have great graphics cards to handle shaders, etc.
I didn't mean to the latest one, but 2.1 or 3.3 would be infinitively better. Take in account we talk about 2008 technologies.
I can image moving would require a very large effort, but you should think about that everytime you develop on such an old version you may have to pay an overhead. All these overheads may be smaller than the large effort in the long term.
If the conditions let you do it, you could develop and test it on a side, in parallel.
Z-Knight wrote
I think for v1.1.1, it was probably JOGL, more than a specific driver that handled the clipping planes better for me - like it probably automatically took the absolute value of the far plane (because I've had negative values in there for a while). I also think it was JOGL because I was developing previously on an ATI machine and had no problems - just got a new computer in the last couple of weeks which has NVIDIA.
Then it should be as you say.
Z-Knight wrote
I'm trying to remember what I was using the GLPbuffer for - it's been a while since I looked at this part of the code - it was for a different project so not related to my images above. Basically I had a project where I was rendering to a buffer and I believe then I was retrieving the pixels from that buffer and counting how many were visible and how many were background. Using that info told me what percentage of the screen was covered so I could use that to calculate the visible area of the object. I needed to calculate a frontal area for an object that could be in different attitudes, so the best way I figured was to simply project that view in an orthographic projection and then count pixels - it worked pretty well.
Looking back at this code, I do indeed render to the GLPbuffer. And in the renderer, I do the glReadPixels() to get the pixel data. I'm not exactly sure why the GLPbuffer was or is necessary to do this, but that was my code from a while back and now I can't run it because the GLDrawableFactory.createGLPbuffer() is different, but more importantly there is no more GLDrawableFactory.createGLPbuffer() method....is there a substitute method elsewhere?
Edit: I guess I need to look at the actual docs for more info rather than simply relying on netbeans...I found this in the v2.0.2 docs, and this hence since been removed from v2.3.2, so I need to learn the new way:
createGLPbuffer(AbstractGraphicsDevice device, GLCapabilitiesImmutable capabilities, GLCapabilitiesChooser chooser, int initialWidth, int initialHeight, GLContext shareWith)
Deprecated. GLPbuffer is deprecated, use createOffscreenAutoDrawable(AbstractGraphicsDevice, GLCapabilitiesImmutable, GLCapabilitiesChooser, int, int, GLContext)
Edit #2: That was an easy update. It looked scary because of the bigger words, but it was almost a one-for-one change, like going from JOGL v1 to v2. Sweet.
If that doesn't work for you, you should create the pixel buffer/texture in your own.