Josh Vega

Not to try and prove you all wrong or anything, but I found this article a while ago which says that it is possible to separate the declarations and definitions for template functions into .h and .cpp files. It does seem though (from the sample compiler/linker messages he provides) that he's using MSVC rather than GCC.

 

I use templates in some of my projects and have been using "Method 1" (or as he writes, "Mehtod 1") to get around linking errors. Although, I too use only MSVC (haven't gotten a chance to learn how to use GNU tools yet).

 

EDIT: Fixed typo.

Though it is hated by many, W3Schools is where I go for quick references on every web development language or technology. I have seen a few errors and wrong statements, but none of them have been "game-changers" or really all that important.

 

Also, Tuts+ has a sub-domain of net.tutsplus.com. It is their web development portal. Its not really "tutorials" for people learning web development, but rather articles (and a few tutorials) for advanced developers looking to improve their projects. The downside is that for some of the more "revolutionary" or "this is really epic technology" articles, you do need to be a Tuts+ Premium member which means paying $19/month or $15/month for Monthly or Yearly, respectively.

 

Lastly, I found this page full of links to other tutorials. I've never used any of them, but I just now looked through them and at their code and they seem well made.

PyJS converts from Python to Javascript, not Java. Java and Javascript are two different languages.

 

I think your best bet would be to use PyJS. You will mostly likely need to do some Javascript editing because there might be bugs in the conversion process, but I think it is definitely the best way to got for web games. Its extremely powerful if used properly (e.g. Mozilla and Epic Games just recently completed their conversion of Unreal Engine 3 to Javascript).

Woah!

 

I don't even know how I missed that. I know that from prior experience that InteropServices is a P/Invoke method. I must have have gotten the question confused with another C# question I was emailed by a friend. Its been a busy day for me.

 

Sorry about that.

The pInvoke limitation is worse than you think...  Your code may not require pInvoke, but MonoGame does ( that's how it calls to OpenGL ).  I may be wrong, but im 90% certain the "free" version doesn't work with MonoGame.

 

Well MonoGame uses OpenTK for the OpenGL/ES backends. I checked the source code and it uses System.Runtime.InteropServices not DllImport or any of the other P/Invoke methods (although I don't know what InteropServices does in the backend).

 

EDIT: Information in this post is completely wrong and invalid.

Is it possible to you can post the relevent information from the output window during a build (preferably debug)?

 

I did a quick search for GLEW with OpenGL 3.X tutorials and ran across this page. I'm know that you are using GLFW and this uses Win32/MFC, but maybe the GLEW parts can help you to check against your own code.

 

Another thought that just popped into my head is that maybe GLFW is interfering with GLEW (or vice versa). If its possible, try switching out GLFW for SDL or SFML (or even freeglut) and try testing it again.

 

If all else fails, it might just be easier to switch to GL3W.

 

EDIT: I was just browsing through the forums here and found this thread where the OP has a similar problem to the one you are describing. It may or may not help, but I'm just gonna put it out there for you. You can check the final post for his resolution to the problem.

Plus - anyone else looking to build games on a budget, ID Tech 4 is free too with access to source code - it once powered (and I suppose, still continues to power) Doom 3 , and Quake wars!

 

Yes, id Tech 4 is open source, but under the GNU General Public License version 3. This means that you would need to release the source code to your id Tech 4 based game (and it also has to be GNU GPLv3 licensed as well). Torque3D on the other hand uses the MIT License which means you can pretty much to whatever you want with the code, including releasing your game as closed source.

The OpenGL wiki has a page on some of the common extension loading libraries as well as a page on loading extensions manually.

 

I know you already said that you dislike GLEW, but maybe you should post some code so we can find out why it isn't working. I've used both GLEW and GL3W with OpenGL 3.X before and have had no major problems. Try adding some error checking code:

GLenum err = glewInit();
if (GLEW_OK != err)
{
  /* Problem: glewInit failed, something is seriously wrong. */
  fprintf(stderr, "Error: %s\n", glewGetErrorString(err));
}

 

You could also attempt to load a specific extension as described here.

id Tech 4 and Unity 3D are rather different technologies from UE2.5-3. Comparing between these three engines running identical hardware, Unreal Engine 3 is going to invariably be slower than id Tech 4... Not necessarily "worse".

 

Don't get me wrong, I personally hate the Unreal Engine and have hated it since 1997, but what I was really trying to say was "a game engine written X years ago is going to run faster than game engine Y written yesterday." Get what I mean?

 

Not necessarily. An engine written with the proper optimizations could be designed to run faster than an older engine on the same hardware. Using technologies such as CUDA or OpenCL allows you to take some of the work off of the CPU and place it on the GPU. id Tech 4 games like DOOM 3 don't support GPGPU functionality while newer engines such as UE3/4 or CryENGINE 3 do.

 

And UE3 isn't slower because its newer, its slower because it requires better hardware than what is required for older (or lower-end) game engines. UE3/4 and CryENGINE 3 belong in a different class from id Tech 4 or Unity3D. both UE3/4 and CryENGINE 3 are designed to push the limits of modern computer hardware, while id Tech 4 and Unity3D are designed to run on current and older hardware.

 

Comparing UE3/4 with id Tech 4 is like comparing Battlefield 3 with Battlefield 1942 or Call of Duty: Black Ops 2 with Call of Duty 1. They are designed for different hardware generations. I'm sure if you pumped UE3 level 3D models into id Tech 4 it would run even slower than UE3 itself because it wasn't designed to handle 3D models of such high detail.

 

I've had the pleasure of working with all four engines (UE3, CryENGINE 3, Unity3D, and id Tech 4) at one time or another and can say this: "Each engine has its own strengths and weaknesses. Depending on where you want you game to be strong depends on the engine you should choose."

If you want to stick with Java you could try jMonkeyEngine, but it's a general-purpose engine rather than being specially built for first/third person shooters.

Otherwise if you have previous experience with Unity it would probably make a good choice for you.


id Tech 4 is also a valid choice given your requirements, but you may find it harder to get into and work with compared to some of the other options.

LWJGL (Lightweight Java Game Library) is also a good one that I have used. Though not technically an "engine" it does provide bindings for such things as OpenGL, OpenAL, and OpenCL as well as its own input system. Licensed under the BSD license, it is available for use in both proprietary and open-source games. Actually, the in-house engine created for Minecraft is built atop LWJGL. The only problem is that though it has a lot of documentation, much of it is about how to get started with LWJGL. Thus, creating a complex game is more of a hit-and-miss scenario than knowing exactly what you are doing (unless you do really know a lot about java).

Personally I, being the C++ kid that I am, would prefer to go with an engine such as the doom 3 engine (id tech 4) which was specifically designed for dark, indoor areas (as seen in the Doom 3 game).

If you are willing to release you game under the GNU GPL license I recommend the Doom3 (id tech 4) engine (https://github.com/TTimo/doom3.gpl). The id tech 4 engine was designed for dark, indoor games (like DOOM 3) but will also render very well in outside areas with the use of megatextures. If you are going for proprietary games your best bet would be UDK (http://www.udk.com/). Also if you decide to go with the Doom3 engine, I recommend you know your C++ cause it does include some confusing code and will require some adjustments before it is ready for release.

Oh, btw, you can sell your game if its licensed under the GNU GPL, but once a customer purchases a copy, they must be able to download the binaries and the source code (without having to buy a separate "package").