Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (575)
Games in Android Showcase (154)
games submitted by our members
Games in WIP (623)
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] 2 3 ... 14
1  Game Development / Newbie & Debugging Questions / Re: LWJGL 2D Point lighting on: 2015-04-26 18:18:41
OK so here's a really simple example of lighting using a single white point light using a square attenuation model.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
#version 400 core

in vec3 position;
in vec2 textureCoords;

out vec2 out_TextureCoords;
out vec2 out_WorldPos; //The untransformed position

uniform mat4 projectionMatrix;
uniform mat4 transformationMatrix;
uniform mat4 viewMatrix;

void main(void){
   out_TextureCoords = vec2(textureCoords.x,textureCoords.y);

   vec4 worldView = viewMatrix * transformationMatrix * vec4(position,1.0);
   
   out_WorldPos = position.xy;
   gl_Position = projectionMatrix * worldView;
}


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
#version 400 core
#define ATTENUATION_COEFFICIENT 0.1 //fine tune to get it how you want it

in vec2 out_TextureCoords;
in vec2 out_WorldPos; //The untransformed position

out vec4 out_Colour;

uniform sampler2D texture0;
uniform vec3 light; //x, y refer to position. z refers to intensity.

void main(void){
   float d = length(light.xy -  out_WorldPos);
   float a = light.z / (d * d * ATTENUATION_COEFFICIENT);
   out_Colour = a * texture(texture0, out_TextureCoords);

}


I HAVE NOT TESTED THIS CODE. It should give you an idea of how to go about this even if it doesn't work.
2  Game Development / Newbie & Debugging Questions / Re: LWJGL/OpenGL 3.3+ Voxel Chunk Management on: 2015-04-03 15:11:02
So surely just:
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  
public class Chunk {

   private static final int CHUNK_SIZE = 64;
   private static final int CHUNK_HEIGHT = 128;

   public static void create(int chunkX, int chunkZ) {
      float xOffset = CHUNK_SIZE * chunkX;
      float zOffset = CHUNK_SIZE * chunkZ;
      for (int x = 0; x < CHUNK_SIZE; x++) {
         for (int y = 0; y < CHUNK_HEIGHT; y++) {
            for (int z = 0; z < CHUNK_SIZE; z++) {
               if (y < 16) {
                  if (StartClient.rand.nextInt(2) == 0) {
                     if (StartClient.rand.nextBoolean()) {
                        StartClient.allCubes.add(new Entity(
                              Blocks.cubeStone,
                              new Vector3f(x + xOffset, y, z + zOffset ), 0f, 0f, 0f, 1f));
                     }
                     if (StartClient.rand.nextInt(2) == 0) {
                        StartClient.allCubes.add(new Entity(
                              Blocks.cubeSand, new Vector3f(x + xOffset, y, z + zOffset),
                              0f, 0f, 0f, 1f));
                     }
                  }
               }
            }
         }
      }
   }
}


And also by the looks of it, your code will generate stone blocks and sand blocks in the same location.
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [LibGDX] How to check if Object is in certain part of camera? on: 2015-03-30 13:26:35
Yes, I did mean for the full stop "." to denote the vector dot product (aka scalar product). Sorry for all the confusion, I normally define that. And fyi, I don't use "*" so as not to confuse with the cross product (aka vector product).

As for how to get the left vector, I thought you would already have that to do the frustum test. Essentially you can take it directly from the rotation matrix of the camera. That is the matrix that defines the rotation. Not the viewing matrix (which includes translation) not the projection matrix. Just the rotation matrix.

A1 A2 A3 A4
B1 B2 B3 B4
C1 C2 C3 C4
D1 D2 D3 D4


Then the left vector is just (A1, A2, A3) although if you're using a right handed coordinate system this is the right vector. If you're interested, (B1, B2, B3) is the "up" vector and (C1, C2, C3) is the "forward" vector.

Sorry again for all the confusion.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: [LibGDX] How to check if Object is in certain part of camera? on: 2015-03-28 23:27:39
So if the "Object" is at position A, the camera is at position C, and the camera's left direction is the vector L then:

if (A - C) . L > 0 the object is to the left

if (A - C) . L < 0 the object is to the right

if (A - C) . L = 0 the object is dead in the centre.
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Model Importer - Design Discussion on: 2015-03-15 13:10:20
Sounds plausible. It is a proprietary format after all. But apparently Blender has written their own importer, and have been nice enough to write up some unofficial specs: http://code.blender.org/index.php/2013/08/fbx-binary-file-format-specification/ and http://wiki.blender.org/index.php/User:Mont29/Foundation/FBX_File_Structure. Which might be of some help.
6  Game Development / Newbie & Debugging Questions / Re: Model Wrapper Class Improvements on: 2015-03-15 12:54:54
Premature optimization is the root of all evil. If your game is running too slowly and your analysis shows that the garbage collector is causing it to be slow then you are creating too many objects. Otherwise don't worry about it.
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Model Importer - Design Discussion on: 2015-03-14 14:22:55
So you are right. But the maths really isn't that complicated. If I were you I'd take a look at the COLLADA specs. https://www.khronos.org/files/collada_spec_1_4.pdf. They really are so useful. Chapter 4 is a programming guide and it has a section called "Skinning a Skeleton in COLLADA." Which should explain everything you need to know about skeletal animation. The implementation can be a bit difficult but there are other posts here to help with that.

As for your clusters, I have no idea what they are.
8  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-03-10 15:16:12
kepler

Yes but I wanted to show where it comes from. But also, yes Kepler will give you a more complete view of orbits.
9  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-03-10 08:53:57
...
Your third system would fall apart very quickly , the outer planet is moving faster than the inner ones , if that is the required orbit velocity at that radius then the other two will fall into the star , if it is moving too quickly it will fly off into space. Still very cool effects , would be great to see where these space projects go.

I agree. And it can be proven mathematically. If you equate the gravitational force with the centripetal force:

F = G*m*M / (r^2) = m*(v^2) / r

Where G is the gravitational constant, m is the mass of the satellite, M is the mass of the sun, r is the radius of the orbit and v is the tangential velocity of the satellite.

Cancelling 'm's and 'r's.

G*M / r = v^2

Since G and M are constant, the speed is inversely proportional to the square root of the radius. The greater the radius, the smaller the velocity.

You can use v = w*r to find the angular velocity.

G*M / r = (w*r)^2

G*M / (r^3) = w^2

Hence the angular velocity is inversely proportional to the radius to the power 3 / 2.

It seems like you've gone to a lot of effort to make the star types and positions, it'd be a shame if your orbits weren't right.

 
10  Java Game APIs & Engines / OpenGL Development / Re: Using Slick2D's Image.getGraphics crashes on some machines on: 2015-03-02 19:11:48
Post the exception/error message as well as the stack trace.
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Model Importer - Design Discussion on: 2015-03-02 19:10:32
So I have done something like this before for a few formats. Essentially I just built everything around the way COLLADA structures  it's data. It's an extremely comprehensive format that covers everything and it's designed by lots of collaborators (the Khronos ARB) so it's quite a good average of all the stuff out there.

Also it'll probably be the most complex format you will support so better that you bend everything else to fit it than vice versa.
12  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-02-28 10:10:59
Having started a module on control theory, I cannot see anything like that without thinking about transfer functions and feedback loops. Looks good.
13  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-02-20 21:33:03
Additionally angles are usefully avoidable in the first place.

Yes. Vectors, matrices, quaternions are all better than angles in every respect. Certainly for a computer. As with most complex things in maths, learning about them is the hard part but once you have, then they make things so much more simple and general case.

And "degrees" is more natural is mostly myth.  That's only true for very large angles.

I disagree. Certainly most people would be fine with pi/3, pi/2, pi etc. but once you go to more complex multiples than that then you have to think about it to figure out how big the angle actually is. Or at least I do. And I am studying engineering which is practically maths. I wouldn't be surprised if they dropped you marks if you tried to solve a problem in degrees instead of radians.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-02-20 09:19:23
The idea of degrees is that it takes the sun exactly 360 days to travel around the earth.  And that's exactly how useful they are.

And it doesn't even do that.

But degrees have a use in that they are what people know about. They are what people learn about and hence what most of us think about intuitively with angles. So why not have a degrees to radians method so that people can use their intuitive knowledge in, for example, initial conditions. Yes you should discourage people from using degrees but you shouldn't prevent them entirely.
15  Game Development / Game Mechanics / Re: Calculate Derivatives for Newton's Method on: 2015-02-16 09:21:36
So the first thing to understand about the Newton-Raphson method is that is is an iterative process. You take the answer from the last iteration (xn), stick it into the next iteration (xn-1). Now as you keenly noticed, this requires an initial starting point. The way to get this is to guess an answer, for a human quite simple, for a computer I don't know of any methods of guessing an answer. If you choose well and your guess is near to a root then the solution will converge quickly (in fewer iterations) if you guess poorly then it will take longer. Also, if the function has multiple roots, then the starting point will affect which root is converged upon.

Now calculating derivatives. A derivative is actually defined as:



Now computationally, since we are just using approximations anyway, why not approximate the derivative by using a value of h close to 0. Like 1E-10 for example. That's very simple for a computer to do. (And although I've never heard of it before, I thought secant was a trig function, it seems like this is what they mean by the secant method although they apply it to second derivatives)
16  Game Development / Game Mechanics / Re: questions on opengl, lwjgl(slick util) on: 2015-02-08 22:15:36
1) Depends on impl a bit and what generation you are working with and stuff. In general not the most expensive method but not to be abused either. If you can easily cut down on texture binds then great, if not then lets remember about how sick and evil premature optimization is.

2) No.

3) Don't know the actual implementation in Slick (the method doc should really say) but I would guess yes - it releases the OpenGL texture object.

4)  Releases all textures, buffers, shaders etc. and the whole OpenGL context.

5) Premature optimization again but if Slick has some kind of "Source" class, then I would expect that also has a "release()" method.

6) A PNG is a compressed image file format. When you load a texture, it is stored in a non compressed format so it can be accessed quickly. How much space it takes up depends on the format you store it in. A typical RGBA format is 4 floats per pixel so will take up (roughly) 4 * 4 = 16 bytes per pixel. You will know when you're video card is stressed when the program starts lagging. Premature optimization.

7) I know of no conventional way. Your enum method sounded good. But do what is easier and what works. Premature optimization.
17  Discussions / Miscellaneous Topics / Re: The joys of game dev in C++ on: 2015-02-02 11:39:55
...
Yes, it crashes lol.

Well to be more specific, it throws an Exception. The exception can be caught to avoid a crash. That is a quite significant difference to c++ null pointers being dereferenced. In practise though it makes no difference (although I think Java's handling of exceptions makes an NPE easier to debug) since we rarely catch NPEs but rather check to see if a variable is null before dereferencing as you would in c++.

But we are good programmers so let's be precise.
18  Discussions / Miscellaneous Topics / Re: Java Certificates on: 2015-01-31 18:23:45
So what value do these certificates have?

As much as you paid for them. I have never seen anyone put any value into certification as far as job prospects are concerned. And neither would I.
19  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2015-01-29 11:13:49
Not in the same FloatBuffer object but you should stick it in a ByteBuffer.

So your "creating the buffer" code will look like this.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
private ByteBuffer createInterleavedArray() {
    ByteBuffer bb = BuferUtils.createByteBuffer(m_vertices.length * 52);
    for(int j = 0; j < m_vertices.length; j++) {
         bb.putFloat(m_vertices[j].m_position.m_x);
         bb.putFloat(m_vertices[j].m_position.m_y);
         bb.putFloat(m_vertices[j].m_position.m_z);
         bb.putFloat(m_vertices[j].m_normal.m_x);
         bb.putFloat(m_vertices[j].m_normal.m_y);
         bb.putFloat(m_vertices[j].m_normal.m_z);
         bb.putFloat(m_vertices[j].m_uv.m_x);
         bb.putFloat(m_vertices[j].m_uv.m_y);
         bb.put(m_vertices[j].m_influences[0].m_bone_index);
         bb.put(m_vertices[j].m_influences[1].m_bone_index);
         bb.put(m_vertices[j].m_influences[2].m_bone_index);
         bb.put(m_vertices[j].m_influences[3].m_bone_index);
         bb.putFloat(m_vertices[j].m_influences[0].m_bone_weight);
         bb.putFloat(m_vertices[j].m_influences[1].m_bone_weight);
         bb.putFloat(m_vertices[j].m_influences[2].m_bone_weight);
         bb.putFloat(m_vertices[j].m_influences[3].m_bone_weight);
    }
    bb.flip();//Or whatever
    return bb;
}


and then setting up your pointers.

1  
2  
3  
4  
5  
glVertexAttribPointer(vert_pos, 3, GL_FLOAT, false, 52, 0); //3 * 4 = 12 bytes
glVertexAttribPointer(color, 3, GL_FLOAT, false, 52, 12); //3 * 4 = 12 bytes
glVertexAttribPointer(tex_coord, 2, GL_FLOAT, false, 52, 24); //2 * 4 = 8 bytes
glVertexAttribPointer(joint_indices, 4, GL_BYTE, false, 52, 32); //4 * 1 = 4 bytes
glVertexAttribPointer(joint_weights, 4, GL_FLOAT, false, 52, 36); //4 * 4 = 16 bytes


So you see ByteBuffers are great because you can mix and match data however you want.
20  Java Game APIs & Engines / OpenGL Development / Re: Applying transformations to vertices on: 2015-01-28 15:12:56
The one thing I could see was these two lines:

1  
2  
gl.glVertexAttribPointer(joint_indices, 4, GL.GL_BYTE, false, Buffers.SIZEOF_FLOAT * Vertex.SIZE, Buffers.SIZEOF_FLOAT * 8);//32
gl.glVertexAttribPointer(joint_weights, 4, GL.GL_FLOAT, false, Buffers.SIZEOF_FLOAT * Vertex.SIZE, Buffers.SIZEOF_FLOAT * 12);//48


So when you create the buffer, you specify the joint indices as a float each. But then you interpret the indices as a byte in your pointer. That can't be good.

Also a byte is obviously one byte long and you have 4 of them for the indices. However you have the offset of joint_weights (and I would guess the stride as well) set as if the they were 4 floats (for 16 bytes).

But to be honest I would have thought that these issues would have caused more problems. But correct them and we'll see what happens.
21  Game Development / Newbie & Debugging Questions / Re: Trouble Implementing Simple Projectile into Slick2D on: 2015-01-27 18:10:16
And is this not working?

You need to tell us what is going wrong.
22  Game Development / Newbie & Debugging Questions / Re: Texture always facing the camera on: 2015-01-18 17:39:59
This is called billboarding. And there are essentially two methods or doing it.
1) Don't use the camera rotation as part of the view transform when you are billboarding. The translation part yes but not the rotation method.

2) You can create the geometry you're rendering using the camera's left and up axis for the geometry's left and up axes. Example:
To render a quad of width "w" and height "h" at position "P" with a camera left axis "L" and up axis "U", then the 4 points of the quad would be:
P,
P + w*L,
P + w*L + h*U,
p + h*U

For more help, ask a more specific question and give some information about your current setup.
23  Game Development / Game Mechanics / Re: Translate Point By Pitch/Roll on: 2015-01-14 22:49:57
Also, this must be without any matrices or quaternions.

Why are you trying to make things difficult for yourself? If there is a good reason I will be happy to help you out but I cannot imagine a situation where using matrices wouldn't make this task a whole lot easier.

Seriously, try and imagine rotating a vector about the y axis, the about the x axis and finally about the z axis? Confused yet? No, try drawing down a diagram for each stage with a nice little right angled triangle so you can work out the trigonometry. I say these things because I have tried and it is not worth the effort.
24  Game Development / Newbie & Debugging Questions / Re: Up Vector calculation for matrices on: 2015-01-14 17:27:40
Only normalize a vector when the length isn't one. That should fix this issue.
The issue is that when you cross two parallel vectors, you get a zero magnitude vector so if the forward vector is (0, 1, 0) or (0, -1, 0). Then you normalize a zero vector (giving NaN) or cross it to get another vector (giving another zero vector).

...
Setting the direction to a vector of (0.1, -1.0, 0.0) or (0.0, -1.0, 0.001) seems to work perfectly.

It'll work until you have a forward vector of (0.1, -1, 0) or (0, -1, 0.001). If you are in a situation where your forward vector might be pointing straight up, better to do a check to make sure it doesn't. One conditional is not going to be noticed.
25  Game Development / Newbie & Debugging Questions / Re: Up Vector calculation for matrices on: 2015-01-14 13:44:24
Yeah, sorry. Forgot to say you have to check for this unique case.
26  Game Development / Newbie & Debugging Questions / Re: Procedural Generation on: 2015-01-13 17:04:11
To be honest I think what you are trying to achieve is a bit silly. For asteroids and things of similar scale @HeroesGraveDev is nice. But as soon as you move up to moons or even planets, the scales you are talking about mean that either you are going to see a sphere (as seen from far away) or you are going to see a section of terrain.

Why not treat the planet as an icosahedron and generate each triangle as you would a flat (you know what I mean) 3d terrain. The only time the fact that it is a sphere comes into play is when you need to work out the triangles' neighbours.
27  Game Development / Newbie & Debugging Questions / Re: Up Vector calculation for matrices on: 2015-01-13 16:52:26
What you do is assume that the camera isn't going to be upside down and so "up" will be in the same direction as (0, 1, 0) (by which I mean (dot(up, (0, 1, 0)) > 0). So with that in mind you assume the up vector is (0, 1, 0), calculate the left vector then you have the left and forward vectors from which to calculate the actual up vector.

Pseudo code cos everyone loves a bit of pseudo code.
1  
2  
3  
4  
5  
6  
7  
8  
Matric calcMatrix(Vector forward) {
    Vector up = new Vector(0, 1, 0);
    Vector left = cross(up, forward); //I think it is that way round, might be the other way though. "i"s, "j"s and "k"s confuse me.
    up = cross(forward, left); //Ditto as above.
    left.normalize();
    up.normalize();
    return createOrthoBasisMatrix(left, up, forward); //Make the matrix.
}
28  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-12 12:29:37
I used IntBuffer for indices (since it's more simple than ByteBuffer) for glDrawElements but LWJGL don't have method facilities for use an IntBuffer and providing the number of vertices to fetch except by consumming all datas from the buffer. But my indices buffer is filled with all primitives that i had to draw by multiple calls.

So I forgot to mention this in my last post but in the same way you use the buffer's position to specify the offset, you use the buffer's limit to specify the number of indices. Personally I have this little utility method because it speeds things up no end.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
public static ByteBuffer getSlice(ByteBuffer bb, int offset, int length) {
    int oldpos = bb.position();
    int oldlim = bb.limit();
    bb.position(oldpos + offset);
    bb.limit(oldpos + offset + length);
    ByteBuffer bb2 = bb.slice();
    bb.limit(oldlim);
    bb.position(oldpos);
    return bb2;
}

Which gives you a new buffer which shares content but has independent position and limit. Which is handy. And you can just replace "ByteBuffer" with FloatBuffer of IntBuffer or any kind of buffer and it'll work for them too.

So nglDrawElements( p.type , p.indicesCount , GL11.GL_UNSIGNED_INT, MemoryUtil.memAddress( indicesBuffer ) );
Is the same as glDrawElements(p.type, getSlice(indicesBuffer, 0, p.indicesCount));

I have two technical approachs for handling shaders
  - only one program but i attach/detach shaders when needed
  - One program for each shaders topology.

Go for option 2. I have never seen anyone do option 1. I think the reason (what follows is a lot of guess work, I'd be very happy to be corrected) is that a shader program is not just some executable code, it is all the memory and stuff that goes with it. Essentially all the "heavy lifting" is done in the glLinkProgram() function. That will be where the compiled shader code gets put somewhere where it can process stuff and all the memory associated with the program is allocated and stuff. You don't want to be doing that often, certainly not several times a frame. As a general rule I find, that mess around with OpenGL objects as little as possible in the game loop. You have to bind them. Do so as few times as possible. Sometimes you have to update data in Buffers. Do so as few times as possible. You get the picture.

In fact, once you have linked the shader program, you can safely delete the shader objects that are attached to it.
29  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-08 11:07:53
while  reading you, you are seems to say that VBO and shaders are not suitable together and you must go to VAs if i want to use shaders (that i will soon for doing repeated atlases subregion) ?

I said that vertex attributes (not VAs, VA stands for vertex array in my post) are more suited to shaders since they are more flexible. Using VBOs, VAs or even immediate mode has absolutely no impact on whether you want to use shaders or not.

You say than glTranslatef(), glRotatef() are fixed pipeline stuff, so that means we should avoid theses ? At this time i don't use theses but i use some matrix mode when i need to apply an affine transform (that remains the same than glTranslatef() or glRotatef() but provide more flexibilty).

Yes you should avoid these, but until you are using shaders, you have to use them. Shaders are the only alternative. And yes any OpenGL function to do with matrices is one to avoid. By then end, the only OpenGL function you should be using for matrices is glUniform().

How work the buffer "fb" communication between the cpu and the gpu. You pass it to 2 calls (glVertexPointer and glColorPointer). It have 2 copy into the GPU or the OpenGL API retains that is the same buffer instance and communicate it only on time to the GPU at the end ?

My understanding is that the only thing that gets passed to OpenGL when you call glXXXPointer() (for a VBO or a VA) is an offset. If there is a buffer bound when it is called, OpenGL treats it as an offset into that buffer, otherwise it treats it as an address in cpu memory (when you call it with the function with a Buffer LWJGL does it's magic to translate that into a memory address). It is only when you do the draw call that OpenGL starts reading data from the memory address it has. So you can see that if you are replacing all of the data each frame then there really shouldn't be too much of a difference between VBOs and VAs.
30  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-06 19:21:10
(1) Enabling GL_TEXTURE_2D and enabling GL_TEXTURE_COORD_ARRAY are two different things. GL_TEXTURE_2D should be enabled whenever you are drawing something with textures. Also see (*). GL_TEXTURE_COORD_ARRAY should be enabled whenever you are drawing something and the texture coords are coming from the glTexCoordPointer().

(2) Firstly see (*). These functions should work exactly the same as with immediate mode rendering.

(3) Yes, transforms, blend settings and uniforms can essentially be seen as OpenGL state. And the settings that get applied to the rendered primitives is the state OpenGL is in when you call the glDrawXXX() function. In terms of placement, it kind of replaces glEnd().

(4) So first of all I will explain vertex attributes (whereas VA stands for vertex arrays - you see why we were complaining about naming being confusing) but bear in mind they don't particularly apply to what you are asking. See (*) as to why they were brought up in this topic. So in the fixed function pipeline there are a few set "channels" (for want of a better name) of data with a fixed function. Eg position, colour, tex coords, normals. But when we get to using shaders we want things to be a bit more versatile so we have "vertex attributes" which are exactly the same as position, colour, normal etc except that they can be used for whatever you want and they are referenced with an index instead of a name.

So if we were using index 0 for the position.
"glEnableClientState(GL_VERTEX_ARRAY)" -> "glEnableVertexAttribArray(0)"
"glVertexPointer(2, GL_FLOAT, stride, offset)" -> "glVertexAttribPointer(0 /*index*/, 2, GL_FLOAT, GL_FALSE /*normalized*/, stride, offset)"
"glVertex2f(x, y)" -> "glVertexAttrib2f(0 /*index*/, x, y)".
So you can see that other than the  index and normalized parameters, they work exactly the same as before. But you are not using shaders so this isn't relevant to you right now.

Now Vertex Arrays. The basic idea is that instead of pointing to a position in a VBO on the gpu, you point to a location in your program's cpu memory which in LWJGL is implemented by passing a Buffer instead of an offset. An example then.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
//With VBOs
//Init
FloatBuffer fb = BufferUtils.createFloatBuffer(3 * (2 + 3)); //3 vertices with 2 position floats and 3 colour floats.
fb.put(new float[] {...}); Imagine this is the data for a triangle with XYRGB interleaving.

int bufferId = glGenBuffer();
glBindBuffer(GL_ARRAY_BUFFER, bufferId);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, fb, GL_STATIC_DRAW);

...
//Render (Assuming you've enabled all the relevant stuff)
glBindBuffer(GL_ARRAY_BUFFER, bufferId);
glVertexPointer(2, GL_FLOAT, 20 /*(2+3)*4*/, 0);
glColorPointer(2, GL_FLOAT, 20 /*(2+3)*4*/, 8 /*2 * 4*/);
glDrawElements(...); //You know this bit

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
//With VAs
//Init
FloatBuffer fb = BufferUtils.createFloatBuffer(3 * (2 + 3)); //3 vertices with 2 position floats and 3 colour floats.
fb.put(new float[] {...}); Imagine this is the data for a triangle with XYRGB interleaving.
//And then we DON'T create a VBO for the data.

...
//Render (Assuming you've enabled all the relevant stuff)
fb.position(0); //Move the buffer's position to the vertex offset.
glVertexPointer(2, 20 /*(2+3)*4*/, fb); //Notice that we don't pass the "type" parameter in LWJGL becuase it will infer that these are floats since it is a FloatBuffer
fb.position(2); //Then we move the buffer's position to the colour offset.
glColorPointer(2,20 /*(2+3)*4*/, fb);
glDrawElements(...); //You know this bit


So again very simple.

(*) And a little appendix to clear things up. In your first post and subsequently you referred to these improvements as moving away from the fixed function pipeline. This is wrong but a very common misconception, not sure why. What you are doing is moving away from "immediate mode rendering" (glBegin() and glEnd()) and towards "deferred rendering" (VBOs, IBOs, VAs and pointers).

The fixed function pipeline is OpenGL's built in transform stuff (glTranslatef(), glRotatef() ...) and quite a lot more. The opposite of the fixed function pipeline is the programmable pipeline which is shaders. This is why vertex attributes were brought up - if you were using shaders (which technically you did say you were) then vertex attributes are a good idea, just because they are more flexible. And a wee bit of extra info, if you were using the programmable pipeline then you wouldn't need to enable GL_TEXTURE_2D to draw textures.

That was a long post. Hope it helped.
Pages: [1] 2 3 ... 14
 
BurntPizza (29 views)
2015-04-23 03:42:11

theagentd (35 views)
2015-04-22 16:23:07

Riven (48 views)
2015-04-16 10:48:47

Duke0200 (59 views)
2015-04-16 01:59:01

Fairy Tailz (41 views)
2015-04-14 20:13:12

Riven (44 views)
2015-04-12 21:36:37

bus hotdog (60 views)
2015-04-10 02:39:32

CopyableCougar4 (66 views)
2015-04-10 00:51:04

BurntPizza (70 views)
2015-04-06 22:06:58

ags1 (68 views)
2015-04-02 10:58:48
How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27
java-gaming.org 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‑gaming.org
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!