I’m working on a new Camera class that maintains its own OpenGL compatible matrices. These matrices are used to do trackball rotation, screen-to-world and world-to-screen transformations, among other things. Because this class has these matrices available, it only needs to make use of a couple of JNI OpenGL methods, glMatrixMode and glLoadMatrix. This makes the JNI specific part of this Camera class very small. I considered adding this functionality to AbstractCamera but I realized that it still has to have its own JNI specific implementation, which presents me with a problem.
I would like to reuse the LWJLRenderer class but currently, it will only accommodate one type of camera, LWJGLCamera. I’ve been looking at what I would need to do to add a new type of Camera without changing existing code and it’s not pretty. It appears that I would need to create a new DisplaySystem class that can create a new type of Renderer that will accommodate the new Camera class.
A possible alternative would be to remove the LWJGLCamera restriction from LWJGLRenderer. This could be accomplished by using a Camera interface as the attribute type instead of the using the LWJGLCamera attribute in LWJGLRenderer and removing the type check from the setCamera method. This creates the potential for putting an incompatible Camera instance in the Renderer but at the moment I don’t see another way to use a different type of Camera with the existing Renderer classes, short of creating several new classes with a lot of duplicate code in them.
Is there another alternative?
Is there any way you can extend LWJGLCamera instead?
I thought about that. I would like to be able to reuse the basic code in the new Camera class with other types of renderers when they appear. I think, and correct me if I’m wrong, if I extend LWJGLCamera with the new Camera class it will be locked into that specific implementation. I would like to avoid that situation if I can.
Yeah it would be locked into LWJGL, but if you are specifically using it in a LWJGLRenderer… I see what you are saying though… you are making a camera that is not dependent on the Renderer, but you’d like to use it with the renderer… Could you make it a child of abstractcamera and then write a shell class for each renderer that would simply pass the calls to the underlying independent camera type?
If you are using JNI calls to talk to OpenGL, you have to use LWJGL or JOGL there’s no way around it. So, your new methods will have to be in either LWJGLCamera (currently) or JOGLCamera (when it exists).
However, are you only using glMatrixMode and glLoadMatrix? Is so, I can think of an abstract way to give you access to them. Perhaps you would call display.getRenderer.setMatrixMode(Renderer.PROJECTION), and so forth.
Would that do what you need to do? That would move the API specific stuff back into LWJGLRenderer.
I tried renanse’s suggestion and derived a class from LWJGLCamera and then made the new camera class a child (attribute) of the extended LWJGLCamera class. Then I overrode all the methods and used the new camera class to handle the methods. That sounds a little confusing, but it allows me to put custom functinality in a LWJGLCamera class without changing LWJGLRenderer.
Pretty cool when you think about it.
Actually, that is pretty cool. I had to remember that you are working on the editor that is somewhat external to the jME API, so your additions are happening in your own package outside com.jme. Glad to see that as an "outside user" you are able to play with core components to make them do what you want.
Heh, not my idea really, one of those "Gang of Four" patterns. Glad it worked for ya!
What’s the name of the pattern??? Let me guess…:? …is it a Decorator?
Im afraid my thought process hasn’t evolved to the point of thinking in terms of design patterns. I’m working on it though.
So many good ideas, so few neurons…
Yeah, Decorator. Hey, if you’d like to practice your patterns and you don’t already have this book, I highly suggest it:
Design Patterns Java Workbook
I do want to practice them. I’ll check it out.