Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
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: Picking issues on OSX? on: 2004-03-12 07:16:25
I do not really know, how to solve the problem using direct buffers. When I had the same problem, I had to created a pure java solution making all the necessary geometry calculations for hit checking myself.

I looked up the bug report:

I suspect, that the C-Code quoted in the Bug report must be modified to extract the backing array of a direct buffer. glVertexPointer, which should run into the same problem, uses a Buffer as parameter. The code can probably adapted for glSelectBuffer.
2  Java Game APIs & Engines / JOGL Development / Re: Surface alrea on: 2004-03-07 15:11:50
This is probably no Multithreading issue.

You have created a modal dialog from the display method of your canvas. The event dispatching thread enters a modal event loop and the modal event loop finally calls display from within display. This will not work.

You can either create a non-modal dialog or call show from outside display.

The callstack you posted looks like the dialog is not created from the mouse event but from the repaint event triggered by the mouse event. You should generally avoid creating modal (in fact any) dialogs from repaint events. Try to create the dialog directly from the mouse event. You can also create a seperate event to show your dialog via SwingUtilities.invokeLater.
3  Java Game APIs & Engines / JOGL Development / Re: Picking issues on OSX? on: 2004-03-07 14:53:28
> Is anyone aware of picking issues on a Mac, either in JOGL or underlying code?

When I tried to use the selection buffer on mac os x, my program started to produce random results and even crashed sometimes with segementation violations.

I found out, that the problems were much more likely, if many objects were allocated or garbace collected during the picking. My guess is, that the VM moves the location of the selection buffer in memory after it was registered with jogl. There is an issue filed in the bugtracking system, stating that an nio direct buffer should be used, but I can't remember, where I found it.
4  Java Game APIs & Engines / JOGL Development / Fullscreen Antialiasing? on: 2004-03-03 00:48:52

does anyone know whether fullscreen antialiasing (fsaa) can be used with jogl? I have looked at a tutorial at NeHe, but the code is very Windows specific and involves some special context creation.

I know that I could use the accumulation buffer and draw my scene mutliple times, but my application is geometry limited (it uses no textures at all) and would loose most of its performance.

What I really want is that OpenGL renders at a much higher resolution than necessary and then sampling the image down to match the output.
5  Java Game APIs & Engines / JOGL Development / Re: synchronising with a physics thread on: 2003-12-15 23:48:45
If you are drawing the same scene, that your physic engine is simulating, you will probably need to lock the entire scene for each of the tasks. So there is no point in using Threads at all.

I would suggest using the display loop as a basis.

Save the start time of your application and plan a physical simulation step every 30 (or so) msec. Before drawing each frame, read the current time and do all outstanding physical simulation steps before drawing.

I cannot get the description right, so I'll try an Example:

Loop iteration 4:
Total elapsed time: 100
Simulation steps so far: 1
Outstanding steps: 2 (no. 2 (at 60 msec) and no. 3 (at 90 msec))
-> Do 2 steps, then paint.

loop iteration 5:
Total elapsed time: 110
Simulation steps so far: 3
Oustanding steps: none
-> paint

This solution can never run into any race condition and (sometimes important) the physical simulation is completely independent from the speed of the machine. Only the frame rate drops.
6  Java Game APIs & Engines / JOGL Development / Re: Simple BufferedImage question, should be easy on: 2003-12-15 23:20:21
The conversion of any (preloaded) type of image, transparent or not, can be really easy, if you just draw it onto a BufferedImage that already has the correct format. This conversion could be somewhat slow (don't know), but textures are often created in advance, when speed is not yet an issue.

public static byte[] awtToGL(Image image) {
 int width = image.getWidth(null);
 int height = image.getHeight(null);
 BufferedImage converter = new BufferedImage(width, height,

 Graphics2D drawer = converter.createGraphics();

 drawer.drawImage(image, 0, 0, null);

 int[] ints = converter.getRGB(0, 0, width, height, null, 0,
 byte[] bytes = new byte[width * height * 4];
 for (int i = 0, j = 0; i < ints.length;) {
   int color = ints[i++];
   bytes[j++] = (byte) ((color & 0x00FF0000) >> 16);
   bytes[j++] = (byte) ((color & 0x0000FF00) >> Cool;
   bytes[j++] = (byte) ((color & 0x000000FF));
   bytes[j++] = (byte) ((color & 0xFF000000) >> 24);

 return bytes;

The required byteorder (RGBA) is not provided by BufferedImage, so I converted it by manually masking the correct bits in the last step.

To bind the generated Teture, use:

gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, 4,
 width, height, 0, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE,
7  Java Game APIs & Engines / JOGL Development / Re: glutStrokeString width of the font somewhat ne on: 2003-11-28 15:10:40
I think, that bitmap-based rendering is more appropriate for your task than converting strings to polygons (although converting fonts on a per-character basis does not work for some languages, like arabic), but I will nevertheless post, how it can be done. You might give it a try.

We start with a font and a string.

String s = "Hello";
Font f = new Font("Helvetica", Font.PLAIN, 12);

First, we need a FontRenderContext. As we are not rendering to any device at all, we can just create a new one.

FontRenderContext frc = new FontRenderContext(null, false, false);

The first parameter is an optional transformation, the second and third parameter are antialiasing and fractional metrics. I could not see any effect of the last two. They probably only affect rasterization, which we won't do.

Next we will instruct the font to layout our text and create a geometrical shape representing it:

GlyphVector g = font.layoutGlyphVector(frc, string.toCharArrray(), 0, string.length());
Shape shape = g.getOutline();

The resulting shape mainly consist of arcs. To render the shape as polygon, we have to approximate the arcs by straight lines and create a triangulation of them.

OpenGL provides a tesselator to calculate a triangulation. The tesselator takes the line segments and reports the triangles via callbacks. To use it, we have to register a callbackAdapter for some callbacks first.

GLUTessCallbackAdapter adapter = new MyTessAdapter();
GLUTEsselator tesselator = glu.gluNewTess();
glu.gluTessCallback(tesselator, GLU.GLU_TESS_BEGIN, adapter);
glu.gluTessCallback(tesselator, GLU.GLU_TESS_VERTEX, adapter);
glu.gluTessCallback(tesselator, GLU.GLU_TESS_END, adapter);

We tell the tesselator, that we will start producing points right away.


Then we will iterate over the shape representing our text, line by line, and forward the points to the tesselator.

PathIterator i = shape.getPathIterator(null, 0.05);

The first parameter is again an optional transformation, the second parameter specifies, how far lines between the points produced by the iterator may deviate from the actual arcs of the shape. Reducing it increases the rendering quality but produces more lines and takes more time.

Iterating over a path is slightly different than iterating over a collection. We need a temporary array of coordinates.

double[] segment = new double[6];
while(!i.isDone()) {
 switch (i.currentSegment(segment)) {;

The PathIterator puts the coordinates of the next point to the array and tells us, which type of point we have. There are three possibilitys:
MOVETO &#8211; The point starts a new line strip
LINETO &#8211; The point is the next point on the current line strip
CLOSE &#8211; Close the line strip to become a loop. We got no point this time.

   case PathIterator.SEG_MOVE_TO {
     double[] coords = new double[3];
     coords[0] = segment[0];
     coords[1] = segment[1];
     // z value stays 0

     glu.gluTessVertex(tesselator, coords, coords);

The tesselator is told to start a new line strip by gluTessBeginCountour. The gluTessVertex call takes two double arrays. The first one contains the coordinates of the point. The second one is the reference that the tesselator will report to us later as part of the triangulation. We therefore need to store the coordinates in a new array for every single point.

   case PathIterator.SEG_LINE_TO {
     double[] coords = new double[3];
     coords[0] = segment[0];
     coords[1] = segment[1];

     glu.gluTessVertex(tesselator, coords, coords);
   case PathIterator.SEG_CLOSE {

The tesselator expects all lines to be loops. Fortunately they are in all fonts I have seen so far. Now we are done parsing and tell the tesselator to start working.


Callbacks will come in to our adapter (sorry, stupid use of the word adapter):

class MyCallbackAdapter implements GLUTesselatorCallbackAdapter {
 public void begin(int primitiveType) {
 public void vertex(Object data) {
   gl.glVertex3dv((double[] data));
 public void end() {

MyCallbackAdapter just renders the triangles immidiately. It might sometimes be usefull, to store them in a display list instead.

After this process, we should finally see some text. It will probably look poor, because it is not properly antialiased. Basically, we want this:


To do the antialiasing properly, we have to use the correct blend function and to render *all* objects *front to back* without using the z buffer.


I have not really understood what this does, but it works. If you have a background other than black, you need to change the clear color to black and draw a quad of the desired color covering the complete view as last element.

As I said, it is a rather complex procedure. But you will get a true polygonal text in an arbitrary font, which can be scaled, rotated or textured. It is fast, if a display list can be reused, but slow ohterwise. Not really slow, off course, but compared to bitmap fonts.
The antialiasing is problematic, if you want to use the z-Buffer. The quality is decent, but not as good as fonts rendered to a buffered image by java, because it uses special antialiasing for font rendering.
8  Java Game APIs & Engines / JOGL Development / Re: glutStrokeString width of the font somewhat ne on: 2003-11-26 13:39:04

I had the same problem today and found two different solutions.

The first one is to set the line thickness with gl.glLineWidth() to some value greater one and then render the fonts with glutStrokeString().

The solution is attractive, because it is easy to implement and because it needs no additional memory and renders fast.

However, there are two problems:
- The line width must be set explicitly and is not automatically derived from the scaling of the current transformation.
- The connections of different line strips in the glyphs are not rendered correctly. The text looks damaged, especially when it is really large.

The second solution creates an actual polygon from the string to render using a java font and bypasses both problems of the outline fonts. It is rather complex, but I can post it, if you are still interested.
9  Java Game APIs & Engines / JOGL Development / Re: Picking deadlock with GLJPanel on: 2003-11-17 20:35:04
But how can I make this rendering thread actually perform the rendering on my panel?

If I simply try to call display, it will trigger a repaint() and the repaint manager will put an event on the AWT-Queue, where it causes rendering fom the AWT-Thread.

Additionally, all calls to setAutoRedraw are simply ignored by GLJPanel (I checked this in source, the method is empty).
10  Java Game APIs & Engines / JOGL Development / Picking deadlock with GLJPanel on: 2003-11-17 14:48:48

I tried to implement picking objects on a GLJPanel using the selection buffer, but my code invariably produces a deadlock.

What I need to have is a method, that works like this:

public SelectableObject pick(Point mouseLocation);

To implement this method, I firts store the mouse location in a global variable and then call display() on the glJPanel.

JOGL should then callback the display(Drawable) method of my GLEventListener, where I change the renderMode to GL_SELCET, draw all Objects, read the selection buffer and finally store the results in a global variable.

When the display call on GLJPanel returns, I want to read the selection results from the global variable and return the selected object to the caller of my pick method.

My Problem is: calling display() on GLJPanel from the AWT-EventDispatchingThread causes an immidiate deadlock.

Here is the respective code from GLJPanel.

public void display() {
   // Multithreaded redrawing of Swing
   // components is not allowed
   try {
     synchronized(semaphore) {
       repaintDone = false;
       while (!repaintDone) {
   } catch (InterruptedException e) {

The reason for the deadlock is obvious: the repaint is triggered but can never be executed, because the only thread executing repaints is the thread waiting for them.

The same procedure for selction works fine with GLCanvas.

I have two Questions and would be especially glad, if anyone could answer the first one:

1. Does anyone know a working solution to implement the my pick method for a swing gui without running into deadlocks? The method must be callable from the AWT-EventDispatchingThread and I need to have the result as a return value of the method.

2. Why doesn't display check, whether the current thread is already the AWT-EventDispatchingThread? The repaint could be done immidiately in this case.
Pages: [1]
EgonOlsen (38 views)
2018-06-10 19:43:48

EgonOlsen (20 views)
2018-06-10 19:43:44

EgonOlsen (40 views)
2018-06-10 19:43:20

DesertCoockie (187 views)
2018-05-13 18:23:11

nelsongames (122 views)
2018-04-24 18:15:36

nelsongames (121 views)
2018-04-24 18:14:32

ivj94 (861 views)
2018-03-24 14:47:39

ivj94 (122 views)
2018-03-24 14:46:31

ivj94 (758 views)
2018-03-24 14:43:53

Solater (139 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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!