Messages

46

AGI Development Tools / AGI extended character support

« on: April 02, 2022, 02:21:00 PM »

This topic was mentioned at https://sciprogramming.com/community/index.php?topic=2051.msg15257#msg15257, but it's off topic for that thread, and it already got many interesting topics, so I'm replying at a new thread...

AGKorson discussed what's possible with the original Sierra AGI interpreter, running on Dos/Dosbox.

However, with ScummVM we have more flexibility. Actually, I have translated PQ1 to Hebrew - https://sciprogramming.com/community/index.php?topic=2001.0.

For instructions, please see https://github.com/adventurebrew/HebrewAdventure/tree/master/tools/agi.
I admit that these instructions were phrased mainly as a reference for myself in the future, but I will gladly help if you want.

Also, maybe some minor modification need to be done to ScummVM to support AGI French, but I can do this as well.

47

The Games and other Sierra Adventure stuff / Re: MTBLAST.DRV and SQ3 volume control

« on: February 27, 2022, 11:52:44 AM »

1. Have you tried with ScummVM?
2. MUNT simulation is pretty CPU intensive. If it doesn't get enough CPU cycles, it will sound bad. Try running with a stronger computer, with less processes running in the background, and see if it sounds better.

48

AGI Development Tools / Re: WinAGI Version 2.1.10

« on: February 04, 2022, 03:22:31 AM »

Hi.
It's a good opportunity to say how much I, and I assume everyone here, appreciate your work on creating, and constantly improving, WinAGI.

I prefer (and strongly recommend) using the 'AutoExport' option

Suggestion - if this feature is strongly recommended, maybe you can turn it on by default? If someone dislikes it, it can always be turned off.

49

SCI Development Tools / Script file: exports object - where does it point to?

« on: January 24, 2022, 09:57:42 AM »

Hi.
I'm trying to understand the scripts' format (with the help of https://wiki.scummvm.org/index.php?title=SCI/Specifications/SCI_virtual_machine/Introduction), and I don't understand the exports segment.

Let's take SQ1VGA, script 103.
ScummVM's debugger ("dissect_script 103"), says that its exports segment is:

Code: [Select]

Obj type #7, size 0xa: Exports
000004: 01 00 22 03  00 00                                   |.."...          |
According to the Wiki, it means that there is one exported function, at address 0x322.
But 0x322 is the middle of the Object 'rm103'. I expected it be something in a code block.

What's going on?

50

SCI Development Tools / Re: Is it possible to know selector's type?

« on: January 24, 2022, 09:41:56 AM »

The script resources are subdivided into a few different blocks, such as local variable storage (including initial values), class and instance definitions, actual script code, a pool of string literals, a pool of said specs, and probably one or two other types I forgot.

The decompiler can tell that the lookStr value is a pointer because it's a fairly high value (same way Print can tell a string literal from a text resource tuple), and it can tell that it's a string because said value matches a location in that resource's string literal pool. By the same token, it can recognize said specs. If it's none of those kind of thing even if it's a sufficiently high value, it's probably an integer constant.

In the later versions with the split SCR/HEP resources, all of those things went into the HEP resources except for the actual script code, which went in the SCR resources, while the said spec block was removed.

Certain later versions of Sierra's compiler allowed lackluster type tagging, where a selector was tagged as an int or an id. I'm not sure how much the compiler actually cared.



And you're right to think it might mistake a value for a string! I'm not sure what would happen and would like to find out. I'll get back to you.

Test results
(= test $02BD) where $02BD is also a string literal's location doesn't break much because that would emit an LDI opcode (Load Immediate), while assigning a string pointer would use LOFSS (Load OffSet to String?) and the decompiler knows what to do here.
However, as I expected, changing one the test room's cardinal exits to $02BD does confuse the decompiler into thinking it's a string.
HOWEVER HOWEVER, changing it to $02BE, just one byte off, made it an integer again! Apparently the decompiler is smart enough to check if it's the very start of a string. So no such risk.

Thanks for the detailed answer and the experiment.
However, the conclusion (IMO) is that there is such a risk, only its probability is low. But I wouldn't call it very low. Considering there are, what, maybe (just guessing) 20 problematic values out of 64K, that's roughly 1 to 3000. In a game with 100 scripts, it's 1 to 30 chance to encounter such a problem.

51

SCI Development Tools / Is it possible to know selector's type?

« on: January 23, 2022, 01:30:43 PM »

Hi.
Is it possible to know the selector's type?
For example, in SQ1VGA, room 103, SCICompanion has decompiled all `lookStr` as strings. How does it know that it's a string?

Is it guessing?
If it's guessing because the selector's value matches a string address in the file - it might confuse a random value that just happens to match some address - does it avoid that?

Or maybe it has some list of string selectors?

Or something else?

52

SCI Community News / "Microsoft to acquire Activision Blizzard" (and Sierra...)

« on: January 18, 2022, 11:27:10 AM »

https://news.microsoft.com/2022/01/18/microsoft-to-acquire-activision-blizzard-to-bring-the-joy-and-community-of-gaming-to-everyone-across-every-device/
So, Microsoft is buying Activision, which owns Sierra's rights.

Is it good?
I personally think that it can be hardly worse than now, and there is a (small) chance that they will do something good with Sierra.
I'd like to hear other opinions

53

AGI Development Tools / LucasFilm development machines ; and some Sierra influence

« on: January 13, 2022, 09:21:04 AM »

Well, it's actually an expansion to my comment on another thread (http://sciprogramming.com/community/index.php?topic=2034.msg15053#msg15053), but since it'd be quite off topic over there, I write it here...

I said there:

IIRC, I once read an interview with one of Lucas developers, and he said that they developed on another machine

So, I just (re-)found it: https://www.gamedeveloper.com/design/the-scumm-diary-stories-behind-one-of-the-greatest-game-engines-ever-made, it's an interesting reading.

And while looking for it, I've found some other piece (https://gamesnostalgia.com/story/170/legendary-game-designers-ron-gilbert), about Ron Gilbert, where he mentions the influence KQ had over him, and Maniac Mansion design:

that was the first time I had seen any of the King’s Quest games and the first time I had ever seen an adventure game with graphics. ... I just watched him play, and it was like this epiphany moment... Like “Oh, this is what Maniac Mansion needs to be. It needs to be an adventure game with these pictures on it.”

It's interesting to compare this to Ken Williams' claim in his book that he (and Sierra) was never interested in what was done in other companies.

54

AGI Development Tools / Re: Sierra's AGI Compiler (CG.EXE) Disassembled

« on: January 12, 2022, 08:39:35 AM »

I agree with Lars

Few comments:
1.
Regarding the file's date. As far as I remember, directories were added only in MSDOS version 2 (can someone confirm that? I think it's implied from https://en.wikipedia.org/wiki/MS-DOS, but it's not 100% clear). Anyway, according to that Wikipedia article, MSDOS 2 was released on October 1983. So, if I'm right here, that's the earliest possible date for starting to work on a program that has directories support. But the guys at Sierra had to buy the new MSDOS version on October, learn its new features, design to use them, implement that, then there's vacation at December...
So, we could guess that it's from the 1984's beginning, in the earliest case.
However, an alternate story would be that Sierra had their hands on a DOS 2 before it was released (maybe as part of the special relations with IBM around that time), and in that case, the earliest date can be earlier...

2.

The compiler is a native MSDOS program (obviously, I think- but maybe not...)

Well, it's not obvious. IIRC, I once read an interview with one of Lucas developers, and he said that they developed on another machine. I don't remember which one, but he said that the IBM-PC was too weak to do real work with it, so they used some stronger machine, and cross-compiled to PC.

3.

Code: [Select]

cg room [room...] [-o output_directory] [-b buffer_size] [-v]That's very interesting!
DOS usually used slashes (/) for parameters. That was no problem, since DOS-1 didn't have directories.
When they added directories, they had to use the strange backslash (\), because the regular slash (/) was already used.
So, it's interesting that Sierra's tool used the more Unix-like tradition of - for parameters.
Maybe it could be related to the previous item, and hint that the tool was used on other machines as well?
But that's really a far-fetched guess...

4.
To be honest, I haven't (yet) read all the syntax differences details you wrote. However, I'm just curious if you checked with the original AGI sources that we have - do they all compile with "canon" compilers? With that CG compiler?

5.
Again, great work, and thanks!

55

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: December 05, 2021, 12:02:30 PM »

It looks like the actual AddWav.exe program does not like Unicode either, so I will have to deal with non-ASCII file names completely via the GUI. It uses SoX not just for extracting the header info of the WAV files, but also for downsampling them to prepare them for AddWav. Gumby updated a few of these DOS tools to Win32, but I don't think he did AddWav. If this GUI and the tools it uses are useful to translations I might think about redoing it to fix where Unicode breaks it if you are willing to test it for me.

Anyway, here an updated version. It will now output to the same folder as the original WAV. That particular error code does not seem to break it, so I set the error reporting to ignore that warning. Could you try a resulting embedded SOUND resource in an actual SCI game to be sure that it is producing a good SOUND resource?

This one is better. However, when creating the sound file, it tries to create it in "C:\Program Files (x86)\SCI Sound Utilities", and fails because Windows denies access to that path.
You can see this one for yourself, it fails also with English file names.

Anyway, I'm not really sure that fixing the Hebrew file names issue is such important :-)
If you want to continue, I'm happy to test your fixes. But if it wastes your time, well, a simple warning message can do as well...

56

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: December 05, 2021, 05:28:02 AM »

OK, give this a try.

When I start it, it says: "Unhandled exception" (etc.). If I click "Continue", I get 2 dialog boxes, with "FormMain_GetFocus".
Then the GUI looks OK. Adding Hebrew files seems to work OK, with the correct information table.

However, when I click "Append" button, it writes in the status line "Sound file appeneded with בדיקה.wav" - but the files doesn't appear in the expected directory.
I found it in "C:\Users\Zvika\AppData\Local\Temp", and it's indeed a good file!

So, bottom line, 2 problems are left:
- The unhandled exception and the strange dialog boxes upon startup
- Copy back the resulting sound file from temp directory to original directory

Thanks

57

SCI Development Tools / Re: SCI32 Templates

« on: December 01, 2021, 04:43:34 AM »

That's great!
I'm really happy to see SCI32 support.

I thought that SCICompanion couldn't do SCI32 (de)compilation.
(See http://sciprogramming.com/community/index.php?topic=2006.0 , on the other hand, Lars' reply at the end of http://sciprogramming.com/community/index.php?topic=2005.0 gives important information...)

Is it something that was recently added to SCICompanion? I haven't seen relevant commits in Kawa's fork (and I was glad to see a recent commit in Phil's branch, but it doesn't seem to be related).

Or is it simply that SCI2 support for (de)compilation was always there (even in Phil's "classic" release), and it's only SCI3 that's troublesome?

58

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: December 01, 2021, 04:30:41 AM »

I decided that simply making a temporary ASCII named copy for SoX wasn't that big of a chore, so here is test build for you to try. If you report that it is OK I'll update the Wiki with the new build.

It solved the information table problem - it shows the information for Hebrew files.
However, when I click 'Append', it fails with "Error: String cannot be of zero length. Parameter name: oldValue".
The failure is both for Hebrew and English file names.

59

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: November 30, 2021, 03:18:03 AM »

Well, I don't think that it's worth the effort the recompile SoX - it could be a very deep rabbit hole, and my problematic use case is probably rare.

However, if you do want to improve things a little, there are two options that might be easy:
1. If the filename contains non ascii characters, copy it to a temp file with regular English name, and silently work on that temp file. The user won't even be aware of that.
2. If the filename contains non ascii characters, pop up a dialog box recommending to rename it to English in order to have the details table working.

Anyway, this thing is low priority. Your tool is great and does it job perfectly.

60

SCI Development Tools / Re: SQ3: Where is "Where am I?"?

« on: November 29, 2021, 04:42:44 PM »

Following this from your link in the Space Quest III French thread, I thought I would look into this. Can you upload the WAV file with the Hebrew file name for me to try?

Well, that's embarrassing. I haven't kept that specific file. And now I cannot reproduce the problem. I have tried Hebrew file name, inside a Hebrew directory, with spaces, and even an apostrophe. But no avail. It always work :-)

So, I'm glad that's your tool is such robust. You can "close" that bug report.
Thanks for wanting to fix it, though

EDIT
====
It is *working*, however, there is something weird about Hebrew files - they don't show Encoding, Sample Rate and Channels information.

Screenshot of the difference is attached, as well as the Hebrew file. You can rename it to English, and see the different behaviour.