NimbleBit has been busy busy busy! As you can tell by the lack of blog updates, we have been busy getting things done. Here is what we have been cranking on:
I learned two good lessons last week: Printing out text to the console in windows takes way more time than it should and precompiled headers are great if compile time is the slow part of the build process. Thanks to precompiled headers and a cool python script from Games From Within, compile times went down by about half. I still need to greatly improve link time but any kind of speedup is worth it when it comes to long build times. I started getting MyGUI integrated into Zero Gear. While we already have Hikari for our GUIs, we need something a bit faster for the in-game stuff.
I am starting off this week with a search for the fastest way to print out text to a console in windows (any suggestions?) After solving that problem I plan to get back to network optimizations (which I was intended to work on last week before getting interrupted by things like the slow console printing :().
Oh, almost forgot to mention I finally joined the dark side and got one of them fancy ITelephones that I keep hearing about. Any suggestions for neat program applications? I hear the stuff here is pretty cool…
P.S. A note about that python script linked above, I had to convert the VC++ 9 build log to ASCII from unicode in order to use it.
I have been busy keeping track of all the work we have been doing and logging future tasks we need to do in order to get Zero Gear closer to another beta. I have been tweaking values and sizes of things as they get implemented, and otherwise doing any other little bits of polish where I can spot the opportunities for them. I also spent a few days modifying and tweaking our Tag Test map, to be a little more open and play nicer with vehicles.
Later in the week I spent a lot of time becoming familiar with MyGUI and how to re-skin and create gui layouts with it. So far I am finding it to be a neat little gui library with a lot of functionality. It has a neat little layout editor that is allowing me to slap together guis pretty fast. We will see if hooking them up to the game through LUA is as easy! This week I will probably continue building some guis before seeing where the rest of the week takes me.
Last week we spent some time thinking about the type of game Zero Gear is, and what we want it to be. After spending lots of time playing the different game modes over the last couple weeks I got the feeling something small was holding back a lot of potential. ZG is quite a unique mixture of FPS-like gameplay mixed with vehicle controls. One thing I’ve been finding a little frustrating is the lack of control over these cool weapons in the game.
One solution we came up with was to make each weapon somewhat guided, but that wouldn’t eliminate all the 3 point turns I seemed to be doing in the game. After some thinking and looking at vehicle combat in some other games we decided to try out a mouse look system to be able to aim weapons and gaze around the levels in 360 degrees of freedom. I’ve gotten the free look system working well and now just need to hook up the aimed weapons to see how much of an impact this feature would make on gameplay.
@murphy About the slow printing to the console: I don’t know exactly why this is so, but it appear to me that when you print your process is halted waiting on I/O for Windows to pick up your text and send to the console.
I’d suggest dedicate a thread just to printing, then your print function would add lines to a queue and a printing thread comes and sends the text to the console. This way at least it wouldn’t slow any of your main loops.
Other alternative would be use some sort of logging library that has a variety of printing output options (like sending things to a file) . Unfortunately I’m not familiar with logging in C++ world, but I guess log4cpp could solve your problem.
If this doesn’t help, there’s always StackOverflow
well, good luck
Thanks for the suggestions Fabio. I ended up spending the whole day in windows GUI programming hell. I created a edit dialog box that I could print into.
My initial test showed an amazing improvement. I later realized the test ran before the GUI console was initialized thus preventing the text from actually being output (was only output to file where I checked the results of the test as I didn’t have a scroll bar on the GUI at the time). After fixing this it seems that I am back where I started. About 2 MS per print out
I am going to take your suggestion and try to implement some threading to solve this. I wish I didn’t need to do this in the first place. The game client’s console prints a line in 0.02 MS, super fast.
I am curious how your writing to the console ? are you allocating a console ? or just using a console application ?
I was using a normal windows console application. Since then I have created a custom windows GUI using the C++ API made out of 2 edit boxes. That didn’t result in any performance gains so today I ended up threading the printing with a fast sync. This gave us the kind of gains we needed.
As far as I can tell, there is no way to get sub-MS prints without threading in windows.
So you where using printf? I do not think the threading is really required to be honest with you.. I work on applications that log at times thousands of lines of log lines to the console and the app can still serve 100,000 logins a second. So I am curious as to how you where getting the log lines to the console ?
I tried puts(), std::cout, std::cerr, and WriteConsole. I also tried all of these methods with all the suggestions I could find online to make them faster like unsyncing std::cout with stdio and setting a buffer for std::cout, etc. If you know something I don’t, please don’t hold back
Note that this is in Windows too, I am guessing things are much faster in *nix.
Printing to the console is slow on any platform afaik.
[...] solution to last week’s console print slowness ended up being to thread the printing as Fabio suggested in the first comment. This resulted in [...]