Tag Archives: C++

To share or not to share…

Posted on by
Reply

So, I’m gradually working towards making a simple fighting game, using my Kinect as the input sensor. I think initially it’ll be one person punching a punching bag, then two people competing, and then probably some sort of computer controlled AI which looks at your pose, and chooses the right pose/move accordingly (although since I don’t really know how to fight, that will be interesting).

The Experiment

Anyhow, a few weeks ago I got a very rudimentary scripting host working, where I have my rendering infrastructure written in C++, and I have a mono .NET window displaying the output etc. Well I have since improved it to allow me to create entities on-screen in a (somewhat) adhoc manner (they’re all the same entity at the moment). In doing this I decided to do an experiment to discover what we all know is true: if you have more than one instance of the same model on screen, it better be the same vertices et al in memory. My Naive version loaded the model from disk, and packed it into my renderable format in memory each time the scrip requested an entity from the engine. I wanted to do 1000 entities, but the Naive approach crashed my computer at ~380, so for my performance comparisons I only went up to 200. My second approach uses boost::flyweights to share the model amongst all the entities that use it. I performance tested this one up to 200 as well, but as you can see below it gets up to 1000 dwarves on screen quite happily.

Snow-white couldn’t cook for all these guys.

Continue reading →

.NET Class Wrapper coming along

Posted on by
Reply

I’ve been embedding mono into my game engine, and decided that what I needed was a code generator to generate C++ classes which wrap .NET classes that exist inside the sandboxed runtime.

I’ve decided on StringTemplate for the templating side of it, and after trying to write a template without first knowing what the class should actually look like, I set about writing an initial prototype of what I would like my generator to eventually produce. This went quite smoothly (if rather slowly), and eventually I found that my application, whilst calling all the .NET code I wanted it to, was crashing when trying to free some memory.

I eventually found that my problem was that I shouldn’t be calling free for a pointer that was allocated using g_malloc, because that’s just asking for trouble. However, g_free, just won’t compile (well, link actually), not in a million years, not in my code (but for some reason it does in libmono). However, the lovely people over at the mono-devel mailing list said I should use mono-free (which wasn’t in my library definition, causing me much angst). Eventually I edited mono.def, recompiled mono, and my code, and what do you know? It works.

Next stop, a code generator.

Progress with Mono!

Posted on by
Reply

So today I spent some time building embedded Mono into my game engine (if you can call it that, it’s pretty skeletal so far). It’s pretty poorly done at the moment (design-wise), but I can execute code from a .NET dll within my application. What I didn’t realise until just now, was that the mono runtime will happily load dll’s built with Microsoft’s compiler, which means I don’t even have to worry about needing a separate build environment for the C# code (although it’s pretty easy, just run xbuild on your project/solution from cygwin).

The next steps here will probably be along the lines of turning the runtime stuff into some sort of script host, and coming up with patterns for writing/generating bindings between the two environments. I think I’ll investigate SWIG for this. Binding C# code to C++ types will be fairly easy – the C++ type just needs to register all of its member functions with the runtime, and then a wrapper around these can be written in C# in much the same way as you would wrap any other C dll, using the extern keyword and the MethodImplAttribute. On the other hand, accessing C# types from within C++ requires a fair amount of code (somewhat like using reflection in C#), and so it will be necessary to use some sort of code generator to generate efficient wrappers.

Very Interesting.

Finally worked out my problem with Windows Events

Posted on by
Reply

For a while now I’ve been trying to use Windows Events as my logging framework, but I have suffered from one seemingly fatal problem: if my application terminated unexpectedly (thus ungracefully), my session was left open, and I was seemingly unable to stop it or re -enable providers against it. This was beginning to make me feel like Windows Events was not the right framework for debug logging, because an ungraceful termination is very likely during development. However, I have since found that I was not passing the name I thought I was to the StartTrace function, and so although I could close my session as long as my application didn’t terminate (due to some state in my logging class), a “Cold-Stop” (as in a ControlTrace call at the start of my app) would not work.

I have now corrected this bug in my code, and can now close the open session and restart it if I encounter ERROR_ALREADY_EXISTS upon starting my session.

WIN!

Success with Mono at last!

Posted on by
1

I have been trying (I use this term loosely, since I’ve probably only spent a slightly long working day on it), for a couple of weeks now to write a C++ application which spins up an embedded Mono runtime environment, and executes some C# code – my aim being to write a game engine which uses C# as its scripting language.

All of this would have been quite simple had I not decided that I want my engine to be 64-bit from the get-go, and so started my long journey to getting mono-embedded working.

First, I was under the impression (which turned out to be right), that I would need to build all of mono from source, so I checked out the source code (which took a long time my mono folder is 1.72GB on disk, although some of that must be binaries surely?), only to find that only the runtime can be built from Visual Studio (the framework and compilers must be built from cygwin – autotools, YUCK!). So I then asked the community how much I needed to build, and was told I only needed a 64-bit runtime. So, I tried to build the runtime in Visual Studio 2010, but couldn’t, so I moved to Visual Studio 2008, where I eventually managed to get the runtime compiling, but found there was a bug in the code which I later fixed on the advice of one of the community members.

So finally, I had a working runtime, only to find that the installed version of the framework I had was too old (it seems the source code I downloaded is much newer than the released 2.6.4 version of mono). So, I had to bite the bullet and install cygwin (which took me a couple of attempts to get right). Anyhow, nearly two hours later and the code is built, installed, and the test embedding application works like a charm.

WIN!

Thanks especially to shana for this article on building mono for windows. If you’re going to follow it, I recommend installing the cygwin version of make, rather than 3.80 (the article is a little old, and cygwin have fixed their make).

Anyhow, it is way past my bed-time on a Sunday, but I’ll post more about my experiences embedding mono in the future.

A Quick and Dirty tutorial on Event Tracing For Windows: Part 1 the Event Trace Session

Posted on by
2

[EDIT 4 September 2010]
Thanks to David M for pointing out an error in my code. When starting an ETW session you should pass in the session name not the log file name. See the correction (in bold) in the LoggingController::Start member function below.
[/EDIT]

So, Windows Events, its the new Logging API for Windows Vista+, it brings together Event Tracing for Windows (ETW) and Windows Event Log. The basic layout of ETW is that you have an Event Tracing Session, for which you enable providers. These providers write log messages into the session. You can enable the providers with various settings allowing you to filter the type and criticality of the log messages, and do all that fun sophisticated tracing stuff. If you use a “manifest-enabled” provider (more on that later) you get the Windows Event Log side of it for free. You can also create consumers of these sessions, to monitor the logs and stuff. Continue reading →

A successful day

Posted on by
Reply

I started actually writing some code on my new experimental engine today. One of the things I want to do with this engine is write as little code myself as I have to. Also, I’d like to avoid using third party libraries for things Windows already does, like logging. A lot of people would use something like log4cxx, and whilst there’s nothing wrong with that (other than being notoriously difficult to use with MSVC), Windows already has a pretty sophisticated logging API called Windows Events, which unifies both the Windows Event Log, and the Event Tracing for Windows APIs. This is a mature, flexible, high-performance API for logging on Windows, and it is built into the operating system, which to me represents far lower risk than any other options; AND I get built in log-file analysis tools (Windows Event Viewer) to help me peruse my log files.

The catch is that there is a little bit of work involved to wrap around it, as I have found, and the documentation is not awesome. Mind you it is no more work than would be involved in log4cxx to programatically set up your loggers etc.

Today I got to grips with a couple of the Windows SDK samples, and wrote a class which wraps around the Windows Event Trace Session, to allow my engine to set-up and tear-down a session. It still needs a little finessing, but this will come once I have created my own provider (for now I’m using the sample provider app to write events into my tracing session).

I’ll post a short article a little later.

Learning DirectX and C++: Step 3, Timing and Text

Posted on by
Reply

I’ve pondered, for a while, on the merits of me writing out every lesson I learn on my journey to become a game programmer, and I think that the HOWTO format is not going to be sustainable. So, from now on I’ll be jotting down some notes, and some key points, but I’ll be dispensing with full code listings and blow-by-blow coverage of what’s going on.

So, on to timers and clocks in DirectX.

Continue reading →