At this time, is it possible to create a AWT frame or something similar from a SFML window? That could solve it for me.Code for that already exists, but is not checked in at this point. I should make it a branch really... It's supposed to be added in a future JSFML version.
Code for that already exists, but is not checked in at this point. I should make it a branch really... It's supposed to be added in a future JSFML version.
Wouldn't it be possible to take like the HWND or something like that from the Java Frame and create an SFML Window from that?
Exception in thread "Thread-0" java.lang.UnsatisfiedLinkError: Native Library C:\Program Files\Java\jdk1.7.0_07\jre\bin\awt.dll already loaded in another classloader
By the way, you do not have to do the rendering in an extra thread, you can use a main loop in the main thread without problems. All AWT / Swing events are handled in the separate "AWT Thread" already, so it won't freeze. You just have to deal with AWT events (e.g. button presses) asynchronously. A concurrent list to queue such events to be processed could be of help here.
Ah no I mean the game graphics are done in another thread. So I want the thread to be able to directly render to the render canvas so I don't have to deal with the context activations problems that SFML has. So the game library itself will not be aware that it is using a render canvas, it thinks it is only working with a render target while the tools application which generates the actual runnable code will be the one handling the AWT interface ;)But if you use a "classical" main loop, you can render to the canvas like to any other render target with no trouble at all. You can use it like a normal RenderWindow, AWT will not interfere and run happily in its own thread.
some ugly thing with timersWell, that actually is the Java way to do it. You would create another thread that loops. It always sleeps for a certain interval and then does whatever timed action you want. Abusing validation and painting for this is not even nice in C#. :P
I did experiment with LWJGL a little in the past. LWJGL is much better known than JOGL in the independent scene. It was clearly made with game development in mind, but it's a fully functional OpenGL, OpenAL and OpenCL binding for Java. JOGL is rather used in professional applications, I believe.
In any event, I'd like both LWJGL and JOGL to work with JSFML so you can do custom rendering.
I'd be extremely happy if JOGL and LWJGL were supported. :)The best way of getting some help from JogAmp maintainers doesn't consist in disparaging any JogAmp API. JogAmp contains fully functional Java bindings for OpenGL, OpenGL-ES, OpenAL (it supports OpenAL-Soft too), OpenCL (both in desktop and mobile environments, under Android too). JogAmp is used both in games (the MMORPG Salem, Poxnora, ...) and in other kinds of applications. Most major middle and high level APIs for 2D & 3D rendering support JogAmp. In my humble opinion, promoting our main competitor when someone simply asks for help isn't very professional and ethically incorrect.