Latest posts of: eteq - Java-Gaming.org

Show Posts
Pages: [1] 2 3 4

1	Java Game APIs & Engines / JOGL Development / Re: Announcing: joglutils project	on: 2007-04-13 10:07:31
This has been a project I've had in mind for a while, although someone may have beaten you to it... see the pm I sent. Thanks!

Java Game APIs & Engines / JOGL Development / Re: Saving GLUTessellation Data

on: 2007-04-12 18:07:23

Probably the simplest way to do this is with a display list. The syntax is something like this:

1
2
3
4
5
6

int list = gl.glGenLists(1);
gl.glNewList(list,GL.GL_COMPILE);
...
your call to the Tessellator here
....
gl.glEndList();

Then, when you want to actually render into the scene, call
gl.glCallList(list);

There are other techniques like vertex buffer objects and the like, but that would probably require a major re-write of your Tessellator. This technique is pretty quick and easy.

Java Game APIs & Engines / JOGL Development / Re: newbie: read and display bitmap

on: 2007-04-06 20:15:47

Two possibilities leap to mind for me:
1) Instead of glDrawPixels, use the TextureIO and Texture classes that are in the com.sun.opengl.util.texture package. Then enable and bind the texture and draw a square with the appropriate texture coordinates:

1
2
3
4
5
6

glBegin( GL_QUADS );
glTexCoord2d(0.0,0.0); glVertex2d(0.0,0.0);
glTexCoord2d(1.0,0.0); glVertex2d(1.0,0.0);
glTexCoord2d(1.0,1.0); glVertex2d(1.0,1.0);
glTexCoord2d(0.0,1.0); glVertex2d(0.0,1.0);
glEnd();

The use of the texture classes is fairly straightforward from the javadocs (and a bunch of the demos use them, as well). This is convinient in JOGL because those texture classes encapsulate all the hard work.

2) using glDrawPixels, use the javax.imageio.ImageIO.read(file) method to read the file, and pull the pixel data out of the resulting BufferedImage and store it in a java.nio.floatBuffer . You should be able to pass that into glDrawPixels... except, I think (although I'm not sure how consistent this is on various machines), bmp data is stored as BGR instead of the usual RGB, so your format will probably be GL_BGR (although it might be GL_RGB).

4	Java Game APIs & Engines / JOGL Development / Re: Linking JOGL GL interface docs to opengl SDK	on: 2007-04-06 11:43:26
Done, see https://jogl.dev.java.net/issues/show_bug.cgi?id=291 . I also included the mini-program I wrote to generate the file... maybe with a little polishing it can be automated in the javadoc generating process.

5	Java Game APIs & Engines / JOGL Development / Linking JOGL GL interface docs to opengl SDK	on: 2007-04-04 02:43:10
I noticed the documentation for the GL interface (that is, the "iterface to C function" links) still links to the rush3d.com web site's online bluebook. Is there some reason why the OpenGL SDK ( http://www.opengl.org/sdk/docs/man/ ) isn't being used?

6	Java Game APIs & Engines / JOGL Development / Re: Where to buy OpenGL 2.0 Reference Manual?	on: 2007-02-24 22:40:42
This thread is a bit dated, but I think this is an important tool to point out that just became available: http://www.opengl.org/sdk/ This essentially renders the blue book totally obsolete, as all the reference information is on that page. That's probably why there's no new paper bluebook.

7	Java Game APIs & Engines / JOGL Development / Does JOGL work under Vista?	on: 2007-01-18 03:21:22
I'm curious if anyone has tested JOGL under one of the Vista Release Candidates - does it work at all/well?

8	Java Game APIs & Engines / JOGL Development / Re: Announcing: joglutils project	on: 2007-01-12 09:57:37
It looks like it, yes - the loader just loads the file into a bunch of object verticies and materials, and you're free to modify what actually gets sent to JOGL.

9	Java Game APIs & Engines / JOGL Development / Re: loadDRIHack() vanishes in 1.1.0	on: 2007-01-12 09:14:24
hmm... ok... looks like I'll have to work-around my workaround

10	Java Game APIs & Engines / JOGL Development / loadDRIHack() vanishes in 1.1.0	on: 2007-01-10 07:46:57
I noticed that the com.sun.opengl.impl.NativeLibLoader.loadDRIHack() method mysteriously vanished in jogl 1.1.0 ... does this mean that the NativeLibLoader class shouldn't be used in applications (e.g. that it may or may not be around in the future) ?

11	Java Game APIs & Engines / JOGL Development / Re: Mouse pointer	on: 2006-12-19 08:36:14
I've been looking into using java.awt.Robot to do as you say (e.g. to keep it from leaving the frame). But the javadocs suggest that it isn't supposed to be used in applications (e.g. for "testing"). Is there some reason that they say it should be only used for testing?

12	Java Game APIs & Engines / JOGL Development / Re: Java2D dynamic Texture is upside down	on: 2006-12-19 07:43:29
Looks impressive to me... are you interested in perhaps cleaning it up a little and putting it into the joglutils project? but you might want to add the mime type application/x-java-jnlp-file jnlp to your web site, though - I had to download and run the .jnlp file.

Java Game APIs & Engines / JOGL Development / Re: How to calculate vertex normals.

on: 2006-12-08 02:16:06

Below is the method I use for computing normals in a hightfield data set (the getData(x,y) method call gets the height value at the specified x,y coordinates). The main complication is that around the edges, there are viewer values available to do it. Note that I'm using the Java3D vecmath package for the vector math.

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

/**
     * Computes the normal at the grid point (xCoord, yCoord) and assigns it to the first vector in normalCompVecs
     * @param xCoord the column of the grid point (strips iterate over these)
     * @param yCoord the row of the grid point (one strip each)
     * @return the calculated normal vector.  Note that this vector may change - make a new one and initialize it to store this normal
     */
    private Vector3f computeNormal(int xCoord,int yCoord) {
        //uses all of the vectors past the first for computing the normal
        Vector3f[] vecs = this.normalCompVecs;
        int gran = this.normalGranularity;
        float scal = this.normalScaling;
        
        float value = getData(xCoord,yCoord);
        if ((vecs.length - 1) == 8) {
            
            int vecsToCross = 1;
            int xp1 = xCoord + 1;
            int xm1 = xCoord - 1;
            int yp1 = yCoord + 1;
            int ym1 = yCoord - 1;
            //check edges
            boolean left = (xCoord == 0);
            boolean right = (xCoord >= (getXSize() - gran));
            boolean bottom = (yCoord == 0);
            boolean top = (yCoord >= (getYSize() - gran));
            
            if (left&&bottom) {
                //bottom-left corner
                vecs[1].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecs[2].set(gran,gran,scal*(getData(xp1,yp1)-value));
                vecs[3].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecsToCross = 3;
            } else if (left&&top) {
                //upper-left corner
                vecs[1].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecs[2].set(gran,-gran,scal*(getData(xp1,ym1)-value));
                vecs[3].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecsToCross = 3;
            } else if (right&&bottom) {
                //bottom-right
                vecs[1].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecs[2].set(-gran,gran,scal*(getData(xm1,yp1)-value));
                vecs[3].set(-gran,0,scal*(getData(xm1,yCoord)-value));
                vecsToCross = 3;
            } else if (right&&top) {
                //upper-right
                vecs[1].set(-gran,0,scal*(getData(xm1,yCoord)-value));
                vecs[2].set(-gran,-gran,scal*(getData(xm1,ym1)-value));
                vecs[3].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecsToCross = 3;
            } else if (left) {
                //left edge
                vecs[1].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecs[2].set(gran,-gran,scal*(getData(xp1,ym1)-value));
                vecs[3].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecs[4].set(gran,gran,scal*(getData(xp1,yp1)-value));
                vecs[5].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecsToCross = 5;
            } else if (right) {
                //right edge
                vecs[1].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecs[2].set(-gran,gran,scal*(getData(xm1,yp1)-value));
                vecs[3].set(-gran,0,scal*(getData(xm1,yCoord)-value));
                vecs[4].set(-gran,-gran,scal*(getData(xm1,ym1)-value));
                vecs[5].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecsToCross = 5;
            } else if (top) {
                //top edge
                vecs[1].set(-gran,gran,scal*(getData(xm1,yCoord)-value));
                vecs[2].set(-gran,-gran,scal*(getData(xm1,ym1)-value));
                vecs[3].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecs[4].set(gran,-gran,scal*(getData(xp1,ym1)-value));
                vecs[5].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecsToCross = 5;
            } else if (bottom) {
                //bottom edge
                vecs[1].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecs[2].set(gran,gran,scal*(getData(xp1,yp1)-value));
                vecs[3].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecs[4].set(-gran,gran,scal*(getData(xm1,yp1)-value));
                vecs[5].set(-gran,0,scal*(getData(xm1,yCoord)-value));
                vecsToCross = 5;
            } else {
                //clockwise from right
                vecs[1].set(gran,0,scal*(getData(xp1,yCoord)-value));
                vecs[2].set(gran,gran,scal*(getData(xp1,yp1)-value));
                vecs[3].set(0,gran,scal*(getData(xCoord,yp1)-value));
                vecs[4].set(-gran,gran,scal*(getData(xm1,yp1)-value));
                vecs[5].set(-gran,0,scal*(getData(xm1,yCoord)-value));
                vecs[6].set(-gran,-gran,scal*(getData(xm1,ym1)-value));
                vecs[7].set(0,-gran,scal*(getData(xCoord,ym1)-value));
                vecs[8].set(gran,-gran,scal*(getData(xp1,ym1)-value));
                vecsToCross = 8;
            }
            
            for(int i = 1; i < vecsToCross; ++i)
                vecs[i].cross(vecs[i],vecs[i+1]);
            if (vecsToCross == 8) {
                vecs[8].cross(vecs[8],vecs[1]);
                vecsToCross = 9;
            }
            vecs[0].set(0,0,0);
            for(int i = 1; i < (vecsToCross - 1); ++i)
                vecs[0].add(vecs[i]);
            
        } else
            throw new Exception("Invalid number of vectors for normal calculatuion");
        
        vecs[0].normalize();
        return vecs[0];
    }

Java Game APIs & Engines / JOGL Development / Re: Java2D dynamic Texture is upside down

on: 2006-12-08 02:10:04

Try using

1	texdata = new TextureData(GL.GL_RGB, width, height, 0, GL.GL_BGRA, GL.GL_UNSIGNED_BYTE, false, false, true, imageBuffer, null);

The difference being the boolean argument "mustFlipVertically" is true instead of false. There are a billion and a half ways of storing textures, and it seems like half of them are upside-down and half are rightside-up (depending on the file format it came from and so on)...

15	Java Game APIs & Engines / JOGL Development / Re: glGetTexImage help	on: 2006-12-07 21:08:50
I tested this on one of my machines (nVidia GeForce 6600 on WinXP), and it did exactly what it's supposed to (e.g. the array was filled with [1,0,0] elements). Maybe the problem is in your drivers?

16	Java Game APIs & Engines / JOGL Development / Re: Can I push shader state?	on: 2006-12-06 00:26:05
I'm fairly sure this can't be done - I know I've tested glPushAttrib(GL.GL_ALL_ATTRIB_BITS) , and it doesn't preserve the shader program state. There may be some other function I'm not aware of that pushes shader states, though.

17	Java Game APIs & Engines / JOGL Development / Re: Exception on isFunctionAvailable call	on: 2006-11-23 11:17:45
Ah, that would explain it - I could certainly belive it wasn't supported by the machines it was called on. Thanks for the info.

18	Java Game APIs & Engines / JOGL Development / Exception on isFunctionAvailable call	on: 2006-11-23 03:57:00
Below is a stacktrace of an Exception that was thrown when I tried to call gl.isFunctionAvailable("glCreateShader") . This exact same code works perfectly on three other computers, but for some reason it throws this exception on two others (I don't see any obvious connection between the two that generated the exception, other than that they were both Dell laptops). What could be causing this? java.lang.NumberFormatException: For input string: "GL_ARB_shader_objects" at java.lang.NumberFormatException.forInputString(Unknown Source) at java.lang.Integer.parseInt(Unknown Source) at java.lang.Integer.valueOf(Unknown Source) at com.sun.opengl.impl.FunctionAvailabilityCache$Version.<init>(FunctionAvailabilityCache.java:312) at com.sun.opengl.impl.FunctionAvailabilityCache.isPartOfGLCore(FunctionAvailabilityCache.java:200) at com.sun.opengl.impl.FunctionAvailabilityCache.isFunctionAvailable(FunctionAvailabilityCache.java:83) at com.sun.opengl.impl.GLContextImpl.isFunctionAvailable(GLContextImpl.java:323) at com.sun.opengl.impl.windows.WindowsGLContext.isFunctionAvailable(WindowsGLContext.java:241) at com.sun.opengl.impl.GLImpl.isFunctionAvailable(GLImpl.java:27847) at sddm.SDDMListener.setupShaderAna(SDDMListener.java:109) at sddm.SDDMListener.init(SDDMListener.java:86) at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:72) at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:264) at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:189) at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:258) at javax.media.opengl.GLCanvas.display(GLCanvas.java:130) at javax.media.opengl.GLCanvas.paint(GLCanvas.java:142) at sun.awt.RepaintArea.paintComponent(Unknown Source) at sun.awt.RepaintArea.paint(Unknown Source) at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

Java Game APIs & Engines / JOGL Development / Re: Drawing a Circle

on: 2006-11-13 18:35:59

And if your not up for the working out the math, this should work:

1
2
3
4

gl.glBegin(gl.GL_LINES);
for (int t = 0; t < 2 Pi; t+= stepsize) 
   gl.glVertex2d(Math.sin(t),Math.cost));
gl.glEnd();

20	Java Game APIs & Engines / JOGL Development / Re: Strange graphics Corruption	on: 2006-10-31 19:15:15
Strange... it's still there for me. Anyway, I uploaded it to my web site: http://ags.uci.edu/~etolleru/singlecolorweirdness.PNG

21	Java Game APIs & Engines / JOGL Development / Re: How to use Swing and JOGL to implement this application?	on: 2006-10-31 09:05:15
That seems like a reasonable project... I'd recommend you read the JOGL User Guide at https://jogl.dev.java.net/nonav/source/browse/checkout/jogl/doc/userguide/index.html?rev=HEAD&content-type=text/html or included with the latest release. The demos that can be found on the main JOGL page are also useful. Some of them include Swing interfaces... Or, again, is there something more specific you're asking?

22	Java Game APIs & Engines / JOGL Development / Strange graphics Corruption	on: 2006-10-31 09:00:26
Attached is a screenshot from an ATI Radeon Mobility 9200... I've gotten something looking like this twice now, once from copying from the frame buffer to a texture, and now in applying a color matrix and copying pixels. Even more strangely, however, if I just copy the frame with the color matrix left alone, it works fine. Has anyone seen anything like this before? It's probably not JOGL-related (more likely the hardware) but I just want to check to be sure.

23	Java Game APIs & Engines / JOGL Development / Re: GL_COLOR_MATRIX or GL_COLOR_MATRIX_EXT	on: 2006-10-26 11:55:22
I've been meaning to take a look at FBOs when I get some time, anyway, although given that I'm mostly writing this as a compatibility technique for older hardware, I'm not sure how useful it'll be. It seems like you aren't thanked often enough at the end of threads despite pretty much always answering the question... so thanks, Ken

24	Java Game APIs & Engines / JOGL Development / Re: Checking doublebuffering from inside a GLEventListener	on: 2006-10-26 11:52:10
Basically I just need to know if glDrawBuffer(GL_BACK) will cause problems or not... I can't really imagine the application running anywhere other than a double-buffered context, but this little nagging voice in the back of my head says that if its bad form to not check. Oh, well, not a big deal. Thanks Ken.

25	Java Game APIs & Engines / JOGL Development / Re: trouble with display()	on: 2006-10-26 11:42:39
Is this repeatable on different hardware? I looked back at my code, and although I'm still not sure if its blocking, it definitely redisplays the Pbuffer within a fairly short time every time display() is called...

26	Java Game APIs & Engines / JOGL Development / Re: How to use Swing and JOGL to implement this application?	on: 2006-10-26 11:40:30
I'm not sure I understand the question here - are you asking for a basic rundown of how to do anything with JOGL at all, or something specific about this application? It seems fairly straightforward to me - you can draw all the models with the GLUT class that's included in JOGL, and all the settings on the sliders are the basic OpenGL fixed functionality, not Programmable Shaders or anything. I don't imagine it would take more than a few hours to write this (of course, that's without accounting for learning how JOGL works)... So is it just a feasability question, or did you have something more specific?

27	Java Game APIs & Engines / JOGL Development / Checking doublebuffering from inside a GLEventListener	on: 2006-10-25 04:40:27
The subject pretty much says it - is it possible to check if you're single-buffered or double-buffered inside one of the GLEventListener methods? I could, of course, send some sort of signal when generating the listener based on the GLCapabilities, but that's kind of a hassle. I can certainly imagine that the whole point of de-coupling the listeners and drawables would make this impossible, but I'm wondering if there's some clever hack that I'm missing exists...?

28	Java Game APIs & Engines / JOGL Development / Re: GL_COLOR_MATRIX or GL_COLOR_MATRIX_EXT	on: 2006-10-25 04:34:57
Ok, well, that's unfortunate... I wish there was some way to know if it is slow, and use it only when necessary... Oh,well, I guess its the dreaded "implementation specifeic." Also, is there a way to call glCopyPixels() and have it read/write from a PBuffer to the main frame buffer, or do I have to read from the PBuffer to a texture and then draw to a framebuffer screen-filling rectangle with the texture on it?

29	Java Game APIs & Engines / JOGL Development / Re: GL_COLOR_MATRIX or GL_COLOR_MATRIX_EXT	on: 2006-10-24 11:41:39
After a little bit of experimentation, I've determined that it isn't the color matrix at all - copying from one buffer to the same buffer is apparently very slow (e.g. at least 1000X slower than from one buffer to another). This seems strange, but not a serious problem, as I can just write to aux buffers or Pbuffers and copy from there. Still, it seems strange that a buffer can't self-copy without such a gigantic delay (at least on my test machine). In a related note, will gl.isExtensionAvailable("GL_SGI_color_matrix") return true if I have an OpenGL Version that supports the builtin version of GL_COLOR ? I'm not sure what version this was added in (I know its there in 2.0, but I'm not sure about anything before), otherwise I suppose I could just directly check the version.

30	Java Game APIs & Engines / JOGL Development / Re: GL_COLOR_MATRIX or GL_COLOR_MATRIX_EXT	on: 2006-10-24 05:30:18
That seems to work, although I can't test it because of a different issue... I'm trying to use the color matrix to manipulate the colors in an image I'm rendering to the frame buffer. If I understand the color matrix correctly, it applys only to pixel transfer operations, but I don't want to copy to main memory, because that's relatively slow. Instead, I'm just doing glCopyPixel(), which in principle should only operate in video memory. The problem is, it's EXTREMELY slow, in fact, much slower than if I copy all the pixels to CPU memory, manipulate them with software, and copy them back, which doesn't seem right. Is there something else that slows down glCopyPixels() that I can work around?

Pages: [1] 2 3 4

Check out our latest community projects!

Play Revenge of the Titans! The situation is critical. We need fancy commanders to defend Earth, the moon, Mars!