Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Yesterday, 02:12 PM

#5119286 Have you made a game engine

Posted by on 26 December 2013 - 06:49 AM

At work we have been making a C++ 3D engine which favours portability above all else. The technology used varies per platform (The only common part is OpenGL).


Some of the tech used for desktop platforms is Xlib/glx, libpng, openal, libogg/libvorbis.

The consumer platforms (Android / iOS) use the underlying platform's stuff but wrapped with C APIs similar to the desktop counterparts to minimize #ifdefs and other changes to the core games.


All the model loading, animation and physics is bespoke and written in C (with C++ wrappers) so is perfectly portable to everything.


To get it up to a usable state ready for games it took two of us a couple of months. It is unlikely to be as advanced as Hodgman's but as an "indie" studio, we currently need to battle with tablet / phone support and all the gimmicky short lived technology that it brings.

#5118382 SDL or Unity?

Posted by on 20 December 2013 - 10:26 AM

SDL and Unity are quite different things. SDL is usually more of a core library rather than a complete game making product.

I wouldn't be suprised if the Linux version of the Unity player uses SDL as a static library. (The HTML5/WebGl / Emscripten version will)


For 2D development, you do not need a complete game engine so unless you are a beginner, I highly recommend SDL (_mixer and _image) since it provides image loading, audio etc...


If you are a beginner with an interest in programming, I still recommend learning SDL since you will learn more (i.e event based programming) and it will look better on your CV. It will also allow you to step up nicely to OpenGL if you go that direction.


I know Unity has recently made a push to hoover up the 2D indie game development market but it still doesn't provide much. 2D animation is simple using tools like Spine (http://esotericsoftware.com/) (or you can write your own in a couple of days).

2D collision is also very straight forward so Unity doesnt really provide much more there either.


Tbh, I recommend anything other than Unity for 2D games but you might want to see what others on these forums suggest. ;)

#5118335 Shaders (GLSL) in one file? Is it practical?

Posted by on 20 December 2013 - 04:56 AM

As Kaptein suggested, as you load the file into your program, you just prepend the correct ifdef before the shader source code before sending it to OpenGL.

Another way of doing this could be as follows.

char *sources[2] = { "#version 330\n#define VERTEX_PROGRAM\n", sourceFromFile };
glShaderSourceARB(shader, 2, sources, NULL);

This basically send the define to OpenGL just before the rest of the shader source.

#5117820 glTexBuffer and Texbuffer Objects samples

Posted by on 18 December 2013 - 06:35 AM

glTexBuffer is part of the OpenGL 3.1+ standard.

glTexBufferARB is part of OpenGL as an ARB  (Architecture Review Board) extension.

glTexBufferEXT is part of OpenGL as a vendor (NVIDIA, ATI etc...) extension (i.e if found you download gl2.h from NVIDIA's website).


So basically, if you use an old version of OpenGL you need to use the ARB or EXT versions.


However, if you use something like libglew, it will match the correct function (pointer) to glTexBuffer so you don't need to worry about what is providing the actual functionality, you just use "normal" OpenGL.


For sample implementations, you might want to look at open-source software implementations of OpenGL (such as mesa http://cgit.freedesktop.org/mesa/mesa/tree/src).

#5117556 Can you help me plot out a long-term plan?

Posted by on 17 December 2013 - 07:01 AM

I guess what I want to do is limit the amount of outside input necessary to build a functioning game. I want to grow as a programmer so that I don't have to rely exclusively on others in that area to create games. Plus, programming is just fun.


If you can get away from relying on products like Unity and sticking with core technology then it will certainly help you keep up as technology evolves (which is why we don't teach Unity at University).


If you enjoy programming and can do this, then you are in a very good position. Personally I would go with OpenGL since it is immediately portable but at the end of the day, the two APIs are very similar so porting between them is much easier than people make out.

#5115935 What should I start with ?

Posted by on 10 December 2013 - 10:43 AM

and udk and torque 3d are the only viable options because ce3 works only with internet [...] and an internet based engine is unpredictable.

have +1 rep on me for realizing that CryEngine is ridiculous for the online requirement smile.png. I am not sure why CryTek is wasting indie developers time with this crap quite frankly.

As for you other options, you do have more than UDK and Torque 3D. A 3D table tennis game should not be too tricky in Irrlicht, Unity or DarkGDK.

OpenGL and Ogre3D might be a bit too "hands-on" when starting out but with enough 3rd party libraries, there is no reason why they should be much more work.

MonoGame is kind of an intermediate between low level OpenGL and a high level game engine like Unity. However it has loads of sample projects that you can grab the code from effectively making it almost as full featured as a game engine.

ThreeJS is also becoming very popular if you can stomach Javascript.

My personal suggestion is start with a 2D game in OpenGL and C++. Keep with these technologies and keep building up your own codebase until you are at a level to make a 3D pong game. That way your experience grows with your codebase. Then at the end of it you can make a game in C++ and OpenGL that really does work on all platforms with suprisingly little modifications.

#5115870 Which game engine to make Zelda-Style 2D game?

Posted by on 10 December 2013 - 05:26 AM

Since one of my first projects was a Zelda like engine, I can try to add a few more bits of info, you might find useful.

1) You don't need any rotations etc since it is all done with spritesheets. This means that you don't really need 3D acceleration which will keep things much simpler for you (and more portable between platforms).

2) Collision can be kept to simple rectangles (since there is no rotation, skewing etc...) so you don't really need a complex maths library.

3) When Link walks under signs or behind buildings you need to have layers but pixel art means that you can use a mask rather than full transparency.

So the following APIs (using various languages) should be ideal since you dont need a full game engine just yet.

C/C++ - SDL
C++ - wxWidgets
Java - javax.swing
C# - System.Windows.Forms
Javascript - HTML5 Canvas

Some tools that might be useful for your game:
http://londeroth.org/~fry/gonstruct <-- Simple level editor
http://graal.in <-- Graal Reborn - A developer site for Graal Online (including versions which include animation editors, level editors spritesheets etc...).

#5115700 Which game engine to make Zelda-Style 2D game?

Posted by on 09 December 2013 - 01:16 PM

For 3DS and Vita, I don't think Unity targets them. It is hard enough to get a Unity license for anything resembling a AAA gaming device, let alone a source license for unsupported platforms.

AFAIK C/C++ and OpenGL are the only technologies that definitely work on all 4 of your requested targets. Even then the OpenGL implementation for the PSP and 3DS is an abstraction layer over the native graphics systems.

If you can relax your requirements to just target iOS and Android, then you can use consumer tools like Unity and Gamemaker with no problems.

#5115653 Win32 programming, relevant in windows 8?

Posted by on 09 December 2013 - 08:32 AM

Personally, I would therefore definitively consider learning Win32. It is maybe not the prettiest, most straightforward quirk-free API in the World, and some things could definitively be better, but it will usually let you achieve what you want, and it really isn't that bad.

Yeah I know what you mean, whenever I try teaching students DirectX programming, they look terrified by the ugly Win32 function / variable naming when opening a simple window to render onto.

It seems a shame that Microsoft keeps getting distracted by things like .NET and Metro instead of creating a decent Win32 GUI wrapper.

Afterall, with OpenGL / Linux programming, I teach them using Qt which uses the equally ugly libXaw / libX11 underneath and they like it much more.


which after registering followed with "you have permission to develop for 30 days". That was an immediate dealbreaker.

I agree, I won't let anyone have that much power over myself or my company. Those arrogant fsckers. The failure of their platform suggests that we are not alone with our opinions ;)


Another annoying thing about Metro, Microsoft were in a position to really start a positive migration from Intel chips to ARM by providing a proper implementation of Windows and development tools. Instead they decided to lock it down so an ARM chip could only be used like an unpopular iPhone. ARM development really isnt any different to Intel (The C++ code can remain 100% the same in many cases), it is only these completely crippled operating systems that make it such a faff. So when people reject Surface RT because "it runs arm :(", that really annoys me. The real reason why they are not selling is because Microsoft is broken.

#5115615 Win32 programming, relevant in windows 8?

Posted by on 09 December 2013 - 04:57 AM

You surely have a reference for that bollocks?

Nope, but I didn't when VB6 was going down the pan either ;)

Just way too much software is working with it so Microsoft won't throw them away any time soon.

Microsoft did with VB6 and a lot more businesses relied on that for internal logic than they do with .NET now. Some of Microsoft's own products also used VB6 whereas .NET has never been embraced in Microsoft's products (other than perhaps plugins).

I am not saying that .NET technology will go anywhere since we have the open-source mono and products like Xamerin but I am very confident that Microsoft will be dropping 1st class support for their .NET implementation. Perhaps not in favour of Metro (since that is not doing so well) but if something "better" comes along...

Contrast this to the native Win32 API which Microsoft can't remove. If they did, Windows wouldn't boot. Even though Windows RT doesn't allow developers to access the full API, it is still there in its entirety since Office needs it and so does the low level underlyings of Metro itself (and everything else).

#5115446 What Language or Languages for Web and Mobile Apps

Posted by on 08 December 2013 - 02:45 PM

The Emscripten project (https://github.com/kripken/emscripten) will allow you to port your C++ code over to Javascript with minimal changes. If you use open technologies such as OpenGL, SDL, OpenAL etc... then this task is almost trivial.

Emscripten is a rapidly maturing project (sponsored and actively developed by Mozilla). You might want to give this a shot (at least until the "desktop" becomes cool again ;)).

#5115443 Win32 programming, relevant in windows 8?

Posted by on 08 December 2013 - 02:39 PM

The Win32 API is going to outlive this Metro gimmick. The standard native windows API has outlived VB6, WPF, XNA, soon .NET and many more. Why should this recent (unsuccessful) locked down tablet platform be any different?

If Microsoft does ever drop Win32 (i.e likely only if they retire the Windows OS and potentially move over to Singularity/Midori), then the open-source Wine project will be more than happy to support all the many thousands of large commercial software that rely on it. Wine is not likely to ever support the locked down crud that is Metro.

#5112808 Viability of Java For Video Games

Posted by on 28 November 2013 - 12:09 PM

Java can be compiled to native machine code with GCJ, so then as long as you use the right libraries it would have the same performance as C++.

I don't think I have ever seen a game written in Java and compiled using GCJ. Probably because GCJ is not very actively developed and still only supports ~Java 1.4.

Either way, since standard Java will very likely need to be using native libraries to create a game (OpenGL, OpenAL, ODE, Bullet, etc..), the speed is very unlikely to be an issue since much of the processing is done by native code (in the .dll or .so) anyway.

#5112569 Where is the source for cout

Posted by on 27 November 2013 - 03:53 PM

It's interesting since AMD doesn't supports their hardware on FreeBSD AFAIK, so they're probably rolling some custom drivers too.

Yep, thats right, though interestingly since we have had no help in the form of binary drivers from AMD, the open-source radeon driver is actually pretty usable for 3D (almost on par with that in Linux). However, since Nvidia provides binary blobs for its hardware, the open-source "nv" is utter shite (nowhere near the usefulness of Linux's Nouveau).


Moral of the story, AMD has had to be cruel to be kind ;)


All I know is that if I was that skilled developer putting all that effort into developing a highly complex driver, it must be soul destroying to know that in ~5 years when the new console comes along, all your effort will be completely lost. I bet they would love to open-source their work and prove to the world that they are one of the rare breed of programmers, smart enough to be able to create something like that!


Edit: Thinking about it. I bet all AMD did was release the specs for their hardware to Sony and they did it all in house. Afterall, AMD's UNIX drivers are extremely low quality (no 2D acceleration for a start) which would be an issue for the PS4.

#5112487 Viability of Java For Video Games

Posted by on 27 November 2013 - 10:52 AM

I have some experience of using Java / OpenGL for Android development. It was fast enough but since the Java garbage collector does not extend to the graphics card buffers, I found it to be really fiddly to manage the memory manually.

C++ has RAII for memory management which works great with vertex buffers, textures etc.. whereas I found the Java code needed to be spammed with try catches. Java was not great here.

All in all, I suggest that unless you know that you have all the Java wrappers required to do your project, Java is fine. If you feel you may need to wrap native libraries, not only will you need to write the native side of the Jni layer in C/C++ anyway but you will be spending time writing bindings rather than games.

I recommend Java shim and the rest in C++ any day of the week smile.png