Messages

61

The Games and other Sierra Adventure stuff / Re: Space Quest III French translation ?

« on: November 29, 2021, 06:45:45 AM »

Congratulations!
Great news.

Did you manage to do everything with SCICompanion? (you had some problems with it in the beginning, if I remember correctly)

Regarding your questions:
1. Do you see that difference also in standard English SQ3 in ScummVM compared to DosBOX? If so, please open a bug at https://bugs.scummvm.org/newticket.
2. It's indeed possible. I managed to make Roger say it in Hebrew, thanks to the help of the guys in this forum. Read the question and answer: http://sciprogramming.com/community/index.php?topic=1922.msg13797#msg13797
3. Nice finding. It's internal stuff used by Sierra during development of the game. You can safely ignore it.

62

SCI Development Tools / Re: GK1: strange error after compilation, without any changes

« on: July 04, 2021, 05:39:07 AM »

Zvika, maybe consider working with the script disassemblies instead of decompiled source?

Interesting idea - I thought about patching the .scr files.
However, that's a good point - is it possible to use SCICompanion to disasm/asm SCI2 scripts? (and SCI3 scripts?)

63

SCI Development Tools / Re: Is there a SCI32 compiler? If not - why?

« on: July 04, 2021, 03:45:42 AM »

V56/P56 definitely changed. Kawa has some blog entries about it. CSC is the new script format in SCI3. Very different format, the main advantage seems to be that you can have huge scripts in it (> 64K), somewhat counterbalanced by the fact that scripts simply are bigger in that format. Makes you wonder if it was worthwhile to change it. We used to have a complete list of huge scripts (there aren't many) in ScummVM because we couldn't load them.

So, now I understand that it's not really SCI32 vs older, but SCI3 vs older?
I'm interested in SCI2 - as I wrote in the other thread, I'm trying to compile GK1 scripts.
How much do they differ from SCI1?

64

SCI Development Tools / Re: GK1: strange error after compilation, without any changes

« on: July 04, 2021, 03:43:30 AM »

If all you want is to mess around with the GK1 class library, I guess you could grab the demo and work with that. It's SCI1.1.

Actually, our team has translated GK1 to Hebrew, and I want to fix few issues with right alignment of the text, and re-compile few scripts that have text strings hard wired inside them (as we've done to SQ3 and QFG1VGA).
Surprisingly, I've successfully compiled one script (64915 - DText.sc), and that solved the right alignment of the regular messages. When I tried to handle the right alignment of the "Interrogation" dialogs, things got weird, and that's why I've opened this thread.

Now I wonder, is it OK to use my compiled DText, or maybe it's a "ticking bomb", because it shouldn't really work?

65

SCI Development Tools / Is there a SCI32 compiler? If not - why?

« on: July 01, 2021, 01:00:12 AM »

As I've been told in other thread, Scicompanion can't compile SCI32 games. Do we have any other tool that can do that?

If not, is there a technical reason for this? Some complexity maybe? Or it's just that noone had the time/interest to write one?

66

SCI Development Tools / Re: GK1: strange error after compilation, without any changes

« on: July 01, 2021, 12:54:39 AM »

Two things. SCI Companion's decompilation isn't perfect. Also, because GK1 uses a higher version than SCI1.1 it isn't really supported for compiling.

Ok, that makes sense.
It's interesting though, that I've successfully compiled few other scripts. But that's probably some luck.
Or maybe, I'm not aware yet of the problems with those scripts 

67

SCI Development Tools / GK1: strange error after compilation, without any changes

« on: June 30, 2021, 07:39:55 AM »

Hi.

In GK1 (GoG version), I've decompiled all scripts, and then recompiled script #22 (GKNarrator.sc) without any modifications. Then, I've exported the .scr and .hep files, put them in a clean game directory, and it miserably fails upon loading in ScummVM (as Dos) with:

Code: [Select]

Invalid species 169(0xa9) unknown max 169(0xa9) while instantiating script 22!
I've tried both with Kawa's 3.2.3.2, and with Phil's last version.
In Kawa's version, I got two warnings, which I ignored:

Code: [Select]

Warning: (GKNarrator.sc) Duplicate case values. Already encountered a case for '18'  Line: 90, col: 5
Warning: (GKNarrator.sc) Instance 'talkPlane' is not used anywhere.  Line: 167, col: 9
While in Phil's version the 'case' think is an error - so I've commented that line.

Any ideas?

68

The Games and other Sierra Adventure stuff / PQ1 (agi): Hebrew translation - finished

« on: May 21, 2021, 03:03:48 AM »

Hi.

We've finally finished the PQ1 (agi) Hebrew translation project.
It was very fun
Thanks for everyone that helped, and especially AGKorson, for WinAGI, and the great support!

https://github.com/adventurebrew/HebrewAdventure/releases/download/pq1_v1/pq1-hebrew-installer.exe



 

69

AGI Development Tools / WinAGI: feature request - batch import/export

« on: May 03, 2021, 02:45:06 PM »

Hi.

If it's feasible, it'd be nice to have batch import/export feature from the console.

Example possible APIs:

Code: [Select]

conWAGI.exe /export_all
conWAGI.exe /export View6 /export Picture12

conWAGI.exe /import c:\some\directory\with\importable\files
conWAGI.exe /import View6.agv /import Picture12.agp

BTW, our PQ1 Hebrew translation project is now in beta testing, and you have an important part of it, so, thanks again

70

AGI Development Tools / Re: Should WORDS.TOK have even number of bytes?

« on: May 03, 2021, 02:38:14 PM »

The trailing zero is required. That's how the word search function knows it's reached the end of the file. If you strip that off, the word search function will continue looking at data from the heap that immediately follows the words.tok file (the OBJECT file), thinking it's valid word data; eventually, a null value will be found, which AGI interprets as the end of words. In most cases, this will happen without the player ever even knowing, because there is almost always a zero value (0x00) byte in the OBJECT file's header. That byte will cause the word search to end.

Even in the unlikely event that you have more than 85 inventory items (which means the header WON'T have a zero value byte), it would be even more unlikely that the rest of the OBJECT file header and item data would contain the exact characters needed to create a false word match before a zero value is eventually encountered.

I don't know the exact algorithms, but I would not be surprised if NAGI and SCUMMVM ignore the trailing null character; they most likely use array indices to keep track of the end of the word list (this is just speculation on my part though).

So, technically, you could have a WORDS.TOK file without the null character at the end, it will work 99.99999% of the time. But it's better to have that ending character, so WinAGI enforces it.

Thanks for the detailed explanation, you've convinced me
Can you add that trailing zero to WinAGI help's description of WORDS.TOK format?

And does anyone here have write permission to http://agi.sierrahelp.com/Documentation/Specifications/8-2-WORDS_TOK.html and can update it there?
Or maybe there is somewhere more updated copy?

71

AGI Development Tools / Re: Should WORDS.TOK have even number of bytes?

« on: May 02, 2021, 10:58:26 AM »

Some of the old Sierra games had WORDS.TOK with odd file sizes (KQ3 in particular). If WinAGI couldn't open them, we would have heard about it, right?

Yeah. You're right.
I just discovered that I was wrong - the point isn't parity.

However, there is still this additional mandatory zero.
Now I think that it always expects a trailing zero. But I'm not 100% convinced that I'm correct...

72

AGI Development Tools / Should WORDS.TOK have even number of bytes?

« on: May 02, 2021, 08:35:38 AM »

It seems that WinAGI expects WORDS.TOK to have even number of bytes.
Is it on purpose?
If yes, please update the WORDS.TOK spec, in WinAGI's help.
If no, please fix it...

It can be demonstrated by creating a new WORDS.TOK file, with only 'a', 'anyword' and 'rol', and opening it in hex editor. It has an unexpected zero at the end. If it's removed, and loaded again to WinAGI, it complains that the file is illegal.

73

AGI Development Tools / conWAGI.exe output redirection fails

« on: April 29, 2021, 07:25:03 AM »

Hi.

I've tried to redirect conWAGI.exe's output to file, but the file was empty.
I've also tried to capture the output with Python's subprocess.check_output, but it returned an empty string. I assume these issues are related.

Thanks

74

AGI Development Tools / Re: WinAGI Version 2.1.10

« on: April 04, 2021, 09:22:26 AM »

Thanks, man. Unfortunately the list of people who know about Sierra + Apple IIGS games is about as long as the people who actually know details about Sierra's MIDI implementation- something like less than 5, and they don't know each other.

I think you're too pessimistic...

Anyway, if you want information regarding Sierra's Apple IIgs games, I assume you've read http://www.agidev.com/articles/agispec/agispecs-9.html. Another, less known resource - https://wiki.scummvm.org/index.php?title=User:Buddha%5E/GSoC2007-ProjectDiary.
You might also want to just read ScummVM's implementation, it's not too long: https://github.com/scummvm/scummvm/blob/master/engines/agi/sound_2gs.cpp

It's been posited the AppleII GS version sends SysEx data at game launch.

Where have you seen that? I don't think it's accurate.

If it's true, you should be able to find it either in the game source files, or in the aforementioned ScummVM's 2gs 'driver'.
ScummVM doesn't have such code. I haven't searched the game source files, but I believe it's not there either. You can simply check it.

BTW, it won't help you with your 2gs query, but I have added a feature to ScummVM to dump MIDI commands, if using standard MIDI devices. Just run it with '--dump-midi'.

75

AGI Development Tools / Sierra had keys to control sound volume in Tandy

« on: April 04, 2021, 06:15:20 AM »

Maybe it's a known fact, but I just discovered that today, so, wanted to share...

I have always thought that in AGI the sound is either turned on, or off.

However, WinAGI help says:

v23: Sound Attenuation

For Tandy systems, this variable is used as a global volume control

OK, having a global volume control is great, but how does the user control it?

Well, I have found this at PQ1: (I assume it's similar for other games as well...)

Logic101:

Code: [Select]

if (machineType == TANDY)
  {
  set.key(61, 0, c38);
  set.key(45, 0, c39);
  set.key(43, 0, c38);
  }

and Logic0:

Code: [Select]

if (machineType == TANDY)
  {
  if (controller(c38))
    {
    --attenuation;
    }
  if (controller(c39) &&
      attenuation < 15)
    {
    ++attenuation;
    }
  }

i.e., if the machine is Tandy, then the user can press '-' to increase attenuation (= decrease volume), and '+' (or '=', which are on the same key) to decrease attenuation (= increase volume).

ScummVM already supports PCjr sound emulation, which as far as I remember should be similar to Tandy, (is it possible with DOSBox? I have never tried...), however, it currently doesn't have a PCjr or Tandy computer types:

Code: [Select]

enum AgiComputerType {
kAgiComputerPC = 0,
kAgiComputerAtariST = 4,
kAgiComputerAmiga = 5, // Newer Amiga AGI interpreters' value (Commonly used)
kAgiComputerApple2GS = 7,
kAgiComputerAmigaOld = 20 // Older Amiga AGI interpreters' value (Seldom used)
};

Compared to the types in WinAGI help:

Value Computer Type
0 IBM PC compatibles
1 IBM PCjr
2 Tandy 1000
3 Apple IIe, IIc
4 Atari ST
5 Amiga
6 Macintosh
7 Cortland*
8* PS2 with MCGA

It's interesting that these two lists don't perfectly much each other. WinAGI help explain that 'Cortland' is actually 'Apple IIgs'. ScummVM is missing PCjr, Tandy, Apple IIe/c, Macintosh and PS2 - I assume because they aren't supported. However, WinAGI help is missing '20 // Older Amiga AGI interpreters' value (Seldom used)'.

So:
- Sierra added volume control keys to Tandy. Was it a known fact?
- Why didn't they add volume control keys to other platforms that had better-than-PC-speaker sound device?
- Maybe the Older Amiga machine type should be added to WinAGI help?
- What were the differences between the Tandy and a regular PC, besides improved music? In other words, is it a good idea to set machine type for Tandy (2) in ScummVM, instead of PC (0)? 'grep'ping in PQ1 source code shows that it's harmless, but that's not enough indication to make such a change...

I have tried my last idea, with KQ2 (because of the sea sounds at the beginning which are great for volume tests), and '+' and '-' really change the volume. Cool!
('=' doesn't work, because in KQ2 it's saved for swimming)

However, another strange thing is that these keys don't appear in the menu, or in the in game help.