Idea's maven and VCS integration is a lot nicer and native compared to the plugins that Eclipse makes you use.

I switched just recently, and the weirdest thing for me to get used to is not needing to save files.

** EDIT: This answer is more OpenGL than Slick oriented **

If it's a solid tint over the entire quad/triangle, you can do it with the texture environment and color of the vertices. Just set the environment to MODULATE and change the vertex color and you should see a tint without having to mutate the texture object (this also means you can tint different meshes separately without re-tinting the texture).

You can also use the BLEND and BLEND_COLOR environment options to specifically tint the texture regardless of what the vertex color has been configured as.

But but the angles, we need to use the radians stat or the cosines will get lonely!

I remember reading that you could effectively detach data from a VBO by calling glBufferData(target, null).  The GPU would continue using the previous block of data to complete rendering, but any data manipulation commands would use the new block assigned with the glBufferData call.

Have you tried this at all?

 

I am attempting to placate you, much like a cultist praying to Yogsethoth.

Well it is now redirecting for me now, too, so yesterday I was crazy.  In my defense, I've been using a hotel's internet service :/

It is nice to hear your opinion on the matter, Riven, and seems fair. Not that fair is an important detail for our glorious leader.

When visiting http://javagaming.org instead of http://java-gaming.org, it no longer redirects to the current domain name for JGO and shoes a for-sale page by go-daddy  Does this mean that:
A. I am, or my current DNS, is crazy
B. It's not really go-daddy and has been hacked
C. We could actually purchase javagaming.org because Oracle/Sun has given it up

Thoughts?

I'm sure you could, but I haven't implemented that yet. Since it can support generic perspective frustums with arbitrary right/left, top/bottom values, I should assume it's possible.

No, it uses a grid structure for inserts/removals from the spatial index, intersecting pair queries, and AABB queries. Then a quadtree is built on top of the grid and stored in a single int array; this is possible because it's a complete tree, where the leaves map to the grid cells.

*edit*
The reason I brought this up was because I implemented it to be a structure that worked well with dynamic objects.  Both the grid and quadtree array can be cleared quite quickly, and building the quadtree up from the grid is more efficient than building the tree top-down.  In my game system, I then clear the tree each frame, possible updating what its extents are, and then re-insert every object.

Checkout my quadtree implementation: https://bitbucket.org/mludwig/ferox/src/b0fc96dafa358ace4ccdf3e92aee468a72afd6f7/ferox-math/src/main/java/com/ferox/math/bounds/QuadTree.java?at=default

It's a quadtree built on top of a grid.

1 million at 97ms

Your element size and strides don't make any sense in glColorPointer and glVertexPointer.  In both cases, your element size is 3 (red/green/blue and x/y/z).  Since each consecutive attribute immediately follows the previous, your stride should be 0 (not 4 << 2, which is 16 btw).

Reasons why I don't like Python, and why Java blows it out of the water:
1. Global interpreter lock, makes multithreading a huge pain. You could just fork, but their GC model breaks the copy-on-write policy used to make forking worth it.
2. Not statically typed. It is a huge pain to work in 50,000 lines of python with multiple people and not have static type checking.
3. I hate their dependency/library management system.

Reasons why Python is cool:
1. Duck-typing is pretty nifty
2. First class functions
3. List comprehensions

Congrats, may your combined madnesses create beautiful things

The light position is transformed by the current state of the model view matrix and those transformed values are what you see in the GLSL shader.

The effects that you might see depend on what matrix you've set before you call glLight().  If you have the identify matrix, and then call glLight(), and then perform your rendering, the light position you specified is already in "eye" space and it will move along with the camera.

If you set the matrix to the view's inverse transform, and then call glLight(), the light's position you specified is in "world" space and should be fixed.

If you set the matrix to the view inverse multiplied with the model matrix of an object, and then call glLight(), the light's position will be in "model" space and will move along with the object.

It sounds like you're having the first problem where you set the light position too soon, which is odd since you claim to be setting it after you translate the model view matrix.  I'd double check the flow of your operations to make sure you are doing it in the right order.  It might help me to see the rest of your Java code that sets everything up too.

As an aside, what type of diffuse light are you trying to simulate? An infinite direction light or a point light?

Here is an example where threads can see half-constructed instances:


Here, without any synchronization or volatile going on, the 2nd thread might have an inconsistent view of the memory modified by the first thread.  Although thread 1 sees dep's reference fully constructed, thread 2 might only have seen the assignment to the dep variable, and not the memory initialized by OtherObject's constructor. 

So in that rare situation, thread 2 sees a partially constructed object.

Going back to the original, bad double-checked lock in Math.random(), the problem is that the first check against the randomNumberGenerator field is not synchronized. The calling thread could see a non-null reference written by another thread that just completed initRNG() and think it doesn't need to instantiate the RNG.  Since there was no synchronization, though, the actual instance might be in an inconsistent state to the calling thread and all bets of correctness are off.

Reading your problem from gamedev.net, it sounds like compressing normals isn't really the best solution to your problem.  If you have that much terrain data, but only a small amount of it is visible, you have a prime candidate for culling and LOD.  That way you only really have to swap in the high-detail geometry for the small area around the player and the distance rendering uses a simpler mesh.  If you combine this with normal mapping, it will be very likely nobody can notice it.

If you're set on compressing the coordinates, you might look into using the integer vertex attribute types, but that might require masks and shifts and I can't recall how well that's supported (or if it's even available in the newer shader models).  I'm pretty sure that the floating point attributes are a fixed size, unlike with texture formats.

If you use object space normals in a normal map, then you don't need vertex normals, and then you can compress those into a 2 component texture and reconstruct the z value.

You didn't go through the hassle of getting your library hosted on the Maven central repository (which is managed by Sonatype). It's "nice" to host things on the central repository because all Maven projects will check that location for libraries. With your way, we have to update our own project to use the additional repository

I use Maven quite a bit with work and really like it, and it sounds like some people have misconceptions or just don't know much about Maven so here's my take on what it can do and why it's cuddly:

Maven is a combined dependency management system and project build/lifecycle manager.  The build system is powerful but can be largely ignored if conventions are followed.  The dependency manager is nice because it forces you to document the exact libraries AND their versions that you depend on. As said before, it will download the JARs for those dependencies, and the JARs of any transitive dependencies, etc.  It will also resolve as best version conflicts between dependencies.

At work before Maven, my classpaths might grow to 50 jars in some of our servers, with libraries I'd never use personally but were a dependency. If I wanted to update Struts or Hibernate, it was a very bug prone hassle to try and get the correct new versions of their dependencies.  This is trivially easy to do with Maven and should not be sneezed at.  I doubt my games will ever need that many dependencies, but it's still nice to have as a feature.

There is a very nice Maven plugin for Eclipse so you still create your project through Eclipse (just a different type than plain Java). Eclipse still does all of the compiling and it can still do its magic classpath sharing between projects (even other Maven ones in your workspace). The plugin will automatically download the Javadocs and source associated with a dependency when you go to inspect an element, and links it for you into the normal Eclipse source inspection system.

By the time you need to build your final application, you might have to mess with some XML funny business, but there's a good chance you'd have done that with ant.  Maven has much better fat-jar support compared with Eclipse.

IMO Maven helps keep your own projects more modularized because you can split them into separate modules. Do you have custom math functions and vectors, etc. It's a module. Physics library or helper code; it's a module. Input system or event system, or core AI routines? Module. Then you can have them depend on each other as needed, and have a last module that brings them all together and implements your game.

Want to make a new game, just pull in your modules you want to reuse instead of trying to gut pieces by hand.

It's not too bad, I've drunk the Maven cool-aid and although it infects everything you do, I don't find I'm bothered by it.

I read Half life and instantly thought Steam :/ didn't stop to think about the timeline.

I think it was a key that got linked to your steam account, and then the DRM was tied to logging in with steam, and that is basically like how I described above.  It auto-logs in and remembers credentials locally, which is convenient, and is fine for DRM purposes since it really only needs to stop multi-comp logins.

Just have them create accounts so they have to log in before they play. Then it doesn't matter how many times they copy it since you can just allow one authentication at a time.

If you're worried about people wanting to play offline, just keep them "logged in" for an hour if they disconnect without going through the proper protocols.  That way that can't just unplug their comp and let someone else log in.

My problem (and the reason for the cranky post last night) was that this isn't really a gift. 90% of the reason he's releasing the code is so someone else can solve his problems.  This appears to be a valuable project, so he ought to use bitbucket, googlecode or github to create an opensource project for it.

Then the help he gets is contributions, but we know he's serious about actually sharing it. Instead it looks like he got stuck, and instead of coming back a few days with progress to show he's still trying to solve it, we get a bump. It looks like he is expecting us to lay down our own work, dig through his code, and then solve his problems while he relaxes.

NO

I like the static API of LWJGL but sometimes I find it awkward to remember which version of opengl the function was defined in (choosing between GL11, GL15, etc.) while having a GL object allows inheritance to define the different opengl versions (and to remove functionality in the case of moving to Opengl 3+).

One thing that I've always been confused about in both JOGL and LWJGL is what happens when an ARB function is invoked. In JOGL, the API doesn't even expose ARB so I'm assuming that it must do something like GLEW and calls the ARB version if no core function is available.  With LWJGL, both the ARB and core functions can be called explicitly in Java but if I call the ARB and the core is available, will it upgrade and call the core function?

I think a lot of us have realized that applets are just a bad deployment model. Might as well make an application or android app. And IMO JWS is near as bad as applets, it's like playing Russian roulette for whether or not an exception is thrown.

Do this:


You don't need to use glPushMatrix and glPopMatrix here.  You should call glPushMatrix right before you set the transform for your model, and glPopMatrix right after you render it.  The pushing and popping are specific to the matrix mode you have activated.

Depending on the fog hint, I believe opengl fog can be view dependent because it approximates distance using eye-space z coordinates.  You should try getting rid of your first call to glTranslate(), and glLoadIdentity() and move setCamera() to the first thing you do within that method.  That way you have your camera configured before setting up your fog.

However, I don't think the ordering of those commands should really affect things, so there's a chance that later on your rendering corrupts the modelview matrix so that fog sees the incorrect view transform.  This is all conjecture.

You could also try setting the fog hint to NICEST, since that should enable a view-independent fog path.