Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
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]
1  Game Development / Newbie & Debugging Questions / Re: 3D trigonometry on: 2013-10-19 01:48:19
I could be misunderstanding what you're looking for, but I you'll want to look into Linear Algebra for doing 3D calculations.
It sounds like you're trying to code a rendering pipeline. And since you posted this in the newbie forum, I'm guessing that's not really want you want to do.
I don't want to flood this with a wall of text, so the punch line is: there's a reason things like DirectX and OpenGL exist; they're an interface to the graphics hardware and
for developers, that's the lowest level we need to take things. They're not libraries which handle all the fundamental 3D operations nor required math.

From An API (OpenGL/DirectX) Perspective:
When dealing with points, you simply have a 4x4 Matrix which represents the the xyz rotation/scale/translation.
Then you have a 4D Vector, which represents the coordinate of a point.
Where the point is displayed is basically the result of the matrix multiplied by the vector.
You could try and do all this with Trig, but you'd be making it much harder on yourself. The basic linear algebra you would need to learn is pretty easy to boot. I suck with math and I picked it up in like a day or two.

Images are handled quite differently and you won't get into that for a bit. You basically create an object with points and then wrap it with a texture.

Java OpenGL Bindings:
In order for Java to talk with OpenGL, it uses bindings. To the best of my knowledge, there's only LWJGL and JOGL.
They're mostly just an interface for working with OpenGL. But we'll prolong the differences for another time.

Java 3D
I've never worked with Java 3D. My understanding is it now uses JOGL anyway.

If none of the above helps, then you'll probably want to specify exactly what it is you're aiming for and what environment you're working in (JOGL/LWJGL/something else).
I know you mentioned you're just trying to scale an image in 3D, but you'd be surprised how open ended that is. Scaling a texture/image in 3D would fall under a specific need for a specific reason and is probably not what you mean.
2  Discussions / General Discussions / Re: Java-Gaming at Minecon on: 2013-10-15 18:24:42
I don't know if this necessarily fits, but I've noticed one of the most common reoccurring beginner questions I've seen here is:
"should I use LWJGL, LibGdx or JME", which really isn't an apples to apples comparison.

Maybe you could provide a general explanation about the the differences between bindings/OpenGL vs engines. This would hopefully refine their information search, depending on which direction they choose; and even if they choose a different language.
I get the distinct impression a lot of people get confused between the two and ultimately end up blindly selecting one of the options.

3  Game Development / Game Play & Game Design / Re: 2D vs 3D World Immersion on: 2013-10-07 22:41:29
After spending a great deal of time working in 3D, I would argue it's easier to create an immersive environment in 2D. With 2D, you can create backdrops to set the mood for the level/scene. 3D often offers players the freedom to run all around the place and inspect the things you wish they wouldn't notice.
Think of it like the Statue of Liberty; from a distance it looks amazing, up close you'll find she's a dirty girl in need of some serious cleaning.

This is a neat little web site showing off some 8 bit backdrops.
http://www.effectgames.com/demos/canvascycle/

Of course it's still possible to create great 3D environments, it's just going to require a lot more finesse.

Immersive opinions aside, I would weigh the 'ol 3D vs 2D design based on which format fits your game play and how much work do you want to dump into this.
4  Game Development / Newbie & Debugging Questions / Re: some Garbage Collection and LWJGL memory managment questions on: 2013-09-07 10:09:17
To further confuse the #3 answer: In my experience, both are right.

From a released application stand point, you shouldn't have any worries if you're not cleaning up after yourself.
During development however, you can shoot yourself in a sensitive body part.

I think my best example for this was working with Transform feedback buffers. I was getting different results based on how long I would wait before restarting the application.
The punch line being I was somehow picking up the handle to those buffers before the OS had cleared them out. When I waited long enough, the buffers would clear and things behaved as expected.

My opinion on the matter:
If you've built your graphics objects so they're easy to handle/unload, then do so. A clean home is a happy home.
If things just aren't that friendly, then f-it. A clean home is the first sign of a serial killer.
5  Discussions / General Discussions / Re: How to not let someone steal your game ? on: 2013-09-05 23:22:25
I see this as a goal instead of a hurdle. If I make something popular enough for people to want to steal from it, then it's a good day.

While it doesn't hurt to research and ask questions like you're doing, just don't lose any sleep over it unless you start to amass a lot of attention.
6  Discussions / General Discussions / Re: Do you get bored, discouraged or demotivated with your projects? on: 2013-08-28 19:33:01
The more you hate your project, the better it is.

Well that may not be completely true, but I do believe there comes a point when it transitions from 'fun' to 'work'. That doesn't mean you won't enjoy the successes you achieve, they'll just be separated by periods masochism.

Furthermore, it's fine to feel you've just pieced together the next Frankenstein. If you walk away thinking you couldn't have done it any better, then you haven't gained that much experience from the process. And you won't level up. Cause you were just beating on level 0's.

There does reach a tradeoff point with reworking your own code. Not enough streamlining can make things difficult fix later, too much reworking and you're just code-turbaiting. I find a healthy mix of comments chastising my own work is a good indication of when things need to be mangled.

I don't believe there is any finite set of rules for when a project needs a bus ride to the trash can. It comes down to the individual banging away at the keyboard. What are your realistic goals for the project.

Keeping yourself on task is the crux of all this. It's ok to step away from a project, but be realistic and keep in mind the longer you are away, the more likely you are to never return. And the code ain't goin ta write itself. Code requires time. You're not going to come back after a 6 month break, type a few keys and magically create the next masterpiece of the game world.

After having dumped all my free time (and I do mean ALL) into a project for the past 2 years, this is my take-away for staying on track. Take it a piece at a time. Don't get caught up in "what about ______". If you don't focus on just one small task at a time, then you'll get overwhelmed.

-(Insert Something thought provoking and ends with "A journey of a thousand miles begins with the first step")
7  Game Development / Newbie & Debugging Questions / Re: Texture atlas bleeding w/mipmap on: 2013-08-22 22:40:03
I think you'll save yourself a lot of trouble if you switch to texture arrays.

After researching ways to correct atlas bleeding, I was left with the impression that doing so leads down the path of extra processing and trying to handle special cases. Before texture arrays, this was the only viable way to handle tiled atlases, but now I wouldn't recommend it. Not the same case for UV maps though of course.

Aside from not having to worry about bleeding, texture arrays have the added benefit of being able to wrap. In my opinion, it's this which makes them exponentially better than a regular tiled atlas.

Working with texture arrays and adding them into your project should be pretty easy. I find them to work very similar to regular textures. Most the changes would be in your initial loading of textures. After that it's just making sure you bind a texture array when you draw and adding another coordinate for accessing the texture in your shader.

Here's an explanation about how to use them.
http://www.opengl.org/wiki/Array_Texture
8  Game Development / Newbie & Debugging Questions / Re: [LibGDX] Decals and Models on: 2013-08-15 22:18:01
The only 3D method I know for decals is using projective texture mapping. The end result mimics the way a projector would display an image in real life. The process however is a bit different.

It's hard to explain it in a brief description, but you basically use a biased matrix to convert a texture to the proper UV coordinates of a model. This is combined with a "look at" matrix. I should note any predefined UV coordinates for a model are not used nor needed for this. When I first started learning projective texture mapping, I often got tripped up thinking I needed to use the baked in UV coordinates of a model.

It's a technique often used in conjunction with shadow mapping to project the shadows on to objects, so you may find some useful information in tutorials which talk about shadow mapping.

Here are some further explanations about projective texture mapping.
http://blog.wolfire.com/2009/06/how-to-project-decals/
www.arcsynthesis.org/gltut/Texturing/Tut17 Projective Texture.html

Unfortunately, I found the most accurate and best explanation to come from a book: OpenGL 4.0 Shading Language Cookbook.
http://www.packtpub.com/opengl-4-0-shading-language-cookbook/book

But before you go through all that, I would check through LibGDX to see if they've already got something to create the projective matrix for you. Maybe you'll get really lucky and find they've got something set up for projecting. If not, you're going to need to code your own shader.

Also Note: If you're maintaining an orthogonal view, then using a depth buffer as DaveDes alluded to, may be easier to understand instead of applying a full 3D solution.
9  Game Development / Networking & Multiplayer / Re: Bouncing Balls in a multiplayer game on: 2013-08-14 22:26:28
For a small project, this could be over-kill, but a nice way of handling online games is using snapshots.
Basically the clients send their data to the server and the server compiles a snapshot of all the data it has.
The server sends out something like 20 snapshots a second to the clients.
The clients then interpolate the position of everything based on their most recent snapshot.

This article talks a bit more about this method.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Depending on what you're aiming for, you can have the server calculate all the collisions, or have the clients calculate collisions for objects they own.
The later takes the load off the server, but makes it vulnerable to hacking and extreme network latency.
10  Game Development / Game Mechanics / Re: [LibGDX] Calling LWJGL/OpenGL glBegin on: 2013-08-14 21:47:12
As RobinB said, you'll want to use Vertex Array Objects, Vertex Buffer Objects and Shaders. These are the meat and potatoes of the new OpenGL pipeline. The process involves stuffing a bunch of information like Vertices into a buffer and then a script (called a shader) processes the data for rasterization. As DaveDes said, LibGDX has some utilities to make your life easier. It's also going to require using matrices to position your objects in the 3D world. Again, LibGDX likely has a lot of that hard work done for you.
But don't let all those long words scare you away. Just take it piece by piece and you'll find it's really not that bad. A little more work than the fixed pipeline, but easily doable.

Billboarding
This is likely getting a bit ahead of you, since you'll want to get the basics of working VAOs, VBOs and Shaders down first. So this is for after you go down that dark road.

It looks like you're putting together some billboards. This is the process of taking a flat panel and making it always face the camera. You can think of billboarding like a sign on the side of the road, only these signs would always face you no matter where you stand. Typically this is done with a quad and a transparent image instead of a disc. Rendering a quad is a lot faster, since it's only 4 vertices. Though it's not limited to just quads, so if you really want to use a disc, then you can still use the methods I'm going to list, to help tackle your problem.

Easy Method
Just don't billboard. Stuff a sphere into a VAO/VBO and render it where you need. I bring this up, because if you just want something to represent where your light is for development purposes, there's no reason to go mad over billboards just yet. If you want to use this in actual game play, then it's probably not the best method. Especially if you'd be using a lot of them, then you would need to use instanced rendering and blah blah... so no.

Medium Method
Stuff a quad into a VAO/VBO. Pretty simple so far.
The next part is a little more tricky and requires using something called a "Look At" matrix. This does what the name implies. You feed it 3D vectors called Eye, At and Up. The matrix then does some behind the scenes magic and makes the object face where you want it to. This is perfect for billboards, just tell it to look at the camera and shazam instant billboard.

The previously mentioned vectors are
Eye: The location of the object.
At: A point the object is looking at
Up: Which direction the top of the object is facing (sort of).

Note: sometimes people refer to these vectors in different names like "right, center and up". I imagine LibGDX has already implemented the math for this and you just need to figure out the syntax for calling it.

Difficult Method
My favorite method for handling billboards expands on the previous example. Though instead of flipping back and forth between the CPU and GPU, we simply feed a bunch of 3D vectors to the GPU and then use something called a Geomtry shader to create the actual billboards.
What makes this somewhat difficult is you'll first need to learn how to use Geometry shaders. Then you'll need to figure out how to calculate the Eye, At and Up vectors in the shader. So you'll need to know a bit of basic vector math.
It's not terribly complicated, it just requires a lot of basic knowledge about a bunch of different things.

The really nice part about this is being able to deal with billboards as single points, which becomes very useful when you get into particles systems. It also leaves the door open for some advanced particle systems which exist solely on the GPU (which means stupid fast).

You'll probably want to work your way up to this though. I mention this mostly as something to keep in mind, so you don't get too entrenched in a more basic method.
11  Game Development / Game Mechanics / Re: [LibGDX] Calling LWJGL/OpenGL glBegin on: 2013-08-14 17:24:15
I can't speak to using LibGDX, but the OpenGL functions you are trying to call are part of the fixed pipeline and are deprecated. Maybe LibGDX only exposes relevant functionality based on the OpenGL version you're working in?

Aside from that, I would like to steer you away from the deprecated functions. For every function which has been placed on the endangered species list, there now exists a newer and better way of accomplishing the same goal. I'm curious why you need to use the older methodology.
12  Game Development / Newbie & Debugging Questions / Re: Learning 3D Graphics with LWJGL on: 2013-08-13 18:59:26
You'll probably want to embark on the wonderfully frustrating world of lighting. The Arcsynth tutorials are really good at explaining the per vertex lighting. However, you'll want to move into per-fragment lighting soon after that (also called Normal Mapping).

After that, it really starts to come down to what you want to do with the graphics. You may need to get into particle emitters or Frame Buffer rendering and so on.

But it's important to the proper ground work in first. I suspect you may be using the fixed pipeline functionality, it seems to be a natural direction everyone gravitates to when starting. I strongly recommend you ditch that and use OpenGL 3.3 or higher.

Here's What I Iecommend:
1.) Use Arcsynth to get a solid ground work. Make sure you're using things like Vertex Array Objects, Vertex Buffer Objects and non deprecated functionality. As I mentioned, it's also a good source for per vertex lighting. It does have some useful information on textures as well.

2.) http://www.opengl-tutorial.org/ Is a great resource for beginning to intermediate tutorials. I think they have the absolute best explanations overall. I recommend learning things like normal mapping and Frame Buffer Objects from here.

3.) http://ogldev.atspace.co.uk/index.html This also has some beginner and intermediate tutorials explaining things like normal mapping and so on. In the beginning, it'll just be a nice place to ping-pong between if another tutorial isn't making sense. Much later on down the road, it becomes a great resource for more advanced concepts.
13  Game Development / Game Play & Game Design / Re: Switching from LibGDX to LWJGL good choice? on: 2013-08-12 19:27:43
Fight The System! Use Pure LWJGL!

I actually have nothing against engines or libraries and even suffer from engine-envy now and then. Which to use is a matter of how you learn and how deep do you want to go. Do you want to take the blue pill and live an easy life, or take the red pill and live in a world of hell.

I've been developing a 3D project using LWJGL only (not even using their maths) for quite a long time. You seem pretty set on using LWJGL, so here's some heads up things:

-It's going to take a long time.
-It will take longer than you think.
-No really, it's going to take much longer than you initially expect.

It'll break your will and kill your motivation before you even get to render a simple cube. Be warned, after you get that first RGB triangle to render, you're now on borrowed time. You'll spend your days chasing that same high you got from the first triangle, only to find you've gone a month without any visual results. This isn't something you just "do for a couple months", since it'll take a couple months before you even get a simple camera able to look at a 3D object.

It's not that the concepts are that difficult. It's because you'll spend so much of your time creating things you need in order to just do the basic operations. Davedes has already listed a couple of those things for starters.

Aside from the time it takes to accomplish the basic functions, you'll also find there isn't a lot of information for creating everything from scratch for a Java 3D engine. A lot of examples will be done in a C language. But really most of it is understanding the concept and the individual syntax is less important.

Despite seeming negative about going this route, I'm not. I just want to emphasize how much of a marathon this is. It's not about difficulty, it's all about endurance. You'll need a lot of it.

The end result is amazing however. You'll have a greater understanding and won't even need to dodge bullets anymore.

So by all means do it, just be aware of what you're getting yourself into.
14  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-03 02:13:42
You're not alone in this problem. I'm fairly certain you're running up against the exact problem I encountered, because I built my own objects for handling matrices and vectors.

Also like you, I figured arrays would be the most natural way of handling this. Now you can still do it with arrays if you really want, but here's what I found:
Arrays are objects, so every time you create one of those, you end up with the potential for garbage. This problem is compounded when you do things like set the Matrix by using a new float[] or have it return a new float[].

You may be wondering how you handle passing around matrices and stuff without referencing the original matrix. I mean if you pass a matrix to a method and have it mangle the bastard, it's going to destroy the original copy you wanted to keep, since Java behaves like objects are pass by reference (pedantic note: My understanding is Java is considered pass by value).

The answer comes from a seemingly unlikely place. Since Java handles objects like references and primitives as values, it's actually easier to to set your Matrices and Vectors to contain primitives. For me it felt like this goes against what you're taught in programming 101. But like everything with code, it's always subjective to the what you need it for.

So here's what I did:
I changed my matrices to be something like
1  
2  
3  
4  
   public float c00 =1;   public float c10 =0;   public float c20 =0;   public float c30 =0;
   public float c01 =0;   public float c11 =1;   public float c21 =0;   public float c31 =0;
   public float c02 =0;   public float c12 =0;   public float c22 =1;   public float c32 =0;
   public float c03 =0;   public float c13 =0;   public float c23 =0;   public float c33 =1;

And of course the same thing as with the vectors.
Now you can do all the multiplication and what not by passing matrices into other matrices and then do your operation using the primitives.
Here's an example of setting a matrix from another matrix
1  
2  
3  
4  
5  
6  
7  
   public void setMatrix(Matrix4 matrix){ //Set the matrix
     
      this.c00 = matrix.c00;   this.c10 = matrix.c10;   this.c20 = matrix.c20;   this.c30 = matrix.c30;  
      this.c01 = matrix.c01;   this.c11 = matrix.c11;   this.c21 = matrix.c21;   this.c31 = matrix.c31;
      this.c02 = matrix.c02;   this.c12 = matrix.c12;   this.c22 = matrix.c22;   this.c32 = matrix.c32;
      this.c03 = matrix.c03;   this.c13 = matrix.c13;   this.c23 = matrix.c23;   this.c33 = matrix.c33;
   }

This way you avoid linking two matrices together by reference. The above method will create an entirely new set of values from the matrix which was passed in.

This actually turns out to be quite fast. I was a little concerned that using primitives like this would eventually lead slowing things down. So I did some testing and it turns out Java is very fast at setting primitive values. And since you'll only handle up to 16 values, you're not losing out by skipping arrays.
It also makes accessing individual cells kind of nice.

Conclusion:
I started down the rabbit hole of correcting my math, because I encountered the stuttering effect due to garbage collection. Before I fixed everything, I noticed my used memory was accumulating faster than an ex-wife could amass debt with her ex-husbands credit card. It was knocking over hundreds in seconds.
Now that I've cleaned the math up and reused objects like matrices, it takes a couple seconds before I even see it kick over 1 MB. I imagine you'll encounter the same.

And like the others have said before me, reusing your Buffers will also go a long way.

In the end, I think most of us go through this at one point or another. So don't let it get you down.
15  Game Development / Newbie & Debugging Questions / Re: GC causing massive delay on: 2013-08-03 00:00:21
Concurrent garbage collection seems to be the way to go. At least it works well for me. You can try tweaking the memory settings a bit, but that's likely not going to solve your overall problem.

Basically what happens is the GC thread causes everything else to pause while it goes through and cleans house. Adding a large chunk of memory just makes its pauses further apart, but last longer.

The real way to fix this is by profiling for your data build up. I use Java VisualVM to help profile and track down bottle necks.
http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/

What's likely occurring is you're creating a lot of new classes during your looping. One of the best ways to handle this is to reuse objects which can be reused. However, I recommend running your code through the Profiler first so you can get a break down of which classes are building up the most data.

16  Game Development / Newbie & Debugging Questions / Re: Failing to render? on: 2013-08-01 23:29:59
You're presenting a bit of a broad problem. So this is likely going to take a bit of going back and forth while we narrow down what's going on.

You mentioned porting a matrix library, but you also said nothing appears on the screen. Does this mean
a.) It doesn't matter what matrix values are used (Id etc...) nothing renders.
b.) Nothing appears on screen using your matrices, but you've been able to render things with this engine in the past.

Scenario A
I think the best place to start debugging here is from the Shader level. If you're familiar with Geometry shaders, you can create one to output a simple triangle and then just tell your fragment shader to output a single color (instead of the texture stuff you're trying to do).

On that note, I would just tell your fragment shader to output a single color until you get this stuff ironed out.

Vertex Attribute Array Pointer
More often than not, when I've encountered something not rendering it was actually due to the Vertex array. Either I was passing in the wrong values, or the more common case where I was setting the vertex array attributes incorrectly.

If you're able to implement the Geometry shader this would help you determine if you have a Vertex array issue. If you can draw something with the shader, then you likely have a Vertex array issue.
Gemotry shaders are somewhat easy to work with and should be something like:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
out vec3 vertex;

void main(){
   vertex = vec3(-0.5, 0, 0);
   EmitVertex();

   vertex = vec3(0, 0.5, 0);
   EmitVertex();
   
   vertex = vec3(0, 0, 0);
   EmitVertex();
}

Keep your culling in mind with the order. Or just err on the safe side for now and disable any culling you may be doing.

If none of the above has gotten you to a point where you see at least -something- on the screen, then you've likely got a problem with initialization or calling the draw function incorrectly.
But I'll wait on your findings before trying to drill down into that.

Scenario B
If you -have- in the past been able to render a "Hello World Triangle", then I just wrote a bunch of shit for no reason. But that's ok, it's all penance to please the coder gods.

Perspective Projection
It also means I would wager a soul (not mine, of course) that you've got a perspective projection matrix problem.
You can check this by making the perspective matrix an Identity matrix and the same for the other matrices you pass in.
If that works, then here's a general overview about investigating the perspective projection matrix.
A lot of perspective matrix implementation looks similar to the following
1  
2  
3  
4  
5  
6  
7  
R   0   0   0
0   R   0   0
0   0     A    B
0   0   -1   0

A = (F+N)/(N-F)
B = (2FN)/(N-F)

R is the frustum
F is the far plane
N is the near plane

Unless you're doing something crazy, you can ignore the upper left portion of this matrix. All it does is compress the window by width or height.
The easiest place to make a mistake is the lower right quadrant, since this controls the Z. It's easily possible to project an object behind your view. You can try flipping the -1 to positive.

Transpose
The classic transposed matrix, where your rows are your columns and columns are your rows. Though most of the time this just results in objects looking behaving strangely vs not appearing.

You can easily play with this by simply flipping the transpose boolean value from false to true in the function which sets the uniform matrices for the shaders.
glUniformMatrix4(int location, boolean transpose, java.nio.FloatBuffer matrices)

17  Java Game APIs & Engines / OpenGL Development / Re: Framebuffer viewport problem on: 2013-07-31 22:10:12
It's possible things aren't getting attached correctly.
I'm not too familiar with the way you're binding the FBO (fixed pipeline ?).

Aside from that, my process is similar to what's being done here:
http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/

Basically you generate an FBO handle, set some parameters and attach some textures to it.
I don't see where any textures are being attached, so maybe you're doing it in a different place?

At the very least, this should help. Check if the FBO is getting created properly.
1  
2  
3  
if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE){
      System.out.println("Why Do you HATE ME!?!");
}

There's a couple error codes it will spit out if things didn't go according to plan. Unfortunately I'm stuck in my 9-5 prison, so I'll dig those out of my project once my captors feel I've kludged enough code for today.
18  Java Game APIs & Engines / OpenGL Development / Re: Calculate Texture coordinate in a 3d terrain grid done with GL_TRIANGLE_STRIP on: 2013-07-30 18:40:47
Edit: I really hope my beautiful ASCII art displays properly. If not, then pretend those are quads.

I'm probably missing your problem in its entirety, so you may need to provide a little more of an explanation if the issue is more complicated.

With that, I'll provide what information I can:
Keep in mind texture coordinates are subjective to the texture being used. So you'll want to keep them consistent with the orientation of the texture.
Since you're doing terrain tiling, I'll assume you're tiling quads and distorting the height

Texture coordinates range from 0-1, regardless of the model size. Also, keep in mind the OpenGL texture coordinates start at the lower left and increase to the upper right. So (0,0,) represents the lower left corner of the image and (1,1) is the upper right coordinate.

So really all you have to do is start apply that to your model. If you think about your tiles as a quad (instead of two triangles), then you know the coordinates would be:
1  
2  
3  
4  
5  
6  
7  
(0,1)   (1,1)
 _______
|       |
|       |
|       |
|_______|
(0,0)   (1,0)


So if we think about how to apply this to a quad made of multiple quads (I believe 8 in your case), then we just need to divide 1 by the number of quads in a certain direction. That would tell you the increment for a given UV coordinate in a particular direction.

For Example:
If you're putting 8 quads together to form your tile, then you can calculate the UV increment with 1/8 (=0.125). Then the current vertex texture coordinate would just be a matter of multiplying 0.125 by the vertex position in the quad (not the actual OpenGL position).

So let's say we want to figure out the U value for one of the 4th vertices from the left.
1  
2  
3  
4  
5  
6  
7  
 _______ _______ _______ _______ _______ _______ _______ _______
|       |       |       |       |       |       |       |       |
|       |       |       |       |       |       |       |       |
|       |       |       |       |       |       |       |       |
|_______|_______|_______|_______|_______|_______|_______|_______|
                        ^
                We want this one

Then U = 0.125 * 3.
Of course you would do the same thing with the V coordinate, but you need to make sure the the lowest vertices on the tiles are the 0 value.

Unwrapping
The above method will indeed work, but it will cause some stretching of the image. However, I still suggest you to try the above method first, as you may not even notice any distortion. The stretching will be a factor of the difference in vertex height.

If you want an accurate UV mapping, then you're going to need to apply some unwrap methods. Now, I've never actually written model unwrapping, but for this case it should be a pretty strait forward method to calculate the length of a vertex in an X or Y direction and then weight it accordingly on a 0-1 scale.
19  Game Development / Game Mechanics / Re: Collision detection and Thread.sleep() on: 2013-07-25 20:25:45
It looks like you're doing movement updates based on a time delta, which kicks over every hundredth of a second.
And as you pointed out, running the loop without a sleep timer goes much faster. This also means you'll be running a lot more collision checks in a short span of time. It also means your delta time would be significantly less.

What you're seeing is a hopping issue, though it's likely not as noticeable. Your character is moving a much larger distance in between checking the collision, because a lot more time has elapsed between collision checks.

A Simplified Example:
Your point of collision is at 0,0
Your character is falling from a position of 0,10

In the non-sleep version of the game loop, your character falls at -0.1y every cycle.
In the sleep version, the character falls at -1.5y every cycle.

If we were to check when chracter.y == 0, we would never encounter it in the second version.

Solution
It's possible your bounds for collision may be too small, or you may need to calculate the penetration value of a collision and adjust for that.
Think like a character encountering a border. Instead of letting them transition beyond the border, we move them back to a place where they're within the border.

edit: Also what JonJava said.
20  Discussions / General Discussions / Re: blendFunc woes on: 2013-07-22 19:18:16
I think I understand what you are doing and why you're getting the less than stellar lighting result.
Unfortunately the end answer isn't a simple solution.

The problem with using a flat color as a light is what you're seeing. It's prone to saturation and really not good for main lighting.
That being said, I think you've done a pretty nice job mangling it to a point where it's not too bad.

I left it out of my above explanation, but the way to do lighting is a bit more complex. Instead of blanketing the light area with a single color, you actually want to use the exact color of every pixel for every pixel in the lit area.
Take your light as an example. The steps would be roughly
1.) Copy pixels covered by the light and save them.
2.) Draw your shadow texture
3.) Draw the pixels you saved back to the main screen using glBlend(GL_ONE, GL_ONE).

The end result is a perfectly round circle with all the pixels accurately lit without saturation.
But now you have a new problem. It's all lit, but now you're missing the nice feathered lighting. So in order to apply the attenuation, you'll either need to redraw a dark circle over the light, or get down into the shader code and apply an attenuation calculation based on the position of the light. The later being the optimal of course.

This approach is similar to something called a G-Buffer, where you draw parts of your scene to a off screen textures called Frame Buffers. For example, you'd draw all the objects to something named a diffuse buffer (note: I'm simply naming it diffuse), which contains everything without any lighting or shadowing. Then you can easily sample from the diffuse buffer and apply it to your output.
Think of it similar to a copy paste approach. Only the user never sees the source picture and when you paste the picture to the main view port, you can make it paste in special ways.

At this point, you're probably thinking "Wow... that's a lot of shi-" yes, it is.
Of course this isn't the only approach, but it's an effective one which mirrors the way many modern 3D games handle lighting.

Fortunately, you appear to be using LibGDX and davedes has done a nice job of pulling up some tutorials which should make your life a lot easier.
I don't use LibDGX, so I can't say for sure, but I believe the second link is more similar to my above approach. Only it's made easier through LibGDX (lucky you).
21  Java Game APIs & Engines / OpenGL Development / Re: stock with concept - game stage/scene on: 2013-07-18 22:50:21
I didn't see anything specific to OpenGL, so if I missed it then let me know.
That aside here are my thoughts on your predicament.

One Way of Doing This
I think the best way to do it is to split it up into 3 different classes or rather 2 classes and the all your sub classes who extend the abstract class.
Basically you have a handler class who is responsible for handling the basic graphics, like initializing any OpenGL and LWJGL Display settings.
It would also handle the transitioning between your stages.

For the stages themselves, they would contain all the objects you need to load, unload and how you want to draw stuff for that stage.

But let's take a look at the code first. It should make a bit more sense. Though do keep in mind I'm sure there's more ways to do this and I make no claims to being a pinnacle of proper programming practices.

Here's the stage Handler
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
public class StageHandler{
   public static final int STAGE1 =1;
   public static final int STAGE2 =2;
   public static final int STAGE3 =3;
   public static final int OPTIONS =4;

   public Map<Integer, AbstractStage> stage = null; //A map of all your abstract stages  

   public boolean running = false; //If the rendering of the engine is running      
 
   private AbstractStage currentstage= null; //The current stage you want to draw
 
   private boolean change = false;   //If you need to change the stage
  private int newstage = 0; //The id value for a stage you want to change to  
 
   public void StageHandlder(){
      this.stage = new HashMap<Integer, AbstractStage>();
     
      this.stage.put(StageHandler.STAGE1, new Stage_One(this));
      this.stage.put(StageHandler.STAGE1, new Stage_Two(this));
      this.stage.put(StageHandler.STAGE1, new Stage_Three(this));
      this.stage.put(StageHandler.STAGE1, new Stage_Options(this));
   }      

   public void startRender(){ //Start the render loop
     this.running = true;
      this.changeStage(StageHandler.Stage1);

      while(running){ //Your drawing loop
        if(change){
            this.changeStage(this.newstage); //Change the stage
        }
         
         this.currentstage.draw(); //Draw all the stuff in your stage
     }
   }

   public void postStageChange(int stageid){ //Prep for a stage change
     this.change = true;
      this.newstage = stageid;
   }

   private void changeStage(int stageid){ //Change to a new stage
     if(this.currentstage!= null){ //Avoid the start up null
        this.currentstage.unload(); //Unload the stage you are transitioning from
     }
      this.currentstage = stage.get(stageid); //Get the stage you are transitioning to
     this.currentstage.load(); //Load all the stuff for the stage
     this.change = false;
   }
}


And here's the Abstract class
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
public abstract class AbstractStage{
   
   private StageHandler stagehandler = null; //Used as a reference back to the handler
 
   public AbstractStage(StageHandler stagehandler){
      this.stagehandler = stagehandler;
   )
   
   //Load, unload and drawing stuff
  public abstract void load();
   public abstract void unload();
   public abstract void draw();

   void changeStage(int stageid){
      this.stagehandler.postStageChange(stageid);
   }
}


Now in order to change stages, all you have to do from your extended abstract sub is call the stage you want to change to (let's use Stage3 as an example):
1  
this.changeStage(StageHandler.STAGE3);


This setup does leave the door open for calling out a stage and rendering it from within anywhere; the catch being it needs to already be loaded. For example, you would need load the Options stage when the options are entered and then unload them after they're exited. (I'm not a big fan of this, see below).
To do that, all you need to do this from wthin a stage:
1  
this.stagehandler.stage.get(StageHandler.OPTIONS).draw();


Some Things to Keep in Mind
I'm not really sure you would want to draw 2 stages at the same time. Particularly with the options menu. That seems like something which should be taken care of with a class which handles the drawing of windows. Trying to combine window logic with stage logic could get messy.

This is only the tip of inter-class communication. If you're running a multi-threaded application, you'll need to take care when passing messages back and forth.
22  Java Game APIs & Engines / OpenGL Development / Re: performance dropping when camera move / rotate with frustum test on: 2013-07-12 19:28:38
Have you profiled it yet to see if you're encountering a garbage collection issue?
23  Game Development / Newbie & Debugging Questions / Re: OpenGL VBO rendering vs Immediate Mode on: 2013-07-12 18:57:10
When left with no other option, it's perfectly acceptable to buffer data often, even every frame. When calling glBufferData, it's best to set the usage to GL_Dynamic_Draw.
You can also use glBufferSubData to update only a portion of the buffer instead of the whole thing. You can also use glBufferSubData to replace all the data and this will avoid some reallocation.
I believe there are also some tricks involving glMapBuffer, but I'm not too familiar with them.

I've done some stress testing with rebuffering every frame (~60 fps) and found you can swap out quite a bit of data before you start to see a frame rate decrease.
That being said, I only recommend this as a last resort; be sure there isn't a way to buffer the data less frequently and manipulate it with matrices.
24  Game Development / Newbie & Debugging Questions / Re: Camera Calculation on: 2013-07-11 00:00:31
I see, you're saying the result is 1792 and not a value you're using to determine camera position.

Alright, after doing a bit of back solving, it looks like your viewport (window size) is 1280x768.
So now we can start plugging some values into your calculations.

Scanning through your logic, it appears the max values are causing the problems. So let's run the values through and see what happens.

Max Width
(3200 + (1280/2)) /2
(3200 + 640) /2
3840/2 = 1920

Max Height
(3200 + (768/2)) /2
(3200 + 384) /2
(3584)/2 = 1792

From the above, it appears the way you're calculating the max limits is the error.
The reason it's working with the width is because 3200 - 1920 = 1280. This means you're using the edge of the screen as the camera position instead of the center.
So in sticking with that coordinate system, you should just be subtracting the viewport x and y from the map size to find your limits.
 
To make sure I didn't derive something incorrectly from your code, I suggest plugging in 2432 for the maxHeight value as a test.
25  Game Development / Newbie & Debugging Questions / Re: Camera Calculation on: 2013-07-10 20:11:03
Alright, after doing some guess work on what you're looking to accomplish. It seems like you're trying to stop the camera when it reaches the border by taking half the screen width or height from your defined border.

Going with this assumption, if you're passing 1920 as your screen width, then your screen height should be 1080.
So I think your camera Y should be 1080 instead of 1792, unless you have some sort of weird resolution.
26  Java Game APIs & Engines / OpenGL Development / Re: Attenuating light source via glLight methods? on: 2013-07-10 19:14:34
*Disclaimer: I remember very little from the OpenGL deprecated functions

You have to set the attenuation parameter for that light.
So something similar to:

glLightf(GL_LIGHT0, GL_CONSTANT_ATTENUATION, 0.5f);

The default value is 1.0 for attenuation, which means no attenuation. And the min value is 0.

Down near the bottom of this page is a more detailed explanation of the attenuation parameters and how the attenuation is computed.
http://www.khronos.org/opengles/sdk/1.1/docs/man/glLight.xml

27  Game Development / Newbie & Debugging Questions / Re: Best approach to do OpenGL 3D Animation on: 2013-07-10 19:01:20
I'm guessing you're using Blender. In which case, you can export to *.X3D, which is an XML file.
The layout is pretty easy to understand and can be observed using a plain text program like Notepad.

There's always the option to write a small program to read the X3D file. I use this method to import models and stuff them into my own file, so there's no processing during loading, just simple file I/O.
However, I'm sure the engines have a really nice solution for importing models. So it's really a matter of will you be using a preexisting engine, or making your own.
28  Game Development / Newbie & Debugging Questions / Re: Implementing Vector Maths on: 2013-07-09 23:46:31
As a non-mathy person, I found this to be extremely helpful.

http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-1/

It also has nice pictures, so easily distracted persons like myself don't get lost.
29  Game Development / Game Mechanics / Re: 2d particle system efficiency on: 2013-07-09 19:26:21
After playing around with different ways implementing particles, I'm compelled to offer up the idea of a GPU system.
When I first read about this, I began trying to guess how many animal sacrifices I would need to get this magic to work.
Turns out it wasn't that bad at all. In many ways I found it easier.

The whole idea centers around ping-ponging between two Transform Feedback Buffers (I'll call them TBO for short). TBOs are buffers you can draw into and from.
When you draw from one TBO to the other, you use a Shader to update particle information like position, velocity, age and so on. You also tell OpenGL to skip the rasterize step when you do this. Then all you really need to do is stuff this bad boy into a particle emitter class and tell it to draw when you want.

This ends up being extremely fast. When I compared it with my other particle systems, it was like a race between an Olympic Sprinter Vs. A Walmart Scooter Jockey (sans scooter).

You can use Geometry Shaders for updating, spawning and destroying particles, as well as using them for creating the billboards.
30  Discussions / General Discussions / Re: blendFunc woes on: 2013-07-06 00:09:48
Alright, I'll give it a shot.

Explain Like I'm 5 Version:
When a mommy pixel loves a daddy pixel, they sometimes make a baby pixel.
This might get confusing, let's try another approach

Explained How I Understand it:
The Blend Function, as you may have guessed, is a function which defines how two colors combine to make the final color.
It helps if you think of this as a per-pixel process. So don't think of the entire image in the buffer, just consider one pixel.

First off we need to understand which parts of the functions apply to which color.

Source Color: This is the color you want to draw to the surface (the one you're currently drawing with).
Destination Color: This is the color which already exists on the surface.

So we have the basic idea:
Source Color + Destination Color = Baby-I mean Final Color.

Blend Function
Well, the above is great and all, but simply adding two colors together isn't always going to produce the results we want. Thus along comes the Blend Function.
Instead of just adding the two colors together, we're now going to mangle both colors and then add them together to create the final result. So we're going to define a function
for how we're going to mangle each pixel, by using the blend function.

BlendFunc(Mangle Source Function, Mangle Destination Function);

And once we plug the colors into the blending process, we get:
Mangle Source Function * Source Color + Mangle Destination Function * Destination Color = Final Color

Essentially, the function is a scaling factor for the specified color (think multiply each element in a color).

Of course this isn't the exact math under the hood, but we can overlook that right now.

Blend Function Parameters
You're probably already familiar with this, but just in case: elements of a color are defined in a 0 to 1 range.
The blend function defines how those elements should be scaled.

Let's take some simple examples, we'll be using RGB format:
You already drew your scene and now you want to add some lighting by drawing a circle/sphere over a specific area.

Circle/Sphere = Source Color
Scene = Destination Color

We'll go ahead and keep this simple by making a medium light completely white. So
Source = (0.5, 0.5, 0.5)

Let's assume all the colors under the light are dark blue. Thus
Destination = (0, 0, 0.3)

Since we're making a light, we obviously want to make the dark blue color a lighter shade of blue. So how should we do this?
Easy enough, just slap those two bad boys together with an add function and BAM instant lighting.
How do we tell OpenGL to do this? Well, we us the blending parameter called GL_ONE.

glBlendFunc(GL_ONE, GL_ONE);

This means the source and the destination are going to be multiplied by 1.
And here's essentially what happens:

Source Color: 1 * (0.5, 0.5, 0.5) = (0.5, 0.5, 0.5)
Destination Color: 1 * (0, 0, 0.3) = (0, 0, 0.3)
Final Color: (0.5, 0.5, 0.5) + (0, 0, 0.3) = (0.5, 0.5, 0.8 )

Note: This actually answers your question about which blend function to use for your lighting. Also, you can change the color and strength of the light
by manipulating the Source Color elements. IE: change to (0,1,0) if you want a really strong green light etc...
I recommend you play with it to get the effect you want, but start with lower numbers and work your way up. Once a color goes out of the 0 to 1 range, it's clamped to either 0 or 1.

In this example, we'll use RGBA format. And we'll tackle a common question when trying to do transparencies.
How do you draw a transparent object on top of a scene?
You're going to need a transparency value (the alpha element of course). Keep in mind the destination color does not need an alpha value, but the source does.
I think the magic of this one is easier understood by just looking at an example.
The function we'll use is

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

This means we're going to multiply the Source Color by the value of the Alpha channel on the source value.
Then we're going to take 1 and subtract the Source Color Alpha channel. The result is then multiplied against the Destination Color.

So let's say we want to blend a dark red over a blue Scene. But we only want to blend it by half (in other words, 50% transparency).
Source = (0.3, 0, 0, 0.5)
Destination = (0, 0, 0.3)

And essentially what happens:

Source Color: 0.5 * (0.3, 0, 0, 0.5) = (0.15, 0, 0, 0.25)
Destination Color: (1 - 0.5) * (0, 0, 0.3) = (0, 0, 0.15)
Final Color: (0.15, 0, 0, 0.5) + (0, 0, 0.15) = (0.15, 0, 0.15, 0.5)

The end result is a purple-ish looking color.
If the final destination doesn't contain alpha values, then to the best of my understanding the alpha channel of the final color is taken to a farm out in the country where it lives the
rest of its days - and wasn't by any means taken out back and shot.

Other Blend Function Parameters
There are a lot of other parameters you can set. To be honest, you'll likely see the above two example used the most.
The reason you can use things like GL_DST_ALPHA in the Source parameter, is because sometimes you feel life just isn't hard enough. No no no, that can't be right.
I haven't run into a case where I've needed a value from the destination channel, so I can't really provide an example. But I'm sure there are specific cases where it comes in useful.


Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (12 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (24 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!