Show Posts
|
|
Pages: [1] 2 3 4
|
|
4
|
Java Game APIs & Engines / JOGL Development / Re: GLCanvas mixing with custom Swing problems
|
on: 2009-10-04 13:07:58
|
|
My application which uses GLCancas and Swing and which has been working for about 2 years seems to recently have stopped working with the same symptom - the GLCanvas just displays as white.
I'm not sure what changed - my application certainly didn't. I'm trying to work out if it's relateds to having moved to a later patch level of Java.
|
|
|
|
|
7
|
Java Game APIs & Engines / JOGL Development / NPOT Textures and glTexImage2D
|
on: 2008-06-19 17:39:55
|
Hello, I'm creating some non-power-of-two textures procedurally, and then creating the texture using the following call: 1 2 3 4 5 6 7 8 9
| gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGB, w, h, 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, bb); |
Where 'bb' is the ByteBuffer holding the data. I was expecting that I should simply lay the data out in the byte buffer as bytes as follows: R,G,B,R,G,B,... but what I'm finding is that I'm having to ensure that the data for each row starts on a four byte boundary, meaning that if w is not a multiple of 4 (as it can be, since I'm using NPOT textures), the texture appears sheared when rendered. Is this what I should expect ? I'm running on an nVidia Quadro FX 350M, and I can't tell if this is a driver bug or not. The following program illustrates the shearing: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248
| package rob.jogltest;
import java.nio.ByteBuffer;
import javax.media.opengl.*; import javax.media.opengl.glu.*; import javax.swing.JFrame;
import java.awt.Color; import java.awt.Font; import java.awt.Graphics; import java.awt.image.BufferedImage; import java.awt.image.DataBufferInt;
public class JoglTest extends GLJPanel implements GLEventListener {
private int[] texture1; private float size = 30.0f; private float alpha = 1.0f; private static final int SIZE = 255;
public JoglTest() { super(new GLCapabilities());
addGLEventListener(this); }
public void init(GLAutoDrawable glad) { GL gl = glad.getGL();
gl.glEnable(GL.GL_DEPTH_TEST); gl.glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
if (!gl.isExtensionAvailable("GL_ARB_texture_non_power_of_two")) { System.out.println("Need NPOT Textures!"); System.exit(1); } }
public void displayChanged(GLAutoDrawable glad, boolean modeChanged, boolean deviceChanged) { }
public void display(GLAutoDrawable glad) { GL gl = glad.getGL(); GLU glu = new GLU();
int clearBits = 0; if (true) { clearBits |= GL.GL_DEPTH_BUFFER_BIT; } if (clearBits != 0) { gl.glClear(clearBits); } gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity();
render(gl, glu);
gl.glFlush(); }
public void reshape(GLAutoDrawable glad, int i, int x, int width, int height) { GL gl = glad.getGL(); GLU glu = new GLU();
gl.glViewport(0, 0, width, height); gl.glMatrixMode(GL.GL_PROJECTION); gl.glLoadIdentity(); if (true) { double aspectRatio = (double) width / (double) height; glu.gluPerspective(45.0, aspectRatio, 1.0, 400.0); } else { gl.glOrtho(0.0, width, height, 0.0, -100.0, 100.0); }
gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity();
}
private void renderFace(GL gl, int[] t, float w, float h) { int imgw = SIZE; int imgh = SIZE; if (imgw > imgh) { h *= ((float) imgh) / imgw; } else { w *= ((float) imgw) / imgh; } float w2 = w / 2f; float h2 = h / 2f;
gl.glEnable(GL.GL_TEXTURE_2D); gl.glBindTexture(GL.GL_TEXTURE_2D, texture1[0]);
gl.glColor4f(alpha, alpha, alpha, alpha); gl.glBegin(GL.GL_QUADS); gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex3f(-w2, h2, 0f); gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex3f(w2, h2, 0f); gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex3f(w2, -h2, 0f); gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex3f(-w2, -h2, 0f); gl.glEnd(); }
public void initTexture1(GL gl) { BufferedImage bi = new BufferedImage(SIZE, SIZE, BufferedImage.TYPE_INT_RGB);
Graphics g = bi.getGraphics(); g.setColor(Color.RED); g.fillRect(0, 0, SIZE, SIZE);
g.setColor(Color.BLUE); g.fillRect(5, 5, SIZE - 10, SIZE - 10);
g.setColor(Color.WHITE); g.setFont(new Font(Font.MONOSPACED, Font.BOLD, 30)); g.drawString("Hello", 50, 50);
texture1 = new int[1]; gl.glGenTextures(1, texture1, 0); gl.glBindTexture(GL.GL_TEXTURE_2D, texture1[0]); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP_TO_EDGE); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_T, GL.GL_CLAMP_TO_EDGE); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR); gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR);
int w = bi.getWidth(); int h = bi.getHeight();
ByteBuffer bb = convertToByteBuffer(bi);
bb.rewind(); gl.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGB, w, h, 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, bb);
}
public void render(GL gl, GLU glu) { if (texture1 == null) { initTexture1(gl); } if (alpha == 0f) { return; } glu.gluLookAt(0, 10, 90, 0, 0, 0, 0, 1, 0);
float size2 = size * 0.75f;
if (alpha <= 1.0f) { gl.glEnable(GL.GL_BLEND); gl.glBlendFunc(GL.GL_ONE, GL.GL_ONE_MINUS_SRC_ALPHA); }
gl.glTexEnvi(GL.GL_TEXTURE_ENV, GL.GL_TEXTURE_ENV_MODE, GL.GL_MODULATE);
gl.glPushMatrix(); gl.glTranslatef(0f, 0f, size2); renderFace(gl, texture1, size, size); gl.glPopMatrix();
if (alpha <= 1.0f) { gl.glDisable(GL.GL_BLEND); } }
private ByteBuffer convertToByteBuffer(BufferedImage image) { ByteBuffer ret = null;
int[] data = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();
int h = image.getHeight(); int w = image.getWidth(); int www = roundUpToMultipleOfFour(w);
ret = ByteBuffer.allocateDirect(h * www * 3);
System.out.println("data size is " + data.length);
System.out.println("bi width is " + w); System.out.println("bi height is " + h);
int tindex = 0; for (int y = 0; y < h; y++) { for (int x = 0; x < w; x++) { int sindex = y * w + x; int val = data[sindex];
int blue = val & 0xff; int green = (val >> 8) & 0xff; int red = (val >> 16) & 0xff;
ret.put(tindex++, (byte) red); ret.put(tindex++, (byte) green); ret.put(tindex++, (byte) blue); } } return ret; }
private int roundUpToMultipleOfFour(int num) { if ((num % 4) != 0) { num = num + 4 - (num % 4); } return num; }
public static void main(String[] args) { JFrame frame = new JFrame("JOGL Texture Demo"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.add(new JoglTest()); frame.pack(); frame.setSize(400, 400); frame.setLocationRelativeTo(null); frame.setVisible(true); } } |
|
|
|
|
|
8
|
Java Game APIs & Engines / JOGL Development / Re: Exception in GLPbuffer.display()
|
on: 2007-06-06 17:08:38
|
Ken, Thanks for the reply. The problem occurs even if I stub out all the code in the display() method of the event listener to be nothing but: 1
| System.out.println(drawable.getGL()); |
I guess this leaves this as being most likely a driver isssue. I'll see if I can investigate further. Thanks again, Rob
|
|
|
|
|
10
|
Java Game APIs & Engines / JOGL Development / Exception in GLPbuffer.display()
|
on: 2007-06-05 20:34:44
|
Hi al, I'm making calls to the display() method of the GLPbuffer, but after many hundreds of such calls, I see an exception thus: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
| [java] Exception in thread "Thread-2" javax.media.opengl.GLException: javax.media.opengl.GLException: Error making context current: 0 [java] at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271) [java] at com.sun.opengl.impl.GLPbufferImpl.maybeDoSingleThreadedWorkaround(GLPbufferImpl.java:199) [java] at com.sun.opengl.impl.GLPbufferImpl.display(GLPbufferImpl.java:88) [java] at rob.squares.sources.CompressedMipmapSquareSource$Tracker.notifySquare(CompressedMipmapSquareSource.java:162) [java] at rob.squares.AbstractSquareSource.notifyCallers(AbstractSquareSource.java:8) [java] at rob.squares.sources.CombiningSquareSource.process(CombiningSquareSource.java:52) [java] at rob.squares.ThreadedSquareSource.run(ThreadedSquareSource.java:66) [java] at java.lang.Thread.run(Thread.java:619) [java] Caused by: javax.media.opengl.GLException: Error making context current: 0 [java] at com.sun.opengl.impl.windows.WindowsGLContext.makeCurrentImpl(WindowsGLContext.java:169) [java] at com.sun.opengl.impl.windows.WindowsPbufferGLContext.makeCurrentImpl(WindowsPbufferGLContext.java:102) [java] at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:127) [java] at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182) [java] at com.sun.opengl.impl.GLPbufferImpl$DisplayOnEventDispatchThreadAction.run(GLPbufferImpl.java:233) [java] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) [java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) [java] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) [java] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) [java] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) [java] at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
[code]
This is on WinXP, Nvidia FX5200.
Can anyone suggest what might be going wrong here please? I've struggled to reduce this to a simple testcase and still have the problem occur. |
[/code]
|
|
|
|
|
11
|
Java Game APIs & Engines / JOGL Development / Re: JSR-231 beta 1 and nightly builds available
|
on: 2005-11-01 09:08:19
|
Ken, Thanks for the reply. I've started moving my code to JSR231, and apart from a bit of work moving from a number of old JOGL APIs that took arrays to the JSR231 Buffer variants it's all going very smoothly and easily. Re glBufferData() We discussed the issue of "number of bytes" versus "number of elements" some months ago and in some detail. I will not reinterate here, other than to say that all other Java APIs that deal with Buffers deal in numbers of elements. My code now looks like: 1 2 3 4 5 6
| FloatBuffer fb = tsa.getInterleavedFloatBuffer(); gl.glBufferData( GL.GL_ARRAY_BUFFER_ARB, fb.limit() * BufferUtils.SIZEOF_FLOAT, fb, GL.GL_STATIC_DRAW_ARB); |
Is there any chance of having a version of glBufferData that explicitly takes a FloatBuffer and where the 'size' is in "number of elements" please ? 1) This would eliminate the possibity of supplying an invalid size when using a FloatBuffer (e.g. currently 7 can NEVER be a valid size when supplying a FloatBuffer) 2) It would eliminate my having to use SIZEOF_FLOAT which is an anathema to any Java programmer 3) In the above I'm pretty much force to use BufferUtils (a non-core com.sun API) any time I want to use the above (core, javax.media API) If I understood you correctly, the start of the data is now taken from the Buffer position which is specified as the ordinal of the first element, so a length in bytes is really odd. Thanks, Rob
|
|
|
|
|
14
|
Java Game APIs & Engines / JOGL Development / Re: display lists and texture size: unexpectedly s
|
on: 2005-05-26 16:31:04
|
|
I've got a similar app that does terrain rendering for parts of the British Isles.
All my vertex data is stored in VBOs down on the card (I'm using GL_STATIC_DRAW_ARB when setting up each VBO) along with the texture data.
Very little flows across the Java<->JNI<->AGP<->Video Card boundary to render each frame, just a request to bind each texture in turn and render each relevant VBO, and not any of the vertex or texture data itself.
I can fit about 1.2 million vertices worth of vertex data plus 100 1024x1024 compressed textures on a 128MB Nvidia FX5200.
It renders at around 23 frames/sec (~20million tri/sec) at 1024x768x32bit, which is pretty much entirely limited by the card.
Rob
|
|
|
|
|
15
|
Java Game APIs & Engines / JOGL Development / Re: Smooth scrolling with JOGL/AWT
|
on: 2005-04-09 07:44:45
|
Rex, One of the problems now is that GLCanvas.reshape() doesn't not check ... My point was that reshape should not be being called with the frequency that it is. If you use a JTextField instead of a JLabel in your posted demo code, the reshape method only gets called once in a run of the test, not all the time. Your change to reshape() in GLCanvas is a work-around to an issue that is only occuring, I think, because of your (mis) use of JLabel. Rob
|
|
|
|
|
16
|
Java Game APIs & Engines / JOGL Development / Re: Smooth scrolling with JOGL/AWT
|
on: 2005-04-08 08:24:23
|
How much of this issue is the use of JLabel? I had related issues with JLabel, and concluded that it wasn't really intended to be used for text that was being changed (indeed as its name implies). I moved to using a JTextField on which I had called 'setEditable(false)' as can be seen in my webstart demo here: http://abraded.co.uk/jogl/By the way, I don't see the tearing with your demo if I run with -Dsun.java2d.noddraw=true as Ken suggests. The tearing is *very* bad without this. I can't tell however if the above helps: basically for me running your testcase both JLabel and JTextField get tearing without the -D flag, and neither get tearing with the -D flag, but at least the 'reshape' doesn't get called with JTextField. Another major issue I had mixing Swing with JOGL is that updates to Swing components can be expensive enough to cause you to miss frames in the GLCanvas if you are trying to hit the vertical refresh rate. I minimised this by minimising my updates to the Swing components - primarily by ensuring I was *not* updating the Swing components every frame. Rob
|
|
|
|
|
17
|
Java Game APIs & Engines / JOGL Development / Re: 3 little questions
|
on: 2005-04-07 09:14:03
|
Can i ask why anyone really wants a final refresh rate of more than 24fps since this is the speed of motion video and anything more is spurious? Well, I guess because 24fps (or there abouts) is the point at which the brain *starts* to be fooled that it's seeing continuous motion rather than a sequence of individual frames. Higher frame rates do look much smoother, particularly when the viewpoint is moving fast, e.g. try rotating the camera in a scene about a vertical axis. This looks much better and smoother at high frame rates than 24fps. Try it. I've never quite understood the point of wanting to exceed the monitor's vertical refresh rate though... Rob
|
|
|
|
|
18
|
Java Game APIs & Engines / JOGL Development / Re: 3 little questions
|
on: 2005-04-05 08:29:24
|
thx swap intervall works good... but am i right that the 'w' stands for ms-windows? (no portability) I use glXSwapIntervalSGI on Linux. My code does: 1 2 3 4 5 6 7 8 9
| if (gl.isExtensionAvailable("WGL_EXT_swap_control")) { System.out.println("Disabling VSYNC (Win)"); ((WGL)gl).wglSwapIntervalEXT(0); } else if (gl.isExtensionAvailable("GLX_SGI_swap_control")) { System.out.println("Disabling VSYNC (X)"); ((GLX)gl).glXSwapIntervalSGI(0); } else { System.out.println("Could not alter VSYNC"); } |
Don't know about Mac. Rob
|
|
|
|
|
21
|
Java Game APIs & Engines / JOGL Development / Re: Initial startup delay in running JoGL app
|
on: 2005-03-30 08:00:38
|
|
Ken,
I'll post here since this may be the same monjur's problem.
This issue I'm seeing is that the setVisible() call on my JFrame can take up to 45 seconds to execute. It doesn't happen every time, and when it does happen pressing ctrl-break to try to get a stack dump does nothing until the frame appears at the end of the delay, when the stack information then spews out.
Sometime the delay occurs in the immediately preceding pack() call.
This is with a cleanly installed machine built from scratch yesterday with:
Win2K Pro (With all latest Windows Update maintenance) JOGL 1.1 b10 NVidia drivers 7184 Java 1.5.0_02
Previously before my machine rebuild, I was running with the same JOGL but Java 1.5.0, and 66.93 drivers. I don't know if any of this is relevant. I'm going to try regressing levels.
The frame rate degradation was a red-herring - I was using '-Dsun.java2d.opengl=true' which was causing this and which I have now removed, but the start-up delay remains.
Very puzzled over this. Rob
|
|
|
|
|
24
|
Java Game APIs & Engines / JOGL Development / Re: Loading model from .obj file problem
|
on: 2005-02-25 13:46:15
|
|
The OpenGL culling I believe works more or less like this:
1) Calculates a *face*normal, n, by calculating e1 x e2 where e1 and e2 are two of the edge vectors of the face concerned in the winding order defined and 'x' is the vector cross product
2) Calculates n.r where r is the position vector of any one of the vertices of the face. and '.' is the vector dot product. The sign of this gives the sign of the cosine of the angle between n and r, and hence determines if the face normal is pointing to the viewpoint or away from the viewpoint.
Don't confuse the face normal with any vertex normals you may have defined, btw, they are completely different things.
Rob
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|