ANSI Cursor Control (Update)

From: Gary Barnett (gbarnett@POLARNET.COM)
Date: 09/02/97

A while back I posted a request for information on how to
do cursor movement on a mud.

After being told there were several implementation issues, including the
requirement to enter character mode, I put the project on the back burner
while I did some research.

This is the solution I found:

Clients Tested          Comments

zMud 4.62 32 bit       (works, but be careful with your values or strange
                        results occur.  Don't use this client to test your
                        implementation. Wait until it works with a standard
                        client to avoid confusing yourself :-) )
QVTNet 4.1.2           (Use the ANSI font)

MS Telnet              (Fails: Does cursor movement, but not
                        non-scrolling region.)
Wintin95               (Fails: Doesn't do cursor movement or non-scrolling
Genewic Mud Client     (Fails: Doesn't do cursor movement or non-scrolling

All of those clients run under windows.. I just put a test system up on mud
though and will have my builders test their clients. We have a couple mac
users and a few unix users.

ANSI Codes used:

The following ANSI escape code works for cursor movement:

 L = Line (0 - xx)
 C = Column (0 - 79)

 ESC [ L ; C H    In c: sprintf(buf, "\033[%d;%dH", l, h);

The following ANSI escape code works to control the scrolling region.

  B = First line of scrolling region (0-xx)      (0 is top of screen)

  E = Ending line of scrolling region (0 - xx) (0 is top of screen)

 ESC [ B ; E r     In c: sprintf(buf, "\033[%d;%dr", y, x);

 E must be greater than B+1

The following ANSI escape code works to move the cursor up one line:

 ESC [ A   In c: "\033[A"

The following ANSI escape code works to clear the screen:

 ESC 2 J   In c: "\0332J"

Note that this code is not supposed to move the cursor to 0,0.. but it
does on all the clients I've tested.


1) None of these clients had to be in 'character mode' to process
the codes, nor did they require any special handling in the code
(see #8 for the exception dealing with prompts.)

2) output on the last line of the screen will cause some clients to
overwrite the scrolling region by one line. Recommended that the
non-scrolling region be made one line longer than needed to account
for this.

3) When the non-scrolling region is being updated, keystrokes by
the character can be placed in the region, which messes up the display.

4) I use this routine to create a terrain map of the room on the top left
of the screen, with a legend on the right. I did not test for bottom line
prompt or anything else. Just the ability to lock the top 12 lines of the
screen and update it when needed.

5) An atomic function can be created to update this region via an
event in the mud. Then, whenever the contents change, the screen
update is generated and sent. No polling loop *yay*

6) When switching into the non-scrolling region display for the first
update, clear the screen, paint your screen, then move the cursor
out of the non-scrolling region before returning control for best operation.

7) You need to know the actual number of lines on the client's console
or you will get a virtual window on your client (on zmud/qvt at least) that
extends below the screen. Typing look will not cause the correct scrolling
action.  A routine to gather that info by sending 100 numbered lines and
then asking them what the top number on their screen is seems like it
would work for those who wouldn't know the answer off the top of their
head :-)

8) You have to update the output routines to not send extra line feeds to
the client along with the prompts. Additional handling through the cursor
up one line works as well. Just return the cursor to the last position,
move it up one line and let the mud send the newline. I'm assuming that
anyone with the routine enabled has an input line and they don't get the
prompt as they already have the info in the non-scrolling region.

9) I am not implementing this for general use the entire gaming session.
I have it setup to start up during combat and end after combat is over.
In addition, space travel/combat will use another implemention using much
the same interface.


I can picture in my mind a world without war, a world without hate.
And I can picture us attacking that world, because they'd never
expect it.     - Jack Handey

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/08/00 PST