Mindblowingly awesome game development.
I had a problem where even though math.h was included, and M_PI was found, sqrt, tanf and other math functions were not.
Turns out NetBeans has an option under the current project’s context menu name Code Assistance->Reparse project, respectively. Be sure to open the file in question in the code view, so you can ensure this has removed the issue. I had to do this separately with 2 different files in the same project, oddly enough. Thanks to this source.
Turns out I’ve been studiously avoiding runtime debugging for some time now, earlier due to general Eclipse issues, and recently just because I’m so used to not using this approach. As it turns out though, as described in articles here, here and here, it can be an excellent “poor man’s optimisation tool”. Since dealing with performance issues in my software renderer has now reached critical importance, I decided to take a stab at this approach. According to Mike Dunlavey, it is actually a pretty darn accurate way of finding out where your bottlenecks lie, without dealing with nasty stats and graphs (ahem, gprof) that (a) don’t give you just what you need, (b) aren’t actually accurate anyway, because of the way they take samples and what they _don’t_ sample, and lastly (c) the fact that I like to keep things simple. And this is the definition of simple.
However, Netbeans refuses to pause. First off, I realised I was missing the -g compiler option for my debug profile. Fine and good, but that didn’t solve the problem.
Next I realised I was being informed of illegal memory accesses, since every time I ran the app, I got a dialogue asking about SIGTRAP, which prevented the debugging process from proceeding. I sorted that out quickly enough — an array bounds bug in the voxel world generation routine.
But I still couldn’t get the pausing working. So it was time to try another tack. Use gdb on it’s own?
I know at least enough to get by on a few basic things with gdb. TBF, I don’t think it’s that complex, at least at the superficial level of use I need it for right now. A kindly person over on stackoverflow answered my question about pausing gdb at the command line. Between his answer and my subsequent findings about gdb and threads, it turns out all that is needed is to do the following, once at the command line:
Voila! Debugging, and a poor man’s optimiser, all from the CLI.
So at last I’ve decided to migrate my rendering code to OpenGL. The reason was not actually to do with any immediate performance needs at this this stage; instead, I was hitting a wall where SDL software rendering, given a minimal configuration, was not responding well to SDL_Flip calls, even though I was doing nothing other than locking and unlocking surfaces correctly as well as using a correct, minimal initialisation section. By not responding well, I mean it wasn’t responding to input — and this had nothing to do with my input code which in a separate minimal test case, was also perfect. It didn’t seem to be heap corruption causing this, either. I needed to hit OpenGL for this project eventually, anyway.
So, to get OpenGL running under Netbeans in a Windows environment, the following should be known:
Right, this was fairly straightforward compared with Eclipse CDT! I will list the process I went through, rather than stating explicitly what must be done, as I may have been lucky the first time with certain things just working OOTB.
After installing NetBeans 7, I started a new project. I was immediately presented with mingw32 as a toolchain option. Whether this was because I’d previously installed it myself, or because it is part of the NetBeans for C++ installation, I don’t know, but I suspect the former. Selecting this toolchain, the project started and I had a simple Main.cpp file in place.
I moved the basic SDL setup code over from my Eclipse project. Now it was time to set up compiler and linker options. As in Eclipse, I right-clicked on my project in the Projects Panel, selected Properties… at the bottom and was presented with NetBeans’ considerably more compact Project Properties dialog: Specifically, the Build category.
First, C++ Compiler->General->Include directories — straightforward. Mine looked like
../../../libs/SDL-1.2.14-MinGW/include;../../../libs/SDL_ttf-2.0.10/include
I made sure the “Use Linker Libraries” option was checked. Under C++ Compiler->Command Line->Additional Options I set
-O3
(yes, with the hyphen) for highest level optimisation.
Next up was the Linker. This was incredibly simple, ultimately. Add your /lib subfolder within your SDL folder (wherever that is). After setting up using the ellipsis button provided, mine were:
../../../libs/SDL-1.2.14-MinGW/lib
Under Linker->Libraries, I added the two core SDL libs, which for SDL-1.2.14-MinGW, were
libSDLmain.dll.a, libSDLmain.a
…In that order in the pop-up dialog that appears when you hit the ellipsis alongside Libraries->Libraries. After exiting the dialog, these will appear as
SDLmain, SDL.dll
in Libraries->Libraries. Lastly, under Command Line->Additional Options, ensure you have
-lmingw32
(Again, with the hyphen.) You should find that this linker option will appear before your SDL linker options, when you try to run the app (provided the code is A-OK); indeed, this option MUST appear beforehand or you will get errors such as that SDL_Init cannot be found, issues with WinMain, etc. We’re done here, so OK the dialog to go back out into the IDE at large.
One last thing you need to do is to set up a run configuration. Once you’ve done so, attempt to run. Once compilation succeeds, NetBeans attempts to run the .exe and you should get an error asking you for DLLs. Go to your Files panel (should be on the left in default layout) and click the dist folder under your project folder. Locate your newly generated .exe therein, and place your SDL.dll in beside it.
You should now be up and running.
PS. If you are having troubles with your setup, (a) make sure you are using a minimal example as presented here, to start with (i.e. just core SDL and mingw32), and (b) be sure your linker flags are in the correct order, for all linked libraries.
After quite some months of putting up with Eclipse CDT, today I took a brief look at Code::Blocks and later, Netbeans. Both of these support MinGW32 out of the box (at least these days). I will not go into my frustrations with Eclipse CDT here. There are countless such stories across the web. I will simply say that I think Eclipse tries too hard to be everything to everyone, and ends up being a bit subpar across the board.
Code::Blocks loaded fast, UI appeared very quick, and the interface was very simple, a key point for me. I will still use it if I’m pushed to it, but I wanted to check out NetBeans first.
NetBeans was only fractionally slower to start up, but had a very slick, quick process for self-updating, which it did and then restarted itself quickly. Once in, presents a far more compact and professional looking front end than C::B, incredibly fast and handy autocompletion, and decently ordered menus (in fact, having now used them, I think I find them even better than what I saw in C::B. It also detected my MinGW32 installation (or does it have it’s own?) so that I could instantly start a new project with the correct toolchain in place. I immediately fell in love. It took me a couple of hours to get SDL setup (really my own fault for not specifying libs in the correct order); setting the linker and compiler up was an absolute breeze compared with CDT; setup dialogs are very well presented.
Next post I’ll outline setting up SDL with MinGW32 under NetBeans.
First issue: I needed the VC win32 development version of the library. It contains the header file needed to access the library. Also note: had to rename SDL_ttf.lib to libSDL_ttf.a, so that the gcc linker would be happy. Had to add -lSDL_ttf (with uppercase and the underscore) under your linker settings (“libraries” and “miscellaneous/linker flags”). Lastly, set up the include path or copy all necessary DLLs to where they need to be, and include folder under “GCC C++ compiler” in Settings.
The second two issues I had were actually one: SDL_ttf.h expects to be put in your main SDL library, in my case libs\SDL-1.2.14-MinGW\include\SDL. The reasons are twofold: It wants begin_code.h and end_code.h, and, at least in my Eclipse CDT (Indigo SR1), it simply will not give you access to any of the header’s provided entry points to the DLL — they will not show up in intellisense. Strange problem. The moment you move it into the main SDL include directory, you are a for away. Don’t forget to correct your path in your include statements, for the new location (in my case, it’s usually in SDL/).
Also note that once you’re up and running, for some reason SDL_ttf expects to find fonts in the project root, not in your release or debug folders! Curiouser and curiouser.
…That’s because you need to
#include <stdio.h>
…It’s not in <iostream> or anywhere else!
There’s not much out there to help in building Box2D for MinGW. The text file that comes with Box2D in this regard isn’t much help. Luckily I found this stackoverflow question which helped me get it sorted out.
I was using SDL_CreateRGBSurface today to produce precomputed rotations in Reactive Arcana. These (I’ll refer to them hereafter as the destination surface) were being created exactly according to the specs (format, flags etc.) of the original sprite being rotated (the source surface)… Or in hindsight, so I thought.
I then plotted a single red pixel into the new surface, to test it, and I made sure to blit it to my screen surface. No go.
I couldn’t understand why I was getting nothing but black to blit. Neither the pixel plot a rect blit would work. I checked all my parameters eg. masks, bit depth (which I thought may have been incorrectly set as bits instead of bytes) and none of this worked.
Also, if I set the colour key to black ({0, 0, 0}, which is what I use and which works perfectly in my sprites subsystem), it would indeed set the colour key, as the rect would now be transparent. However if I set the colour key to any other colour, it would also show as transparent! So I knew something had to be wrong with the pixel formats…
Then I remembered that the new image I was testing this with was in fact an indexed PNG-8 I made a long time ago (thus I’d forgotten the format); all my other images were PNG24′s. I modified the image to use RGB instead of indexed colour, filled the transparent background in as black for use with colour keying, and saved it as PNG24 (very important! — the other steps will be sufficient for you to blit the image, but the colour key won’t work). Everything now ran as expected. The problem of course was that all my parameters assumed a true colour mode in the image to be rotated (24-bit strictly speaking, as alpha is unused in favour of colour keys). All appeared well for a time, until…
I tried to plot large numbers of my rotated pixels from the source image (which was able to blit to the screen just fine, showing that it was in working order) to the destination image (which up till now had been black with a single red pixel). I realised something else was wrong, and it wasn’t my rotation function — plotting pixels appeared corrupted on the destination (“rotated”) surface. A light went off in my head and I remembered something I should have done early on in the codebase but hadn’t – http://sdl.beuc.net/sdl.wiki/SDL_DisplayFormat. After setting the display format for the original surface, the destination surface created from it worked perfectly. I recall that this makes things a lot faster, as if you don’t do it, an implicit conversion is performed on every single blit.
I had a problem getting Boost 1.47 set up for my Eclipse CDT installation. Considering this was as simple as using an include (no precompiled libraries required), I was surprised at how this refused to work.
Solution was to include both the boost root folder boost_1_47_0 AS WELL AS its subfolder boost which is where the actual headers (.hpp in this case) lie. Once the subfolder was added to the project includes, things began to work using either of
#include <boost/lambda/lambda.hpp>
or
#include “boost/lambda/lambda.hpp”