So how customisable is the interface in SCI1.1?

[Scavenger]

I've been going through SCI, trying to get the hang of each bit of it, but there's something that's bothering me about it that I need to clear up: Is the standard Sierra interface hard coded, or in a script somewhere? I've been looking and looking for it, but I haven't yet found where the interface is defined. I know the top bar is drawn by the script, and you can change it, but I'm not sure about the iconbar, or whether you can create a different interface style that doesn't have the iconbar/right click cycle. Maybe something like Left click interact, right click look? A verb coin? How hard coded is the interface in SCI1.1, and if it isn't, where is the script that controls these things?

[Kawa]

It's scripted. Everything you just described can be implemented, and it's a few different scripts.

[Scavenger]

Can you help to point me to where the mouse handler is, and the iconbar is drawn? That's the main thing I'm having trouble with. Once I find out where everything is, I can probably program it myself, but there are like, 30 scripts and I have no idea where everything is.

[Kawa]

class IconBar of Set is in script 937 iconi.sc. instance templateIconBar of IconBar in turn is in #0 main.sc. Look for evMOUSEBUTTON to find the various places where mouse input is considered.

[Scavenger]

Thank you, I'll read these over and see how to create my own interface from it!

[Kawa]

Y'know, no offense but considering we have a template to use an iconbar in SCI0, and that SCI0's text parser is entirely optional (much like AGI's, as seen in BC and MH1+2), it strikes me as a little bit silly to ask if you can replace the bar.

(Not to mention SCUMM: Loom and the later games didn't have a verb grid, being mostly done in script.)

[Scavenger]

Honestly I think that's a little uncalled for. I'm just here trying to learn an engine with very little documentation or up to date tutorials (half the tutorials on SCI1.1 use a syntax that doesn't compile in what I'm using, it's very confusing), and I'm gonna have to ask a lot of questions you may find silly because you already know the answers to it.

The last time I used SCI0, I asked if the text parser box was done in-engine or in-script, and the consensus was it was hard coded into the engine and you needed to do a lot of workarounds to make it be something else. I am not aware of many games that used a nonstandard interface in SCI1.1 (even the SCI1.1 version of LSL6 used the iconbar and not the interface from the high res version), so I was concerned that the iconbar was the same deal as in SCI0. This engine isn't SCUMM, it's its own thing, and I've worked with a lot of engines with hard coded elements (such as OHRRPGCE, which has a pretty non-customisable battle engine).

I'm just trying to learn this engine. :\ It's difficult, and I don't know enough about it at the moment to know how to ask the "right" questions. I'd appreciate it if you helped me and didn't snipe at me?

Anyway, I've been having a look at it, and it looks like, though I can't be sure, that you use GetPort on the current viewport and SetPort to draw a new window overlay, though I'm not sure exactly how it works. Looking at the status line code, it seems pretty straightforward in that you can draw directly to the screen using the Graph function, but I'm not entirely sure how you draw a button yet. There's no documentation on Get/SetPort that I can find, either. How does that work?

Edit: Ok, I've messed around a little to try and get drawing shit done, and added this to the room instance, but when it's there I can't click on anything and it gives me the error "35979.fon not found" and hangs whenever an interaction is supposed to take place.

Code: [Select]

(method (doit oldPort)
(= oldPort (GetPort))
(SetPort -1)
(Graph grFILL_BOX 20 20 40 40 VISUAL 5 -1 -1)
(Graph grUPDATE_BOX 20 20 40 40 VISUAL)
(SetPort oldPort)Pretty sure I'm doing something wrong, but I don't know what.

[troflip]

Yeah, that was pretty rude, I agree.

SetPort takes a window handle. See the example code in the GetPort documentation: http://scicompanion.com/Documentation/Kernels/GetPort.html

The error you're seeing is because the interpreter is treating -1 like a window handle, and I guess going a bit crazy.

But I don't think you should need to use SetPort/GetPort, unless you're making a new window. If you're trying to make custom buttons, I think you can just override the draw method on DButton, and use the Graph calls there. If you're trying to customize the items in the icon bar, I think that's in the show method of IconItem (not positive about all this, just from a quick glance around).

And it's true, there are still a lot of tutorials on this site that use the old syntax. It would be great if someone had time to convert them.

[Kawa]

Mmyeah, sorry 'bout that. I was half asleep by then. I'll try not to do that again.

[Scavenger]

I am trying to make a new window, just to experiment and learn how this works - I don't just want to edit the iconbar but make an entirely new interface. The one I had in AGS looked like this:


So I wanna know how to replicate it in SCI. I'm... more of an artist than a game developer really.

I tried using NewWindow, here is my code:

Code: [Select]

(method (doit oldPort hWnd)
(= oldPort (GetPort))
(= hWnd (NewWindow
        20 20 40 40
        "Test Window"
        nwNODRAW
        nwON_TOP
        clBLACK
        clWHITE
))
(SetPort hWnd)
(Graph grFILL_BOX 20 20 40 40 VISUAL 5 -1 -1)
(Graph grUPDATE_BOX 20 20 40 40 VISUAL)
(SetPort oldPort)
)
And here is the, quite honestly baffling, output:



Today I learnt that SCI1.1 has the full 0-256 range for ASCII, which makes translation a lot easier! But what went wrong here?

[Kawa]

To replicate that, don't use windows. Instead, basically have the template game's icon bar draw not on the top but on the bottom of the screen for starters, then find and remove the parts where it can be hidden and shown. There are more bits to adjust, no doubt, but that's good for starters.

Actually, your AGS screenshot reminds me of LSL6's interface (the low-res version) a lot, being permanently visible on the bottom of the screen, with the inventory and everything. So you might want to decompile and study that. class ButtonBar of Set in #87 BarIconI.sc specifically.

[troflip]

Yeah, Kawa made a good suggestion. Find a Sierra game that does something similar and decompile to find out how it works.

As to why you're getting the error message, I suspect it's because you're creating a new window every frame (in the doit method), but never cleaning it up/closing it - so the interpreter keeps making a new window every frame and runs out of space. Generally, you'd be using the SysWindow class, and not the NewWindow kernel directly (although you still need to remember to dispose: these).

But as Kawa said, I doubt you need to use a window at all. Just from glancing over the IconBar code, it saves what was underneath it, then draws on top of the main window. Then when its done, it restores what was underneath.

Does the one in LSL6 also "auto-hide", or is it there all the time? If it's there all the time, then that might be a slightly different implementation (maybe it does use a window).
[edit:] Took a look at it. Looks like it uses an undocumented call to SetPort. If 6 or more parameters are passed, instead of setting the port to a window, it changes the current port's rect.
(SetPort top left bottom right xOrigin yOrigin)

Even for me as an experienced programmer, the "system level" stuff in SCI can be hard to do. It's a low-level language like C... you need to be mindful of memory management. Luckily, if you're just doing actual gameplay stuff, the scripts tend to manage that for you pretty well.

[Kawa]

LSL6's bar... I think it only hides in handsoff and such, but like GK1 the backgrounds are widescreen -- there's nothing behind it to obscure.

[lskovlun]

As to why you're getting the error message, I suspect it's because you're creating a new window every frame (in the doit method), but never cleaning it up/closing it - so the interpreter keeps making a new window every frame and runs out of space. Generally, you'd be using the SysWindow class, and not the NewWindow kernel directly (although you still need to remember to dispose: these).

Seconded. It looks like you're creating a new window on every frame, which will exhaust heap memory... quite quickly, actually.

troflip: The long form of SetPort was discussed here

[OmerMor]

This file is a good (official) documentation on low-level SCI kernel functions:
https://github.com/OmerMor/SCI16/blob/master/DOC/KERNEL.TXT

However it covers only SCI0.