Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Online Last Active Today, 09:56 AM

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

Posted by Karsten_ 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 Karsten_ 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 Karsten_ 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 Karsten_ 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 Karsten_ 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 Karsten_ 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.

#5131020 From C to ?

Posted by Karsten_ on 13 February 2014 - 06:23 AM

I'd probably go C# right now. Java left me a bitter taste and not in the good way.


If you want an even more bitter taste, try using C# with Windows Metro... They cut out loads of classes for their core profile and does tend to cause quite a few headaches.


Whilst C++ is a perfectly robust language, the only one I have known not to evolve in any radical way (for many years) is C.


... Oh wait, you say that there is now <stdbool.h>? C99 is Madness!

#5130636 Examples of "SDL Game Development" in ANSI C?

Posted by Karsten_ on 11 February 2014 - 04:09 PM

For some of your tasks, perhaps something like this could help:

struct Texture
  SDL_Surface* surface;

struct Sprite
  struct Texture texture; // *Not* a pointer to the struct
  int frames;
  int x;
  int y;

What is quite cool about this is that a Sprite can now be passed into a Texture function (in C, I don't even think you would need to cast it). i.e

struct Texture* tex = texture_create("someimage.png");
struct Sprite* sprite = sprite_create("someimage.png");

This technique is used in large C libraries like Gtk+. It also means if you do this form of "poor man's inheritance" on all your structures in the game, you could use a generic type of Object as the array type for example.

When using the popular component entity system (preferring composition over inheritance), I find using C is much more feasible for games development.

#5127995 old interpreter cint

Posted by Karsten_ on 01 February 2014 - 12:38 PM

I use CINT on UNIX for our build scripts where it "just works". I have never tried it on Windows. You will generally need binaries of a library in order to use them and you will often need to write your own binding layer since although CINT is C/C++ it is not running natively so you will need to bind it to native libraries (as is also required when using Python, .NET, JS and others) since there is no linking stage.


Fyi, CINT is a bit obsolete these days, it has been replaced by cling (http://root.cern.ch/drupal/content/cling). This is much more modern and uses clang / LLVM as a backend. Using C/C++ as an interpreter is still very much alive at CERN smile.png


You might also be interested in Pico C (http://code.google.com/p/picoc/). It is really light in comparison to CINT but you will still need to implement bindings to "non-core" libraries yourself.



There are also more heavy languages which you can embed like JS and Python.

The mentioned "Mono" is much heavier than JS and Python and unless you only ever use bindings that someone else has written, you will still need to be able to build native libraries and write the managed/scripted wrapper yourself anyway. I find developers always seem to forget this fact when using .NET, Java etc...

#5127795 Engine with C++ scripting?

Posted by Karsten_ on 31 January 2014 - 12:56 PM

For C++ interpreters, there is CERN's CINT project (http://root.cern.ch/drupal/content/cint) which supports scripting in both C and C++.

I really like it and use if for our expansive build system at work but I personally would not use it for creating games.


There is also Pico C (http://code.google.com/p/picoc) which looks much more usable for game scripting (though you would need to hook it up to the chosen engine manually). It is C only (no C++) but with the popularity of the component entity system these days, OOP is not really critical IMO.


If I were, you, I would do without the scripting part and look into something like Irrlicht. This is simply a 3D engine with a C++ API. Yes, a lot of people seem to not like it but frankly, the license, the ease of use and the portability of it is great for beginners.

The GoldSource engine was quite cool for mod development before Steam/DRM came along but you will need pretty decent knowledge of C/C++ before you will be productive using it. It doesn't spoon feed you unlike products like Unity or even in some respects like Irrlicht (less tutorials, documentation etc...).

#5123939 Classes and use of 'New'

Posted by Karsten_ on 15 January 2014 - 01:07 PM

  std::vector<std::shared_ptr<Car> > cars;

Looks ugly as sin* but provides fantastic functionality.


1) Deterministic destruction

2) No leaks

3) Exception safety

4) The pointer is guaranteed to remain the same even if the std::vector is resized. (i.e cars.at(7).get())


* Actually, the C# IDisposable pattern is much uglier when trying to get deterministic cleanup or resources.

#5119469 Have you made a game engine

Posted by Karsten_ on 27 December 2013 - 06:29 AM

Sony likely decided to use FreeBSD as the basis of the internal OS on the PS4 purely due to the permissive BSD 2-Clause license rather than any technical superiority that the OS has over Linux.

I think any version of the GPL license makes game studios itchy ;)

Then again, talking about licenses at this stage of engine development is perhaps not very productive. Get the engine built first and you can always swap out the parts using unworkable licenses.

#5119286 Have you made a game engine

Posted by Karsten_ 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 Karsten_ 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 Karsten_ 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.