Hi Brian (assuming you're most likely know to answer this),|
I wanted to ask if there will be an easy way to make a VGA SCI game that has a parser-based interface like the old SCI0 games.
I know that SCI1 interpreters did not include an internal parser. However I don't know about VGA games such as Jones In the Fast Lane, or the VGA Christmas card - maybe they did include an internal parser in them? Or maybe the late SCI01 interpreters were able to display s56 resources (256 colors) ?
Or maybe it'll be possible to hack the interpreter like you did with the AGI-256 color support?
|Brian_Provinciano||I need to disassemble them, but I believe that one or two (particularily those which you mentioned) do have VGA and support the parser. They still include the debugger removed from VGA interpreters (except of course, those earliest ones), as well as include all the vocab resources needed for parsing. I will investigate.|
|Brian_Provinciano||I've disassembled the Jones interpreter, and the parse has been removed. The KParse and KSaid kernels both were removed and replaced with messages stating "Parse: there is no parser" and "Said: there is no parser", but the KSetSynonyms interestingly enough wasn't removed. In the SCI11 interpreter I disassembled, all three were removed completely and simply point to the KDummy kernel, which will give you a PError ("Oops") if used.|
So if there is no such interpreter available, what about the other 2 options:|
1) check if the sci01 interpreters support 256-color resource, or
2) try to hack an sci01/sci0 interpreter and add 256-color resources support
|Brian_Provinciano||Well, hacking to support 256 colours would be easy, since many have MCGA (mode 13h) drivers already. To modify it to use vectored 256 colour pics would be simple, and all that stuff. Unfortunately, There aren't enough people interested in VGA-parser based games for me to spend my time on such a thing. AGI hacking was a fun challenge, but with SCI Studio already supporting SCI32, hacking SCI0 to look like SCI1 seems kind of silly to me, even if it's for the parser. A script based parser would do the trick with no hacking required. Plus, with PCs nowadays, you could scan through millions of words in your scripts without slowdown, so it would work fine. The AGI parsing system is only about 30 lines of code, so there's not much to it.|
|Omer Mor||Your idea (of script-based interpreter) sounds great. I had no idea that writing such an interpreter be would so easy.|
AGI's interpreter doesn't have all the word types and such like SCI. Simply words in groups. With text resources, you could have a list of words in a file separate from the script without a need for hacking. SCI does support FileIO, so you technically could manually read the vocab.000 too though. With the text resource, you could manage words by index as well to speed things up. |
My idea: Have 26 text resources, one for each letter (or 27 for non-alpha as well). Each text resource would contain an array of words that are accepted. Now, make the first character or two (sci is 16-bit based) of each word it's group.
Get the first character of the word. Load the resource "text.%d", (<words text start num> + letter - 'a'). Then, scan through them to find the word group. If no group found, "I don't understand the word \"%s\"!" can be displayed. Now, compare that word group number with the said index (ie. you'd have a ProcSaid( ... indexes) which scans the word to paramTotal word groups). Each word would simply be obtained by separating them by $20 (space), $09 (tab), $00 (eos).
See how simple it is :)
I might whip up a parser engine+words converter soon enough now that you've got me thinking about it :)