 Show Posts
|
|
Pages: [1]
|
|
2
|
Java Game APIs & Engines / JOGL Development / Re: AWT has an option called GeneralPath how i can use a like with JOGL..
|
on: 2008-07-23 04:34:20
|
Ok, I have not exactly done any of this myself, but I am trying to point you in the right direction, so bare with me... Now, OpenGL is pretty low level, so there is no "GeneralPath"-like class that you can just call, you have to implement curve/path rendering on your own, i.e. use some math  First, I would explore gamedev.net forums, as I am sure people have asked this before there. I found this post which might give you some idea of what you're getting yourself into, and at the very least some buzz words that will be useful for further research. I think bezier curves and NURBS are what you're looking for. http://www.gamedev.net/community/forums/topic.asp?topic_id=378739After you've read that, this paper should give you a pretty solid intro to one of the popular approaches on how curves are done in OpenGL: http://www.mat.ucsb.edu/~c.ramakr/articles/dls/nurbs.pdfHope that helps |
|
|
|
|
3
|
Java Game APIs & Engines / JOGL Development / Re: Announcing: joglutils project
|
on: 2008-07-21 05:16:38
|
|
Would you guys be interested in a Frame Buffer Object class? It covers all the basic stuff like color and depth attachments, but it has some neat features like support for multiple color attachments (a nice feature for those doing GPGPU stuff), and you can designate either a texture or render buffer as the attachment type.
|
|
|
|
|
6
|
Java Game APIs & Engines / JOGL Development / Re: Problems loading texture and a question about sprites
|
on: 2008-06-22 17:12:54
|
So lets say you have a project with a package like org.MyProject Inside the package MyProject you have a class called TextureLoading, and an image called image.jpg 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| import com.sun.opengl.util.TextureIO;
import com.sun.opengl.util.Texture;
...
public class TextureLoading {
private Texture tex;
...
public void init(GLAutoDrawable drawable) {
...
try {
tex = TextureIO.newTexture(
getClass().getClassLoader().getResourceAsStream("org/MyProject/image.jpg"), false, TextureIO.JPG
);
}
catch(IOException e) {
e.printStackTrace();
}
...
}
} |
Also, make sure you have textures enabled? |
|
|
|
|
9
|
Java Game APIs & Engines / JOGL Development / Re: vertex shader causing slowdown
|
on: 2008-06-20 16:42:54
|
Thanks for all the advice. I did some research and it turns out that ATI has taken a loong time to adopt vertex shader texture fetching, so their cards are especially slow at it. I am an undergrad student in a computer graphics lab at school, so I just asked to be moved to a computer with a better graphics card, (nVidia 8800 GTS, dual CUDA! Sooo awesome...) and now I am pumping out 160+ fps. Oh technology  So I think I will stick with the shader approach, because I really like the idea of using a shader to do my deformation of the field using a texture. VBOs are definitely something to keep in mind though if/when I want to make my code more portable to computers without behemoth GPUs. Cheers |
|
|
|
|
10
|
Java Game APIs & Engines / JOGL Development / Re: Problems loading texture and a question about sprites
|
on: 2008-06-19 19:38:21
|
Can you paste in the call where you are trying to create the texture? Here's a quick example of how to output the texture once you successfully created a Texture object: 1
2
3
4
5
6
7
8
9
| Texture myTex = TextureIO.newTexture( ... );
myTex.bind();
gl.glBegin(GL.GL_QUADS);
gl.glTexCoord2f(0, 0); gl.glVertex2f(0, 0);
gl.glTexCoord2f(0, 1); gl.glVertex2f(1, 0);
gl.glTexCoord2f(1, 1); gl.glVertex2f(1, 1);
gl.glTexCoord2f(1, 0); gl.glVertex2f(0, 1);
gl.glEnd();
gl.glBindTexture(GL.GL_TEXTURE_2D, 0); |
Now you may have to fiddle with the texture coordinates to get the proper orientation of the image, I didn't really bother to look at the order. I would highly suggest you read up on how OpenGL texturing works before going any further. Then once you figure out the basics you can try implementing the techniques that the previous poster mentioned |
|
|
|
|
11
|
Java Game APIs & Engines / JOGL Development / Re: NPOT Textures and glTexImage2D
|
on: 2008-06-19 18:58:12
|
|
A simple idea:
Make an image in photoshop or something, then using the built in texture classes in com.sun.opengl.util.texture, use TextureIO.newTextureData(File file, boolean mipmap, String fileSuffix) to load the texture. Then, look at the data that got loaded into the TextureData's buffer and see how it's arrangement compares to yours. Good luck!
|
|
|
|
|
12
|
Java Game APIs & Engines / JOGL Development / Re: vertex shader causing slowdown
|
on: 2008-06-19 18:45:28
|
|
How do I specify two separate VBOs for my position data? Could I have one VBO with 2D position and TexCoords and a separate one for height displacement? In other words, is this a possible setup for my height field?
VBO1: posX1, posY1, texX1, texY1, ... , posXn, posYn, texXn, texYn
VBO2: posZ1, posZ2, posZ3, ... , posZn
VBO3: triangle indices
thanks
|
|
|
|
|
15
|
Java Game APIs & Engines / JOGL Development / vertex shader causing slowdown
|
on: 2008-06-18 21:04:44
|
So I want to draw a height field using shaders. I have a VBO of 2D position coordinates and 2D texture coordinates, and a texture containing height values. I have a shader that takes in this texture and displaces vertices based on the value in the texture. Before I used this approach I just had one big VBO with 3D position coordinates, but I wanted to be able to deform the height field quickly and easily using shaders by making changes to the texture, so I changed to this approach. So I get this working, but it is really slow (~6fps). The height field is 600x600 and ran at around 50-60 fps when I was using just a VBO. I am curious if this is just too much data for the GPU to handle, or if I am doing something wrong. So here's my vertex shader, 1
2
3
4
5
6
7
8
9
10
11
12
| uniform sampler2D heights;
void main()
{
gl_TexCoord[0] = gl_MultiTexCoord0;
vec4 position = gl_Vertex;
position.z += texture2D(heights, gl_MultiTexCoord0.st).r * 2.0;
gl_Position = gl_ProjectionMatrix * gl_ModelViewMatrix * position;
} |
And the fragment shader: 1
2
3
4
5
6
| uniform sampler2D heights;
void main()
{
gl_FragColor = texture2D(heights, gl_TexCoord[0].st);
} |
And here's a snip of the rendering process just in case: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| * textures and buffers are bound, vertex and texcoord pointers created *
* The field is a flat plane rendered as rows of triangle strips, the shader displaces along z *
int stride = numCols * 4;
shader.engage(gl);
for(int i=0; i<(numRows-1)/2; i++) {
gl.glDrawRangeElements(GL.GL_TRIANGLE_STRIP,
0,
endIndex,
stride,
GL.GL_UNSIGNED_INT,
stride*i*BufferUtil.SIZEOF_INT
);
}
shader.disengage(gl); |
Thanks! |
|
|
|
|
17
|
Java Game APIs & Engines / JOGL Development / When/Where to perform collision detection
|
on: 2008-06-05 18:42:25
|
|
So I am writing a JOGL application that requires some collision detection, but I am unsure what the best practice is as far as when and where to implement your collision detection code.
This program is a real time simulation that needs to check for collision very quickly and accurately, so when should I run my collision detection algorithm? Should I run it once every rendering, in my display() function, Or should collision detection be separated from rendering, in some sort of main loop?
for example;
mainloop() {
while( !done ) {
collisionDetection();
render();
}
}
I am currently using the Animator class that contains its own main loop to continually call my display(), so I would have to either extend the Animator class to include my collision detection in the main loop, or make my own animator type class, but since JOGL is all thready and I would really not like to do that.
So what do you guys typically do? Checking once per frame seems fine as far as accuracy, but the application needs to do a lot of computation once a collision happens, so I am thinking if collision detection is in the same thread as the renderer that it will create a pretty tight bottleneck.
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
