Cool. Thanks!

Okay, that is weird. Sorry, I didn't get what you meant at first. That's going to take some looking into.

Also, run the program with PROP_ON changed to PROP_OFF. Same thing. Total line count might be different, but it still gets offset by 1 every time there is a command prompt. It's not a problem with Fixed vs. Prop -- just seems to be a bug in the engine. Anyway, I worked around it by not starting the game at the top of the screen, but it's still something I thought I should mention. :)

And it *might* just be a bug in the Windows version. I run the DOS he.exe, and it works fine.

#include "verblib.g"
#include "hugolib.h"
#include "resource.h"
#include "window.h"
#include "hugolib.h"

!------------------------------------------
routine init
{
    counter = -1
    player = you
    location = TestRoom
    move player to location
    FindLight(location)
    !location is visited
    DEFAULT_FONT = PROP_ON
    Font(DEFAULT_FONT | PROP_ON)
    STATUSTYPE = 0
    prompt = ">"   ! prompt cursor
    cls
}

!------------------------------------------
routine main
{
    counter = counter + 1
    PrintStatusLine
    run location.each_turn
    runevents
    RunScripts
    if parent(speaking)~=location
       speaking = 0
}

!------------------------------------------
room Testroom "Test Room"
{
    long_desc { "Blah blah." }
}

!------------------------------------------
player_character you "You"
{
    long_desc { "Yeah, you're you." }
}

!------------------------------------------
replace doScore
{
    cls
    locate 1,1
    print "This is line #"; number display.cursor_row
    print "This is line #"; number display.cursor_row
}

!------------------------------------------
replace doSave
{
    print "This is line #"; number display.cursor_row
    print "This is line #"; number display.cursor_row
}

Hmmm -- I probably didn't explain the problem very well. :) I figured out about the difference in the fixed versus proportional fonts, but what I'm seeing seems to be a failure of the command ">" prompt to actually add the space it takes up to display.cursor_row.

What makes me think this is the following.

I can locate 1,1
display.cursor_row is now 1.

I can print 2 lines of text, without preventing line-wrap:
print "This is a test"
print "This is another test"
display.cursor_row is now 3.

Up to that point, everything is correct.

Now, control returns to the parser, and the ">" prompt appears.

From this point on -- until the text reaches the bottom of the screen -- display.cursor_row is one off. It might be the prompt causing it, or it might be the blank row before the prompt. I'm not sure. But I wrote a little program to demonstrate what I mean.

When you run the program, first type:
SCORE
Then type:
SAVE
Then type it again:
SAVE
and again:
SAVE

You can see that the prompt isn't being included in display.cursor_row. Each time you do it, until you reach the bottom of the screen, the numbers will be 1 higher than they're supposed to be -- for each prompt. And the font size doesn't matter. You can have a tiny fixed font, and a large prop font. The value of display.cursor_row is always correct, except where a command prompt is shown. And then it's one off, for each prompt.

Hope that helps! It's a really weird thing.

---- Mike.

[code]#include "verblib.g"
#include "hugolib.h"
#include "resource.h"
#include "window.h"
#include "hugolib.h"

!------------------------------------------
routine init
{
counter = -1
player = you
location = TestRoom
move player to location
FindLight(location)
!location is visited
DEFAULT_FONT = PROP_ON
Font(DEFAULT_FONT | PROP_ON)
STATUSTYPE = 0
prompt = ">" ! prompt cursor
cls
}

!------------------------------------------
routine main
{
counter = counter + 1
PrintStatusLine
run location.each_turn
runevents
RunScripts
if parent(speaking)~=location
speaking = 0
}

!------------------------------------------
room Testroom "Test Room"
{
long_desc { "Blah blah." }
}

!------------------------------------------
player_character you "You"
{
long_desc { "Yeah, you're you." }
}

!------------------------------------------
replace doScore
{
cls
locate 1,1
print "This is line #"; number display.cursor_row
print "This is line #"; number display.cursor_row
}

!------------------------------------------
replace doSave
{
print "This is line #"; number display.cursor_row
print "This is line #"; number display.cursor_row
}[/code]

Sounds like the tricky thing here is how the "locate x, y" statement calculates the cursor position. From the Hugo Book (p. 165):

"Note: The maximum horizontal/vertical cursor position is constrained by the boundaries of the current text window. The cursor position is calculated in fixed-width character coordinates."

So it's probably the fact that the fixed and proportional fonts are different heights.

The design decision to use only the fixed-width character coordinates is hopefully an informed one: there are some implementation and design details behind it that we could go into at greater length. For instance, some other systems/terps force all fonts to be the same lineheight regardless of the actual font size. This was a concession of a different sort.

This goes for windowing, as well, which may help explain the [MORE] prompt you were seeing.

The best way to print a positioned block of proportional-font text on multiple lines is probably within a window block.

I've spent the last several hours trying to figure out a problem with my custom menu. As far as I can tell, there is a bug in the Hugo engine, when calculating display.cursor_row.

I'm using a proportional font, and display.cursor_row returns the correct row number -- but only as long as I haven't cleared the screen and moved the cursor back to the top. If I just do a "cls", where the cursor starts at the bottom and every command scrolls the screen, then display.cursor_row is always right. But if I locate back to the top, then it appears that the command prompt ">" doesn't get included in the row count, so display.cursor_row returns one less than it's supposed to be.

I have worked around it, by simply not locating back to the top at the beginning of the game. :)