Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Today, 11:44 AM

#5143493 Linux development...

Posted by on 31 March 2014 - 09:21 AM

A few tips that might help.

1) Like any new platform, start simple. Use a plain text editor and compile from the console until you understand what the IDEs are "meant" to be doing for you.

2) Are you new to C/C++ development too? If so, perhaps learn this on the platform you currently use so you are not in a completely foreign environment.

3) With Linux, in exactly the same way as OSX and Windows. If you have hardware that the OS does not support, swap out the hardware with something that does. In your case, a graphics card is quite an easy thing to replace. However, I would be suprised if your card was not supported. Perhaps try running glxgears or a 3D linux game (i.e OpenArena) to see if it is working.

What issues were you experiencing with Irrlicht? Did you install it from the package manager (# apt-get libirrlicht-dev) or manually from a source archive? If you specify the error you are having, I might be able to help solve it with you. In most cases you can compile code like:

$ g++ MyCode.cpp -lIrrlicht
Linux is trivial to develop for so once you get over these initial hurdles, you will find it extremely straightforward from then on.

#5142912 Browser-Based Game: Best Language?

Posted by on 28 March 2014 - 01:11 PM

There are many Javascript tutorials around the internet because it is quite popular (Perhaps due to the flux of web developers flooding out of universites between 2008-2011). So I am sure you can find some quite easily via google.
The only additional tips I can offer is to be weary of w3schools which traditionally has been infamous for bad habits (though it might be better now).
You will also come across many examples pushing JQuery. I would keep well away from this because it is not standard Javascript and it is not always very interoperable with other libraries.

A site that does look quite useful is Mozilla's developer site. It doesn't look browser specific either which is obviously important.

#5142815 Browser-Based Game: Best Language?

Posted by on 28 March 2014 - 05:32 AM

There is currently a catch with the following technologies:



C# (Unity 3D)

C# (Silverlight)

AS3 (Flash)


They require your users to have a plugin (of the correct version) installed. This also means that your software will only work in specific browsers on a limited number of operating systems (that supports the plugin). Tablets in particular will not load them in their web browsers.

Plugins are a legacy technology that are slowly and surely moving over to Javascript / asm.js. Unity is making good progress at porting their plugin to pure Javascript via Emscripten, Unreal engine has done the same. Adobe have also stated that they are going to be migrating their tools and language over to HTML5. Unfortunately none of these are quite ready yet.


So instead, since you are starting from scratch anyway, I recommend the following choices.


Javascript (+ Canvas) - For 2D web games

Javascript (+ WebGL) - For 3D web games (perhaps using three.js to help)

HaXe / Typescript etc. export to JS too so these kind of things might suffice if you really dislike Javascript.


If you or anyone else in your team is interested in getting into programming in a big way, then this opens you guys up to Emscripten (C++ -> Javascript compiler) which is becoming very popular now with larger companies and native developers but also allows you to utilize a massive back catalogue of traditional C and C++ libraries to help you develop your game (rather than reinvent the wheel).

#5139446 Framework or game engine with highest cross platform index?

Posted by on 16 March 2014 - 08:56 AM

For me, I have yet to find one complete tool that is more portable than C/C++ and a mish mash of open-source libraries.

  • OpenGL
  • glut (or SDL)
  • libpng (or SDL_image)
  • OpenAL (or SDL_mixer)
  • glm (or linmath)

This compiles and runs great on the following platforms

  • *BSD
  • Linux
  • Mac
  • Windows
  • HTML5 and/or WebGL via Emscripten
  • Android (via NDK)
  • Ouya
  • Blackberry (via Blackberry SDL)
  • iOS (via Objective-C++)
  • PS3 Homebrew / AltOS


It has the possibility to run on a few others (with a few gotchas and not personally tested)

  • NaCL (if libraries are sufficiently wrapped)
  • Haiku (in software)
  • Windows Store (via Emscripten and WebGL)
  • Plan9 (I did test this one ;) Software only for now)

I believe some of the professional AAA console SDKs and homebrew SDKs support many of these libraries but the consumer ones like Xbox Live, PSN etc. are probably a no hope.


If you prefer a single library than the mishmash suggested above (and do not need to support Plan9), then Marmalade provides a similar approach to how it handles cross platform requirements but wraps up all the libraries in a single homogeneous API (and uses proprietary ones rather than things like SDL).

#5139042 What is a day like in the life of a programmer?

Posted by on 14 March 2014 - 12:42 PM

It might also depend on how much of a purist you are. Where I work, sometimes instead of solving a problem correctly, there is quite an undesirable trend of "just grab a plugin and hack round it's failures". This leads to a really crummy and unportable codebase and is not very enjoyable to work with and no-one has any real sense of ownership or care. Luckily the company is also sponsoring me for my PhD so I always have that work to fall back on if I can see a project implementation going this way ;)

However, sometimes the project at work involves a team of like-minded individuals who don't mind implementing a bit more code to get things "right", then it can be a great laugh (and the output is of a much better quality).

So it really depends on the specific company, their policies and their existing employees that really makes the difference to whether it is just as fun as coding as a hobby.

#5138108 Are some people not cut out for programming?

Posted by on 11 March 2014 - 08:29 AM

If you want to go into language parsers in a big way, the "dragon" book will be a great asset.


Also, perhaps you might want to have a look at a slightly simpler implementation of a C (not C++) parser.


More than likely not as robust but since you are probably a games developer and want to make games rather than language parsers, it might be a better starting reference.

#5136628 Switch or Not?

Posted by on 05 March 2014 - 05:06 PM

Well, C++ by proxy of C does support trigraphs.
I dont suggest using them but if you cannot seem to get the '~' character to work this might be a last ditch effort ;)
#include <iostream>

int main(int argc, char* argv[])
  std::cout << "??-" << std::endl;
  return 0;
When compiled with the -trigraphs compiler flag, this will infact output "~".

One of the most important skills you can learn in game development is to stick to something. If you keep losing interest, this is not going to produce a good outcome.

#5136613 Switch or Not?

Posted by on 05 March 2014 - 04:20 PM

Why does Unity seem like the best option for your 2D game?

If you switch to C#, are you going to start from the console level again? Or jump a few steps straight to using a game engine?


My suggestion is keep with C++ and a use a simple 2D graphics library like SDL to start your game.


In particular I recommend using SDL 1.2 and following these great tutorials: http://lazyfoo.net/SDL_tutorials

Read the corresponding tutorial as you need it for your own game. After all, he best way of learning is by doing.

#5133273 Legacy code (what's it and how is related to c++)?

Posted by on 21 February 2014 - 09:13 AM

Well C++ does have a deprecation system. For example std::auto_ptr<T>.


Also, if you don't use an old feature of a language. How could that effect your project negatively? Just because the language supports something, it doesn't mean you have to use it. Same with new features, I know a lot of developers I work with tend to overly consume language features because they are "new and cool".


Most C and C++ compilers also have a way to specifiy the standard to use via a compile time flag (i.e -std=C++11, -std=C++0x, -std=C99). It also has "non standard" standards support (i.e -std=gnu++0x) and even one that adds basic RAII into GNU C (cant recall the compile time flag).


What would you prefer? A slightly more complex language or one that a library you rely on no longer compiles because the language has changed?

Ironically using something like Java or .NET does not solve this because both these languages are compiled using C / C++ so a breakage in the underlying C language has a knock on effect on these entire platforms (i.e porting Java to a new platform is a massive task made almost impossible if the C++ language changes every year).

#5133268 Legacy code (what's it and how is related to c++)?

Posted by on 21 February 2014 - 08:46 AM

so backwards compatibility is a good thing? I heard C++ is also backwards compatible with C and that struct comes from C while the C++ equivalent is class.


Definitely. My main interest in the C++ language is the backwards compatibility.

If Java could support old C and C++ code and didn't need a JRE, I would be all over that mofo ;)


C++ is mostly backwards compatible with C (in that it is very easy to get C compiling with a C++ compiler). Objective-C also is backwards compatible with C. C++ is a little more strict than C in that it needs explicit casts etc.. but in general it is all good.


C++ has structs as well but the only difference between a struct and a class in C++ is that by default everything in it is public. A well designed C++ application can make use of both structs and classes.


I might add that although C++ is backwards compatible, the design of the code is different and should be treated as such. New(ish) features like custom deleter functions in smart pointers make dealing with C code much nicer however.


I think the best example I can think of is OpenGL which is a C library can be directly consumed by C++ code. Contrast this to using other languages where you have to use a wrapper (a wrapper is a large project to bind the native C code to another language). These things are notorious for becoming very unmaintained and out of sync with the latest version of the original library. Even Microsoft couldn't be arsed anymore with XNA (A fat binding for DirectX 9). Another example is the many Java OpenGL bindings. These things are platform specific (so you instantly lose one of the potential features of Java) and they are also a massive pain to rig up compared to just doing the whole thing in C++ and binding it at compile time (try writing a simple C++ OpenGL application and then try the same thing in Java and make up your own mind).


Plus, C and C++ can easily go the other way too. They can call, for example, a Java library or .NET library using libjni or libmono (or even Microsoft C++/clr). Trying to get Java code to call a .NET library is extremely fiddly.


That said, some of these features I have just ranted about are not always necessary for games development so it is largely irrelevant to most people. It still comes down to use the language you prefer and can get the game done quickest in ;)

#5133264 Legacy code (what's it and how is related to c++)?

Posted by on 21 February 2014 - 08:32 AM

Surely your comment just agreed with that quote.

Languages may never fully go away but the popular ones that get used 24/7 do naturally generate legacy code. So again, the sheer popularity of C and C++ is what has caused the influx of legacy code.


I honestly have never seen Smalltalk code in the wild (let alone legacy libs) but I come into contact with Lisp quite often via my use of emacs and admittedly I have seen some pretty crusty Lisp (even though it is a slightly different dialect) ;)

#5133258 Legacy code (what's it and how is related to c++)?

Posted by on 21 February 2014 - 08:19 AM

As stated by Bjarne Stroustrup


"There are only two kinds of languages: the ones people complain about and the ones nobody uses".


The only reason why there is legacy C and C++ code is because C and C++ was common back then, still is common and will remain common in future (afterall, it is pretty much *the* standard language in software engineering).

If Java or .NET was around back then and it was deemed better than C++, then there would be lots of legacy code lying around in those languages.


A good example of this is Microsoft VB6. There is a tonne of legacy VB6 code lying around but unlike C++ the new VB.NET is not backwards compatible so developers are reimplementing it in current (more portable) languages (like C++ and Java).


In another 50 years, the original legacy C and C++ code will probably still work so what will it be called? Archaic? In my opinion, if legacy code works, is maintainable and well documented then it is great. It means that it was originally correctly written and used correct "futureproof" technology. Contrast this to code that you need to rewrite every few years because you keep choosing technology that becomes obsolete / dies (I am looking at you VB6!).

#5133207 SDL and android?

Posted by on 21 February 2014 - 03:53 AM

I won't say i'm new to programming, however I am new to android and mobile platforms. My question is simple, How difficult, if possible, would it be to port over a game made for desktop, onto the android platform. I'm not worried about IOS, as I simply have no desire for it. Is this even possible, and excluding modifying controls, what would most likely have to be changes. It's a simple 2D platformer, that is still to early in development to post any preview pics of, or I would as I feel it could help answer my question. Oh and im using Visual Studio 2013, C++11.


To port your game to Android it obviously depends entirely on the complexity and dependencies of the game.

Usually I would do the following steps:


1) Look at all the dependencies your game has. For example, SDL, OpenAL, libPng.


2) Look around for Android ports of those technologies and test them out. If they are messy, then don't spend any further time with them.


3) Look at what dependencies your game has left and start duplicating the API but instead hook up the functionality to the underlying Java platform (via JNI). This is the more fiddly step but once you get familiar with JNI, the very large and featureful Android API does provide almost every feature you could require.


4) Get a very good system for debugging on the device. You are going to have to do this a lot and if your compile / test / debug cycle is fiddly it will take an enormous amount of time. I.e learn remote gdb. The time really pays off!


5) If you are developing the game from scratch to target desktop and Android. It really pays off to setup a build server so whilst you are developing on the desktop version (which is still easier to debug and build) you know you will be alerted if there is a compile failure on the Android side. You can also periodically test the build by simply grabbing it straight via the Androids web browser.


Some additional tips.


1) Glut has a seemingly more portable design than SDL in that it's callback system is easier to hook up to platforms that do not allow you to control the main loop yourself (such as Android and Emscripten). You don't need to use Glut but perhaps design your SDL application in a way that the main loop is in a callback. This will end up being called from Java on the Android side (unless you go with the NativeActivity which is great but only works on newish devices).


2) Prefer individual (swappable) technologies rather than one large massive framework. SDL, SDL_image, SDL_mixer is an example. If you need to replace SDL, you will also be required to replace everything else that relies on it.


3) Don't drag in dependencies when you can implement the functionality quite easily yourself. Remember that it is always easier to port your own code between platforms than it is someone elses.


4) Avoid locked down platforms (like you are doing with iOS). They are a massive faff unless you jailbreak them but lets be honest, that is barely a permanent solution when your original development device breaks and you have to track down another "hackable" device.

#5132350 Making WebGL game multiplayer

Posted by on 18 February 2014 - 09:53 AM

At the moment there is no way for a websocket to "listen" in a web browser which is a bit of a pain for peer to peer games.

If you want to stick to Javascript (to maintain a similar codebase) you can use node.js for this.


Otherwise I recommend http://websocketserver.de. One thing you will notice is that websocket servers are so sodding overengineered and it is almost impossible to find a simple client / server example beyond the handshake (which is actually the easy bit).


As for a list server, I highly recommend using IRC as the system to distribute instance server details. It is barely any bandwidth (so wont annoy other users) and also means you don't need to maintain a central server. Though for websockets to normal sockets to communicate you will still need to set up a websocket proxy.

#5131049 From C to ?

Posted by on 13 February 2014 - 09:17 AM

Yes, admittedly I have never even seen C11 code in the wild.


I still dont think MSVC fully supports C99 either which is quite annoying. Microsoft's excuse was that they would rather spend time on C++0x functionality.

Now, as a C++ developer, I agree with this choice. Unfortunately their C++ support is a bit lacking too :/


With Microsoft's new direction with C++ (Albeit C++/CX) perhaps we will see them make up a bit of ground here in the near future including in C support.