Cursor questions (move & restrict)

[gumby]

First Question:
So with this call I can move the cursor to whatever coordinates I wish:

Code: [Select]

/* sets the cursor to CURSOR.997, makes it visible, and positions it at 160,100 */
SetCursor(997 TRUE 160 100)

...which works just fine.  But as soon as I move the cursor it jumps right back to where it previously was.  Anyone know how to make any further movement of the mouse obey the new cursor location?

EDIT:  Never mind, this was the result of using DosBox with 'autolock = false'.  Setting this to true fixed the issue.

Second question:
Anyone know how to restrict the operable space of the cursor?  I'd like to try to limit the cursor to only a region of the screen (specifically the bottom third).

[gumby]

I think I know how to do this.  I'm going to put a doit() method in my room script that constantly checks the  position of the mouse.  If it isn't where I want it, I'll make a SetCursor call that will force it into the region that I want.  I'll post the code when I've got it working.

[Doan Sephim]

I think I know how to do this.  I'm going to put a doit() method in my room script that constantly checks the  position of the mouse. 

That's what I was going to suggest!

[gumby]

Unfortunately, it doesn't work very well.  The mouse can stray way out of the bounds of my specified area before it's 'snapped back' into the valid area.  I'm wondering if doing something with ports might work here...

Does anyone recall any of Sierra's games ever doing this?  Restricting the mouse movement to a smaller area than the entire screen?

[Collector]

Could you do something with control lines?

[gumby]

I could probably leverage control lines (or maybe a control 'fill'), but I think the result would be the same if there is no alternative to constantly evaluating the mouse position (see this post here:  http://sciprogramming.com/community/index.php/topic,37.0.html) rather than having a window/port enforce the valid mouse region.

I guess the real issue is that I'm trying to do something that really should be handled within the SCI engine itself (in my opinion).

[Doan Sephim]

Well I gave it a shot also and the effect I got was a bouncing cursor. Sometimes it would look ok, but if you move the cursor with any speed it will go over the "barrier" line by 10ish pixels and then kind of bounce up and down over the invisible line.

I think rather than forcing the player to have his cursor low, just having a hand prop that moves along the x-axis whenever your cursor is below the y-line mark will get the idea across that the player should focus his cursor attention down low.

EDIT - Also, when I compiled your code with SCIStudio3, the game would crash whenever I tried to click, but when I re-compiled it in Companion, it worked ok. Just a strange thing I noticed.

[gumby]

Yeah, that's exactly the same results that I got.  If you move the mouse really fast, you can get even further past the boundary before it snaps back.   The effect was definitely unacceptable in my opinion.

[Collector]

I take it that you want what is like in GK1, where the bottom 90 or so pixels are reserved for the dialog text. The cursor's y axis will not drop below that point. If you continue to move the mouse, it can move along the x axis but not the y until it is moved up.

[gumby]

Yeah, that's correct.  I don't recall any SCI0 game doing this however.  I'm guessing that Sierra made this improvement in the later engines.

[Collector]

I'm guessing that Sierra made this improvement in the later engines.

Sierra was always tweaking the engine, adding features as needed. Often it would become so specialized that it would only work with the one game. In fact the source for the interpreter was usually stored with with the game source because of this.

I don't know what games/interpreters have this ability, but I have often wished that Brian had used at least a little later game to make the template, even if only late SCI0. It would have supported a few more features and probably had a more robust parser.