Accursed OS specific errors

David Shaw, 10:37 am 11th August 2009
Posted under: Blog Babble

I spent most of today’s programming inadvertently proving Andrew Russell’s points against C/C++ (see the comments to Don’t bring C to a string fight).

I’m up to porting across the wrapper code I’ve written for SDL and OpenGLs graphics. The code base consists about half-and-half of initialisation/deinitialisation code and a sprite management system. The sprite management system is possibly over-engineered and so I might leave it for now, but the base wrapper code for all that initialisation stuff should in theory be reusable for any app. It’s just the basics for setting up windows, swapping buffers and telling code when it needs to hurry up and render something if it wants it be up on the screen this frame. It’s mostly a mess of cryptic library calls to SDL and OpenGL, but if it works it works.

At least that what I thought so. However the call to the SDL function that sets the video mode just refused to run on my Mac system. It would just crash – not even returning a null value for my error checking to deal with. My gut instinct was that I had to be doing something boneheaded, like forgetting to initialise something obvious, but it seems like I was doing everything I should be doing. I spent hours tracing it through, running it in different release builds (which caught an unrelated but also nasty string bug in the file initialisation code, C really is evil in that regard). It turns out SDL was also throwing a whole bunch of memory leak errors in the console that were either new or I’d missed, as my own output is to an HTML log file. This was weird, because I’d never noticed errors like this before in previous SDL apps.

It turns out my instinct was right, and I had done something stupid. On the Mac, SDL needs to run under an Objective-C wrapper. They helpfully provide you with a sample one, but I’d somehow removed it from the build path. Consequently SDL’s threads were disintegrating spectacularly into a whole raft of error messages. I’d probably missed this kind of problem in my previous little games because I’ve never developed a C based game on one before; I’d written them in Windows first then ported it across.

It’s not a good start to the trial of a C with scripting language game base. Admittedly it’s a very OS specific error. Once I get all the wrapper functions working and tested then I should be dealing mainly with my own code, and at least then I should have a fair idea where the trouble spots may lie. But the thing about unexpected difficulties is they act in unexpected ways. I’m fairly sure there’ll be similar challenges when I’m working in a language like C, and whether the time I lose to solving these problems is worth the fact that I like working and thinking in the language. I’m a bit behind schedule as it is, despite C being my strongest language. My feeling is that I should still slog on with my plan for now, but if I hit an alarming frequency of this kinds of bug stoppers I should start strongly considering a different course involving a higher level language.



5 comments for “Accursed OS specific errors”

  1. brian.ripoff says:

    I’d never move back to raw C. I could live with C with C++’s standard library, plus RAII wrappers for external resources. But not raw C.

    Also, I find that it can be a lot of work using a scripting language for large amounts of code. Even though scripting languages can be very concise, the number of runtime errors can be a productivity drain. I was trying to write a system with mostly Lua for the code and a little C++ to wrap graphics, input etc but I found it was almost as much work than writing the majority in C++ and wrapping game play. I think there is a nice middle ground, but its hard to find…

  2. David Shaw says:

    I’ve never used a scripting language in my games before, so this is meant to be an experiment to see what it’s like. I’m hoping after an initial learning curve for a productivity boost, but if it turns out to be too messy then it’s probably time to ditch the approach and move to Python or C#.

    I’m also starting to think the pure C approach might not be that great an idea, and moving to what is a version of C++ that is essentially C with namespaces and STL containers might be wiser. I’ll see. Part of my trouble is that I haven’t touched any application above an academic prototype size for a while, so I’m remembering the best way to approach things (unit tests, debugging techniques, etc.)

  3. Andrew Russell says:

    Language aside – I think your problem may be that you’re trying to make some kind of engine or “framework”.

    Take my Dream Build Play entry (“Dark”) as an example. There’s nothing (editor aside) there that even needs unit testing – you’d struggle to find even 20 lines of engine-ish code in there. I basically treat my platform (C#, XNA, Farseer Physics) as a glorified scripting language. Because of this the only things complex enough to need unit-wise testing (shadows, player physics) could be tested visually by using line drawing as one might use Debug.WriteLine or printf. Otherwise my “debugging technique” (as if you only use one?) was to liberally apply Edit and Continue (nice in an IDE and language where it works reliably).

    Yes, the code is a little inelegant – but most of it can safely stay that way!

    Only now that I’m finished the game am I even considering getting more “engine-like” – taking what I have so far as a prototype of sorts and fixing the narrow areas where plain C# and XNA are limiting. You could just about call it refactoring!

    I think that, perhaps, you are being too academic about things. And not so much with the unit-testing (which is fine – albeit a “warning sign”). Game development doesn’t need to be treated like one big monolithic, academic assignment that must be all done correctly and in one attempt (with a healthy dose of “not invented here”).

    Just pick a platform that lets you get to the actual meat of making a game and stick to it. Treat game development like an artform rather than an engineering exercise. (And I mean the game-as-art sense, obviously – as much as I love it, code-as-art has an extremely small audience.)

    (If you must be cross-platform off the bat, Unity and PyGame spring to mind as potential platforms. I don’t recall what SDL provides, but raw OpenGL is much less than ideal.)

    (PS: I say all this because I have been in very similar places myself – you might even recall a particular project of mine, how well it went, and how much time it devoured.)

  4. Andrew Russell says:

    Damn. I spy grammar errors in that.

    I also forgot to link the talk “Unique Knobs” from the folks at Metanet (http://www.metanetsoftware.com/technique.html) which says a similar thing.

  5. David Shaw says:

    I think after Freeplay I’ve come to the same conclusion. I guess I couldn’t really help it. I was trying to rekindle the developer spirit I had back as an undergraduate, but I was a software engineer who specialised in software testing; complex plans and management is what I was trained to do.

    Give me a day to collect my thoughts and notes from the event, but I’m leaning towards using the framework I currently have as just a place to rip source code from and going back to a series of weekly prototypes. Although I am going to look at some of those engines like Unity and see what they’re capable of.


Leave a Reply