Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Today, 10:14 AM

#5093021 Some Queries about game dev?

Posted by Karsten_ on 10 September 2013 - 08:57 AM

The term "engine" is perhaps a bit overused in game development. Typically it is just a collection of other separate libraries (i.e OpenGL, glm, OpenAL, SDL, libpng etc...) with a bit of glue code to hold it all together as a framework (often including extra things like a scripting layer, serialization, etc...).

#5092514 Stick with C++ or venture into C#?

Posted by Karsten_ on 08 September 2013 - 12:10 PM

A typical programmer will certainly need to know a few languages so it is always worth improving your knowledge of a language. I guess just try to avoid falling into the trap of always flittering between different languages and never specializing in any.


I only ever choose to use C++ (and it has paid off since I like to think I am pretty good at it now ;). However I still need to know C# so I can understand example algorithms that are written using it. I also need to know C# so I can implement glue code between Microsoft technologies.


For example, I also needed to know enough Java so I could kickstart my native C++ game on Android. I also needed to know enough Objective-C to kickstart the same game on iOS.


Programming languages are like cars. Once they crash and burn, you need to be able to move onto something else in order to get to your destination.

#5092031 sucking potata

Posted by Karsten_ on 06 September 2013 - 02:57 AM

Since C++ is on a much lower level Socket programming makes use of sockets implemented for each Operating System

Although C++ makes it easier than Java or .NET to work directly with low level C code, generally there is no reason that you should.


However as Khatharr mentioned, the sockets API on most platforms is very similar (Mainly because Winsock was designed based on BSD sockets a long time ago).

This combined with the fact that using the sockets API directly isn't that difficult (i.e not too much boilerplate code required to get quick results) so I probably suggest wrapping your own socket library. I could give you a link to loads of premade socket libraries but personally I dislike using other peoples wrappers for this kind of thing.


Below is a list of simple examples. I use these as a basis for my own netcode.



Server - http://msdn.microsoft.com/en-us/library/windows/desktop/ms737593%28v=vs.85%29.aspx

Client - http://msdn.microsoft.com/en-us/library/windows/desktop/ms737591%28v=vs.85%29.aspx


POSIX / BSD / UNIX Sockets

Server - http://www.linuxhowtos.org/data/6/server.c

Client - http://www.linuxhowtos.org/data/6/client.c


Of course there is also Boost.Asio if you want to use a pseudo standard library (Akin to .NET and Java sockets).


For UDP, have a look at the simple examples here - en.wikipedia.org/wiki/Berkeley_sockets

#5090227 Confused about OpenGL 3.0+ shaders

Posted by Karsten_ on 29 August 2013 - 03:31 PM

From the looks of it, TheChubu based his answer off your sample code where you used vertexPosition_modelspace.


Try using in_Position instead because that is the correct name of the uniform.

#5090125 I Already Pick my Language and Now What i Need?

Posted by Karsten_ on 29 August 2013 - 09:52 AM

You seem to assume that he is using a Unix or Unix-like OS for that apt-get command.

That makes a nice change from assuming Windows and providing a link to the "setup.exe".


However, it does specifically assume a Debian based Linux distro (probably Ubuntu) as opposed to UNIX-like in general but it certainly is a start towards popularity of developing games on open-source platforms smile.png

#5089463 user input key store in array

Posted by Karsten_ on 27 August 2013 - 05:02 AM

Hopefully this will better explain what I mean smile.png


class Input
  static std::vector<int> keys;
  static std::vector<int> upKeys;
  static std::vector<int> downKeys;


    else if(event.type == SDL_KEYDOWN)
      bool found = false;

      for(int i = 0; i < Input::keys.size(); i++)
        if(Input::keys.at(i) == event.key.keysym.sym)
          found = true;

      if(found == true)
        // go onto the next SDL_Event
    else if(event.type == SDL_KEYUP)
      for(int i = 0; i < Input::keys.size(); i++)
        if(Input::keys.at(i) == event.key.keysym.sym)
          Input::keys.erase(Input::keys.begin() + i);

from https://github.com/osen/mutiny/blob/master/src/mutiny/Application.cpp

#5088632 Should I make a sacrifice?

Posted by Karsten_ on 24 August 2013 - 03:51 AM

Unity is working on a WebGL exporter which one day will be as ubiquitous as HTML5 (yes, even the latest IE is beginning to support it ;)) so your projects in Unity will work in standard browsers without plugins (probably by the time you have finished it).


Another option is to use the open-source tool which even Unity is using to make this possible, Emscripten allows you to write in standard C and C++ and output to HTML5 (via the wrapped SDL library) or WebGL (via the inbuilt OpenGLES 2 support).


If you want to stick with Javascript (rather than C++ or .NET/UnityScript) then have a look at three.js. This is apparently quite a popular engine.

Even Microsoft is suggesting it in their preliminary WebGL docs (http://msdn.microsoft.com/en-us/library/ie/bg182648%28v=vs.85%29.aspx).


I think where you might be hitting a wall is trying to use technologies like CSS. This type of web tech does not offer enough flexibility for pseudo realtime games (I personally also find it completely defective for normal web pages too). So I suggest looking at "coding" languages as opposed to markup (layout) languages.


But yes, I also believe games are going the direction of the web. If only because it allows publishers to "lend" the game to a player rather than allowing them to keep a copy (i.e DRM).

Most tablets are also so locked down and crap, that people can only really use them for the web browser anyway, so games on the "web browser" platform are more convenient for potential players.

#5087537 Creating My First Large Scale RPG

Posted by Karsten_ on 20 August 2013 - 04:11 AM

Especially when the article you linked clearly states that C++ does not have a garbage collector, as opposed to Java which does.

Yep, which I agree with. C++ does automatic memory management without requiring a garbage collector.
You can strap a garbage collector onto C, however I wouldn't say the C programming language has automatic memory management. Yet this is exactly what people seem to do with Java.

#5087410 Creating My First Large Scale RPG

Posted by Karsten_ on 19 August 2013 - 04:37 PM

Java seems easier to learn (e.g. due to automatic memory mgmt)


C++ has automatic memory management. Java doesn't, that's why it requires a garbage collector.





Either language, C++ or Java should easily be capable of a 2D RPG. Both should work great on desktop computers and Android. However if you want it to run on iOS too, I have yet to find a decent Java solution for iOS, in which case C++ might be the better option.


C++/SDL/OpenGL and Java/OpenGL(JOGL) are some examples of the libraries you could use.

#5086495 Do you find C#'s lack of an explicit destructor to be an issue?

Posted by Karsten_ on 16 August 2013 - 09:51 AM

need to implement and call the necessary methods yourself anyway. So no, I don't really see any issue there.

In languages with RAII and "other" solutions to memory management (such as C++ or Objective-C), you indeed need to implement the specialized cleanup code (as you would in C# / Java) (such as send disconnect messages, stop thread etc...) however, you don't need to call the methods yourself. This is extremely important for me because if an exception has been thrown, then in many cases the manual calling of the cleanup code you would need to do in C#, would not be called.

// Pseudo-code/C#: The IDisposable pattern has too much boilerplate for me to be bothered.
MyThread mythread;
  myThread = new MyThread();
  // oops an exception is thrown
  if(myThread != null) { myThread.Destroy(); }

void Dispose()
  if(myThread != null) { myThread.Destroy(); }

The finalizer or Dispose function for a class that never completed its constructor will never be called. You now have a Memory / Resource leak


In C++, the thread started by start thread would be destroyed (as the thread object pops off the stack), however in C#, this is made even worse by the fact that the garbage collector will never cleanup the thread because even though it has no reference left, it still has a unit of execution running on it (i.e itself).


Again, this can be solved elegantly using either RAII in native C++ or auto_handle in managed C++/CLR


In C# or Java, the solution might be something like this (which I personally dont like)

    myThread = new MyThread();
    // oops an exception is thrown

Ironically when I use Java and C#, I find myself writing more cleanup code than C++ (which admittedly requires none unless you use low-level C libraries (as you would also need to in C#/Java).

#5086439 Do you find C#'s lack of an explicit destructor to be an issue?

Posted by Karsten_ on 16 August 2013 - 03:56 AM

You can implement the IDisposable interface and wrap the usage in a using block which ensures that Dispose() is called after the using block is exited.



Note that this only works within the scope of a function. In programming, it is very common for variables which need explicit cleanup to exist outside of function scope (i.e as a member variable).


The common solution to this is similar to when working with Java. Lots of try catches around the place.


Interestingly, the memory managed C++/CLR has auto_handle (a clone of auto_ptr for managed references) which effectively does use the IDisposable pattern but works on things like member variables.




I looked at the emitted IL and it literally spams the output code with try/fault statements in every function that the variable is used. Basically it seems an elegant solution from a coders point of view, but the underlying system is a tad horrid!

I would actually like to see something like this in C# before I would consider using it for anything other than scripting.

#5084075 Why companies still use C++ and what should I learn then

Posted by Karsten_ on 08 August 2013 - 02:34 AM

I think C hit off because it was more source portable than assembly.


Something like C# however is not more source portable than C or C++ (since the runtime source is written in those two languages for a start)


It may be more binary portable but frankly phones and tablets are so limited and restricted these days anyway that you cant simply drop the .exe onto their memory cards and run it, so is a completely useless feature.


For this reason, C#, Java, etc... don't offer me any benefits I care about. I can still only target every device out there using C and C++.


Heck, (and referring to another thread) Microsoft couldn't even write an operating system in C#, they had to develop in sing# in the end to add "low-level programming language constructs, which are necessary for implementing system software" to actually do anything useful (based on spec#) (http://en.wikipedia.org/wiki/Sing_Sharp)


Don't get me wrong, the managed languages are quite pleasant to use. If they output native assemblies (and there is no reason to suggest one day that a compiler to do this wont exist) then I would indeed seriously consider using it. If more third party libraries supported being compiled using the the native Java compiler (gcj), I would probably use it with no issues.


For me personally, it isnt about the language but more the platform that they force you to use. For example I wouldnt use C++/clr, C++/cx, managed C++ or any of that either.

#5081509 Why companies still use C++ and what should I learn then

Posted by Karsten_ on 29 July 2013 - 11:57 AM

 but imo learning C# first makes you more disciplined, this ofc is just my opinion based on the books that are out there, the resources and the way in which they teach

I know you said it was your opinion, but I simply cannot see how learning C# first (probably using a RAD IDE) and getting used to completely disregarding memory management could possibly ever turn up a diciplined programmer in the long run.


As for Blizzard looking for other languages, the majority of openings are definately C++ with the exception of Java for the backend stuff (a grey line as to whether this is game programming or an accounts system). I have assumed Java programmers are only used for the backend framework for the simple fact that AAA games companies rarely provide games written in anything else other than C++ (minus some internal scripting engine).

#5081036 Win32 vs x64 ?

Posted by Karsten_ on 27 July 2013 - 03:45 PM

Perhaps not so relevant for personal projects but compiling for 64-bit usually makes your software harder to crack due to less tools being readily avaliable which support 64-bit extensions (OllyDbg for one) laugh.png

#5080449 Why companies still use C++ and what should I learn then

Posted by Karsten_ on 25 July 2013 - 08:01 AM

Legacy code, and lots of it.


Why is there so much legacy code for C(98) and C++(pre tr1)? Why not VB6, Java 1.2, .NET 1.1 or other popular languages or platforms of past years?


In ~20 years, sure we will probably call things like SDL legacy and sure people will still be slating C++ against their new language of choice and yet C++ will still be going strong, SDL will still work and everyone would have long forgotten .NET, C# and XNA.