In-Game Console

Started by
14 comments, last by Kurask 11 years, 3 months ago

That's what I was thinking. I'd have my output go to some text file and have something constantly echo whatever is in that file onto the screen. I don't know the best way to do that though. My project is in C++ using DirectX for the graphics. I was thinking I'd just make a textbox using CreateWindowEx that displayed all the output and I'd have another textbox slightly below that to handle the input. I'd have to figure out how to do that, but it sounds reasonable.

Using CreateWindowEx isn't going to make a console that's really usable in-game, unless you are running windowed mode. IIRC DirectX has some font rendering classes if you are using earlier versions. Check the SDK samples.

As for logging: echoing from a file is not the greatest idea. Buffers can take time to flush. You may not want to lock a file constantly while a program is running (and conversely lock it while reading).

There are a bunch of good logging frameworks out there (check this thread on stackoverflow) that let you have multiple backend emitters. I use Boost.Log (not officially part of boost) in my projects and it works great for that sort of thing.

Yeah, I can render text to the screen, I just wasn't sure if it was efficient to do so.

I don't know how I'd get started on binding input to the source, or even getting input to appear on the screen instead of using it to control the camera, as nife87 said above.

Advertisement

The actual logic behind a console system isn't too hard to put together, I have a simple Cvar class which uses template specializations for the argument types I support (float, int, string, and nothing) so when you create a Cvar object, it sets an internal flag accordingly for the type you tried to give it so it knows how to act on it later. It uses a FastDelegate internally for the function pointer stuff.

Then I just dump them into a map<string, Cvar> for the lookup. The Console class has an exec() function which just takes a string -- if there's 2 parts to it (like "test 500") then I split that into to name and argument, use the name for the lookup, and 500 is converted and handled accordingly. It's not really robust, but it's really tiny and simple, I think the whole thing is like around 150 lines.

[quote name='Kurask' timestamp='1358024739' post='5020845']
I don't know how I'd get started on binding input to the source, or even getting input to appear on the screen instead of using it to control the camera, as nife87 said above.
[/quote]

I just added my console as one of the states in my game's state management system. That way it intercepts all of the inputs from the user while it's up, and when you're done you just pop it right off the state stack and go back to the game. You can use your game's internal logging system as a backing store for the console output also, which makes implementing it a bit easier because now your console window is a very watered down input parser/command execution host and log viewer.

(the newest edition of id's cvar system in actual source, that I know of, lies accessible in their Half Life 2 SDK)


You could, alternatively, read the source code of one of id's games, like Quake.

That's what I was thinking. I'd have my output go to some text file and have something constantly echo whatever is in that file onto the screen. I don't know the best way to do that though. My project is in C++ using DirectX for the graphics. I was thinking I'd just make a textbox using CreateWindowEx that displayed all the output and I'd have another textbox slightly below that to handle the input. I'd have to figure out how to do that, but it sounds reasonable.

Using CreateWindowEx isn't going to make a console that's really usable in-game, unless you are running windowed mode. IIRC DirectX has some font rendering classes if you are using earlier versions. Check the SDK samples.

As for logging: echoing from a file is not the greatest idea. Buffers can take time to flush. You may not want to lock a file constantly while a program is running (and conversely lock it while reading).

There are a bunch of good logging frameworks out there (check this thread on stackoverflow) that let you have multiple backend emitters. I use Boost.Log (not officially part of boost) in my projects and it works great for that sort of thing.

Yeah, I can render text to the screen, I just wasn't sure if it was efficient to do so.

I don't know how I'd get started on binding input to the source, or even getting input to appear on the screen instead of using it to control the camera, as nife87 said above.

This depends on how you're handling input. If you are directly testing for input in functions to move camera and such you'll need to check if the console is open or not when making those calculations.

Rendering text to the screen, like pretty much everything else in programming, can be efficient or not depending on how it's done. Earlier versions of D3D have ID3DXFont which may simplify this. Newer versions don't come with D3DX, so you'll either need to write your own font renderer, use someone else's, or use DirectWrite.

Thanks for the suggestions; I ended up getting everything working. I was looking for functions that handled it altogether in case one existed. As stated earlier, the code to make one was pretty simple (I imagined it being a little more difficult than it turned out to be).

This topic is closed to new replies.

Advertisement