Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Today, 04:02 AM

#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.

#5077537 C++ Developer moving to Web

Posted by Karsten_ on 14 July 2013 - 03:20 AM

Simply put, people using C++ on the web, are doing so because they are unwilling to learn another language.  

This is certainly true, it allows them to get productive quickly with whatever languages they already know.


For me, it is a portability issue. I know with C++ I can write my game once and know it can be compiled on every platform under the sun with minimal rewrite of the core boilerplate (boring) bits. I cant seem to find a single javascript platform that works on more than one or two platforms (including 3D) whilst still offering me enough flexibility to also use native libraries when required.


Plus the javascript emitted by Emscripten has the LLVM optimizations as a bonus so runs much faster than what I could manually write.

#5077454 C++ Developer moving to Web

Posted by Karsten_ on 13 July 2013 - 06:54 PM

It is my understanding that Wt is more for server side related code but am not sure how well it integrates with server side node.js.


Emscripten integrates with Javascript pretty well. Below are a few ways officially supported by the project. You might want to have a browse through and evaluate if this additional effort is worth it. (For my uses, it definately is! ;)





Though not supported by the Emscripten project, I made a small tool to allow me to inline Javascript within C++ code (in a similar way to how you can with ASM). This pretty much offers best of both worlds in that you can do the majority of your work in C++ but also get a 100% javascript environment to interact with libraries and APIs etc...



#5077369 C++ Developer moving to Web

Posted by Karsten_ on 13 July 2013 - 10:56 AM

If you already know C++ then you might want to bypass learning a web language and use something like Emscripen (https://github.com/kripken/emscripten‎).

It is basically a C++ to Javascript compiler. It works quite differently to things like coffeescript and typescript but the outcome is even better. You put in typical C++ code including smart pointers, STL etc... and it generates either a .js file or a .html file complete with a console, webgl rendering context or canvas component as output. Can't get simpler than that ;)


Quite a few companies are using this now, it is also getting popular in porting well known game engines to the web such as Epic's Unreal engine and Unity's web player engine.

I use it at work and for my personal projects and it is pretty awesome since it provides development libraries for things like SDL, glut, GL out of the box.

#5076748 link libSDL2.a with cmake

Posted by Karsten_ on 10 July 2013 - 06:17 PM

If I recall correctly, there was a compile time option for SDL_image to either load in libpng.so dynamically at runtime or to statically compile in support (in which case zlib and libpng source files are also needed during compile time of the library). Perhaps there is a similar option in SDL2?


But yeah, it is a shame SDL2 is taking so long to reach the package repos / ports collections. I also find version 2 to be very poorly documented so I am staying away for a while longer ;)

#5076604 link libSDL2.a with cmake

Posted by Karsten_ on 10 July 2013 - 07:48 AM



Basically the '.a' file is a static link library, meaning it pretty much only contains an archive of the SDL '.o' object files.

The '.so' file is a shared library meaning that it drags in its other dependent libraries as required at runtime.


If you do an 'ldd libSDL2.so', you will see that it lists all the SDL dependencies such as pthread etc...


However, if using Linux (rather than *BSD), you should usually explicitly specify linked dependencies even though the .so file already has them due to DSO linking changes in newer Linux distros. (http://fedoraproject.org/wiki/UnderstandingDSOLinkChange)


And, yes, if you statically link "everything" into your binary, it should mean that you can take it across to other Linux distros without having to get your players to install packages. Otherwise you would need to also carry across the .so files and set the LD_LIBRARY_PATH or something for your application to use them.

Linux is always in such a state of flux though that this isn't always guaranteed to work however, if the version of libc differ for example. Unfortunately certain libc versions also require an older or newer version of the Linux kernel.

Again, do a 'ldd' of your output application to see exactly what external libraries it depends on.

#5075408 Recommended SDL beginners books

Posted by Karsten_ on 05 July 2013 - 03:03 AM

This is perhaps slightly off topic but I have seen a user on these forums called lazyfoo, not sure if it is the same guy. If it is and he is reading this, it would be awesome to turn the lazy foo tutorials into a book! I would definately buy a bunch and give it out to students ;)