I just hacked up a preliminary API spec for the lowest level of the “text
console emulator” I’m about to hack. It’s documented and on-line:
No SDL_Surface target yet - I wanted to keep the basic API totally
independent of SDL and other libraries, as I might have to backport it to
DOS or something… heh
I’m going to add ce_open_sdl(SDL_Surface *screen, …) or something like
that… A similar approach could be used to render into a raw RGB or RGBA
buffer, for OpenGL and the like. (Actually, that would work with SDL as
well, to some extent!)
Sounds like a tall order.
Nah! Used to hack that kind of stuff in asm back in the Amiga days.
It was usually the easy part!
The PC lacks the hardware and OS of the Amiga.
Yeah - but this stuff was directly on the hardware, bypassing or entirely
disabling the OS.
Also note that the original Amiga lacked hardware text modes entirely -
everything was done in bitplane based graphics mode.
My immediate goals are slightly simpler:
I’d say this sounds very much like something that could be
implemented on top of what I’m just about to hack.
All of your windowy stuff sounds like it is far overengineered from
what I’m looking for.
Dunno. Looking at conemu.h, you may notice that it could be
interpretted as supporting overlapping windows - but so could DOS
conio.h, which doesn’t!
conemu probably will support overlapping windows eventually, although I
don’t really need them right now. (Other projects I have in mind will,
What I need to implement is basically just a text screen “emulator”
(not VGA register compatible or anything!), the “conio” interface,
and a function that writes printf() formatter strings onto the
Basically that’s all I need really, with a scrollback and an input
line, but that’s more or less seperate from drawing anyway.
Yeah. Calling ce_scanf() should give you something like a line editor at
the current cursor position, and suitable keys could be used to inc/dec
the virtual scroll postion of the current window.
I think I’ll have ‘\n’ on the last line of a virtual window scroll the
whole buffer up one line, just as DOS conio does it by default, so that’s
all there is to it - except that someone needs to figure out what to do
about the cursor '\n’ing outside the visible part of the window. Maybe
just scroll (using the virtual offset) automatically - but I’d rather
have that optional, as some applications may not like it…
I don’t need multiple windows, my target is a simple server
console, though obviously if it writes to both SDL and OpenGL
surfaces it can be used in-game as well.
That’s exactly what I was thinking about!
Good - except that we need the non-graphics immediately and the
graphics stuff is a maybe future thing. =p
Whereas I need the graphics mode right away, and perhaps the text part
If it is to be used in-game though, attributes
are a necessity for me at least.
I’ll need them right away, as well as simple, non-overlapping text
windows, as that DOS app uses it a lot.
nod Understandable if you’re porting a dos program, it’s easier to
have different priorities since this is for new code here.
Yeah… But how about my proposed API? If I hack up the skeleton and a
rudimentary SDL and stdio implementations, could your implementation fit
in? (I’ll probably use some “backend plugin struct” internally, so you
just have to fill one in and add it to the list of targets. Would be nice
to know more about *curses before designing that, though.)
Would *curses be able to “push” an array of characters + attributes
to the console without incredible amounts of overhead?
Yes and no. curses assumes that it knows best how to draw things. If
you have a reasonably good terminfo database and your terminal is
fairly smart, it can just go mad. OTOH, less intelligent terminals
will be slower. And of course, incorrect terminfo entries will result
in odd looking things.
But if say, mc works, can I assume that such operations will work? (Don’t
know how mc does stuff.)
(In fact, all you need is “cursor locate” commands, and a way of
telling the window size in characters. You can even get away with
"home" + “nl” and/or “cr” if you really have to!)
You have both of those, plus the ability to move the cursor around.
You can use that to draw to what curses SHOULD have on the screen. It
then attempts to determine the best way to make that happen, which may
or may not involve a similar set of commands to the ones you issued
since last update.
The analogy to something in OpenGL would be vertex arrays. Lots of
pain to carefully stuff the right things in the right places, make sure
the right states are set up, etc. Then you just call one function and
what you need just happens, just about as fast as the hardware can do
Well, that’s kind of similar in philosoyhy to my conemu - although my API
is based on a simple, “brute force” buffer paradigm. Kind of like an
emulator of on of those old video controllers with hardware window
Stuff that I don’t need right now, but will try to keep in mind:
* Redirection of stdout to the simulated console.
* Overlapping windows.
* Graphics windows.
* "Opaque standard widgets". (Edit boxes, buttons etc.)
* OpenGL target.
This is an even taller order. =) I don’t need a GUI here.
What I’m thinking about here is basically a Delphi remote terminal
implementation that can smack in native Windows widgets, as an
alternative to the primitive text “widgets” that I’ve already
implemented on top of my extended constream interface in the DOS app.
Hell, why not just implement a VNC server! That’ll get you a remote
console with complete text and graphics support under just about any
Yeah, I’ve considered that and similar solutions (like running an X
server on Windoze), but how about running it over RS-232, preferably
without blocking the real communication that goes on over the same
line, at the same time…? Does VNC support pure text modes?
(Old instruments don’t have NICs, and we’d like to be able to upgrade
them without entirely replacing the electronics.)
direct output to the console my own way - in fact all output at
this stage goes either to Com_Printf or Sys_Printf anyway.
My problem is that the application needs some notion of "windows"
at the very least. If I just pipe everything to stdout, it’ll just be
a big mess - unless I disable some very useful debugging and testing
I understand that. And I need a concept of a window too - for the
curses implementation at least. Need a status and edit line, so the
screen needs some division. I’m just intending to do that at a little
Ok. That’s basically how conio + constream works; conio has only a “clip
rect”, which constream keeps moving around to simulate windows - although
without overlapping support. (If they overlap, it’s just “last move
Both are capible
of logging and other nice features.
That sort of stuff is actually much higher level than what I have in
mind for the actual “text screen emulation”. The closest feature I’ve
considered is windows with a virtual offscreen buffer, that may be
larger than the window.
nod I wouldn’t do that even at the lowest levels. I think the key
approach to making it work well is the layering.
Yeah - but in some cases, scrolling the whole screen, or an area of the
screen a few lines can be significantly faster than repainting the
whole screen. That’s why I want window support on the “conio” level
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 February 2002 02:00, Joseph Carter wrote:
On Wed, Feb 06, 2002 at 12:08:22AM +0100, David Olofson wrote: