Messages

1

SCI Community How To's & Tutorials / Re: Translating Views (The Dagger of Amon Ra)

« on: June 17, 2022, 03:14:36 AM »

Wow, didnt know that .
I just tried the game in Virtualbox (Win98) without ScummVM and there is no "both" button.
So I cant change it, without changing the SummVM'S code..
Thank you for your info and help .

• Next time you want to check something in the original game interpreter, it might be easier to use https://www.dosbox.com/.
• Changing ScummVM's code for translations isn't too hard. I have done it a few times when translating Sierra games to Hebrew.
• I found the 'both' view in ScummVM's code: https://github.com/scummvm/scummvm/blob/60fdff423165994094ac1133798f97a52f1ceaaa/engines/sci/graphics/view.cpp#L51
• If you want, I can try to help you with adding your translated 'both' view to ScummVM.

EDIT
====
The solution seems simple.
I have read ScummVM's code (same file, line 354) that injects their 'both' view - it depends (among other things) on the fact that 'View 995, Loop 13' has only 2 cells.
So, you just have to add your translated view as 'View 995, Loop 13, Cel 2' - and then it will (supposedly) be used to show that button, and will not be overridden by ScummVM.

2

SCI Community How To's & Tutorials / Re: Translating Views (The Dagger of Amon Ra)

« on: June 16, 2022, 04:46:23 PM »

Strings to translate can be in texts/messages resources, they can be hard coded in the script themselves (more common as the game is older) and can be in the views.

In your case, I haven't checked it, but anothet possibility is that the 'both' doesn't exist in any of these resources.
ScummVM adds this button in some games that didn't originally had them.
Just open this game in Dosbox and see if that button exists.
If it's there - it's not related to ScummVM.
If it's not there - ScummVM added it.
Then, I don't remember all the details. They based it on some mechanism that was already in the game. But I *think* that the button view is in ScummVM code.

Edit
====
For PQ4 there's a comment in ScummVM's code (https://github.com/scummvm/scummvm/blob/101e016af176d95a43c31b1fdb1dd8338c409843/engines/sci/resource/resource_patcher.cpp#L147) that says that there isn't appropriate view in the game, so they added it.
But I haven't seen such a comment for other games...

3

AGI Development Tools / Re: WinAGI - "Invalid or Missing WinAGI file"

« on: April 18, 2022, 03:33:57 AM »

I wonder if I should have added a separate parameter to the Game Property form to let users change the WAG filename separately from the GameID,

I really don't think it's worth your time.
Furthermore, I think it will be more confusing for the users than helpful.

4

AGI Development Tools / Re: ScummVM support for translating/modifying games

« on: April 18, 2022, 03:31:28 AM »

Thanks for the detailed information.

1.
Regarding the automatic GameID setting - is it documented in WinAGI's help? (honestly, I haven't checked...) If not, maybe it'd be nice to add.

2.

If it were me, I would have assumed any game that includes a WinAGI game file is either a fan-made game, if the WinAGI GameID is not a known Sierra gameid, or a variant of a Sierra game if it is known.

ScummVM's folks agree with you, but they had a bug.

That kinda sucks, and I hope the fix you submitted to ScummVM will fix that.

It should fix exactly that.
Please check the daily build.
It should either create a known Sierra gameid, or 'agi-fanmade'.

3.
Fun fact - that bug is partly because of me
When I worked on PQ1 Hebrew translation, I discovered that ScummVM had support for .wag file reading, but it was outdated, and was based on .wag binary format. Which means that it didn't work for modern WinAGI versions. I added support to the modern textual .wag format. Because of that, all that .wag handling code that was ignored for long time started working, include the bug (that was there before I came) that you mentioned, of the unknown gameid.

5

AGI Development Tools / Re: WinAGI: automatically setting gameid

« on: April 17, 2022, 09:19:06 AM »

Thanks for the ScummVM fix, ZvikaZ.

No problem. I have explained the situation now at https://sciprogramming.com/community/index.php?topic=2059.0

6

AGI Development Tools / ScummVM support for translating/modifying games

« on: April 17, 2022, 09:18:06 AM »

This topic has been mentioned here in few threads, and some information is at https://bugs.scummvm.org/ticket/13414.
I have made now some modifications to ScummVm's code (which will be probably available tomorrow at their daily builds).

The situation with my fixes should be (if I'm not mistaken ):

• The game's GameID in WinAGI is determined by the .com file's name, or `AGI` if it's `sierra.com`
• Once the game files are being changed, ScummVM fails to find the game in its detection table
• ScummVM tries fallback detection, based on GameID's value in WinAGI
• If it's a value that's known to ScummVM (ignoring case), it will be used
• Otherwise, it will be `agi-fanmade`
• ScummVM's `gameid` for each game can be seen in scummvm.ini, or at https://github.com/scummvm/scummvm/blob/046b6a6328075a4c876d8ee83c5755efff9da7d9/engines/agi/detection.cpp#L48
• Note that Space Quest 1 (for example) might have 'sq.com' in some distributions, which will make its GameID in WinAGI to be 'SQ', while scummvm expects it to be 'sq1'. Just modify it in WinAGi

I assume that's enough for the translation work.
If something else is needed, or if I'm mistaken, please notify me.

7

AGI Development Tools / WinAGI: automatically setting gameid

« on: April 17, 2022, 05:38:30 AM »

https://bugs.scummvm.org/ticket/13414#comment:9 says:

According to AGK, WinAGI and AGI Studio are choosing the GameID based on the presence of the .COM game loader in the imported game folder. Usually it's Sierra.com, which sets the GameID to "AGI"

Suggestion - in case that's the .com loader is just Sierra.com, maybe the gameid can be set by checking the `set.game.id("SQ");` command's value.

8

AGI Development Tools / WinAGI - "Invalid or Missing WinAGI file"

« on: April 17, 2022, 05:28:58 AM »

Hi.
I've imported SQ1. 'Edit Game Properties' dialog popped up, and I modified GameID to `sq1`, saved, and exited. So far, no error message or warning.
Then I reopened WinAGI, and got an error: "Invalid or Missing WinAGI file", saying that sq1.wag file is invalid or missing, and removed from Most Recent Files list.

It's really not critical issue, as I can still manually load the wag file, but it seems like something needs to be fixed here.
(maybe change the .wag file name if the gameid is changed? or maybe fix the Most Recent Files list?)

9

AGI Development Tools / Re: WinAGI Version 2.1.16 Available for Download

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

Very well, I understand a little more every day. In fact I tend to want to use WinAGI like SCICompagnon 

I have two more questions. French uses accented letters. So I need an AGI font 255 characters with accented letters. http://www.image-heberg.fr/files/1648738546236223923.png

Where is the font located in the game, because I will have to modify it? (Otherwise the game will not be able to read the accents) In fact I would like to be able to write directly with accented words in each LOGICS file. http://www.image-heberg.fr/files/16486955621017682477.png

Is there an AGI font 255 characters with accented letters that I could use?

Thank you for your patience 

I answered at https://sciprogramming.com/community/index.php?topic=2054.0

10

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.

11

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.

12

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.

13

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?

14

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.

15

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?