Possible new version of SCI Companion

[MusicallyInspired]

The buttons yes, but the actual GUI window borders and colours? Great idea about the community contest! Of course, that's perfect.

[Cloudee1]

The buttons yes, but the actual GUI window borders and colours? Great idea about the community contest! Of course, that's perfect.

From playing around with the decompiled scripts, mainly from sq4 but I see alot of the same basic scripts in sq5 as well, there is a BorderWindow script which is used to generate the primary print statements and whatnot.  Inside of that script, is also an InsetWindow class, which kind of lets you put a bordered window inside of a bordered window.

I got this more or less working in sci0, the bordered window came out perfect during the titlescreen but somewhere between it and initrooms the windows that came out in the actual playable room lost the correct border colors on the left and right side  but anyway... each of which can be set separately as well the overall border width and the underlying window shadow.

Code: [Select]

topBordColor 7
lftBordColor 6
rgtBordColor 8
botBordColor 3
bevelWid 3
shadowWid 2

So Basicly, in main where we have

Code: [Select]

(send gTheWindow:
color(gWndColor)
back(gWndBack)
)
...
(instance theWindow  of SysWindow
(properties)
(method (open)
(if(< Graph(grGET_COLOURS) 9)
(if( (< color 7) or (== color 8) )
= color clBLACK
= back  clWHITE
)(else
= color clWHITE
= back  clBLACK
)
  )
  (super:open())
)
)
The instance would change from a syswindow to an instance of borderwindow, and then all those new attributes could be set in the init bit that is posted first.

As for the system options, not sure what else to call it, the window with the save, restore, speed, volume sliders etc. All of the elements of that window are graphical in that they make use of views but from what I can tell they appear inside a type of borderwindow. The finer points on sticking clickable views and whatnot for that one are still beyond me.

[Collector]

And a lot of the games only had the GUI bar visible when the cursor was at the top. I think that some even had a sliding from the top bar. And if you look at all of the pic resources of the SCI1-1.1 games they did not include the bar, thought with perhaps a black bar at the top.

[troflip]

I think they are views since they are animated. You could check with SV to be sure. Once we have some VGA tools we can use for the task we could have a community contest for graphics for the VGA template. That could be fun. It wouldn't be so bad to have a few different styles of UI for a developer to choose from depending on the nature of his game. Ego will have to have loops for moving diagonally.

That's a great idea.

Once I have the basic SCI 1.1 template game working (I doubt it will take very long), I can release an alpha build of SCI Companion, and people can try it out and help figure out what all the various classes do and how they should be used (in addition to making sample view/pic resources). There's a lot of stuff in there I don't understand!

[troflip]

Here's what the message editor is looking like so far...

[troflip]

I thought of a useful idea for debugging games. It seems like it would be possible to have the ability to print debug messages and have SCI Companion pick them up and display them while you're running the game. From what I understand, SCI Audio writes to a file, and a separate process reads from it in order to know what mp3 to play. Seems like this debug functionality could be implemented in a similar way. Given the lack of a built-in debugger in the SCI 1.1 interpreter, it seems this would be pretty useful.

[Collector]

Perhaps Gumby's SCI Logging is a better fit for your purposes. http://sciprogramming.com/fangames.php?action=review&id=189

[troflip]

I've spent the last few hours trying to get the SQ5-based template game running on the LSL6 interpreter, but with no luck. I don't think it's even getting to the play method of the main game class, which should be the entry point of the game. There's no error, the program just closes. In Scumm it works fine.

The only thing it DOES show is an orange hand cursor for a split second. Originally I assume this must mean that it at least succeed in starting the game, but I think this cursor must be actually built into the interpreter.

- The original SQ5 shows a grey arrow briefly, then a grey hand briefly (before starting the title screen, which has no cursor).
- My template game (both running on SQ5 interpreter and LSL6 interpreter) show an orange hand (before going to the title scren, or exiting, respectively). If I modify the cursor that looks identical to it (but it grey), view 997, the orange hand doesn't change shape.
- ScummVM just goes straight to the title screen without showing any initial cursors

That's why I think the cursor must be built into the interpreter. However, it must be using a palette from the game, given that it ends up being a different color. I'm not really sure what's going on here.

Another weird thing is if I remove the interp.err file from the directory, the exits even more quickly (without showing the cursor at all). The interpreters are obviously very picky about what exists where.

Anyone have any ideas?

What I did was I took the LSL6 folder, replaced the resource.map and resource.000 with those from my template game. Then I exported the 65535.map resource from LSL6 (which list the entries in resource.sfx) and imported it into the template game. I also deleted the patch resources (i.e. the instrument patches) from the template game and replaced them with those from LSL6, just in case that made a difference.

[lskovlun]

Sierra's interpreters are indeed very picky about which games they work with. In particular, a resource called vocab.994 tells the interpreter where to find certain properties of certain classes for quick access. It needs to match both the interpreter and the game; recreating it would be quite a task. The timing loop performed during game initialization is one place where this is used. Now, vocab.994 has the same length in LSL6 and SQ5, but they are different according to SV. You may be able to transfer it between the two games, but don't count on it. ScummVM ignores this resource.

- My template game (both running on SQ5 interpreter and LSL6 interpreter) show an orange hand (before going to the title scren, or exiting, respectively). If I modify the cursor that looks identical to it (but it grey), view 997, the orange hand doesn't change shape.

I'm not quite sure what you are trying to say here.

- ScummVM just goes straight to the title screen without showing any initial cursors

This is probably a speed issue. ScummVM does show the cursor if you break in the debugger (--debugflags=OnStartup is nice...)

That's why I think the cursor must be built into the interpreter.

There was code in some SCI01 interpreters (and perhaps SCI1) to display a view before handing control to the scripts, but it is not there in LSL6.

[troflip]

I'm not quite sure what you are trying to say here.

Basically I'm saying that the orange cursor I see must be built into the interpreter, since it doesn't appear in any of the game's resources.

I tried putting a Wait(120) at the beginning of the play method in script 0. In Sierra's interpreter, I see (and can move) the cursor for 2 seconds before the game starts (except in the case of my LSL6-SQ5 mashup, in which case it still exits immediately). ScummVM doesn't show the cursor, so I don't think it's a timing issue.

[troflip]

Sierra's interpreters are indeed very picky about which games they work with. In particular, a resource called vocab.994 tells the interpreter where to find certain properties of certain classes for quick access. It needs to match both the interpreter and the game; recreating it would be quite a task.

Help me understand this 994 resource a bit better. If I understand correctly, looking in SV.exe, the number in the left column (which just increases sequentially) is an interpreter-specific thing. Like in LSL6, 16 might be "Motion.x", but in SQ5, it might be "Actor.cycler".

Then the actual data (the number in the right column) refers to the index in an object at which that property would be found? So if you had:
16     61
The LSL6 interpreter would say, for example, "I'll find the x property at index 61 in this object which should be a Motion class".

Is that roughly correct?

If my understanding is correct, then comparing the LSL6 and SQ5 vocab.994, I see a few ranges of items where the property index number is just off by one. This would mean that some class in LSL6 had an extra property added (somewhere between index 10 (which is not off by one) and 33 (which is)), and so any entries that referred to properties after that class would have a value of one higher in LSL6 (it looks like the "case" property was added to Feature, so that might account for that).

Since all I see are a few ranges where things are off-by-one, it also suggests that the interpreter-specific list of properties in both interpreters is the same (otherwise I would expect things to be wildly different). If that's true, then I'd want to keep the SQ5 vocab.994, since it will match the object hierarchy from the decompiled SQ5 scripts.

[lskovlun]

The LSL6 interpreter would say, for example, "I'll find the x property at index 61 in this object which should be a Motion class".

Is that roughly correct?

That is about right, except the interpreter can't tell whether it's looking at an instance of the right class or the right property. Mismatches here will lead to chaos, though I would expect crashes or odd behavior rather than a clean exit. Does DOSBox somehow treat crashing processes differently than real DOS?

Other properties than those referred to in that table are also used, but the lookup is done via ordinary selector numbers. Even method calls. Any failures here should lead to an Oops! error, though.

I can think of a few other failure sources, but they should all lead to crashes or odd behavior, and they all require the scripts to run in the first place. I suspect you are mistaken, and they do.

Have you tried using File objects or kernel calls to trace execution? I'm thinking you could instrument specific functions to write a text string to file; that way you don't have to make sure things are set up properly for Print. The LSL6 interpreter does have support for a second monochrome monitor - and a kernel call to write to it - but I have no idea how to convince DOSBox to emulate one. Otherwise, that might have been the easiest way.

[troflip]

Yeah, I tried writing something to a file as the first thing in the play method (the play in the Game instance in script 0 is the first code that's run, correct?), but it was never created. And like I said, the DOSBox still exited immediately if I put a Wait(120) there. So the play method is never even executed.

I guess if I really wanted to try to make this work, I could start debugging the interpreter with the DOSBox debugger.

[troflip]

Does anyone know how the interp.err file (which is mandatory) is used? Would those errors be logged somewhere by the interpreter? That might help me find the problem.

Edit: ok, well I just answered that myself. I was always running DOSBox with -exit. If I remove that, then I get the error causing the problem:

Code: [Select]

Stampver error: 360-4294962636
Script #: 0, IP: 0

Which is E_VER_STAMP_MISMATCH in the interp.err file. Now as to how to fix it...

I'm guessing IP means instruction pointer? 0 probably indicates the game code has not started executing yet, which corresponds with my observations.

[lskovlun]

I'm guessing IP means instruction pointer? 0 probably indicates the game code has not started executing yet, which corresponds with my observations.

Yes, the -exit flag would explain things. 
Anyway, this has two parts: There is an interpreter version stamp inside the .EXE, and another somewhere in the game. Looking at the interpreter, it seems to be read from the RESOURCE.MAP file, right after the initial index pointers. So you would have something like (in hex):

80 (view) 0004 81 (pic) 017c 82 (script) 0362 etc. FF FF (8 bit garbage) (32-bit version stamp)

The version stamp in this case should be 139C hex. (360+0x1234).

Doing this, however, causes the game to crash hard; but I think it does enter the script code now.

EDIT: I was doing this by changing the SQ5 resources to match the other interpreter, but I must have overwritten the pointer to 0.V56 in the map (the list of views came to overlap with the version stamp). So a simple hex edit won't do. Sigh.