View Full Version : A simple 'command window'
04-01-2012, 03:10 AM
in some games or 3d engine I've seen something like a command window, that is a 'window', usually semi-transparent, that appears for example when someone click on the esc key button and where you can write commands to submit to the game or to the 3d engine and change the state or make operations. This command window appear much like a common os shell.
How it is called in 3d graphics terminology?
And, how is it usually implemented in OpenGL?
04-01-2012, 07:50 AM
I don't think theres anything simple about it at all.
The actual rendering of the console is a little project on its own
Getting the typed commands and mapping them to functions and variables is not so easy either. There are scripting languages you can freely use but this is not something I have personally tried.
04-01-2012, 08:21 AM
Sounds like you have seen GLConsole (http://www.robots.ox.ac.uk/~gsibley/GLConsole/) used in some games.
04-01-2012, 08:52 AM
As BionicBytes said, it's usually called a "console window".
If you have a text-rendering system then displaying the console is usually just a case of drawing a rectangle + text over what is on the screen. It depends on how powerful you want the console to be as to how much work it will be to make. If you only allow typing 1 word commands it should be fairly easy, but if you want to include programming language features, such as loops/branches + commands over several lines etc. then it could get more complex.
You could take a look at the Doom 3 source code to see how they implemented their Console (https://github.com/id-Software/DOOM-3/blob/master/neo/framework/Console.cpp), also the CVar (Console Var) (https://github.com/id-Software/DOOM-3/blob/master/neo/framework/CVarSystem.cpp) + Cmd system (https://github.com/id-Software/DOOM-3/blob/master/neo/framework/CmdSystem.cpp) too.
04-01-2012, 11:35 AM
Thanks to all.
Your examples are what I needed.
However, it is just as I thought in the first instance. Substantially, the Console Window is just as any renderable object, with the exception that when it is active, it has the 'focus', it gets all keyboard input events or something like that.
I need a simple version of it, with simple commands for now. I'd like to avoid to recompile each time the program becasue the mode file I load for test is hard coded and so on for other configuration state. I don't have the time and the knowledge now to implement a gui, I'm new to 3d cg.
04-02-2012, 08:09 AM
I'm giving a look at Doom3 source code as you suggested and I saw the console window implemented in it.
However I noticed something unclear to me.
This goes outside the discussion/questions I was looking for before.
Primitive data types declared as formal parameters of methods of classes are all, or almost all, const qualified in doom3 source code (look at idVec2 for example).
I know all stuff about passing paramenters in C/C++ and what happens under the hood at the activation record in assembly, but as far as I know there is no difference in speed or in space having a formal parameter declared as "const int param" instead of "in param". Obviously a usage difference exists, that is when you declare "const int param" as parameter in a method you cannot use/re-use it as l-value, but this doesn't concern speed for example.
Is there a valid reason for that const usage?
Are there platforms where the const of primitive data tytpes declaration in methoss does a difference?
04-02-2012, 02:16 PM
Is there a valid reason for that const usage?
Because they're constants. This isn't rocket science; you mark a variable as `const` if it is a constant. It means that the value will not be changed, and the compiler will hold you to that (unless you do unsafe things).
It has nothing to do with performance (unless it's a `const&`) and everything to do with putting useful semantics into the code.
04-02-2012, 02:36 PM
when you declare "const int param" as parameter in a method you cannot use/re-use it as l-value, but this doesn't concern speed for example
Speed is not the only factor to take in account for programming.
Forcing a function parameter to stay constant will avoid modifying it by mistake. Such mistakes, even if rare, are very hard to track.
This file details the code styles for D3, and insists on using const as much as possible :
Besides correctness, if every variable is immutable, code is easier to parallelize for the compiler.
04-02-2012, 04:01 PM
I'm just adding here another question that comes to my mind.
I'm just moving the first steps in the 3d world and I want to do some simple examples just to make confidence with rendering api, opengl and directx.
Since I'm not an expert in the rendering api I'm not able to see far away in the code: I know opengl accepts matrices in column major order while directx accepts them in row-major order.
Now the first thing that comes to my mind is to have a matrix class able to manage internally the two ways and hide all the techincal details from the class-user, this for performance reason. At the same time I think this is going to complicate the code of the matrix class.
So my questions:
if you want to have both rendering APIs in the same project, what is the usual approach in this case?
Do you have two exe? one compiled against opengl and the other againsta directx?
Or, how you deal with the matrix stuff in the scenario above? Do you complicate your matrix class in order to deal with the two rendering api? or do you duplicate the code? or?
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.