Describing the Quake Command System

[Spirit]

Random link to reddit, some small C json parser was posted earlier and I thought of this thread: http://www.reddit.com/r/programming/com ... rser_in_c/

[Baker]

[Baker]

Lossless resizeable console achieved. So more more work than I thought.

Had to think in 1980s terms of carriage returns and line feeds (i.e. move cursor to end of row and advance separately).

Ended up turning console into an object in an unintentional way, had to write a number of macros and some of them favored a pointer to the console and by the time I was done turned all functions into pointers to the console as convenience. For simplicity, resizing the console I had to copy the original console to feed text to the new one and kill the old one. So I wasn't specifically after turning the console into an object.

Dealing with white spaces issues and newlines in various situations was a pain.

[Spike]

what about variable-width fonts?

[Baker]

[Baker]

[Spike]

what about colours?

FTE's console printing is a bit different. Con_Print expands the string into colours+unicode chars first of all (using a generic reusable function to do so), then generates a list of buffers separated by the \ns. If it gets a \r then it arranges for the next char received to clear the entire line. Dynamically allocated, the screen width is not a concern. The console buffer is just a linked list of \n separated tokens, each char has its own flags for colouring.
The lines are wrapped at render time, where annother generic function splits the line into sub-lines that fit the width of the console.
Yay for centerprints reusing these generic functions too.
Advantages:
Console resizing just works. No weird single characters when resizing the window, etc.
Font code handles char width. No console resizing on font changes.
Doesn't waste memory simply because the user is running widescreen.
Can change the number of lines stored in the buffer with a cvar, without needing to memcpy everything or restart the client.
Colours are directly stored.
Disadvantages:
Moving up/down by one line has a tendancy to move up/down according to its \n chars rather than screen estate.
Doubly linked lists... And tracking pointers...
Can be a little slower...

Quake2 does Con_Printf("Loading %s...\r", model->name); etc in quite a few places. Its a nice trick. the \r does nothing until the next char is printed, which overwrites the first char of the line, so print the line, refresh the screen, load the model, print the next model and you don't spam the console needlessly.
Interestingly the same works for Quake. Beware of mods that spam lines with \r in them for some sort of radar!
\r is also commonly used in team messages in quakeworld.
It can also be used to put words into other people's mouths... say "\rIdiot: I'm a <INSERT INSULT HERE>"
You probably want to block that.
Fun stuff really.

[Baker]

[Spike]

colours can be nice for certain things, like using different colours for easier chat.
That said, quake is not an instant messenger.
ezquake's implementation of colours scares me. I really hope its more sane nowadays.

Tbh, mostly I'm paranoid about resizing. Though I assume that if you flag each line as having an explicit or implicit newline, you can always reform the line to resize.

Main issue with variable-width-fonts and fixed-width-consoles is that you need to allocate enough memory for the user to make a line that contains a whole lot of, eg, i chars, thereby resulting in weird wrapping if you didn't give it enough memory for the line.
Different problems, different solutions.

Strictly speaking, the console buffer is a ring buffer. You presumably already allocate memory inside it, just with line granularity instead of byte granularity. A little more complex, but would work fine for variable-width fonts.

[mh]

Colours would actually be neat for chat if they used the player skin colours (top half of text - shirt, bottom half = pants) - an extra visual cue as to who is doing to the talking, and being able to match a chat string to a player model on-screen at a glance. Might be some issues with ease of visibility though.

Personally though I don't like the idea of over-sexing the console. Basic display and input are good enough for me.

[Baker]