A library usually provides an interface for a specific subsystem or component that you might want to integrate into your game: image loading, audio loading/playback, physics, rendering, and so on. A game engine provides the plumbing that ties all of those subsystem/components together (using several existing libraries, a bunch of custom code, or a mix of both) and usually provides access to it all via a framework. In short, a library is something you can use to implement the different systems of a game, and engine implements the systems for you in order for you to get busy with the game code and not worry about all the plumbing.

Technically, an "engine" is still a library. But that keyword lets you know that its doing a lot more for you than just loading images or playing audio. And you still might have a "rendering engine" or an "audio engine" that provide a lot of goodies on top of basic graphics/audio APIs. For example, OGRE isn't a game engine, but a rendering engine--nobody calls it a "rendering library"--because it does a heck of a lot of work for you than just abstracting away the underlying platform and rendering APIs.

I prefer the Kindle version of tech books these days. I don't own a kindle, but rather use a tablet or the Amazon Cloud Reader to view them. I have shelves full of books and just don't have the space anymore.

Try this site. The guy has well over a hundred game ideas for people to use (he's planning to expand it to 300 eventually). I'm currently working on a game that's a modified version of one of his ideas. Great source of inspiration, even if you don't like any of the ideas you see there.

Seen this latest one in the Register yet? This time, it's Java 6.

The court will consider intent when considering damages. Intent to profit will quite likely result in higher damages than just putting something out there for fun. There's more to it than just that consideration, though.

Fear of being sued has nothing to do with it. There's a big difference from someone suing you because they slipped on ice in your driveway and a company suing you for blatantly copying their stuff. When someone asks advice on this issue, I very much think it's wrong to tell them not to worry about it. They need to be aware that a cease & desist order can come at any time, at which point all their effort is for naught. That can be a huge let down for someone who isn't expecting it. Much better to avoid that disappointment completely by using legally available content. Still, if they continue to insist on going down the copying road, at least give them enough info that they do it with their eyes open.

Don't be so sure about that.

The fact is, it does not matter whether or not a game is sold or credit is given to Nintendo, it would still be a violation of copyright or trademark. The only point where the free vs. commercial comes into play is when deciding the amount of damages to pay. Someone selling a game that violates copyright is going to dish out a lot more money than someone giving it away for free.

Is it likely that Nintendo will sue? No. Is it possible? Absolutely. The best course of action is always to avoid using any content that can cause this sort of legal trouble. Advising otherwise is irresponsible.

But the people who wanted to write game engines and not games thought he was a dolt.

OpenGL does not provide any way of loading image files directly from disk. It knows nothing about image file formats, only pixel data. So no matter what programming language you use, you need to load the image file into memory first yourself, extract the relevant pixel data (dimensions, color depth & format, and the actual pixel values) then pass it all on to OpenGL through its texture creation interface. So, no, in Java, using a BufferedImage is not counter-intuitive.

No. A shader does not do any rendering. It manipulates the vertex/fragment data.


If you are using fixed function rendering, you aren't using shaders. That's what the 'fixed' means -- it can't be changed. To render with a shader, you pass your vertex data to the graphics card via vertex arrays or VBOs and set up the projection matrices, blending modes and any other state you need. The only difference with fixed function is that when you want a particular effect, you activate a particular shader to replace the per-vertex processing stage of the pipeline.

Here's the complete vertex stage of the pipeline:

per vertex operations -> primitive assembly -> clip/project/viewport/cull -> rasterize

In the fixed function pipeline, all of this is happening in the driver. With shaders, you are able to completely replace the 'per vertex operations' stage with your own alogrithm as often as you like. Vertex data includes position, color, normal, texture coordinates and, for advanced uses, any custom data you want to associate with each vertex. This allows you to manipulate the data in any way you need to before it is actually drawn to the screen. Look at this shader, for example:



The graphics card gives the position of each vertex to the shader in the variable 'position'. The shader does no manipulation of the position at all. It simply passes it off to the next stage of the vertex pipeline untouched. Now look at this vertex shader:



It takes the same information, the position of the vertex, and modifies it based on elapsed time. It then passes the modified position on to the next stage of the pipeline. While this shader is active, all objects that are drawn will move across the screen.

This is what vertex shaders do. The basic functionality is for transformations and lighting, but you can do a variety of tricks by manipulating any of the data associated with the vertex. That's the key point: you manipulate vertex data, then pass it back to the pipeline for final rendering. In the fragment shader, the concept is the same, but you are now manipulating the final color that is output to the screen rather than vertices.


By what you see on the screen. It's usually fairly obvious if the shader is working or not. What is sometimes less obvious is whether or not your shader is buggy.


Some are automatically provided by the graphics card (like gl_Position above), some are based on the data you configure in the vertex arrays/VBOs (like position above), some you have to pass from your program via the shader API (like time and loopDuration in the second shader above), and some are local (like timeScale and currTime in the second shader above).

I highly recommend this tutorial, Learning Modern 3D Graphics Programming if you've not seen it yet. Also, the Orange Book is a good reference to keep handy.

I think this is the source of your confusion. The shaders aren't "drawing" anything. They are being plugged in to two specific stages of the graphics pipeline: vertex processing and fragment processing. The rest of the work (primitive assembly, clipping, projection, culling, rasterization, etc..) is still handled by the driver. Don't think in terms of images and objects, but rather vertices, normals, color values, texture coordinates and fragments. Those are the things you manipulate in the shaders.

A 3D object is a collection of vertices, texture coordinates, normals and color components. So are 2D images, only on a smaller scale. After all, a 2D image is usually rendered as a set of 4 points that make up 2 triangles. The kinds of manipulation you would want to do on a 3D object are often different than what you would do on a 2D image, but the principle is the same.

I don't know if it meets all of your requirements, but DragonConsole meets some of them.

And that's a developer's choice. If you can get consistent, playable framerates with WebGL, then it doesn't matter if JOGL or LWJGL would be 5 times faster.

This has nothing to do with Apple. People will access your web page through the browser, Safari on the iPhone. Apple is already pushing HTML 5 for video on iPhone and iPad.

It doesn't matter a bit which one is faster. This is all about distribution and platforms. WebGL requires no additional plugins. As long as games are playable at an acceptable framerate, then it becomes a much more attractive option than either Java or Flash. Particularly considering that with a relatively small amount of effort you can get the same WebGL game playing across multiple platforms, including iPhone/Android. Given time for wide adoption and stable implementations, this is going to become an extremely viable option for many types of games.

There are already some game engines being developed on top of WebGL, such as Copperlicht. Anyone with a capable browser installed who wants to play around with it and see what it can do, that's a good place to start.

FYI: YAGE. That one is for the D Programming Language. Something to keep in mind.

I'd happily contribute 5 ~ 10 hrs/wk depending upon my schedule. Some times more when I need a break from my other projects. I'm strictly a programmer. You wouldn't want me anywhere near the art.

Your users likely won't have great connectivity, though. I would recommend a VPS (virtual private server). Both SliceHost and Linnode have plans starting at US $20/mo, with enough memory/bandwidth to get you started (and you can always upgrade, or get more nodes, if you need). You have full control over your node/slice and have the option of several different Linux distros to install. At any time, you can wipe it and start over with a fresh install in a matter of minutes using the tools they provide. The support is top-notch (especially at SliceHost) and there are plenty of resources to help with setup and maintenance. If you need to run multiple nodes, Linnode will exclude internode bandwidth usage from your total.

I've got a VPS with SliceHost that I've been using for personal stuff for a few months now and have no complaints.

Or maybe not. Not every 3D rendering library on the planet needs to be abstracted to such a degree. Some are, some aren't. Life goes on.

Yes, you can adjust the angles at any time, clear and reset matrices and whatever you want. That doesn't prevent gimbal lock from rearing its head, but can open up doors to avoiding it. But this isn't an imaginary problem that goussej is making up. It's a real issue that is common in 3D graphics. You'll find it being discussed in a number of graphics books.

The point you seem to be missing is that those Euler angles need to be applied to the object you are rotating. Whether you let the graphics API handle it or you do it yourself, they are going to be applied one at a time. When rotations are performed sequentially, it's possible for one axis to become aligned with another. The order in which rotations are applied can affect whether or not gimbal lock occurs, so there are ways you can avoid it. This page has a couple of suggestions. The main reason that you don't see gimbal lock with quaternions is that the rotations are essentially applied simultaneously.

The term "gimbal lock" comes from the physical world. It describes the condition in gimbal systems where you lose one degree of freedom (i.e., the ability to rotate around one particular axis). In software it can be an issue when using a rotation system based solely on Euler angles if you don't account for it. You may never see it, but it's certainly possible since it's an inherent characteristic (which quaternion rotations don't have) of gimbal systems (simulated and physical). A real-world example of a near-gimbal-lock situation occurred on the Apollo 10 mission in May, 1969.



I've read that there are several instances in the Apollo records and flight logs where pilots had to make special maneuvers to avoid gimbal lock. So yes, it's a real problem, though the consequences aren't severe in 3D graphics programming

Before the coming of NIO, there was a non-blocking networking architecture someone developed with a bit of JNI. I'm beating myself up trying to remember the name of it and Google isn't helping me. It certainly wasn't an obscure project. Anyway, I remember it was a very performant bit of code. The native part was minimal and most of the work, dispatching Network events and such, was handled on the Java side. I was shocked when I first looked at the source and saw that the dispatcher used instanceof to route the events. My naive assumption had been that instanceof would have been a bottleneck for something like that. From then on I wasn't afraid to use it.

That's so wrong I know a lot of D users, myself included, who will strongly dispute that it's clunkier or more inelegant that Java or C++. It's miles, leagues, ahead of C++ in that regard.

I've been active in the D community since it was in early beta and it has made, and is still making, large strides. The pre 1.0 ramp up took a few years, as Walter (the sole developer at the time) took his time to get it right. D 1.0 wasn't launched until Jan '07. Now, it's perfectly stable and works as advertised (with a few minor quirks).  D2 is under development and is where the major focus is now, with the 1.x series getting bug fixes and the occasional back ported feature. The D2 spec is expected to be finalized by the fall of this year. It's a major shift in focus and will be unlike anything else out there. Multiprogramming is the future, so D is being positioned to meet the challenges that brings.

Take a gander at these slides from a recent presentation Andrei Alexandrescu gave at the ACCU conference (PDF): Grafting Functional Support on Top of an Imperative Language. Andrei is deeply involved in D2's development. Those slides will give you an idea of where it's going.

As part of learning to use packages, you need to learn how to set up the classpath. Once you understand that, it's smooth sailing.

This is one of those points that goes along with programming to the language you're using ('Thinking in Java' and so on), or when people talk about 'programming C++ in Java'.  Every language has different performance characteristics that must be considered. It's not necessarily premature optimization, but just standard rules of thumb. For instance, in C++ people often get bitten by copy constructors being called behind the scenes, so it's a common idiom to mark them as 'private' when they aren't needed or 'explicit' when they are.

So when performance is a concern, I think it's important that you consider the common idioms for the language you use. For 99% of my Java code, I don't think twice about allocating new objects. If it does turn out to be a performance bottleneck after profiling, then I'll worry about it. But there are certainly cases where I do think twice about it. This would be one of them. If you look at the code for the JMonkey engine, you'll see several places where they reuse a scratch Vector object in order to avoid allocation. That's a good policy to follow with Vector operations.

The game server wouldn't have a URL, since you wouldn't be accessing it via http. It shouldn't be anywhere in the web root tree. The restriction is that the Applet can only connect to the same IP address from which it was served. So as long as the game server and web server are running on the same machine, you should be fine.

I think he's referring to the Java version of Berkeley DB. I was curious about this, too. Why use JNI with the C version when there is a pure Java version? Sleepycat was taken over by Oracle, but the license hasn't changed.

No, it's neither wrong nor outdated. The BMP format, which the early NeHe texturing tutorials use, (usually) has the origin of the image in the lower left corner. This matches the default OpenGL texture coordinate system so the images do not need to be flipped. Some image file formats specify the top left corner as the origin, others allow it to be either/or. The BMP format actually lets you specify the (x,y) coordinates of the origin as part of the header relative to (0,0) being the lower left corner.

First, a little background: When a thread enters a synchronized block, it acquires the lock of some object (think of it as a mutex). When a thread attempts to acquire a lock, it will fail if another thread currently holds the same lock. Every Java object has a lock, so any object can be used to synchronize on.


Non-static synchronized methods all synchronize on the object owning the method. In other words, it's the same as wrapping the entire method in a synchronized(this) block. So when a synchronized method is entered, the lock to the owning object is acquired. Another thread calling any of the methods on that object while the lock is held will block until the first thread releases it. So one thread will wait for the lock to be released if both call "a" of if they both call different methods.


For synchronized static methods, the lock of the class object is acquired. So once again, multiple threads calling multiple static methods in the same class will still be synchronizing on one object, which means that only one thread can call any of the methods at a time.


When a thread attempts to acquire a lock that it already holds, success is automatic. So yes, a single thread can call multiple synchronized methods in the same object. If that were not possible, synchronized methods would hardly be useful.


I don't know of any good tutorials online, but there are some good books out there. Java Concurrency in Practice is an excellent reference that covers a great deal more that you need to know besides synchronization blocks.

In my own code, I very rarely use synchronized methods or synchronize on this. As a general rule of thumb, it's a good idea to minimize the amount of work you do in a synchronized block and to synchronize at the lowest level possible. A trivial example:


The idea is that you don't want to needlessly prevent a thread from carrying out operations that don't need to be synchronized, or to make a thread wait longer than it needs to. Consider what might happen if both methods in this example were synchronized: a thread calling doSomethingToAnObjectFromList would acquire the lock on the instance of MyClass and hold it until the method returns, meaning the call to obj.doSomething would be in the synchronization block. This means that any other threads calling addSomethingToList will needlessly be waiting for obj.doSomething to complete. Things really get bad if obj.doSomething is a lengthy operation. So by locking only on theList (i.e. the lowest level), you ensure that only the bits that need to be synchronized actually are and no threads will be waiting for obj.doSomething to complete.

Sometimes it really does make sense to synchronize entire methods, or on this, but most of the time you probably don't need to.

Read this thread at the LWJGL forums.

It's a good idea to pick up a copy of Joshua Bloch's "Effective Java Programming Language Guide" if you don't have it already. There's a lot of great advice in there and the section on the Cloneable interface will tell you everything you need to know about it.