Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (549)
Games in Android Showcase (136)
games submitted by our members
Games in WIP (594)
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  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.
2  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.
3  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.
4  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.
5  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.
6  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.
}
7  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.
8  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.
9  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.
10  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.
11  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.
12  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 System.in, 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.

1  
2  
3  
4  
5  
6  
7  
8  
9  
//In Initialization
BufferedReader sysInReader = new BufferedReader(new InputStreamReader(System.in));

...

//In loop
if(sysInReader.ready()) {
    doWhateverWith(sysInReader.readLine());
}
13  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.
14  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. 
15  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.
16  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.   
17  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:

Quote
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.
18  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?
19  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 error.pid 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.
20  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.
21  Discussions / General Discussions / Re: PrepperCraft! - A free voxel game. on: 2014-11-26 15:55:53
I would advise making some kind of playable demo at the very least before you either post in the WIP board or work on any kind of multiplayer features, like player databases.
22  Game Development / Newbie & Debugging Questions / Re: Buttons, Reading Files, and reading pastbin files. on: 2014-11-24 11:50:33
Also the Scanner class you are already using has support for reading numbers via the nextInt(), nextFloat() (or something similar to these) etc. methods.
23  Game Development / Newbie & Debugging Questions / Re: Bitshift Operators in RGB values? on: 2014-11-10 16:20:33
An excellent tutorial for understanding all things (I joke, if only) bitwise. http://www.wildbunny.co.uk/blog/2012/11/07/understanding-binary/ for future reference and future readers of this post.
24  Java Game APIs & Engines / OpenGL Development / Re: Particle/Billboard rotation issues on: 2014-11-09 11:59:02
So think about it. (Following ignored translation just to be simpler) Your camera rotates your projection matrix by -pitch and -yaw, which simulates a camera rotated by pitch and yaw. Then you have the (rotation part of) the model matrix set to the identity ie not doing anything. So essentially your particle will be rotated by -pitch and -yaw, which obviously works when pitch and yaw = 0 or 180 degrees (180 assuming back face culling isn't enabled) but no other time.

So if you want to get a nice billboard effect, you have to have the model matrix to be rotated by pitch and yaw as well, (or don't have the projection matrix rotated). Now there are better ways to do this computationally speaking but it really isn't necessary.
25  Game Development / Performance Tuning / Re: JNI passing data from Native to Java on: 2014-10-29 13:25:43
To be fair you kind of expect Windows to not allow programs to kill it. Windows is the equivalent of the JVM. It's like the JVM crashing when a Java program doesn't catch an exception. I suspect that Windows did not crash but rather it slowed down trying to find more memory to use and seemed to be non-responsive.
26  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL] Making The Camera Look At A Point on: 2014-10-29 09:27:43
If you are going to roll your own camera implementation straight from the matrices, then you really need to understand the maths. I find the best place to learn this stuff is here: http://www.wildbunny.co.uk/blog/vector-maths-a-primer-for-games-programmers/. It's not too long and will give you a firm basis in vector and matrix maths as they apply to 3D graphics.

If you don't understand this stuff then I'm afraid you are just clutching at straws and you will run into problem after problem.
27  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-10-24 17:10:49
V nice.

Released alpha footage of Basingstoke today: http://www.puppygames.net/blog/?p=1585

Cas Smiley
That's awfully, awfully pretty. Not much else I can say just from the new video.
28  Game Development / Newbie & Debugging Questions / Re: Is using glScalef(...) frowned upon for 2D? on: 2014-10-24 11:37:45
The glScale(), as I stated above, is part of the fixed function pipeline. It can be used with immediate mode or deferred rendering.

There are two different options in OpenGL which everyone gets confused about.

Immediate Mode vs Deferred Rendering
Immediate mode uses commands like glVertex3f(), glTexCoord2f(), glVertexAttrib3f() in between glBegin(), glEnd() blocks. It is called immediate because you send OpenGL the vertex data and the primitives are rendered (pretty much) immediately. Deferred rendering uses VBOs. You send OpenGL the vertex data and it keeps it. You can render primitives with it at any time, hence the rendering is deferred from sending the data.

Fixed Function Pipeline vs Programmable Pipeline
Fixed function uses commands like glTranslatef(), glRotate(), glScalef(), glOrtho(), glMatrixMode() as well as (amongst other things) all of OpenGL's built in lighting support. It is called fixed function because the primitives are modified through set fixed functions, you can modify the parameters of the functions (like the contents of the matrix) but it is quite an inflexible system if you want to to do anything beyond what it is designed for. The programmable pipeline uses shaders to modify the primitives and it is called programmable because, guess what, it is programmable. This means you can do pretty much whatever you want. One important thing to note is that you can still access the fixed function matrices and lighting parameters in earlier versions of OpenGL so if you make use of them, then the above functions will still work.

I hope that clears things up.
29  Game Development / Newbie & Debugging Questions / Re: Is using glScalef(...) frowned upon for 2D? on: 2014-10-23 17:32:56
All of the OpenGL fixed function transformations ie glTranslate(), glRotate(), glScale() etc. perform the transformation the same way. They combine the transformation into the current matrix. Hence using glScale() will have absolutely no effect on performance (other than the actual call to glScale() which is trivial), doing things cpu side by drawing bigger quads would be worse.
30  Game Development / Newbie & Debugging Questions / Re: Collision with inclined plane. on: 2014-10-17 21:15:27
Firstly, that is far too much code to post. You should be posting small sections of relevant code. This code is both long and not relevant and also (and I mean no offence here) but it is in what looks like Spanish and that isn't helping the members of an English speaking forum either.

Now your question. Firstly, are you talking about just the maths of the collision, or the collision response. If you're talking about the collision then a Google search for "plane-sphere collision test" will yield all the results you should need. Come back if you have more specific questions.

If you're talking about the collision response, then you need to think about normal response, the sphere's stretching (and hence bouncing) ability and elasticity of collision.

The normal response is the force the plane exerts on the sphere to stop it falling through and it is called normal response because it acts in the direction of the plane's normal, ie perpendicular to the plane.

Bouncing occurs when the top of the sphere continues to fall whilst the bottom remains at rest, compressing the ball and giving it elastic potential which then converts to kinetic and pushes the ball up. You can cheat this by simply scaling up the normal reaction based on a coefficient of stretchiness (no idea what if any this's name is. Partly Young's modulus but something else as well must be).

Elasticity of a collision determines how much of the energy remains as kinetic and how much dissipates. This will combine with the above so that balls don't bounce infinitely.

To implement sliding properly, you will need to do friction as well.

In terms of answering implementational questions, you will need to post more succinct code. I can deal with the Spanish but English comments would be appreciated.
Pages: [1] 2 3 ... 13
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (13 views)
2015-01-26 04:47:56

Olo (14 views)
2015-01-25 21:26:00

Olo (15 views)
2015-01-25 18:44:22

Robo11 (26 views)
2015-01-25 06:14:26

basil_ (26 views)
2015-01-17 22:29:32

wxwsk8er (26 views)
2015-01-16 21:42:21

wxwsk8er (20 views)
2015-01-16 20:44:20

basil_ (25 views)
2015-01-14 09:46:59

basil_ (21 views)
2015-01-14 09:46:52

wxwsk8er (35 views)
2015-01-13 20:42: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

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17
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!