Boost logo

Boost :

Subject: Re: [boost] Is there interest in a reusable stream-based console?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-03-09 10:36:48


Hello,

I'm interested too. I'd like to share my short experience in the domain.

I've implemented a command line system before that I, too, use in video
games implementations.
The one I wrote at the time might have big design flaws, but at least it
was easy to set custom outputs.
(example: http://www.youtube.com/watch?v=VHFu6q1twtE )
The design was basically:
 - some functions insert inputs (taking characters or strings, manipulating
the cursor position)
 - some virtual pure functions to implement the output rendering: in the
video, it generate a javascript expression, send it to an embedded browser
that will display on the 3D texture you see flying - that is in fact a web
page. It is the third output rendering I've wrote using the same console
base class, the first was simply standard output, the second was raw font
rendering on some 3D textures (but it was slower than the 3rd solution).
 - some functions to add/remove "commands" that are the "applications"
available to the console instance (I use several different consoles, like
in the video)
 - a special mode that allow a command to be "modal"(I can't find a better
term), meaning that the command will keep getting the inputs until it shut
down,
without having to loop inside the command code - to allow rendering to
still happen.

Having an implementation better designed and reviewed by boost people might
be more reliable
than my current code (that I already tagged as to be refactored - this
version is opensourced online but I don't think it's good enough to check
it).

About the swig/boost.python thing, one thing to understand is that command
line don't work
like a programming language. You don't use it for the same purpose, even if
it's tempting to just let a scripting language
as the implementation of the console.
For example you might not want command line to be able to create/destroy
objects.
If you do, it's far better to plug your scripting language inside your
console as a command/application like I did.
It's far more extensible this way.
In the video, I used Falcon (http://falconpl.org) as a scripting language.
I could have used any other language (Lua, Python, ChaiScript) without
changing the console class. I could also have added several other scripting
language, as they are only commands/applcations from the console point of
view.
I plan to have different consoles for different contexts in my current
game, and different commands to manipulate different scripting language VMs.
So I don't think it's a good idea to plug directly a specific language
inside a console.

About the interface, I'm not sure if a command should be defined only by a
simple std::function. I've tried it before but I wasn't able to make it
work as
more information were required.

My 2 cents.

Joël Lamotte


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk