#762 closed defect (fixed)
ZAK256: opcode 00 in SC scripts?
| Reported by: | SF/hibernatus | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Zak McKracken |
Description
Hi, i don't know if it's the right place to say that, but Zak256 seems to use the opcode 00 (stopObjectCode) differently in 'SC' scripts. See: - 49.LFL at 0x88A3 - 49.LFL at 0x8F5E - 49.LFL at 0xA297 - 49.LFL at 0xA6DC It seems to only take a byte as a parameter. Also, there isn't any stopObjectScript instruction (6E) in any 'SC' script. So maybe 00 replaces it?
Ticket imported from: #733964. Ticket imported from: bugs/762.
Change History (9)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
Ok, sorry :) btw, i really think somebody in the scummvm team should look at that instruction in zak256. It happens only 4 times, so maybe it's not very useful, but i'm pretty sure that 00 opcode is used differently and takes a parameter (a byte) when it's in 'SC' scripts. 2 of the 4 scripts are invalid (they end "too early") if you read 00 as scummvm does. For the other 2 scripts scummvm just gets luckily realigned after a few instructions. So i'm just trying to show you a bug.
comment:3 by , 21 years ago
OK, thanks for the clarification. I'll look into it when I find the time; but tha should stop everybody else to look into this before me, I am pretty busy (hm, maybe tonight, if I can finisht this stupid assignment soon).
comment:4 by , 21 years ago
Just to clarify this: I know without doubt, that it's not handled "differently" in SC scripts. If it has an additional parameter for Zak256 (which I still very much doubt), then everywhere, not just in SC scripts.
And the 00 opcode is used in dozens if not hundreds of placed throughout all scripts. So *if* there is a bug in ScummVM, I am 99% sure it is not in the opcode 0 code.
BTW, uhm.. you are refering to scummvm, right? You are not talking about descumm, used on scripts you extracted from the .LFL files, right?
If so, I wonder why you refer to file address in 49.LFL - it would be much more useful to tell me the name of the script file dumped by ScummVM...
comment:5 by , 21 years ago
OK I fixed the descumm bugs; and indeed only 4 occurance of this in SC script remained (but I didn't dump all available scripts). In all four places, immediately before the offendint stopObjectCode, there was a startMusic - and these are the only occurancs of startMusic, too. So an alternate (IMHO more likely) hypothesis would be that startMusic takes an additional 2 bytes as parameters in Zak256... but of course to be fully clear, we'll have to check the disassmbly.
No matter which of both is correct, this is a very good find, thanks :-)
comment:6 by , 21 years ago
Woops, yes i didn't notice it's always startMusic before :) I agree it's a better hypothesis. In case it helps, here are the only other places where you will find startMusic: - 16.LFL at 0x1467A - 50.LFL at 0x32619 The code there is consistent with your hypothesis :)
About refering the scripts etc. I actually use my own program which directly reads all the scripts in the whole game. I just said it was a bug in scummvm because i copied it of course.
comment:8 by , 21 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:9 by , 5 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Zak McKracken |
The patch tracker is not the right place, no (esp. when you don't attach a patch :-). The mailing list, or even better, our IRC channel, would be better suited.
Anyway, I am absolutly certain that no opcodes are treated differently in there. opcode 0 takes no parameter, it just exits the current script, and is in fact used in many scripts/games, not just Zak256.
Anyway, it's not quite clear to me waht you want to tell us with this report... did you mean to suggest a change in scummvm, or descumm, or just wanted to ask a question, or... :-)