1
The Games and other Sierra Adventure stuff / Re: Betrayed Alliance 2 Development Journal
« Last post by MusicallyInspired on Today at 12:39:40 PM »Those screens are so good. Karl really does fantastic work. (As do you!)
Recent Posts
2
The Games and other Sierra Adventure stuff / Re: Betrayed Alliance 2 Development Journal
« Last post by Doan Sephim on Yesterday at 11:25:49 AM »Hey everyone, just wanted to post a quick update here. The Kickstarter was successful and even the stretch goal was reached, so now Brandon and I will be updating the artwork and music assets for Book 1. I say Brandon and I, but a friend of mine, Karl Dupere-Richer is also helping with a lot of the backgrounds for Book 1, two of which I attached to this post. In those pictures, you can see his reworking of the Dock house and the Scientist's house, both of which are beautiful upgrades, but also fit into the world much better.
I've also posted a couple of new backgrounds I've worked on since the KS finished. I'm currently working on getting the rooms up and running with puzzles, text, and animations.
All in all, things are going well. Slowly, of course...but I do a little bit of work each day and over time it adds up!
I've also posted a couple of new backgrounds I've worked on since the KS finished. I'm currently working on getting the rooms up and running with puzzles, text, and animations.
All in all, things are going well. Slowly, of course...but I do a little bit of work each day and over time it adds up!
3
SCI Development Tools / Re: Is it possible to know selector's type?
« Last post by lskovlun on January 25, 2022, 03:28:04 AM »For reference, the bug was mentioned in thread
https://sciprogramming.com/community/index.php?topic=1601.15
and fixed in commit
https://github.com/Kawa-oneechan/SCICompanion/commit/094b0fb73f4f5809d57da274c8ac06a2570bb327
And the reason why that bug happened is because SCI Companion didn't use relocations for this. The fix doesn't either.
https://sciprogramming.com/community/index.php?topic=1601.15
and fixed in commit
https://github.com/Kawa-oneechan/SCICompanion/commit/094b0fb73f4f5809d57da274c8ac06a2570bb327
And the reason why that bug happened is because SCI Companion didn't use relocations for this. The fix doesn't either.
4
SCI Development Tools / Re: Is it possible to know selector's type?
« Last post by lskovlun on January 25, 2022, 02:33:34 AM »Hi.Relocations. If that particular word of the script file is relocated, then it's a pointer. In fact, there was a bug about it.
For example, in SQ1VGA, room 103, SCICompanion has decompiled all `lookStr` as strings. How does it know that it's a string?
5
SCI Development Tools / Re: Is it possible to know selector's type?
« Last post by Kawa on January 24, 2022, 07:35:36 PM »Twenty very specific problematic values out of 64k, assuming there are twenty string literals in the string pool for the script resource currently being decompiled (noting that it only decompiles one script at a time), which includes class names.
I don't math well, but according to this percentage calculator I found, 20 out of 65535 is only 0.03%.
I don't math well, but according to this percentage calculator I found, 20 out of 65535 is only 0.03%.
6
SCI Development Tools / Re: Script file: exports object - where does it point to?
« Last post by troflip on January 24, 2022, 04:56:50 PM »The export table points to objects and code. For a script that is a room, the first entry in the export table should point to the room object.
7
SCI Development Tools / Script file: exports object - where does it point to?
« Last post by ZvikaZ 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:
But 0x322 is the middle of the Object 'rm103'. I expected it be something in a code block.
What's going on?
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?
8
SCI Development Tools / Re: Is it possible to know selector's type?
« Last post by ZvikaZ 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.
9
SCI Development Tools / Re: Is it possible to know selector's type?
« Last post by Kawa on January 23, 2022, 05:44:13 PM »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.
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.
10
SCI Development Tools / Is it possible to know selector's type?
« Last post by ZvikaZ 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?
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?
SMF 2.0.14 |
SMF © 2017, Simple Machines
Simple Audio Video Embedder
Page created in 0.082 seconds with 17 queries.