Month: January 2014

It’s tricky to get the timing right. Some people do nothing but update their engine. they have re-factored it so much and re-implemented everything so often that it is a true work of art, worthy of actually putting in books on how to code. These people never ship a game. The other extreme is people who are still using assembly language routines for loading in ini files because they wrote them in 1996. These people have tech support issues galore, and are probably still using Directx3.

In between there somewhere is common sense, if you *are* going to write your own engine and not use someone else’s. I think, from chatting to devs and surfing a lot on developer forums, that people tend to want to redesign their engine after every game. They consider that quite a major compromise compared to their real hidden urge to do it every morning. The thing is, if you are doing that you aren’t really writing an engine, you are just writing a new game from scratch all the time.

I tend to go with a system of marginal improvement. I still have some code from about 5 games ago (non critical stuff like ini file loading, text handling, game timers and some math stuff), but a lot of it is fresher. The graphics stuff, as you would imagine gets a major refresh more often, and my engine only contains some pretty ‘raw’ directx wrapper and vertex buffer / text engine stuff. The actual ‘scene management’ for my games is done in the game itself.

Despite the occasional between-project update and maintenance, occasionally you have to step in and clean things up. The last big update was when I went from Directx7 (Democracy 2, Kudos games…) to Directx9 (GSB,GTB,Democracy 3). This time I’m updating almost everything BUT the directx version.

I recently bought Visual Studio 2013, mostly for the concurrency profiler to enable me to experiment with multi-threading more. This was a good opportunity to take a look at some of the flakier things in my engine. I have a lot of warnings in there for data-conversion and other sloppiness. I also have code I never use (I’m culling it), and the worst and most embarrassing thing is that I can’t decide if I like char* or std::string. I Figure that std::string must be at least a bit better, more robust and safe than char*, so I’m trying to purge all that char* from the engine, and eventually, the game. I’m also planning on re-wiring stuff so that the main game code doesn’t have any FILE* or other old fashioned stuff, but uses my file wrapper more.

Why? Mostly because I can see me heading towards cross platform eventually. maybe not with the next game, but baby-steps and all that… Plus it makes life easier if getting my engine ported is a less messy business. I’m sure after a few days of sorting out this stuff I’ll be climbing the walls and wanting to code some explosions again…

I’m new to multithreading, and the visual studio concurrency visualiser. I have lovely multithreading code working. basically my main thread throws the Threadmanager a bunch of tasks. The threadmanager has a bunch of threads which all spin doing nothing until told to do a task. Once they finished their task, they set an IDLE flag, and the main threads WaitForAllTasks function then assigns them a new one. It works just fine…. but I notice an anomaly.

See below (Click to enlarge enormously)

The highlighted connection shows thread 4828 sat on its fat ass waiting for the main thread, when it clearly idle and ready to do stuff. The things is, the main thread function is just this:

    bool bfinished = false;
    while(!bfinished)
    {
        bfinished = true;
        for(int t = 0; t < MAX_THREADS; t++)
        {
            if(CurrentTasks[t] == IDLE_TASK)
            {
                //maybe get a queued item
                if(!QueuedTasks.empty())
                {
                    THREAD_TASK next_task = QueuedTasks.front();
                    QueuedTasks.pop_front();
                    CurrentTasks[t] = next_task;
                    SetEvent(StartEvent[t]);
                }
            }
            else
            {
                bfinished = false;
            }
        }
    }

Which basically does sod all. How can this take any time? Setting event sets an event which the worker threads function is calling WaitForSingleObject() on. Again…how can this take any time? Is there some polling delay in WaitForSingleObject? Is this the best I can hope for? It’s the same case for all those delays, it’s just this one is the largest. I’m new to this. Any ideas? :D