i'd like to test jME for my further developments. currently i'm fiddeling with jogl, waiting for lwjgl to get ready on the mac. and before i start to develop a complete scene-graph myself i'll check what you guys did already.

monkey says it runs on mac os x out of cvs - it does not for me :-/

running ant gives me this (and a lot more):

[javac] jme/src/com/jme/util/geom/GeometryInfo.java:249: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier [javac] assert (pg.length == 1);

assert is java 1.5 (right?). currently i am not working on tiger/tiger but still on panther/1.4. (10.3.6)

monkey, how do you compile the stuff from the cvs?

here's my root::pserver:atze@cvs.dev.java.net:/cvsrepository is jme.is there another cvs i should use?

Exception in thread "main" java.lang.Error: Do not use javax.swing.JFrame.add() use javax.swing.JFrame.getContentPane().add() instead at javax.swing.JFrame.createRootPaneException(JFrame.java:465) at javax.swing.JFrame.addImpl(JFrame.java:491) at java.awt.Container.add(Container.java:307) at TileDemo.execute(TileDemo.java:37) at TileDemo.main(TileDemo.java:22)

hm.. i don't create a window. here's a rip-off of my contructor-code. please keep in mind that i am working with my modified fullscreen-version of jogl.the Bounds-class just holds four values: x,y,width,height.canvas.addGLEventListener(this) is done to get the various callbacks, like public void init(GLDrawable aDrawable) and public void display(GLDrawable aDrawable)

Raw bindings to the 'C' openGL APIs shoudl be done once, in one library/class. Never to be done again accept to add bindings to new OpenGL APIs and features.

yes, that's exactly what i'm looking for!

Quote

... the requirements to support subsets of OpenGL for certain platforms

just implement the base standard as an interface. then add the platform/hardware specific methods in a concrete implementation. make that implementation a public class, so that the programmer can decide to stick to the interface (runs on all platforms) or use the native machine-dependent class explicitly (read: has to cast to platform-dependent class) where available.and there still is GLboolean glIsEnabled(GLenum capability) to avoid falling into a pit.

so is anyone able to come up with such an interface and do an implementation-skeleton that we could just flesh out on the different platforms?and maybe the interface could have an identifier (String/array) that could tell the programmer what platform-specific extensions are available?

on top of that you could then put any awt/swing/swt/fullscreen/offscreen/... implementation you like.

anyway, my problem with any unreachable (read 'private to the framework' stuff (context in jogl) is that i always and in every system i've used i had to break the lock after i understood the system. otherwise i'd be forced to find another system to work with.

so either i can drill down to a usable context whenever i need it in jogl (try to unload a texture in the draw-method if the object holding the texture is already gc'ed sometime before the draw-call), or i have to find a system that suits my needs better.

i'm currently checking lwjgl. i finaly managed to compile it but i can not get any demo to run. that leaves a bad taste and i have no time to dig deeper into the system.

you can not differenciate a system by saying that it's for game-programmers or for a 'professional'. the difference is only if it is an open or a closed system. closed systems are of no use for anyone than a beginner. such systems are toys (no offense) to play around but not to get the work done the way you want it. (why is elementData in Vector protected? why is String final? there are things in java that i don't like either)

what i need is a clean opengl-binding with no additional restrictions that i don't have if i'd use C instead of java. <sarcastic>and if multithreading seems to be a problem to some then don't use awt or whatever might get in your way. or just learn the concepts of multithreading and build the restrictions you want yourself.</sarcastic>

i open this thread to introduce a possible solution i'd like to see as a standard. this discussion is about the layer structure and the naming conventions in the different layers. my ideas might lead to a concept that is to far away from the current jogl design. if that should be the case please point me to another forum where such a structure could be discussed and set up.

the presented structure is not complete. it is a discussion-base.

i recommend an api layered in the following fashion, from bottom to top:

OpenGLContext public staticOpenGLContextcurrentContext(); public staticvoidclearCurrentContext(); public voidmakeCurrentContext(); public voidflushBuffer(); public OpenGLDrawabledrawable(); public voidclearDrawable(); public voidupdate(); ...

OpenGLCServer and OpenGLServer are identical in functionality, they only differ in syntax.this specification would solve the following - already discussed - problems:

a) porting low-level opengl from c to javaOpenGLCServer wraps the underlying c-functions of OpenGL keeping the c-naming convention. this is a convenience class for c-programmers and other people wanting/having to stick to the c-naming scheme.

b) make opengl a good java citizenOpenGLServer wraps the server by using method overloading. java programmers should use this interface for any new programs. this should be the recommended way to interface opengl with java. therefore it is not explicitly called OpenGLJavaServer.

c) automatic removal of unneeded pre- and postfixes with java 1.5a static import of OpenGL(C)Server will remove the need to write

1 2

OpenGLCServer.glVertex3i(0,0,0); orOpenGLServer.vertex(0,0,0);

and instead allow

1 2

glVertex3i(0,0,0); orvertex(0,0,0);

d) partial independency of window-systemFullscreenOpenGLDrawable and OffscreenOpenGLDrawable should be independent of the underlying window-system (awt/swing/...). this opens the possibility of building apps that do not need to know anything about it.

e) exposure of the opengl contextthe programmer is able to talk to the context whenever needed, not only in the draw-method. this allows for uploading/destroying textures, generating display-list, ... at a choosen time.

caveatsthe server-methods are kept static because opengl is a state-machine. the client itself has limited knowledge about the current active context. the programmer has to ensure that drawing is done to the right (current) context (or that the right context is current).this becomes an issue when awt and swing are used.the OpenGLContext has to be exposed to the programmer. otherwise the access to opengl would be to restrictive. the threading issues have to be adressed either by the programmer or by the awt/swing/... based classes.

OpenGLDrawables distinguish between the choosen output-path.OpenGLContext is pretty near to NSOpenGLContext from apple.input (keyboard, mouse) is not considered here.

gerard was not there. he got a baby two days before instead, kenneth took his part. he showed mainly a port of quake 2 (jake2) running on jogl. so there was nothing special about jogl itself. it was more about java and graphics in general and how to optimize the code by using shark and opengl profiler. and that the implementation was faster than before and that threading works better now. many poarts are true for DP3 already, so get it and try it. the exact contents are under non-disclosure anyway and you won't get lots of better information.but i was happy to be there to get the difference between view-based and fullscreen contexts over to kenneth, so we might see some improvement at that in the future.

i did a quick test with the new Java JDK 1.4.2 Developers Preview 3 (available since WWDC) and fullscreen now works out of the box on mac os x - but it is not a fullscreen NSOpenGLContext, it still renders into a view.

to get the best performance we still need a modification of MacOSXWindowSystemInterface.m to switch the NSOpenGLContext to fullscreen instead of using a view.i am pretty sure that the DP3 view-based context does not swap buffers, but instead does a bit-blit to the screen - and that's definitely slower.

Quote

Mouse events will not get propageted correctly (dead mouse)

this is due to the missing window/view that you can not ask for movements. i worked around this in my objc-app by using NSApps currentEvent. here's a sample to catch mouse movements:

yes, this breaks the normal behavior, but we are going to write FAST games, right?if somebody knows a better way for this please tell me.

Quote

Swing components with AquaL&F will not work.

ok, let's just accept that as a fullscreen-limitation. what i understood about jogl is that it's an open-gl implementation for java, not a way to render swing on top of open-gl. if i go fullscreen i don't need any swing/awt components. i just want to draw open-gl on the screen. maybe that's just my understanding of fullscreen apps.

another possibility would be to add a new 'true' fullscreen mode in jogl, to circumvent the whole awt and swing stuff like this*:GL context = GLDrawableFactory.getFactory().createGLFullscreenContext(GraphicsDevice, GLCapabilities);*this comes right from my head, not tested, no deeper thoughts done, so don't scream 'hack' again.and while we're at it let's add a context.syncToVerticalBlank(boolean).

my code is not a hack and it is unfortunately not rendered useless with the modifications in DP3. it uses NSOpenGLContext as it was intended for fullscreen and brings the highest available performance to jogl on mac os x. let's work together to bring that speed to jogl.

here is the fix to get a fullscreen context under mac os x!this is an almost clean solution. the only dirty part is that i don't know for sure if you really want to be fullscreen. the decision is made on the size of the window that wants the context:if the window is exactly the size of the current screens resolution, a fullscreen context is generated, otherwise a view-based context is built.

the stupid questions of a newbie... when i hit the submit-button i found the answer:i have to keep the canvas and just call display() on it after a tick() and everything works as i want - with the exception of uploading textures.

so the one question still is unanswered:any way of talking to the context outside of display() to do some modifications to it?

hi there,i have that same very problem. i need to control the drawing outside an animator, as i animate the objects by myself. not to mention that i upload textures when i need them - which is definitely not inside of display() or init().

i call tick() on all my objects, then draw() and finally i issue a glFlush() when i think my gl-calls are complete.this is impossible with the current structure (as far as i can see).

is there any hook to get to that context and call a makeCurrent() or something equal when i need it?or can i halt the gl-thread until i signaled all my objects to tick() and then have that thread display() once?or - the best solution - can i just _not_ detach a new thread for gl and keep all the calls in my own thread?

jogl looks like what i need, but this is a heavy drawback for me, as i can not rewrite all my code. i know that one should not fight the api but use it.any ideas welcome!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org