Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (555)
Games in Android Showcase (148)
games submitted by our members
Games in WIP (601)
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 ... 13
1  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.
2  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.
3  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.
4  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)
5  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.
6  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.
7  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.
8  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.
private ByteBuffer createInterleavedArray() {
    ByteBuffer bb = BuferUtils.createByteBuffer(m_vertices.length * 52);
    for(int j = 0; j < m_vertices.length; j++) {
    bb.flip();//Or whatever
    return bb;

and then setting up your pointers.

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.
9  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:

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.
10  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.
11  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 + 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.
12  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.
13  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.
14  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.
15  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.
16  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.
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.
    return createOrthoBasisMatrix(left, up, forward); //Make the matrix.
17  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.
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();
    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.
18  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.
19  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.

//With VBOs
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);

//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

//With VAs
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.
20  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-04 02:24:50
That does not seem to be the case. glGenBuffers() should only be called once from OP's code.
What I meant was the actual memory of the buffer was being released and reallocated every flush. And I'm sure that the allocation of the buffer (as opposed to the generation of the OpenGL object) is the longest bit. So I just minced words. You may well be right but I find it very hard to believe that VBOs (even dynamic ones using glBufferSubData()) would be faster than VAs under these conditions. Not that it really matters - I think we're dealing with pretty minuscule differences either way - I recommend VAs for sprite batchers just because they're simpler to use.

And as a side note, from what I hear, what is debatable is whether VAOs are really the way to go performance wise. But I don't know anything about that because beyond figuring out how they work I don't use them.

Also I second @gouessej, let's not confuse VAOs and VAs. Whoever came up with these names should be shot but since that wouldn't help us out let's just not confuse ourselves.
21  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-03 22:18:46
So essentially this is what we call (in the trade) a sprite batcher. And (I will compare with what I do, which is not necessarily the best way) you are doing everything right but there are two ways you could obviously (to me) improve.

1) You don't have to use VBOs. You can also use what are called "Vertex Arrays" which work in almost exactly the same way except that instead of the vertex data coming from an OpenGL buffer object, they come from a buffer in CPU memory. Implementation wise, there is a glVertexAttribPointer() function in LWJGL that takes a ByteBuffer (or Float or Int) as a parameter instead of an offset. The offset into this data that OpenGL uses is the position of the ByteBuffer. This will be more efficient than what you are doing which is essentially re-creating a buffer object each time you flush.

2) Generally I have a series of batchers each with their own unique vertex attribs. A begin() method binds textures and sets up pointers. Then the drawXXX() methods add vertex data to the (cpu side) buffers and if the buffers are overflowing then flushes them. Then an end() method flushes if anything is left in the buffers. The crucial thing here is that you set up each set of pointers as few times as possible per frame which is obviously efficient. (So yes, essentially it is back to glBegin() and glEnd())

2 - cont.) Furthering this point, I will also have my batchers only draw the same "type" of geometry. Ie only quads or only 5-sided polygons or only lines. The advantage of this is that the index buffer will be the same each and every time so you can make it entirely static in an IBO. (Grab every bit of performance you can, because why not).

Otherwise you are doing very good (as far as I know). Hope I've been helpful.
22  Game Development / Newbie & Debugging Questions / Re: [solved] Reading commands without waiting on: 2015-01-01 14:06:42
Actually there is no need to use a different thread. The InputStream has an available() method which estimates how many bytes are available to read at that instant without blocking (according to the javadoc). In the case of, it will be the number of characters available to read in at the command line (not an estimate).

An easier way though would be to wrap it up in a BufferedReader so you can read a whole line at a time with one method call in which case you are using the ready() method. Similarly, it returns true if the next read() command is guaranteed not to block.

//In Initialization
BufferedReader sysInReader = new BufferedReader(new InputStreamReader(;


//In loop
if(sysInReader.ready()) {
23  Game Development / Newbie & Debugging Questions / Re: Getting null pointer exception when tring to add/remove objects. on: 2014-12-20 16:11:30
Well where do you set the "playState" variable of Ex? Either you haven't posted that code or you don't set it which would give you a NPE.
24  Game Development / Game Mechanics / Re: How to do 3D Animation on: 2014-12-18 21:44:02
I would recommend the COLLADA format. It is an open-source, xml based format which supports pretty much anything you can think of. Can be a bit of a complex thing to parse but you can ignore most of it so it is OK.

As for consistent rate of animation, you need to use a time step. You calculate the time difference between the last loop and the current loop and use that as a parameter for how far the animation should move on. 
25  Game Development / Newbie & Debugging Questions / Re: LWJGL calls in Slick2D code. on: 2014-12-18 10:46:00
OpenGL is a state machine. Slick sets its state up to be right for how it renders it. You can't just type some code and assume it'll be in the right state for exactly what you want to do. Use Slick or use OpenGL directly.
26  Game Development / Newbie & Debugging Questions / Re: LWJGL - Immediate rendering alternative on: 2014-12-18 00:17:14
Well in fixed function pipeline (which you are probably using with calls like glVertex3f()) there are a couple of matrices defining transformations. GL_PROJECTION_MATRIX and GL_MODELVIEW_MATRIX. The matrix you are currently working on is defined with glMatrixMode(). Modifying these matrices is done with glLoadMatrix(), glLoadIdentity(), glTranslatef(), glRotatef, glScalef(), glOrtho(), glFrustum() and similar calls.

But tbh I would try to stick with deferred rendering. You can use the variant of the glVertexAttribPointer() command which takes a buffer directly to achieve what is essentially immediate mode rendering without changing any of your rendering setup and without the hassle of messing around with VBOs.   
27  Game Development / Newbie & Debugging Questions / Re: "Wrong Component Type or Count" GLSL shader error on: 2014-12-14 14:54:27
Actually I agree with @SHC. I think you are calling one of the glUniformXX() variants with the wrong number / type of arguments which if you read the docs:

GL_INVALID_OPERATION is generated if the size of the uniform variable declared in the shader does not match the size indicated by the glUniform command.

GL_INVALID_OPERATION is generated if one of the integer variants of this function is used to load a uniform variable of type float, vec2, vec3, vec4, or an array of these, or if one of the floating-point variants of this function is used to load a uniform variable of type int, ivec2, ivec3, or ivec4, or an array of these.

I can't see any shader creation/compiling/linking functions that will generate a GL_INVALID_OPERATION if the shader compilation failed. And if it fails, the shader definitely should not work. But a uniform set fail can still work if the default value works or it is set elsewhere.
28  Discussions / Miscellaneous Topics / Re: Pathfinding, making it efficient but basic on: 2014-12-13 13:26:13
Why do you need to make a copy? Why can't you just use the same instance every time?
29  Java Game APIs & Engines / OpenGL Development / Re: Slick2D Shader Crash on: 2014-12-05 21:54:04

Ah, I can explain!

1) It's an trace. The program crashed in native code.
2) The disjoint between the function called and the function in the trace is because the JVM optimized out intermediate function calls. So setUniform4f calls nglUniform4fARB.

1) I know it is a crash in native code. That much is evident, I meant that I've never seen it (Windows?) fail to print the native stack trace.
2) Whilst the JVM may or may not optimize out deferred function calls, 99% of the time you will never see it in debugging, and the other 1% of the time, it is usually to do with implicit anonymous classes or automatic (un)boxing and the like.

I'm inclined to agree with @theagentd btw. Smells like a driver bug, random intermittent crashes in a function called repetitively in the same context. Try searching online to see if the graphics cards have any known problems.
30  Java Game APIs & Engines / OpenGL Development / Re: Slick2D Shader Crash on: 2014-12-03 13:21:56
To be honest, what concerns me is the error message.

1) I've never seen a an error printing the native stack.
2) The stack trace doesn't make sense.

this function "org.lwjgl.opengl.ARBShaderObjects.nglUniform4fARB(IFFFFJ)V" is not called in the source you have shown us. The method you are calling is "setUniform4f()" in ShaderProgram.
Pages: [1] 2 3 ... 13
BurntPizza (23 views)
2015-02-27 06:09:35

BurntPizza (20 views)
2015-02-27 05:56:17

Riven (11 views)
2015-02-27 02:34:15

Riven (18 views)
2015-02-27 01:47:26

Riven (18 views)
2015-02-27 01:46:04

BurntPizza (13 views)
2015-02-27 00:52:04

BurntPizza (15 views)
2015-02-27 00:50:29

Riven (35 views)
2015-02-26 23:38:45

Riven (12 views)
2015-02-26 23:37:24

BurntPizza (30 views)
2015-02-26 21:13:04
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 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!