Karsten_Member Since 19 Jul 2011
Offline Last Active Yesterday, 05:26 PM
- Group Members
- Active Posts 437
- Profile Views 8,710
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by Karsten_ on 07 January 2015 - 10:00 AM
We have already used it commercially for our web games at work and it has proven to be a very good solution
Posted by Karsten_ on 24 November 2014 - 03:36 PM
I also recommed C++ because Java, and C# (and to some extent Obj-C) are largely the same once you know them (and if you choose to not take advantage of any of C++'s most powerful features). C++ however is although a second class supported language on most mobile platforms, it is still a "supported" language so you can generally port your game to any platform with maximum code reuse.
Unfortunately since C++ is not a first class supported language for most mobile platforms, the API documentation is often terrible.
Posted by Karsten_ on 30 September 2014 - 04:40 AM
1) The most standard way
/usr/local/bin (binaries) /usr/local/share/<gamename> (data files) /usr/local/etc/<gamename> (global config files (optional) /home/<username>/.<gamename> (local config files)This is sometimes a pain because it spams the filesystem with files and if you try to move it, often the paths are hardcoded at compile time so they will look in the wrong locations.
2) The common way for ported software
/opt/<gamename> (everything dumped in here) /usr/local/bin (simple script added here to set paths and run game)I personally do not mind this too much. It keeps the proprietary software away from the rest of the operating system. Typically used by software such as acrobat reader, skype etc...
This solution is also good for developers who use non-native (to UNIX) languages such as Java, .NET etc...
I see a lot of indie games written in Mono which distribute an entire implementation of the mono runtime with the game. I much prefer this to having to install mono on the system. I would also quite like to see Java developers distribute their games with an entire JRE. For an extra ~10 megs, it saves some pointless headaches for the user. Almost all software on Windows provides its own msvcrt.dll (C runtime) so the duplication is massive... but who cares right? At least the developer knows that the correct runtime will be used when the user double clicks the game haha.
3) The portable binaries way (kinda a hybrid)
[...]/bin [...]/share/<gamename> [...]/etc/<gamename> [...]/lib /home/<username>/.<gamename>When the application runs, it works out its own path and works out paths to external files at runtime. This allows it to be moved to wherever, /opt, /usr, /usr/local etc... without breaking hardcoded paths.
The hardest thing about this is getting a program to work out where it "lives". I use the following code...
(have a look at void Application::setupPaths())
It may look quite crazy but this is not an easy task to solve in a portable manner (things like procfs only really exist on Linux so I needed something that worked on the BSDs too). Feel free to ask any questions about it.
I also use this method for software on Windows. It works quite nicely and gives it a bit of a UNIXy twist ;)
Posted by Karsten_ on 14 August 2014 - 03:32 AM
You might also like to look more into .NET (C#) than just scripting Unity with it.
It might seem a step backwards but many Unity users do not know how to create a console application in C#.
Also, perhaps have a play with the System.Windows.Forms GUI classes provided by the normal Mono or Microsoft implementations of .NET.
Through this you will learn things like the application lifetime (something that is handled for you by Unity).
Posted by Karsten_ on 10 August 2014 - 05:10 PM
drawImage(Image* img, int x, int y, float rotation)
So an engine like UDK or Unity is overkill. That said, they both provide almost exactly the function above as part of their 2D GUI systems. For the sake of keeping your dependencies low and thus your game more portable, I recommend something like SDL (if you are dealing with C/C++) and MonoGame if you want to use .NET.
If you are planing on a very busy 2D game, you may want to look into using something like OpenGL with SDL to provide hardware acceleration.
Posted by Karsten_ on 30 July 2014 - 04:15 PM
I think both of you are actually quite on the mark when it comes to PHP. It almost seems like you are debating about the same things.
- PHP regardless of "correctness" has been traditionally the defacto web development language
- Because of this, many web developers have learned it and now there are a lot of PHP developers
- Because there are a lot of PHP developers, the average salary of a PHP developer has decreased due to competition
Python (in particular Django) and Ruby (on rails) and Perl have since become popular again but there is much less competition in this area so the average salary can actually be incredibly high! I have noticed that developers who took the time out from PHP to research and experiment with Ruby and Python (which at the time were "non standard") are also more likely to be "full stack" developers purely because they are typically more curious or experimental than other developers. These are also the same sort of people who took the time out from Windows to research Linux and other "server" operating systems and even alternative web servers, again contributing to their "full stack" credentials.
To the OP, unless you are planning on doing very typical web stuff such as effectively a frontend to a database, you might like to look into C++ and CGI. Not having to find or develop your own bindings for native libraries is very liberating. I also find C++ to be a little better at complex file handling than PHP, Perl and Ruby so C++ shines there too. Not having to load an interpreter can also mean you get some decent speed benefits (though using Apache modules like mod_php is likely to beat any type of CGI).
Posted by Karsten_ on 27 July 2014 - 05:54 PM
All of the functional support is implemented using C++(or other language) and rendering( graphical interface components, images, fonts ,ect ect) is DirectX/OpenGL, so repeating myself it's just a program written in C++(or other) and OpenGL/DirectX.
After having read the above, can you confirm that, or am I missing/misunderstanding something?
Like I said. Web Browsers exist that do not use OpenGL or DirectX. So your assumption above is incorrect.
Web Browsers using DirectX or OpenGL is actually quite a new thing that came along with the early spec of HTML5 (i.e for accelerated 2D drawing). NetSurf just uses plain old Gtk+ and Cairo to render pages (not OpenGL). IE6 uses GDI+ to render pages and not DirectX.
Some of the recent common browsers however do use OpenGL or DirectX but only optionally. If for example the machine does not have a graphics card or is rendered via remote desktop / X11 forwarding, it may fall back to software (Or likely emulate OpenGL / DirectX in software).
But yes, a web browser is just a program written in a programming language. Likely by a human!
Posted by Karsten_ on 27 July 2014 - 04:29 PM
Web browser can be quite simple.
Three of the best examples are
- lynx (http://lynx.isc.org/) - a basic text mode browser, great for servers
- elinks (http://elinks.or.cz/) - a slightly more advanced links
Neither of these use OpenGL or DirectX.
If you want to make a web browser, you do not really need much code these days if you leverage the rendering engines provided by these projects. You might want to look into:
- Gtk+ bindings for WebKit - http://webkitgtk.org/
- Microsoft WebBrowser component for C# - http://www.dotnetperls.com/webbrowser
- Mozilla Gecko Engine - https://developer.mozilla.org/en-US/docs/Mozilla/Gecko
There are loads more. One word of warning though is that they do drag in a lot of dependencies into your project and the Microsoft WebBrowser route is very unportable (Though probably the easier solution for Windows users).
Posted by Karsten_ on 23 July 2014 - 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.
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'.
Posted by Karsten_ on 20 July 2014 - 07:01 AM
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)
- gcc for main releases
- Any compiler I can get my hands on since they all potentially pick up on different issues.
- 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:
- Intel VTune
Arguably GLX requires less boilerplate code than Windows alternatives when setting up an OpenGL rendering context.
You may notice it has a line count close to when using Glut.
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.
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.
Posted by Karsten_ on 18 July 2014 - 06:01 AM
I would suggest use the distribution you prefer (they are all pretty similar).
You may want to use Ubuntu because it is one of the most popular so you know that your software is likely to work on other installs of that distribution.
(At the same time you should make sure to statically compile any libraries so that distribution specific library conflicts are avoided.)
Sometime a boring stable distribution is best (Like Debian) so you do not need to keep updating your workflow to match the whims of the latest hip and trendy Linux feature (in particular systemd, Wayland (and to some extent SDL2.0)). This is probably also the reason why SteamOS is based on Debian.
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++.
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.