Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (206)
games submitted by our members
Games in WIP (781)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JOGL Development / Re: loading texture from 2 different threads on: 2006-02-16 19:34:39
So, you want to use Textures loaded/bound for one GL context in a different context, is this correct?
2  Java Game APIs & Engines / JOGL Development / Re: Threading options for JOGL on: 2006-02-11 01:43:51
If I had to guess I would assume that the idea is to keep all rendering in one thread since multiple widgets (and some of them even overlaping) can be using GL and thus you are no longer locking GL processing in one thread and this wa problematic. But that's if I had to guess, and I don't since there are people here who can just answer your quest Wink
3  Java Game APIs & Engines / JOGL Development / Re: Threading options for JOGL on: 2006-02-10 18:36:46
Thank you as always. I understand your recommendation and will follow it, at least until I have better undrstanding of OpenGL in general and JOGL in particular.
However I would still like to continue researching threading with respect to OpenGL in general and JOGL in particular. What do you think would be the best approach for me to get more details on GLContext and the stability problems you are talking about (and maybe some articles about implementation on different platforms and threading)?
4  Java Game APIs & Engines / JOGL Development / Re: Threading options for JOGL on: 2006-02-08 20:10:36
Thank you for the reply. This is probably my personal witchhunt and may be not worth-while but I would really like to stay out of AWT thread for several reasons.
1) Additional synchronization requirements. These are probably not hard to do but I have had some issues with Java synchronization, especially with fast paced environments (mostly when lock was not available long enough for different thread to grab it). These are all resolvable (and pretty easily) but I still would like to review my options...
2) Scene rendering is a heavy procedure. I am a lausy programmer. I want to make sure that when I mess something up AWT still works and I can at least close the window.
3) Not sure 3 is needed since it's very close to 1 and 2 but when you lock AWT on something that happens in another thread it can create a pretty sluggish and unresponsive environment if AWT components (buttons, labels, etc.) are used.

Said all that, I agree that option 2 is probably not the best one (or rather I realize that now, thanks for explanation). However your metioning GLContext.makeCurrent() made me currious. Is this any different from good old setRenderingThread? Is there documentation on this API beyond Javadoc? It looks like this would be the best bet but I would really like to get more information.
Again, thank you for the reply, I will look into your suggestions.
5  Java Game APIs & Engines / JOGL Development / Threading options for JOGL on: 2006-02-07 18:05:32
I know this is not a new question and I did look through information I could find but this is still confusing. I would like to understand my options when it comes to thread management for JOGL.
Here are my options as I understand them so far:
1) AWT mode. Basically, standard AWT event-based rendering model, where when some parameters of the model change I call .repaint and AWT thread calls .display. In this model I can still call .display as blocking, which detects that we are in a wrong thread and basically does an alternative or .repaint();.wait() and when display called from AWT (see above) finishes it sends a notify() to current thread. Or maybe this is not how it works but this is the basic effect.
Easy enough...
2) I can call Threading.disableSingleThreading() which... I am not really sure what it will do. Does it allow me to call GL instructions from my thread AND from AWT thread? In that case, if I do not add any listeners to the GLCanvas, am I safe putting my main loop in the current thread? Are there details on this mode anywhere?
3) I can call Threading.invokeOnOpenGLThread(Runnable r). I am not sure what this does though. Will it call r only once (sort of like invokeLater())? It seems that by default (or in the current implementation) it is dropped into AWT thread so if I put my main loop there I will effectively lock rest of AWT. Would this be a correct assessment?

These are the options I see so far. Are these correct? What I want to do is the main loop as described in the User's Guide. The problem with having main loop in one thread and invoking GLCanvas.display in it is that this is not the only way to initiate repaint and I am not sure what other conditions I need to cover (window gets focus, window is resized, another window moves so that this window is now visible, etc.). I want to make sure my rending does not start while I am updating the scene. Is N2 my only/best option?
6  Java Game APIs & Engines / JOGL Development / Re: how to get the center of a model and rotate from there? on: 2005-06-24 16:22:27
Why do you like that gluLookAt so much? Just do this:
   gl.glPushMatrix();//I use these assuming you may later on have other transformationf before /after; if you just use LoadIdentity after you are done with rotations.
   gl.glTranslatef(-cent.x, -cent.y, -cent.z); //I am pretty sure you need to use reverse transformation; if it makes matters worse use direct ones Wink
   gl.glRotate3d(angle.a, angle.b, angle.g);//or whatever format you have
   //render your model here

Should work... IMO Smiley
7  Java Game APIs & Engines / JOGL Development / Re: loading maya models on: 2005-06-24 16:13:56
Actually, IMO the question is inherently wrong. JOGL ports only low level GL (well and some surrounding stuff like GLUT & Co). Thus a "model loader for JOGL" is an oxymoron. JOGL does not support models. What you could find is OBJ format loader that will just pull OBJ in memory and let you process it like any other data structure (DOM or B-Tree).
A quick Google for "3D obj loader java" gave for instance link. If it does not work for you try Googling with more keywords Smiley.

Another way is to write your exporter plug-in for Maya. Maya comes with example exporter so you could probably modify that one to export into your format (that is if you have Maya Unlimited, I don't think other versions come with SDK).
8  Java Game APIs & Engines / JOGL Development / Re: "Error making context current" error on Linux on: 2005-06-23 16:35:32
 Embarrassed Sorry, you are right.
9  Java Game APIs & Engines / JOGL Development / Re: Do s and Don't s? on: 2005-06-23 14:47:57
I actually already did give you a tip about profilers Smiley. I should have been clearer though. Check out and loog for -Xrunhprof. This is an option you can specify in Sun's JVM to ask it to spit out provfiling information. Second option- use Google Smiley. BTW, Google is one of the foremost tools in modern software development Smiley. I found following link after the first attempt
Good luck!
As for GLUT, just make sure you are not generating millions of polygons by one of those calls. I don't think your implementation of disks and cylinders will be faster, at least not at the moment.
10  Java Game APIs & Engines / JOGL Development / "Error making context current" error on Linux on: 2005-06-22 22:49:50
I get "Error making context current" error when I try to run my test (very simple program) under Linux. Actually, I *used* to get this error until I rebuilt JOGL locally.
Here is the stack:
Exception in thread "main" Error making context current
        at java.awt.Component.setBounds(
I *assume* (and please do correct me if I am wrong) that the root of the problem is in some incompatibilities in OpenGL implementation of GLX by NVidia and whatever is used to build standard linux binary distributive. I saw this error come up several times in this thread and always with no answer. If anybody is interested in trying to debug this problem, let me know (I will do some experimenting myself but all machines I have access too have NVidia).
/*   Java->C glue code:
 *   Java package:
 *    Java method: boolean glXMakeCurrent(long dpy, long drawable, long ctx)
 *     C function: Bool glXMakeCurrent(Display *  dpy, XID drawable, GLXContext ctx);
Java_net_java_games_jogl_impl_x11_GLX_glXMakeCurrent(JNIEnv *env, jclass _unused, jlong dpy, jlong drawable, jlong ctx) {
  Bool _res;
  _res = glXMakeCurrent((Display *) (intptr_t) dpy, (XID) (intptr_t) drawable, (GLXContext) (intptr_t) ctx);
  return _res;
11  Java Game APIs & Engines / JOGL Development / Re: Understanding rotation on: 2005-06-22 22:15:38
You had different requirements, you needed gun to stay aligned vertically while turning at you. It all depends on the task at hand, and original question was about a rotation that would align the two verctors and this question was answered perfectly, IMO.
One note: make sure to check that vectors are not aligned in which case you will get 0 vector as a cross product and it will screw up your picture.
Use Ken's suggestion, unless you know why you can't (additional requirements you have not metioned).
12  Java Game APIs & Engines / JOGL Development / Re: Do s and Don't s? on: 2005-06-22 19:41:15
A generic piece of advice - it may not help but you still to do this nontheless. Run your program through a profiler. At the very least run it with -Xrunhprof. You will see right away what calls take most time and other nice stuff like that.
Another piece of advice. Don't post jar files to run and never run files that you got online from untrusted source. Put source out- 1) people might actually have tips on optimization 2) much less chance that the program will format your drive.
Rest depends on the platform and features that your card supports (if you are using something that it does not suport and GL has to perform software rendering it is going to take forever).
BTW, I don't think Animator is doing much; it is just a thread that calls display() and swapBuffers() in the loop. For performance optimization you might want to ditch GLU (cylinders, disks, etc.) and use pure OGL. If you want to stick with GLU, make sure your tesselation (however it is spelled) is not set to too detailes level (one sphere could produce hundreds of thousands of polygons).
Here... Hope it helps  Smiley
Pages: [1]
Galdo (200 views)
2017-01-12 13:44:09

Archive (369 views)
2017-01-02 05:31:41

0AndrewShepherd0 (827 views)
2016-12-16 03:58:39

0AndrewShepherd0 (762 views)
2016-12-15 21:50:57

Lunch (901 views)
2016-12-06 16:01:40

ral0r2 (1129 views)
2016-11-23 16:08:26

ClaasJG (1232 views)
2016-11-10 17:36:32

CoffeeChemist (1281 views)
2016-11-05 00:46:53

jay4842 (1364 views)
2016-11-01 19:04:52

theagentd (1190 views)
2016-10-24 17:51:53
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!