Jump to content

  • Log In with Google      Sign In   
  • Create Account


Karsten_

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

#5168640 C++ files organisation

Posted by Karsten_ on Yesterday, 07:41 AM

So instead of relative includes, what would be a good way if I don't want a centralized include folder ?
I have this problem recently when I was reorganizing my files and I need to update quite a few of the includes.


Unless you are making reusable libraries as part of your project, I would recommend a single folder for both your src and header files. i.e a single .exe means I would create a single src directory. If you find this folder simply has too much source code files in, then this might even suggest that you need to break your project up into multiple separate libraries (in which case they would get their own src directories (containing .cpp and .h).

So since these libraries and binaries are separate projects, you could say that I don't do any nesting in my projects. Some places where you may be tempted however is if some code is completely standalone from the rest of the project (i.e so no #include "../" needed since it has no dependence on other headers). If a part of a project is also in a separate namespace then you may also want to nest, however often parts in a nested namespace still require ../headers and I do typically try to avoid this pattern.

One system that I have found to be very effective is the following (I use cmake but this should work with many build systems). Imagine a folder structure as follows:
 
proj/
  src/
    game/
    foolib/
    barlib/
If I specify on the command like -Isrc, this means that anywhere in the game source code, I can do
 
  #include <foolib/foolib.h>
If foolib has a dependency on barlib, I can do in the foolib code:
 
  #include <barlib/barlib.h>
This means that you can separate your project into logical libraries (and separate .cpp / .h directories) and yet still be able to reference the correct headers you need.

Whats quite useful about this system is that if barlib was really made to be a standalone library, I could have an installer script like:
 
# mkdir /usr/local/include/barlib
# cp -r src/barlib/*.h /usr/local/include/barlib
# cp lib/barlib.a /usr/local/lib/
And now any project on my computer can access the barlib.h in exactly the same way as when it was part of my project.


#5168240 Is c++ good

Posted by Karsten_ on 21 July 2014 - 05:23 PM

C is more for the hobbyist who is working with a small team (or just himself), because you're not usually dealing with a complex application, i.e., you're making Pong.

 

Some of the largest software codebases in the world are written in C. C is not for hobbyest game projects (arguably that is what C# is for). C is for complex systems level development that deal with problems that languages like C++, Java and C# are not best suited for.

 

C is certainly not "C++ without all the hard bits" ;)

 

You may be well aware of this, I just wanted to emphasise this point in case someone starts learning C because they believe it is the easier of the languages beginning with the letter 'C'.




#5167950 Linux development workflows?

Posted by Karsten_ on 20 July 2014 - 07:01 AM

Since I started out with programming on UNIX I tend to use that same development environment even when on Windows.

In a typical Linux/UNIX project I generally find all of these tools useful.

Editor: Vim - Including the NETRW and Buffergator plugins. Helps navigating scattered source bases quickly. More importantly, it does not require a "project file" for source aware navigation to work. My biggest annoyance with Visual Studio or other IDEs.

Code completion / Navigation
- exuberant ctags (Vim supports by default now).
- cscope (performs some tasks ctags cannot)
- doxygen (With C the automatic flow chart generator is fantastic for development and learning codebases)

Compiler:
- gcc for main releases
- Any compiler I can get my hands on since they all potentially pick up on different issues.

Build System:
- cmake
- simple Makefiles for release builds and test harness

Continuous Integration: Jenkins on a bunch of VMs targeting many platforms

Misc: tmux for multiple terminals

Debuggers / Profilers:
- Valgrind
- gdb
- ElectricFence
- Intel VTune
- AddressSanitizer
- splint

Arguably GLX requires less boilerplate code than Windows alternatives when setting up an OpenGL rendering context.

http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib

You may notice it has a line count close to when using Glut.


#5167704 C++ smart pointer usage

Posted by Karsten_ on 18 July 2014 - 06:27 PM

Valgrind can be used for this (the callgrind and cachegrind tools in particular) (http://c.learncodethehardway.org/book/ex41.html)

 

However for Linux (and Windows) I really recommend Intel VTune. It is quite pricy but it is trivial to detect hotspots in your code.

 

If you want a cheap hacky alternative and you are using libraries that Emscripten C++ supports, I have recently found that compiling the game to Javascript and then running it in a browser allows me to profile it using Chrome's Javascript profiler which is strangely effective (It almost does a good job at locating out of bounds stack array access, something that ElectricFence, Otto's malloc hack and even Valgrind have difficulty with).




#5167701 why c++ is the most widely used language for professional game development?

Posted by Karsten_ on 18 July 2014 - 06:12 PM

There is nothing worse than starting out on a Java or .NET project only to realize that there is no up-to-date binding available for a technology I plan to use (which is extremely likely to provide a C API). That sinking feeling I get when I need to start messing about with JNI or .NET DLLImport code. What a waste of time when I could just be working on the game instead.

 

Whereas for C++ I can use the C libraries directly since C++ by design is an extension of C (so long as I am careful with smart pointers and deleter functions I can often get away without any abstraction layers at all).

 

I think this very reason is why most commercial software written today is still in C++. I think a lot of C# developers on these forums seem to forget that C# is only easy and safe because Unity has already done the actual hard work of writing the engine, binding the libraries and porting the .NET runtime to the many platforms (Same with OpenTK, and XNA-like).

 

As for the language itself I am not too bothered. C++, Java and C# is similar enough so long as you do not use the old crusty parts. I do however find Microsoft's C++/clr:safe very interesting. Basically a merge of C# and C++ so you get all the RAII and memory management goodness of C++ but also the safety of C#. Looking at the generated IL, Microsoft really could add RAII to C# and if it could also compile to native machine code (so it didnt need such a complex (to port) runtime VM), it would likely dominate the world.




#5167108 Is c++ good

Posted by Karsten_ on 16 July 2014 - 03:37 AM

it;s not nice and it wouldn't happen in a more modern language.

Interestingly now that C# is starting to age, I am starting to notice some of the same complexities as in C++.

 

For example, the C# that you would need to write in Metro applications is very different to what you would write in Unity. It has a much more non-blocking / "javascript" like approach where much of the functionality is implemented as async functions (albeit all completely unique to Metro and very unportable so we can't really blame C# here). Much of the standard C# patterns do not work here (in particular the using (or IDisposable, try / finally) pattern for memory management since allocations need to persist across functions).

 

Perhaps the biggest issue is that a lot (too much) of the standard C# library has been removed or replaced in Metro (.NET 4.0 Core) and it is a little harder to work around than in C++ because of a less flexible preprocessor.

 

That said the Metro C++(/cx) is pretty crazy too and sees many of the same issues as C# with the stripping down of the <windows.h>, however it's standard libraries are completely intact allowing for IMO an easier porting process.

 

So I guess it comes down to the fact that Metro is annoying, however, since C++ has a smaller standard library than C# it means there is less there for Microsoft to shred! ;)

 

I wouldn't be surprised if a future version of C# does provide a preprocessor similar to C++. Once C# gets the same amount of legacy baggage as C++ (and since it is a popular language this is quite likely) then it really is going to need it.




#5166987 Is c++ good

Posted by Karsten_ on 15 July 2014 - 08:54 AM

Theres no reason why somebody who has used any of these languages would not understand C++ code.

I dont know... C++ has an automatic memory management system (RAII) that is quite different from other languages (especially ones needing a GC). Even though developers new to C++ may be able to understand what the C++ code does, I don't know if I would trust that their code is safe and correct.

 

But I could be wrong. Apple has proven that if you make a language trendy and cool enough (Objective-C), no matter how low level and complex it is*, even beginner developers are very capable and productive regardless. Better still, many beginner developers are quite happily cross compiling to restrictive ARM devices and remote debugging. Something that is quite a step up from what I was doing when I was starting out (VB6) ;)

 

* no garbage collector (Apple deprecated it), pointers, possible undefined functionality, exposure to C-style memory management.




#5166387 XNA vs Other

Posted by Karsten_ on 12 July 2014 - 05:25 AM

Microsoft used to come around University telling the students that XNA is deprecated in favour of MonoGame (an open-source XNA clone). The VisualStudio IDE used to crash every time they did a demonstration of the content pipeline with MonoGame biggrin.png

http://www.monogame.net

At risk of getting a lower grade because of minor differences between the two, I can't suggest that you use it. But you should probably evaluate it yourself and make the choice.

Your tutor might respect the fact that you are looking outside the box and towards solving issues of portability (a major topic within the game development industry).

If you are stuck with C#, an option that I would personally suggest is OpenTK. It is basically a very portable (and pretty thin) .NET binding around OpenGL, OpenAL etc. Anything you learn here will almost directly be translatable in later life to C, C++ or other languages using OpenGL. Including Javascript and WebGL (or preferably Emscripten).
For 2D you should find it pretty easy. For 3D naturally it becomes a more steep learning curve because you will be learning the fundamentals of modern 3D graphics programming rather than just scripting and automating products like Unity.

http://www.opentk.com


#5165511 DLL Import Failure

Posted by Karsten_ on 08 July 2014 - 04:40 AM

First of all, who ever said anything about Unity?  I never once mentioned it.

Heh, yeah, my bad. I kinda made the assumption that guys here using C# are probably using Unity. Much of my suggestions are C# issues in general than Unity so at least that cuts out licensing restrictions.

 

Now that you mention it though, it does require another DLL.  I don't remember whether I included that into the project as well.  Should I just include both of them and put both of them into the debug folder where the EXE is?

Normally just include them in the same folder as the .NET executable. However try compiling them in release mode. I think debug versions of the binaries could potentially cause issues.

 

If your .dll does come with a .lib file, then yeah it is likely to be a traditional native dll. So no problems here.




#5165288 DLL Import Failure

Posted by Karsten_ on 07 July 2014 - 10:38 AM

The .dll should be the correct one. .lib files are not used like that (On Linux you would use .so rather than .lib too).

However in Unity C# you do not seem to need to pass in the .dll suffix (may be optional). Perhaps try:

 

[DllImport("DllName")]

 

Have a look here: http://docs.unity3d.com/Manual/Plugins.html

 

Btw, this is a Unity Pro only feature so that could be your issue.

 

Perhaps also make sure you are not trying to compile for the Web Player. That has extra restrictions preventing native code for security sandboxing reasons.

 

Can you make sure your .dll does not require any other dlls? Usually if they require more .dlls then it could fail to load. There are tools on Windows that should help you find out (perhaps try depends (http://www.dependencywalker.com)).

 

Perhaps also make sure that you have built a native .dll. It is quite likely that you already know this but if you generated a .NET dll using Microsoft C++/clr:safe or pure, it will not work when loaded in like this.

 

Finally, I once noticed that when I made a Unity plugin with wxWidgets, it actually had to have the wxWidgets dll in the same directory as Unity.exe. Perhaps try this if none of the other suggestions work.




#5158233 After learning basics of C++

Posted by Karsten_ on 04 June 2014 - 04:07 PM

and i saw that none of mobile platforms support C++

They do not advertise very well that they support C++ but the fact of the matter is that they all have to support C++ because they were largely all written in C or C++.

 

So with Android, have a look at using the NDK (https://developer.android.com/tools/sdk/ndk/index.html). The examples are great and you can generally get started (with OpenGL) directly from the hello-gl2 example project.

If you do not want to use *any* Java in your application, then look towards using the NativeActivity. Personally I much prefer using this simple event driven system rather than all the object-orientated fluff required by typical Android development.

 

With iOS, you will be using Objective-C++. Most of the documentation is about Objective-C (i.e https://developer.apple.com/library/mac/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html) but frankly it is quite straight forward to apply your C++ knowledge to extend it to Objective-C++. One of the main tricky bits is getting the automatic memory management (RAII) provided by C++ to play nicely with the automatic memory management (Reference counting) provided by Objective-C.

 

With WP8 / Metro you will be using C++/cx (http://developer.nokia.com/community/wiki/C++_support_from_Windows_Phone_8). This language is very similar to Microsoft's C++/clr compiler and is basically an extension to pure C++ (i.e it also provides ^ and % in place of * and & for managed or WinRuntime references).

 

Blackberry primarily uses C/C++ anyway (have a look at http://developer.blackberry.com/native/documentation/cascades/getting_started/first_app/create_your_first_core_app.html). I enjoy blackberry development. I found its API to be really clean and well documented. It is really noticable that the API is designed with C++ in mind as being its main applications language. Shame Blackberry is no longer "cool" :/.

 

Tizen is apparently programmable with both Javascript and C/C++ but I dont know too much about it. Not yet had a project involving it (some docs: https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.apireference/group__Cplusplus.html).

 

You may also want a look at Marmalade (https://www.madewithmarmalade.com/) which not only provides the C++ SDK but also an abstraction layer to help write cross platform code for many platforms.

 

Finally, and I probably do not advise this but you can also use Microsoft C++/clr to script more hobbyist tools like Unity. If you make sure to use the /clr:safe flag, it even works in the restricted WebPlayer environment (Though you also lose a lot of the power and benefits of C++ too).




#5158085 Language Choice

Posted by Karsten_ on 04 June 2014 - 07:14 AM

Well, I should mention that now both Unreal Engine 4 and CryENGINE are cheaper than most commercial game engines (Better than Unity Pro's 30,000 dollars)

 

Agreed. Epic Games in particular has done a very impressive thing by opening up their Unreal engine to the masses. Frankly I am very happy to pay their subscription costs more as a donation and pledge of support even if I am not currently using their engine for a recent project.

 

Last time I looked at CryENGINE however, it required me to log onto their servers in order to use the main tool. This is called DRM and for this reason, it should not get our support. Similar to why Unity should not get our support.

 

I really am hoping that Epic Games benefits from their decision. They really deserve it. I am also noticing a massive improvement in portability to platforms like Emscripten, Linux and even BSD because of this so again, great job!




#5157305 What to use for an OpenGL-based game engine.

Posted by Karsten_ on 01 June 2014 - 05:14 AM

I personally use wxWidgets for tooling (since I never liked the way that Qt advocates using non standard C++).
It is portable to pretty much any OS people run productivity software on.

The exact widget I use is called wxGLCanvas.

You can read more about it and it's usage here: http://wiki.wxwidgets.org/WxGLCanvas

Most people's gripe with it is that much of the old documentation talks about things like DECLARE_EVENT_TABLE() because it used to use this system back when MFC was "cool", however this is very out of date and you should use connect() instead. Have a read of: http://wiki.wxwidgets.org/Example_Of_Using_Connect_For_Events
Not many developers know this unless they have actually used wxWidgets before so unfortunately this misinformation still spreads.

For the games themselves, I really suggest grabbing a rendering context from some library (Glut will do on desktop, GLSurfaceView will do on Android) and then create your own GUI widgets in OpenGL.


#5155837 Language Choice

Posted by Karsten_ on 25 May 2014 - 05:12 AM

In the professional world of interactive media and games, C/C++ are the main choice.

However for indie game development, you are very much constrained to what your tool of choice uses. For example with Unity you are going to be looking at .NET languages (C#, UnityScript, Boo). Likewise, the "Indie" version of UDK 3.x would require UnrealScript.

Many of the more open-source engines and tools allow you to use C++ (as well as other languages with bindings) including the very latest UDK 4.x (if you subscribe for source access).

So the question really is. Out of all the engines you have had a play with. Which do you prefer? Then pretty much go with whatever language it best supports.


#5153604 How do I add librarys in visual studio 10?

Posted by Karsten_ on 14 May 2014 - 11:06 AM

My favorite method is by using the #pragma comment, ex:

 

#pragma comment(lib, "LibraryName.lib")    

 

I do like the idea of the #pragma solution since for example if you use the GLUT_STATIC or GLEW_STATIC define then the #pragma can be put in the correct #ifdef and link against the static version of the library (glut_static.lib) rather than the dynamic version. This means that you do not need to worry about the linker and build system becoming unsynced with the code.

 

However since I always try to write the most portable code I can, I guess I will never use it until 99% of compilers (especially on UNIX) support this type of linking ;)






PARTNERS