bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Much Weirdness on last printing line...


From: Ryan Pavlik
Subject: Much Weirdness on last printing line...
Date: Fri, 23 Feb 2001 17:41:32 -0800

OK I have a problem I've not seen reported or have experienced before.
I'm working on a scriptable roguelike-ish game engine of sorts.
However, I'm experiencing misrendered output and some screen garbage
whenever the *last* line of output changes in the last 4-5 columns.
Here's an example:

 ##########
 #!........
 #.........
 #.........
 #.........
 #.........
 #.........
 #.........
 #.........
 address@hidden

@ represents the character, and as the character moves to the right
across the bottom row, weirdness occurs (note that everything else
stays the same on the screen except the last row so to conserve space
I'll just show it):

 address@hidden => address@hidden => address@hidden => #..@@..... => 
address@hidden
           ^           ^           ^           ^              ^
The carats represent the position of the cursor as things progress.
At each time, the character *should* progress to the right until it
reaches the last column.  This is what happens when it moves in any of
the rows above it.

A few things to note:

    *  Each row is given to ncurses via mvwaddnstr() after being
       constructed completely; that is, the row is not drawn then the
       '@' character drawn over it, for instance.
    *  This was tested with various characters instead of '@', and
       also with other movement along the bottom (scrolling the map
       with varying characters along the bottom row).
    *  Moving the cursor after drawing the last line makes the
       distortion happen near where the cursor is moved.
    *  Outputting the linebuf to stderr reveals that the linebuf is
       being properly constructed.
    *  This has been tested on 3 different Linux systems, 2 with
       RedHat 6.2, one with beta 7.1, with different versions of gcc,
       glibc, and ncurses (stock RH, 5.0, 5.0 with Debian patches,
       5.2, 5.2 with latest weekly patches).  All exhibit this
       problem, in xterm, rxvt, aterm, and the Linux console.
    *  It was tested on a forth (Debian) system where the problem was
       not exhibited, frustratingly enough. ;-)  (This is why I tried
       the Debian-patched ncurses, which seemed to solve the problem
       initially, but it later returned).
    *  When I make a simple test to emulate conditions, the problem is
       also not exhibited.

You can find the source at sourceforge in CVS:

    http://sourceforge.net/projects/wylderness/

but it also requires SFW (from CVS, not the 1.0.2 release), and the
NJS interpreter (0.2.5 release, not CVS, and it needs installed before
SFW so SFW picks up on it):

    http://sourceforge.net/projects/sfw/
    http://sourceforge.net/projects/njs/

Which may be more trouble than they're worth, but that's where the
actual code resides in case you're interested.  (Actual map rendering
happens in src/plugins/Style/Rogue/RogueMap.C in the
Rogue::Map::render(..)  method.  You can browse CVS and see this
without downloading source as well, of course.)

I've attached two "logs" of the output of the "real" binary and the
output of my test binary which looks visually the same and uses
similar window output, but doesn't exhibit any problems.  Looking at
these I can see where it seems ncurses produces incorrect output after
a move or so (and I have no idea where the 1C is coming from).  If
this is related to something I'm doing or not doing I'd *sure* like to
find out so I can finish this code. ;-)

Thanks for any insight you may lend,

-- 
        - Ryan Pavlik

Attachment: binlRSXEhWF7c.bin
Description: Binary data

Attachment: bin6TdRXhNlZ1.bin
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]