Community
SCI Programming => SCI Development Tools => Topic started by: troflip on March 07, 2015, 10:22:58 PM
-
Hi All! Long time no see...
Good news! I've quietly picked up work again on SCI Companion recently. I plan to release another version in the next month. I hope to include the following changes:
- support for opening and viewing SCI1 and SCI1.1 resources (possible editing/saving support, we'll see)
- decompiler (for SCI0 for sure, possibly for later versions)
- sound playback and midi import for SCI0 (possibly for later versions, we'll see). This was already in the code OmerMor put on github, but never in an officially released version.
- various bug fixes from reports I've seen in the forums
- a host of other smaller features and fixes
- sorry, it will still be C++, not C# :-(. Too big of a change to port it to C#, but I've been organizing the code better and "modernizing" it.
I plan to put it on github as a Visual Studio 2013 project so people can fork and modify as needed, etc... I hope to include a suite of unit tests to help with stability. In order to support unit testing I've had to split the code into a library and an exe wrapper, so this should make it easier to write some command line utilities and such that leverage the code in SCI Companion, if people want.
-
It has been a while Phil, glad to see you swung by. That is some pretty exciting news indeed.
-
:O:O:O:O
:D :D :D :D
I'm looking forward to seeing the source and learning from it.
Will it also have the as yet unfinished C++ notation option?
-
I don't plan to include the c++ style coding option right away, unless people clamor for it.
I'm focused more on support for loading SCI1 and SCI1.1 resources, and hopefully editing them and saving them back.
Here I have a VGA pic resource where I pasted in a screenshot from the game Braid. It automatically chooses an appropriate color palette. Then I drew a bit on the priority screen and plopped Roger Wilco into the scene:
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp1.png)
Here's another new feature, a "room browser" that shows how rooms are connected. This is from KQ5.
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp2-KQ5.png)
-
This is great news indeed. Looking forward to seeing the fruits of your labors Troflip.
-
Ooh, does the room map go by the north south etc properties, actually look at the code, or is it defined separately? By the way, the new icons are looking pretty good too.
-
Ooohhhh I am so psyched for this! I can finally properly continue working on SQ1Retro. I was stuck working with two 256 View editors, one would not preserve or set the origin point and the other would screw up the palette by making all black colours white. I assume your editors don't have these problems? :D
Is it also possible to match an imported background's palette to a pre-existing SCI palette instead of creating a new one? How does it currently work? Do the imported backgrounds automatically set aside the first 64 colours in the palette for sprites and simply use the remaining 192 only? That's how Sierra's backgrounds worked. Otherwise sprites will look wrong in-game.
Sorry, a lot of questions. I'm just curious. Don't feel too pressured by all our excitement.
Yeah, I'm in no hurry for C++ notation, I was just wondering if it was still in your plans.
Does/will this also have the ability to compile SCI1/1.1 scripts or no? I'm thinking no...
-
Ooh, does the room map go by the north south etc properties, actually look at the code, or is it defined separately? By the way, the new icons are looking pretty good too.
Right now it only works for games that define north/south/east/west rooms. KQ6 does for the most part, for example, but SQ5 does not. It wouldn't be too hard to scan the code for calls to the newRoom selector, but only if they directly pass a number e.g. newRoom(76), rather than a variable that came from somewhere else.
-
I was stuck working with two 256 View editors, one would not preserve or set the origin point and the other would screw up the palette by making all black colours white. I assume your editors don't have these problems? :D
I hope not! haha...
Is it also possible to match an imported background's palette to a pre-existing SCI palette instead of creating a new one? How does it currently work? Do the imported backgrounds automatically set aside the first 64 colours in the palette for sprites and simply use the remaining 192 only? That's how Sierra's backgrounds worked. Otherwise sprites will look wrong in-game.
Yes, matching the current palette is actually much easier (that functionality is built into windows). That's what I started with, and the results were generally terrible, so I thought it was necessary to create a palette from the image colors. I found some color quantization code on the web and integrated it into the program.
Right now it looks at which colors are "empty" in the global palette and uses those slots only (hence the view of Roger Wilco still looking ok in the image above). And yeah, like you said, the first 64 colors (and last color always white) are generally set in the global palette, leaving 191 free to use in the pics.
I'll likely offer a choice of options when pasting in an image:
- use only slots that are "unused" in the global palette (or any other palette of your choice)
- conform to an existing palette
- ??? not sure what else would be useful
Does/will this also have the ability to compile SCI1/1.1 scripts or no? I'm thinking no...
Not currently. SCI1 scripts are quite similar to SCI0 though (in fact, nearly identical), so it shouldn't be too much additional work (though surprisingly, at least one of the opcodes changed behavior). I still need to implement writing to the resource map for SCI1 though - the format changed slightly (though not as much as SCI1.1). Also, unless I created an entire template game for SCI1, I'd to support generating .sco files from compiled scripts - haven't looked into this yet. I'll think about this...
Note that the terms SCI1.0/SCI1.1 aren't very exact. The code, the resources, the resource map.... they can all be from one version or the other. For instance SQ1-VGA and SQ4 are both listed as SCI1 games. But SQ4 uses the SCI0 resource map format, and SQ1-VGA uses a slightly newer version.
Are there any "SCI1.1" improvements over "SCI1.0" that you consider important? It seems like most of the changes had to do with conserving heap memory (e.g. splitting script files into separate script and heap resources). Using the SQ4 or KQ5 interpreter would probably be the least effort... they use the same resource.map format as SCI0.
-
SCI1.1 supported sprite scaling, but I don't know if that matters for what you're looking for. Coloured cursors, generally, too. Though, KQ5 had them and it's only SCI1. Could be that blending of resource versions you mentioned at play there, I don't know.
Also, I don't know if it's SCI1.1-specific, but I believe those games also supported playing multiple sound files at once. I recall coming across many SQ5 sound resources that only sounded like pieces of a theme or portions of sound effects. I don't know if SCI1 was also capable of this or not. SCI0 definitely was not.
Regarding background palettes, is it possible to have a system of colour matching to an existing palette much like your SCI0 picture importer? To choose between dithering styles, nearest colour, etc? How about just copying the palette of the imported picture? (If it's a 256 colour palette)
-
Ooh, does the room map go by the north south etc properties, actually look at the code, or is it defined separately? By the way, the new icons are looking pretty good too.
Right now it only works for games that define north/south/east/west rooms. KQ6 does for the most part, for example, but SQ5 does not. It wouldn't be too hard to scan the code for calls to the newRoom selector, but only if they directly pass a number e.g. newRoom(76), rather than a variable that came from somewhere else.
Lol, noted. So what you're saying is, I'm SOL on this feature. No biggie, kind of figured I would be because of the way I call a new room and I haven't used the directional properties in forever.
-
Regarding background palettes, is it possible to have a system of colour matching to an existing palette much like your SCI0 picture importer? To choose between dithering styles, nearest colour, etc? How about just copying the palette of the imported picture? (If it's a 256 colour palette)
Yeah, that's possible.
Which image formats support palettes? (all of them?) I guess I'll have to see what I get out of the image loading library I'm using to see if the palette information is still intact. How would you propose handling images that use all 256 colors? Are there image editing programs that let you select which palette entries are used out of the 256? It's an area I'm not really familiar with...
Lol, noted. So what you're saying is, I'm SOL on this feature. No biggie, kind of figured I would be because of the way I call a new room and I haven't used the directional properties in forever.
I loaded up Black Cauldron, and sure enough, it doesn't work for that. It looks like you plop a number into a script variable, and then use that script variable in the call to newRoom?
-
Are there any "SCI1.1" improvements over "SCI1.0" that you consider important? It seems like most of the changes had to do with conserving heap memory (e.g. splitting script files into separate script and heap resources). Using the SQ4 or KQ5 interpreter would probably be the least effort... they use the same resource.map format as SCI0.
I think that this is the point of the addition on separate AUD resources and the audioDrv switch was added to the RESOURCE.CFG. Previously digital audio samples were just embedded in SOUND resources. Gumby and I were going through Brian's SCI VGA template game. Brian's work on reconstructing the scripts for a template game I believe were based on LSL5, an SCI1 game. It looks like these were mostly complete, but a VGA template game would still need to have the resources stripped down to the minimum required and all remaining game specific resources replaced. This should not be that great of a task given proper editors.
I guess that it does not hurt to now reveal that Gumby and I were working on a new SCI IDE in C#. It had been a while since much has been done with it and with a new version of Companion he will probably give up on it at this point. Gumby was doing the backend and I was doing the GUI.
It was also intended to duplicate the functions of the old Sierra Viewer but with drag&drop capabilities and mass resource extraction/export. It can already drag and drop some resources from the game archive and Windows Explorer. It has the ability to automatically generate an NSIS script for game publication. The NSIS scripts can be directly compiled into installers or the script can be loaded into the Script Editor for customization. The NSIS compiler can be invoked from the editor to compile the script. It can import a project from SCI Studio or SCI Companion.
From the GUI side I was being held up with the graphical editors, but I have managed to acquire the source from a number of other projects directly from those authors that will help. the FONT editor is now functional. I have a working AGI picture editor that allows you to easily move existing nodes after the fact. There is also now a functional View editor, but the backend for these two will need to be adapted from AGI to SCI.
From the backend Gumby had the resource management headed in a good direction. I am not sure if he got very far with the compiler yet.
The intent was to have a full featured IDE for a range of versions of SCI that could meet all needs of game development that could be maintained in C#. The inclusion of AGI development looks to be very doable. Enrico Rolfi gave me the source to his SCI tools, including FotoSCIhop for View and Picture editing from SCI1.1 and 2 resources.
Screenshots here (http://www.sierrahelp.com/Temp/SCIDev.html).
-
Lol, noted. So what you're saying is, I'm SOL on this feature. No biggie, kind of figured I would be because of the way I call a new room and I haven't used the directional properties in forever.
I loaded up Black Cauldron, and sure enough, it doesn't work for that. It looks like you plop a number into a script variable, and then use that script variable in the call to newRoom?
Yep, that's how I do it. That way I can use the unload resource block in an attempt to get every last bit of heap and hunk back at room change. It has come to be my standard practice. :P
-
I guess that it does not hurt to now reveal that Gumby and I were working on a new SCI IDE in C#. It had been a while since much has been done with it and with a new version of Companion he will probably give up on it at this point. Gumby was doing the backend and I was doing the GUI.
Looks like you guys got pretty far, looking at the screenshots. Honestly, I would have ported SCI Companion to C#, were it not for the fact that I'm:
- trying to brush up on my C++ skills, and
- the UI would need to be completely redone, and UI is a ton of work. I don't want to abandon all the work I put into this in SCI companion. Of course, had I known you were making a c# app...
It was also intended to duplicate the functions of the old Sierra Viewer but with drag&drop capabilities and mass resource extraction/export. It can already drag and drop some resources from the game archive and Windows Explorer. It has the ability to automatically generate an NSIS script for game publication. The NSIS scripts can be directly compiled into installers or the script can be loaded into the Script Editor for customization. The NSIS compiler can be invoked from the editor to compile the script. It can import a project from SCI Studio or SCI Companion.
From the GUI side I was being held up with the graphical editors, but I have managed to acquire the source from a number of other projects directly from those authors that will help. the FONT editor is now functional. I have a working AGI picture editor that allows you to easily move existing nodes after the fact. There is also now a functional View editor, but the backend for these two will need to be adapted from AGI to SCI.
From the backend Gumby had the resource management headed in a good direction. I am not sure if he got very far with the compiler yet.
The intent was to have a full featured IDE for a range of versions of SCI that could meet all needs of game development that could be maintained in C#. The inclusion of AGI development looks to be very doable. Enrico Rolfi gave me the source to his SCI tools, including FotoSCIhop for View and Picture editing from SCI1.1 and 2 resources.
Screenshots here (http://www.sierrahelp.com/Temp/SCIDev.html).
So what are the key additional features/design decisions you put into this? From what I gather:
- Mass resource extraction. I guess this just pops out all the resources from a sierra game into individual files? What's the main usage scenario here, to use them in fanmade games?
- NCIS scripts. I've never heard of this before, but I assume this is to make it easy to publish fanmade games? Like it packages everything up into an easy install, with DOSBox configured, etc..? Is this what was used for the betrayed alliance installer?
- It looks like there are some other project management features... including design docs and such.
Any other noticeable UI/feature improvements? From the screenshots, I see there is a ability to move existing vector lines... that seems like a nice feature.
-
I wanted this to be not just for game development, but also for creating patches and other fixes for existing games as well as to help archivist like for the Sierra Museum and the Art of Sierra. NewRisingSun created an number of patches for the many timer related bugs on the SCI1.1 era, but there are still other bugs he missed. Enrico Rolfi made some tools for translating SCI games into other languages. He did the GK2 Italian translation. I have made a few patches for Freddy Pharkas, where I have corrected defects in a few view resources. There were also a number of the audio resources that needed to be equalized. These are included with my FPFP installer (http://sierrahelp.com/Patches-Updates/NewSierraInstallers.html#FPFP). I want to include some basic tools for such efforts. The IDE does include a hex editor to this end. A script disassembler would be a great addition for such purposes.
Brandon Klassen of the Sierra Museum and the Art of Sierra has been needing an easier way to access resources in the SCI archives. SV only lets you extract or export resources one at a time.
But it is not just for extraction. I want to be able to add resources to a game by simply dropping them into the project explorer. Being able to export a picture resource to work with it in an external image editor and then reimport into the game would be great for SCI1 and later games. For a new SCI+ game a background artist could use the old Sierra technique of scanning hand painted backgrounds and dropping the lot of them into the project explorer
NSIS (http://nsis.sourceforge.net/Main_Page) is one of the standard installer packages that is used for quite a few companies. And yes, it is what I used for the installer for Betrayed Alliance. It is what I have used for all of my installers (http://sierrahelp.com/Patches-Updates/NewSierraInstallers.html). I also used it for my installers for the Sunlight Games rerelease of Gold Rush! (http://www.sunlight-games.com/en/?nav=detail&game=Gold+Rush!+Classic&sys=pc&PHPSESSID=49c991ab3c9b6904b773e0865e5b2503). The scripting language has been described as a cross between PHP and assembly. It is extremely powerful and flexible. Most of my installers are for old DOS games and automate setting them up to run in DOSBox.
There are a number of features that I did not mention. The debug feature will automatically run the game directly from the IDE using a debug build of DOSBox. I have incorporated a few wizards, like a new game wizard that prompts the user for things like a game name, which template he wants to use (the SCI Studio, Cloudee's PnC template or one that uses Gumby's sciAudio of hopefully SCI1, If we can add support for later versions of SCI). The wizard will then copy the right template files to new project's folder and edit the scripts to add the game's name. The IDE is fairly customizable. It also includes a launch bar to the right of the main form's toolbar that you can drag and drop programs or shortcuts to external tools, websites etc.
The game's settings file is in XML and the import function will parse the game.ini from a Studio or Companion project to XML. I started the GUI with saving program settings to the Registry, but have been migrating them to XML.
I have been updating the abandoned Visual AGI, an old IDE in C# that was started a number of years ago for the authors to learn dotNET. I was able to fairly easily fold this into Developer so it can now load AGI games and open & edit AGI view and picture resources.
We are not ready to publicly release it, but send me PM if you want to take a look at it.
-
Well it sounds like you're targeting slightly different scenarios (more modding/patching than building games from scratch?), so I wouldn't want you to abandon this project.
It's possible I'll be able to structure the SCI Companion code so that lower level resource-manipulation stuff is in a separate library that could potentially be used by your project sometime in the future. That might be unrealistic though.
As an aside, does anyone know why later Sierra games had so many resources in patch files instead of in the resource.map? Like for instance, Space Quest 5 has about 40 views (v56 files) in the game folder. Are these really just patches that shipped afterwards? Or were they there from the start? Or do I have some "hacked" version of SQ5?
-
It is definitely intended for game creation, too, just that the scope goes beyond.
Are you using manged or unmanged code? It is a little more involved using unmanged in C#. How hard would it be to port your script disassembler to C#?
That is normal for SQ5.
I suspect that the separate patch files had more to do with the increasingly complexity of the games made for more bugs. Many bugs would have not been revealed until the last moment (some not until after the initial release). In the case of SQ5 many of those were for localization purposes. The patches were just dropped in at the last moment or repackaged for a 2nd release. Otherwise the installation package would have had to be completely redone. By repacking the patches into the archive they would have had to resplit the resource archive and possibly alter the the concatenation part of the install script. A patch file requires no alteration of the install.scr file, just drop the patch in the master copy. the install scripts used a wild card (copy %2:*.*) for the file copy part to copy all of the files from the diskette. The only alteration that might have been required would have been if the patch files added and extra disk to the distribution package. Even that would be a smaller, quicker edit than having to alter the concatenation part of the script. Remember, there was a lot of pressure to get product out of the door.
-
Ooohhhh I am so psyched for this! I can finally properly continue working on SQ1Retro. I was stuck working with two 256 View editors, one would not preserve or set the origin point and the other would screw up the palette by making all black colours white. I assume your editors don't have these problems? :D
Is it also possible to match an imported background's palette to a pre-existing SCI palette instead of creating a new one? How does it currently work? Do the imported backgrounds automatically set aside the first 64 colours in the palette for sprites and simply use the remaining 192 only? That's how Sierra's backgrounds worked. Otherwise sprites will look wrong in-game.
Do you have any information how people generally edit palettized images? What common file formats are used to save these images? (For instance, I don't think jpeg support palettes, right?). Are there separate palette files that are commonly used?
-
You would never want to use JPG or any lossy format. BMP or GIF would be the obvious choice. TIF and PNG would also be OK. BMP can support 32bit color and TIF & PNG 48bit. GIF only 256 colors, which is fine for SCI1. The palette for GIF is specified in the file. TIF & PNG can have the palette embedded in the file. There is the Microsoft PAL format for an external file, which I believe is simply an XML. This is a bit different from the SCI PAL resource. Another member here (Aftertaste) wrote a utility in C# that extracts the palette from a view or picture resource and could convert between SCI and Microsoft. He has been more active on my private developers forum.
It does not support anything under SCI.1, but you might also want to take a look at Enrico Rolfi's FotoSCIhop (C++) code.
-
Generally the best way to work with 8-bit color games and palettes would be to use a file format with an 8-bit palette itself. Most old game programs/editors use 8-bit BMPs for this. But I suppose any 8-bit picture format would do. But the logistics of how all that would work is beyond me. They probably each have their own way of storing the palette.
I once tried converting a BMP to a SCI1 picture manually via hex. Obviously I was doomed to failure, but I did notice that the palette header portion was mostly the same; R, G, B values for each bit separated by a null bit or some other random character (can't remember which used what between SCI1 PIC and BMP). I exported a background as a BMP with SCI Viewer and loaded it into PSP5 and fooled around with the colour sliders to make the Deltaur ship in SQ1VGA blue instead of green. But when I went to copy the palette data from my altered BMP to the original SCI PIC in a hex editor the picture came out red ingame instead of blue. So the RGB values must be in an inverted order for every colour which is weird (like BGR instead or something).
As far as images using an entire palette instead of the last 192 (minus the last one), I say leave it to import as is and let the developer plan ahead for that. For instance, creating a BMP that already has the first 64 and the 256th colours set ahead of time. What would be welcome I suppose, though, would be to create some kind of ability to convert an image's palette to condense it to 192 of the most used colours and convert the rest to the nearest matches of what's left over. Again, maybe with other options like dithering, nearest, etc like SCI Comp currently has for importing bitmaps.
Again, I have no idea of the logistics of any of this...
-
Yeah, I was forgetting about part of the palette being reserved.
-
Generally the best way to work with 8-bit color games and palettes would be to use a file format with an 8-bit palette itself. Most old game programs/editors use 8-bit BMPs for this. But I suppose any 8-bit picture format would do. But the logistics of how all that would work is beyond me. They probably each have their own way of storing the palette.
I once tried converting a BMP to a SCI1 picture manually via hex. Obviously I was doomed to failure, but I did notice that the palette header portion was mostly the same; R, G, B values for each bit separated by a null bit or some other random character (can't remember which used what between SCI1 PIC and BMP). I exported a background as a BMP with SCI Viewer and loaded it into PSP5 and fooled around with the colour sliders to make the Deltaur ship in SQ1VGA blue instead of green. But when I went to copy the palette data from my altered BMP to the original SCI PIC in a hex editor the picture came out red ingame instead of blue. So the RGB values must be in an inverted order for every colour which is weird (like BGR instead or something).
Yeah, I've just tested loading some 8 bit images, and the palettes are there and intact, so it should be trivial to extract (I'm just using gdiplus to load them, so I don't need to worry about any specific formats - I've tested it with 8 bit .gif and .bmp so far). The main work will be in giving the user options when they import it. I figure:
- import with palette exactly as is (ignoring which slots are "reserved")
- import with palette indices to the slots NOT used by global palette 999 (generally index 64 to 254) (if there is room). This would be the most common option.
- import with palette shrunk to fit to the free slots 64-254 (if no room), either by recalculating from scratch, or rejecting least commonly used palette colors and replacing them with the closest remaining ones
- remap to the current palette in the pic (basically throwing away the imported palette and generating anew)
- for images without a palette (e.g. 24/32 bit images), either
- generate custom palette based on free slots (64-254)
- generate custom palette ignoring global palette
- map colors to current pic palette
Whew!
Are you using manged or unmanged code? It is a little more involved using unmanged in C#. How hard would it be to port your script disassembler to C#?
It's in native code. It would be a pretty large chunk of work to port it to C#. But if it's in its own library, it wouldn't be hard to make calls to it from managed code if the API layer is "thin" (i.e. just give it the game folder, a script #, and a place to put the resulting file). But I think there are already simpler tools out there that do that?
With regards to the decompiler (not disassembler), it's coming along, though I haven't done too much work on it lately. However, I think I'm going to introduce a new piece of syntax for the "SCI Studio" syntax to support the ternary operator. This is used extensively in the scripts I've decompiled so far. You can sort of emulate it with if/else statements, but it's less than ideal. So, in C++, this is:
gEgo.view = (someVar == someValue) ? 1 : 2;
And in the SCI studio syntax, I'm proposing:
(send gEgo:view(? (== someVar someValue) 1 2))
Currently in SCI Studio syntax, you'd need to use:
(if (== someVar someValue)
(send gEgo:view(1))
)
(else
(send gEgo:view(2))
)
I tried cramming if/else statements directly into the assignment, but I couldn't get something that compiled with SCI Studio (plus it looks ugly). Expanding it out into the above form isn't really feasible either, as they often part of statements that use multiple selectors on the same receiver.
edit..... ok, it does look like SCI Studio permits this (but SCI Companion barfs on it!). Not sure why I came to a different conclusion before... maybe there are some scenarios where it doesn't work? Anyway, it looks like this:
(send gEgo:view( (if (== someVar someValue) 1) (else 2) ))
-
I understand that you are not doing it in C#. I was asking if managed C++ because it is easier to make calls from C# to managed C++ than unmanaged. I didn't think you were, but just thought I would ask.
With regards to the decompiler (not disassembler), it's coming along, though I haven't done too much work on it lately.
Fantastic. And I was under the impression that it was just a disassembler. This would be a huge boon for creating game patches.
-
Managed c++ would be like the worst of both worlds, haha.
I found an interesting website that talks about the original SCI syntax:
http://www.scriptinterpreter.com/syntax
It of course has the notorious code snippet from PQ Swat, but also a discussion of the syntax's similarity to Smalltalk and LISP, and how Brian's SCI Studio syntax differs.
I'm not sure who owns that website, there's no contact information.
In working on the decompiler though, I've come across patterns that indicate certain language features. There was the ternary operator that I mentioned previously, but also another pattern I came across today that tripped up my decompiler. It evaluates an expression, and if it's true it performs an action on the result of that expression. In this case it was just checking if an object was null, and if not it disposed it:
(if (global_0019)
(send <result-of-above-expression>:dispose())
)
Now, in SCI Studio syntax you could express this as :
(if (global_0019)
(send global_0019:dispose())
)
However, if the conditional expression in the if statement was something that caused side effects - such as calling another function - then the above two things result in different behavior:
(if (SomeFunction())
(send <result-of-above-expression>:dispose())
)
vs
(if (SomeFunction())
(send SomeFunction():dispose())
)
The latter ends up calling SomeFunction twice, whereas the first only calls it once. There's no way to do this directly in SCI Syntax, you'd have to add a temp var to avoid the function being called a second time:
(= temp0 SomeFunction())
(if (temp0)
(send temp0:dispose())
)
But the way the disassembly is, it suggests the original syntax had support for this. Without support for this, when decompiling I need to use an additional temp var (which complicates things), or verify that the conditional expression has no side effects, and repeat it (which is also complicated)..
-
Yeah, that is Lance Ewing (http://sciprogramming.com/community/index.php?action=profile;u=95)'s SCI site. He is the author of the original AGI PicEdit. His other site is agifans (http://www.agifans.com/). Unfortunately he has not posted here is some time. A couple of relevant threads of his:
Original SCI syntax (http://sciprogramming.com/community/index.php?topic=372.0)
SCI Decompiler? (http://sciprogramming.com/community/index.php?topic=372.0)
BTW, when you are looking a scripts to disassemble or decompile, are us using ones from games compiles with Studio/Companion or official games compiled with Sierra's tools? Not sure if that would make much of a difference in teasing this apart.
-
BTW, when you are looking a scripts to disassemble or decompile, are us using ones from games compiles with Studio/Companion or official games compiled with Sierra's tools? Not sure if that would make much of a difference in teasing this apart.
I'm looking at official games. There isn't much to learn from decompiling games made with Studio/Companion.
-
It could be useful when you at the point of testing the decompiler to compare it to the original source, but I guess you are not at that point, yet.
-
Yeah, I've just tested loading some 8 bit images, and the palettes are there and intact, so it should be trivial to extract (I'm just using gdiplus to load them, so I don't need to worry about any specific formats - I've tested it with 8 bit .gif and .bmp so far).
Oh good! I guess things are much less complicated with modern programming. I keep trying to do things manually. Maybe I don't have to? I feel like if I want to learn everything I have to learn to do all these complicated things...
The main work will be in giving the user options when they import it. I figure:
- import with palette exactly as is (ignoring which slots are "reserved")
- import with palette indices to the slots NOT used by global palette 999 (generally index 64 to 254) (if there is room). This would be the most common option.
- import with palette shrunk to fit to the free slots 64-254 (if no room), either by recalculating from scratch, or rejecting least commonly used palette colors and replacing them with the closest remaining ones
- remap to the current palette in the pic (basically throwing away the imported palette and generating anew)
- for images without a palette (e.g. 24/32 bit images), either
- generate custom palette based on free slots (64-254)
- generate custom palette ignoring global palette
- map colors to current pic palette
Whew!
That looks great. I can think of a couple other conditions but they probably aren't necessary at all. After experimenting a bit we can probably tweak some things or add some features I imagine? I was going to suggest some advanced features like what SCIComp currently has for importing backgrounds for 16-color vector format, but I figure if anyone needs anything more robust than what you have here they could edit an image beforehand in PSP or PhotoShop, which will probably be happening anyway. Nice to know these things are possible! I'm so excited for this...
-
Just a little update. I have import and export of palettized bitmap images working for pics.
Importing an image:
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp4.jpg)
An exported pic background in photoshop, with accompanying palette:
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp3.png)
There's definitely some weirdness with the palettes on import and export. I support 4 file formats right now: png, tif, bmp and gif. Only bmp works perfectly end-to-end. tif and gif end up always being 256-color palettes, even if less entries are used (i.e. I export a gif of the pic background with a palette of 160 colors, but when loading it into photoshop, all 256 colors are marked as being used, the remaining just filled with black). Not a huge issue. Png does not work properly yet, I'm not sure where the problem is.
-
It seems that most of the SCI1/SCI1.1 tools default to BMP for conversion or import. I always assumed that it was because of the fewest problems. Could the issue with PNG be because of its compression?
-
Nice!
I didn't think it was possible to have an image palette between 16-256 anyway. There'd have to be some kind of entry. But I know so little about it myself.
-
It seems that most of the SCI1/SCI1.1 tools default to BMP for conversion or import. I always assumed that it was because of the fewest problems. Could the issue with PNG be because of its compression?
It's possible, but it's probably more like it's just due to the gdiplus encoder for pngs that doesn't handle writing palettes correctly. I forget, but I think I was able to make a palettized png in photoshop and loading it into SCI Companion ok.
I didn't think it was possible to have an image palette between 16-256 anyway. There'd have to be some kind of entry. But I know so little about it myself.
Yes, it's possible. Perhaps tif doesn't support that though (but I'm sure .gif does). In any case, if the image claims "256 colors", the fallback is just to scan the image data for all the palette indices that are actually used, and reconstruct a smaller palette from that.
Right now I'm working on implementing saving to the SCI1 resource map format. (I've already got SCI1 view and pic saving working, but only to the individual patch files).
-
Nice! Great progress!
-
A bit of a wrench in saving to the SCI1+ resource map.
The SCI0 engine searched for resources by scanning linearly through the resource.map file. This made it easy to put the latest versions of a resource first, and yet still keep older versions in the resource file... kind of like a series of backups.
SCI1 requires that entries are sorted by resource number and package number, and then does a binary search to find the resource to use. This means it could "come at" the resource from either direction, and we can't reliably place the most recent resources first. This means there is no inherent convenient "backup" mechanism in the resource map files.
So either that feature gets lost, or I come up with some alternative. Possibly I could move resources that got replaced into a "backup" resource map.
-
I never keep backups anyway in my SCI0 games. I delete the extras as soon as I save.
-
Ditto. Perhaps just add an option to save the old one in a backup folder as a raw resource? It could just do an automatic rename if there is yet an earlier version by adding a time stamp to the resource's name, i.e. ".\SRC\Backup\VIEW-2015-03-22.025".
-
Interesting... good to know people's habits. I always like to have a few backups around in some cases. Of course, if you're serious about developing a game, you should be using some kind of version control system anyway...
Another thing is that saving to the resource.map/resource.001 might become an expensive (time-wise) thing because the files tend to be a lot larger, and I basically need to read everything in and write everything out again with new things added. I'm not yet sure if it will be noticeable or not. If it is, a possibility is to save resources to individual files by default, and then offer a "package" function that builds everything into resource.map/resource.xxx again (and then as a bonus, you'll still have one backup in the resource.map before you "package" everything again - and the game uses the newest one, since it always prefers individual files over the stuff in resource.map). I've already made changes to "merge" both the items in the resource.map and the individual files into a single view in SCI Companion (since the newer games seem to have so many patch files):
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp5.png)
-
Sounds a bit like a feature in Developer we have that scans the archive when opening to check it against the entries in the project's XML configuration file to resync the listed resources with what is actually in the archive. The extra time required only becomes noticeable with a large game like Betrayed Alliance. At least with this feature you only have to put up with it when opening the game, not every time you save a resource.
Here is a thought; what if the resource/map handling was moved to another thread so so that it could be done in the background? Might not speed it up, but it would make it not so noticeable.
-
Great ideas!
-
Of course, if you're serious about developing a game, you should be using some kind of version control system anyway...
I'm all for saving to individual files, which behaves more nicely with version control (I'd use either Git or Mercurial - would be awesome to have integration with the IDE but really not mandatory), and separate "Package" function for unversioned Resource bundles.
Anyway, remember: "Save early, save often!" ;)
-
Reminds me of the old AGIVS (http://agiwiki.sierrahelp.com/index.php?title=AGIVS) program for AGI development.
-
A little update...
I've been working mostly on the decompiler, which is a real head game. But to take a break, I try to fill in missing pieces of functionality. I can save successfully to SCI1.0 view and pic formats, but today I got views in SCI 1.1 working (KQ6, SQ5, etc...). SCI 1.1 has a significantly different format for view resources, with a bunch of extra info that even scummvm doesn't know about (according to the source code that loads the views). That's not a problem when loading the views, but I needed to figure out what to put in that extra data when saving so that the game thinks it's a legit resource. I'm not claiming to have figured everything out, but I did finally succeed in modifying a SQ5 view, saving it to the resource package and have it appear in the game (replaced one of the ships with a Cylon raider):
(http://www.icefallgames.com/wp-content/uploads/2015/03/SCIComp6.jpg)
As for the decompiler, it was "90% functional", which means it did a good job on 90% of the code, which in practice means it's only successful at producing a completely accurate decompiled full script in maybe 5-10% of the cases. I was using a kind of haphazard method for determining code branching/loop structures, which turns out not to be robust enough. So I'm taking a step back and developing a more rigorous method based on "real" decompiler theory.
When it's good enough, I plan on implementing a way to supply variable names and such via an .ini file. That way when you figure out what procedure #5 in script #32 actually does, you can put a meaning name for it in the .ini file and redo the decompilation, and it will put in the new name you supplied. Same for variable names, etc...
-
Nice progress with the Views.
Is the decompiler just for SCI0 or will you add support for later versions. I suppose when dealing with SCI1.1's HEP resources it would need to decompile those as well.
-
The decompiler works for any of the versions. When I load a sci1.1 script resource, I just merge the hep in. Everything in SCI Companion works on an abstraction that lies above the raw script resources.
The only additional complexity for SCI 1.1 that I haven't tackled yet is writing out the script/hep resources (since the resource data is organized pretty differently). Of course that's more related to compilation.
Overall, the actual bytecode is very similar between sci0 and sci1.1. There are a few more kernel functions, and the behavior of one of the opcodes changed between sci0 and sci1.0, but that's about it.
-
That's great! Exciting news all around! This really seems like the goldmine of features we've been dreaming about since Brian promised SCI Studio VGA! Even if it doesn't all work out exactly as we all hope, thank you for trying. Your work is very much appreciated!
-
Troflip, if I haven't said it yet I'll say it now: thank you for your efforts on this, it's impressive what you've put together so far on this.
-
Agreed. Thanks, we have been needing this for sometime now.
-
Hi all. I'm back...
Yeah, that is Lance Ewing (http://sciprogramming.com/community/index.php?action=profile;u=95)'s SCI site. He is the author of the original AGI PicEdit. His other site is agifans (http://www.agifans.com/). Unfortunately he has not posted here is some time.
Yes, it is my site. I had big plans to fill in all those empty pages and work out how to decompile the code. It sounds like troflip is doing a great job with that though.
I seem to have so many ideas for projects and not enough time to devote fully to any one of them. I entered the js13kgames contest last year, which was a laugh. A great learning experience in JS and CSS. I ran out of time on that and only finished about half of what I'd envisioned. I still had about 4K of space left to use. That's massive!
I've also picked up the Java Picedit code a few times but have yet to release another 1.3 milestone. I migrated it to github earlier this week after Google told me they'd be removing the Google code project at some point.
-
Another question, do you plan on implementing a built-in palette editor? Does GDIplus provide functionality to edit colour values with the Windows standard colour wheel? That might be handy, especially for creating custom global colours (the first 64).
-
Yes, I plan to. Shouldn't be too difficult.
I'm only using Gdiplus to load/save images from files. One they're in memory I can do whatever I want with them.
The challenging part for me is understanding all the ways palettes are used in SCI. Like, what typical patterns are, and how the pic or view palettes are combined with the global palette. And when all the other palettes are used. Like, most SCI 1.1 games have tons of palette resources. But pics have their own built in palettes for the most part - so when do these other palettes get used? (Like SQ5, for instance, has 50 palette resources. Judging by the numbers they mostly seem to correspond to pic numbers).
And I don't fully understand the extra number that's included with each palette color. I believe they are used for letting one palette's color override another's, but I'm not sure of the exact algorithm. Each palette color either has a 0, 1 or 3 associated with it. Since I don't know exactly what that is used for, it's hard to know how to expose it to the user.
-
Hmmm interesting.
Oh that reminds me! What about palette cycling? I know that SCI Viewer has a method of selecting which colours in the palette of an image to cycle through and at what speed for previewing. This might be easier to preview in Companion itself, but what about actual in-game functionality? Would you know if this is somehow related to the way QFG1VGA changes in-game screen palettes to correspond to day/dusk/night/dawn colours? Is that some kind of gradual palette cycling? Well, I guess it wouldn't be exactly the same thing because colour cycling cycles through a specific few colours in the palette, while the day/night transitions seem to be a function of changing the value of each colour in the entire palette gradually. For screen fadeouts/fadeins it just darkens each colour until every colour is black. I think I've seen examples in-game where each colour is brightened to white also...I think. The day/night transitions are probably a matter of darkening and lightening each colour slightly while adding more blue or red values depending on whether it's night or day.
I'm completely guessing here.
-
Is there anything that you can glean from Enrico Rolfi's FotoSCIhop source?
-
Oh that reminds me! What about palette cycling? I know that SCI Viewer has a method of selecting which colours in the palette of an image to cycle through and at what speed for previewing.
Hmm, I don't see any way to animate palettes in SCI Viewer. You can choose which palette to preview an image with, but that's about it.
I think it'll become a little clearer how palettes are used once we have some decompiled scripts from various games.
Is there anything that you can glean from Enrico Rolfi's FotoSCIhop source?
Maybe I'm just bad at finding things, but I've never seen a download for FotoSCIhop or its source code. The only downloads on his website are for TraduSCI. Even though FotoSCIhop is mentioned, it's like he deleted all traces of the actual program?
-
You sure you have the latest released version? Not visible is the animation speed settings which I believe is global for sprite animations as well in SCI Viewer's settings menu.
-
Ah, no, I must have an older version! I have the version I got from here: http://sciwiki.sierrahelp.com/index.php?title=SCI_Resource_Utilities#Sierra_Resource_Viewer
Do you know where there's a newer version for download?
There's still a bunch of data I'm not sure of in the palette resources.. maybe that's information regarding color cycling? I'll have to look through the Scumm source code again...
edit: ok, I found the version you have. It might be an older version? Not sure, it doesn't have a version number. I though the color cycling values were taken from the resource itself, but it looks like you have to enter them manually?
-
Hmm, I don't see any way to animate palettes in SCI Viewer. You can choose which palette to preview an image with, but that's about it.
I have noticed that SV does not always seem to show any differences between the visual and and cels, but it does wit some games like GK1 and PQ4. From the looks of it it was just to animate part of the background without having to use a view resource. The embedded palette does not seem to change the embedded palette. Of course these are SCI32 games. No idea if SV simply does not handle the ones from SCI1 - 1.1 or if it was not yet properly implemented in the earlier interpreters. I would guess the former rather than the latter. The latest version of SV should be the one on the Wiki. It does not have a version number. Version 1 seems to be an earlier version that does not also support AGI games.
Is there anything that you can glean from Enrico Rolfi's FotoSCIhop source?
Maybe I'm just bad at finding things, but I've never seen a download for FotoSCIhop or its source code. The only downloads on his website are for TraduSCI. Even though FotoSCIhop is mentioned, it's like he deleted all traces of the actual program?
TraduSCI is an SCI translation package that also includes a resource dumper. While SCIaMano is used to translate TEX resources. It includes FotoSCIhop to edit view and pic resources for translation of graphics, like signs, etc. Unfortunately it only supports SCI1.1 to SCI32. While SCIaMano was developed in an old version of Dev C++, FotoSCIhop was originally developed in VC and ported to Dev C++. I was able to easily port it back to VC. You can either grab what is on his site or I can give you a link to what I already ported back to VC.
-
edit: ok, I found the version you have. It might be an older version? Not sure, it doesn't have a version number. I though the color cycling values were taken from the resource itself, but it looks like you have to enter them manually?
Yeah, you enter them manually. I had to guess until I found the correct values. Though, if you know the exact value of the beginning of each row of colours it would be easier, plus you can see easily which sequence of colour gradients are meant to be cycled. That would suggest to me that that information is not embedded in the palette file but manually set in the scripts somehow?
EDIT: Just searching through SQ5's resources, I noticed that there are a couple of all white palettes (except for the 0 and 255 entries which are black). Perhaps the fade to black/white transitions are done by gradually fading the colour values of one palette to their counterpart values in another palette. Then there are scenes like Bea in the cryochamber (Pic #47) where only she transitions to a shade of blue or red inside the chamber depending on what setting you set for that puzzle. The equivalent palettes (471 and 472) have all the exact colours except for the section inside the chamber which changes (colours 64-151). There were some really clever artists at Sierra who utilized colour cycling and palette transitioning very effectively. You can do some neat tricks with it.
Incidentally, the naming conventions of these palettes are clearly not an accident. Palette 47 corresponds to Pic 47 perfectly (the crychamber pic), but the red and blue variants are palettes 471 and 472 (as in 47 A and 47 B, distinct from the regular 47, to make it easier to use when scripting), which don't correspond to a Pic 471 or 472, which don't exist (probably intentionally, which suggests that maybe other Sierra games numbered their resources in a similar manner). This might shed some light on why there are so many different palettes. They're used for transitioning.
Though, most picture editors nowadays don't come with functions for working with 8-bit palettes. The only one I can think of is Deluxe Paint for DOS which catered to it rather well, and which Sierra artists used themselves (according to Mark Crowe in the SQ Commentary 2GFA Podcasts). I still am not sure how they concentrated certain colour values to specific portions of the palette (for instance the colour values inside the cryochamber). Maybe Deluxe Paint has further functions I haven't discovered to that end...
-
Though, most picture editors nowadays don't come with functions for working with 8-bit palettes.
Corel PHOTO-PAINT does quite nicely.
-
Can it isolate the colorus used at certain portions of the image to a certain portion of the palette?
-
Should be able to get that effect with use of a mask.
-
Ah thank you!
-
Yeah, you enter them manually. I had to guess until I found the correct values. Though, if you know the exact value of the beginning of each row of colours it would be easier, plus you can see easily which sequence of colour gradients are meant to be cycled. That would suggest to me that that information is not embedded in the palette file but manually set in the scripts somehow?
Indeed. These are kernel calls that the scripts call (in a doit method of a view or a room) manually on each cycle. There is also a kernel call that loads an entirely new palette.
EDIT: Just searching through SQ5's resources, I noticed that there are a couple of all white palettes (except for the 0 and 255 entries which are black). Perhaps the fade to black/white transitions are done by gradually fading the colour values of one palette to their counterpart values in another palette.
This is a new feature in SCI 1.1, unfortunately (troflip isn't targeting that as I understand it?). Another new feature in SCI1.1 is that palette resources can contain smaller ranges of colors; in SCI1 all palettes contain 256 colors. The new format is much easier to work with from a collaboration point of view (and also coding). I guess SV just shows the resource as if it contained all the colors. Yes, and color 0 and 255 have special status in SCI.
-
This is a new feature in SCI 1.1, unfortunately (troflip isn't targeting that as I understand it?).
I plan to, but I'm focusing on SCI1.0 first, I guess?
This shows the feature set as it is currently:
https://docs.google.com/spreadsheets/d/11vR1Yu_go9ttglAxQdnfw4BWhSdg1Z-fZLgiJT_-9L4/edit?usp=sharing
Another new feature in SCI1.1 is that palette resources can contain smaller ranges of colors; in SCI1 all palettes contain 256 colors. The new format is much easier to work with from a collaboration point of view (and also coding). I guess SV just shows the resource as if it contained all the colors. Yes, and color 0 and 255 have special status in SCI.
Isn't this really just a difference in the format in which is it saved, to save some space? SCI1 always saves 256 colors, but some of them are marked with '0' in the 4 unused byte of the color entry, indicating they are unused. Whereas SCI1.1 resource have the ability to save a range of palette colors if the used entries are contiguous. Functionally it seems identical, just a more efficient storage format.
What special status do 0 and 255 have? 0 is always black, and 255 is always white?
-
255 is definitely not always white. Half the palettes in SQ5 have 255 as black. Not sure why, though.
-
255 is definitely not always white. Half the palettes in SQ5 have 255 as black. Not sure why, though.
Are you using SCI Viewer? It shows many of them as black, but they are marked as "unused" in the actual palette. SCI Companion will show which ones are used vs unused (I think SCI Studio VGA showed this too). I can't find any which are used and not white for index 255.
-
Ah. No, SCI Viewer doesn't show which are used and which aren't. But you're probably right on. Maybe it's something old used for the black and white cursors? I do recall the 3-colour cursors (black, white, and grey) from some SCI1 games would quickly fade the grey parts to black and back and forth. Probably the work of palette transitioning, while the white portions stay white (colour 255)? Maybe they're just plain used by the interpreter for debug windows and such. Text, windows, etc. I don't know.
-
Looks like 255 is supposed to be transparent. By default, that will be white. But if a pic is drawn on top of another pic, the parts with 255 show through (judging from pic 175, which I think goes on top of pic 75)
-
Ah that makes sense.
-
I'm just recalling my New Years Resolution of using SCI on my resume to help land a job.
I am looking forward to a working version of this!
-
I finally got around to putting the project (Visual Studio 2013) on github, here is the link:
https://github.com/icefallgames/SCICompanion
I haven't yet checked if I can sync and build from another machine (i.e. there might be files missing), but the source code is all there.
Things are still in a very beta phase, of course. I'll probably be submitted changes every few days.
-
:D :D
-
It is not MFC dependent is it?
-
It is, it's always used MFC for the UI
-
The reason that I asked is that the use of MFC rules out the use of the Express version of VS.
-
Oh yes, that's true. There's no reason to use Express now though, since Visual Studio Community Edition 2013 is free (and SCI Companion requires the c++11 features implemented in VS 2013).
MS also deprecated the non-unicode MFC libraries for VS 2013 (http://blogs.msdn.com/b/vcblog/archive/2013/07/08/mfc-support-for-mbcs-deprecated-in-visual-studio-2013.aspx?PageIndex=3), so to build you need to also download the MBCS MFC libraries here: http://go.microsoft.com/?linkid=9832071
(I suppose I could at some point switch SCI Companion to unicode, but given that Sierra games aren't unicode, it wouldn't be trivial to make this switch).
-
Seems like I heard that MS was starting to deprecate MFC in general.
I'm still using 2010 VS Express. I hadn't moved on as there seemed to be an emphasis on "apps" for the Windows Store. I was halfway waiting for the version that would be more oriented to Windows 10 before upgrading. Though I have heard of a couple of features in the latest C# that would be nice. I work primarily C#. My dabblings in C++ are mostly just to create some GDFs, compile newer versions of certain open source projects or to make some minor tweaks. The lack of MFC is something that has stymied me more than once in the past. I have not been able to do much with Soundbox because it was done with MFC. We had just wanted to add an argument to directly open a SOUND resource by calling Soundbox.
I have not done anything with MFC, but for UIs, how much of an advantage is it over simply doing a Win Forms application?
-
I'd probably rather use winforms, but for a strictly native code app there aren't really any good alternatives to MFC. So it's not like it has "advantages" - it's old and crufty - but it's just what you use for native c++ on windows desktop.
-
My VS2010 has WinForms for C++, at least the designer. The generated script ends up as a header file as opposed to C#'s partial classes.
-
That's c++/CLI, not standard c++. It's still managed code (or at least all the winforms stuff will still be managed code).
c++/CLI is intended mainly for managed/native interop scenarios. So yes, using winforms through that could be a stepping stone to transforming SCI Companion into a fully managed code application. But I'd rather just go full C# if that happened. MS doesn't recommend writing new apps in C++/CLI, and apparently the winforms C++ template has been removed from VS 2012 and newer.
-
Here is some sample output from the decompiler, for a few of the rooms/scripts in Space Quest 5.
I notice some of the kernels are incorrect. For instance, room 110 (the opening room) transitions palettes, and it ends up being identified as Joystick kernel call. I know various kernel functions moved/changed between SCI versions, but looking at the SCUMMVM source code, there was never any palette-related kernels that were in the Joystick slot (0x6d), so it's a bit strange.
Anyway, I'll need to provide some kind of config file to allow for differences in kernel functions in different versions.
This is a lot more powerful that Brian's decompiler was going to be, since it does control flow analysis and attempts to recover higher level constructs like if/else, compound conditions, loops and switch statements. There are still some flow control structures I can't identify though, so I'll have to leave those odd functions as assembly.
-
Nice! This is fascinating stuff! I'm going to have to mull through these. I'm excited to peruse through Sierra's scripts when this is completed. Great work and progress so far, troflip! Awesome awesome.
-
One weird thing you'll notice is that there are a bunch of class names that start the init method of the SQ5 game class (in main script). I'm guessing "using" the class like with (without doing anything with it) perhaps loaded the scripts into memory or something? That way there wouldn't be any pauses when that code was actually needed later on and the game needed to load the script from the relatively slow hard drives of the time.
-
Amazing job troflip!
-
I'm taking a short break from the decompiler work, and today I implemented some very basic sound effect support (currently only tested with the SQ5 interpreter). You can drag a wav file into SCI Companion, and assuming it's the right format (uncompressed, 8 or 16 bit), it will add it to the game as an audio resource. I managed to test this successfully by replacing a sound effect in SQ5.
It currently only supports SCI versions that have separate audio resources (as opposed to a digital track embedded in the midi snd resources, which I think even some SCI0 games support?).
Is anyone familiar with the logic SCI uses to play these audio resources? It looks like there is often a sound resource equivalent for an audio resource... (e.g. midi sound resource 109 kind of sounds like audio resource 109) - but not always. Lots of midi resources don't have sound effect equivalents of course - but the reverse is often true too. And some equivalents don't sound alike at all.
-
There weren't too many of the games that used the embedded wav in the SOUND resource. Mostly just the SCI01 games (KQ1SCI, KQ1SCI demo, SQ3, Some versions of LSL3, QfG2 and QfG2 Demo) and the early SCI1 games (KQ5 floppy, LSLVGA Demo, Mixed-Up Fairy Tales VGA, 1990 XMas Card EGA & VGA, SQ4 floppy). There is the old AddWav that appended a wav file into a SOUND resource for those. That said, is it really worth the effort to add support for these appended resources if there is support for later SCI1 and SCI1.1?
-
Yes. Yes it is. :P What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...
As far as how Sierra implemented pairing of MIDI/digital sfx, I only know how they handled it for SCI0 and early SCI1, which is obvious at this point. Never really delved into that aspect for later versions as we had no tools to make anything with them anyway. One area I was never curious about....now you've made me curious. I wonder if it's as simple as having a conditional block of code in the scripts calling for whether the game is running with digital sounds or not? I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?
Is there also a sampling rate limit, troflip?
-
I know you're not working on palette stuff right now, but I was just fooling around with SCI Viewer here and I noticed that in the colour palette cycling animation feature, you can set two or more isolated colour selections to cycle through with the use of a comma. For instance, in SQ4's title screen the colours 128-159 cycle independently of colours 160-191. But they're also cycled backwards through the palette rather than forward. So in SCI Viewer's "Colors" field when viewing 1.P56 you'd enter:
159-128,191-160
And the colour cycling animation would appear as it does in-game. It would be useful if this preview feature were also in SCI Companion. Also, I had another thought. It'd be easier than entering exact numbers if we could select a series of colours in the palette manually with the mouse (much like text in a word processor) to cycle and Companion would create the palette entry number sequence from that. Manually typing in the numbers in a text field a la SCI Viewer would also be handy, though, as well as it doubling as an output feature which we could quickly extrapolate which palette entries are used in the cycling so that we can more quickly enter them in a script.
Also, if possible please add an optional checkbox for a palette entry ID field to each block of colour so that each colour has its palette number inside the box. Or even just have the numbers beside or beneath the colour. I hate having to count rows, multiply by 16, and then subtract backwards from the last entry in the row to get the colour number lol.
EDIT: Also, I just realized that in SQ4 the "IV" is actually a VIEW but the colours are still cycling. Would it be possible to, in addition to adding VIEWs to a PICTURE when editing it (as we already can), have the colours of the VIEW cycle along with the PICTURE? Or even implement colour cycle previewing in the VIEW editor as well as the PICTURE editor.
Just typing this gives me another idea. What if we could add as many VIEWs (within reason or memory consumption economics) as we wanted to a PICTURE when editing and then click a button to generate a SCRIPT or code blocks which would add every item we've put on the screen into the PICTURE's room SCRIPT with basic info like X/Y location, Loop/Cel values, and Priority value? This might make it easier for some people (especially newcomers) to build their game rooms quickly. Extra info like animation and moving an actor across the screen would obviously be scripted manually, but it'd be a great starting point. You could even do this with other handy room-related things like background music or sound effects with "play on entry" checkboxes or something akin to AGS's interface.
This is all stuff that could come after the actual important features are implemented, though. I'm just brainstorming here. Hopefully I'm not overwhelming you lol. Heck, this doesn't even have to be in the Picture editor (although that'd be easiest). You could create a sort of Room Preview feature which you could add the basic ideas I've listed here among maybe even more, which could then be exported to the SCRIPT. Maybe it could even read the current SCRIPT and extrapolate a preview from it, again with only simple features like actor/prop X/Y locations, Room music, etc. Conditional expressions and other more advanced code blocks would just be ignored. You might as well rewrite the whole interpreter if we were to go that route.
-
Yes. Yes it is. :P What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...
I already mentioned AddWave, which is included in the SCI Sound Utilities, along with Gumby's ExtractWav. If it is not that big of a deal to include it in the IDE, that would be great, but I would give it a lower priority than other features since it was only used for a few games. This might be nice for creating patches for the official games, but for game creation using SCI1.1 should not be that much different esthetically than SCI1 and would give the advantage of discrete digital sounds.
That does bring to mind features of SCI on other platforms. Having Amiga sounds for PC SCI0 would be nice, much like the KQ4 Amiga sound patch for the PC version.
As far as how Sierra implemented pairing of MIDI/digital sfx, I only know how they handled it for SCI0 and early SCI1, which is obvious at this point. Never really delved into that aspect for later versions as we had no tools to make anything with them anyway. One area I was never curious about....now you've made me curious. I wonder if it's as simple as having a conditional block of code in the scripts calling for whether the game is running with digital sounds or not? I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?
I don't think that they did it for more than SCI0 and early SCI1. SQ5's interpreter has both a flag for soundDrv and audioDrv, so there would be little reason to embed digital samples in the sound resources. You had to have SB capable hardware to hear the samples, whether embedded or a discrete resource.
-
Yes. Yes it is. :P What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...
Well, it might be fairly trivial to add it. But I won't have that as a goal.
I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?
I tried adding audio resources for some of the sounds in the opening of SQ5. The midi sounds for the corresponding resource numbers stopped playing, but my sound was also not played. So it looks like it's not quite as simple as that. Maybe the sound resource needs to be modified slightly too? I tried looking through the SCUMMVM code to see how they handle it, but it wasn't obvious. Or maybe the midi sound and the digital audio need to be exactly the same length?
Is there also a sampling rate limit, troflip?
I'm sure there is. The sounds in SQ5 are all 11025Hz. I tried using a 22050Hz one and that worked too. I think the main limit will be the total byte size of the audio though. Everything in SQ5 is under 64KB, which means the samples are only a few seconds long at most. LSL6 (which I think is a slightly later game than SQ5) has several sounds larger than that (and it also uses 16 bit audio instead of 8 bit).
So for music, you may still need to use midi, or something like sciAudio.
-
And the colour cycling animation would appear as it does in-game. It would be useful if this preview feature were also in SCI Companion. Also, I had another thought. It'd be easier than entering exact numbers if we could select a series of ...
Lots of good ideas, but most of these are out of scope for the moment.
I agree that easily getting the palette index is important though.
And I already support selecting ranges of palette colors in order to mark them as "used" or not. So at least that part of your cycling feature is done :P
I think I mentioned before that I took a stab at a "visual editor" kind of like you described, but it was too much work. There's no way SCI will ever have the kind of editor support that AGS does. And so I doubt it will ever be quite as easy to use. (I've only used AGS a bit, and it was a long time ago, so I forget what features the editor had).
-
Wouldn't the move to Audio36 from AUD be to remove some of the limitations the the AUD resource had?
-
Understandable, troflip. :) Forgot that you mentioned that wasn't realistic.
I already mentioned AddWave, which is included in the SCI Sound Utilities, along with Gumby's ExtractWav. If it is not that big of a deal to include it in the IDE, that would be great, but I would give it a lower priority than other features since it was only used for a few games. This might be nice for creating patches for the official games, but for game creation using SCI1.1 should not be that much different esthetically than SCI1 and would give the advantage of discrete digital sounds.
No, I know. I was just agreeing with you that we could simply use AddWave. However, I'd still like to be able to create an SCI1 game with all the features that SCI1 games are capable of, because AddWave only works with SCI0. But I'm crazy and I wouldn't just use SCI1.1 because it's better lol. A fully-featured package is what I'm hoping for eventually; the ability to create everything Sierra could with their respective versions of SCI (up to SCI1.1 at least). With the possible exception of SCI01, which had a couple of extra features over SCI0 like screen scrolling.
As far as how Sierra implemented pairing of MIDI/digital sfx, I only know how they handled it for SCI0 and early SCI1, which is obvious at this point. Never really delved into that aspect for later versions as we had no tools to make anything with them anyway. One area I was never curious about....now you've made me curious. I wonder if it's as simple as having a conditional block of code in the scripts calling for whether the game is running with digital sounds or not? I do know that some games do not have any MIDI equivalents of sound effects at all. There isn't a variation for SQ5's "Doh!", for instance. But there is for when the janitor closet contents spew onto the floor. Maybe it's just as simple as that? Not having equivalents if there are no sounds with the same number for both MIDI and digital?
I don't think that they did it for more than SCI0 and early SCI1. SQ5's interpreter has both a flag for soundDrv and audioDrv, so there would be little reason to embed digital samples in the sound resources. You had to have SB capable hardware to hear the samples, whether embedded or a discrete resource.
Yeah, that's what I said. lol I'm talking about corresponding numbered digital AUD resource files to MIDI SND resource files, like troflip mentioned.
Yes. Yes it is. :P What if we want to be like Sierra sometimes and make 4 different versions of our games (like Mixed Up Mother Goose)? EGA Parser SCI0, EGA parserless SCI1, VGA parserless SCI1, and VGA SCI1.1? Or we could just do it ourselves with AddWave.exe...
Well, it might be fairly trivial to add it. But I won't have that as a goal.
I'd really like to be able to add digital sounds to my SCI0 and SCI1 games...
I tried adding audio resources for some of the sounds in the opening of SQ5. The midi sounds for the corresponding resource numbers stopped playing, but my sound was also not played. So it looks like it's not quite as simple as that. Maybe the sound resource needs to be modified slightly too? I tried looking through the SCUMMVM code to see how they handle it, but it wasn't obvious. Or maybe the midi sound and the digital audio need to be exactly the same length?
That seems unlikely to me. A case of extra scripting would be my first guess. But I could very well be wrong.
I'm sure there is. The sounds in SQ5 are all 11025Hz. I tried using a 22050Hz one and that worked too. I think the main limit will be the total byte size of the audio though. Everything in SQ5 is under 64KB, which means the samples are only a few seconds long at most. LSL6 (which I think is a slightly later game than SQ5) has several sounds larger than that (and it also uses 16 bit audio instead of 8 bit).
Fascinating. I wonder if the interpreter can handle up to 44100? I imagine not. Most DOS games of that era were limited to 22050.
So for music, you may still need to use midi, or something like sciAudio.
Oh, no I wasn't asking for that reason. Just curious about the limitations. I'd never use sciAudio for music personally. MIDI is too much fun. :) Adlib ftw!
-
That seems unlikely to me. A case of extra scripting would be my first guess. But I could very well be wrong.
Except that in the opening room (110) in SQ5, I hear both digital samples and midi sounds. And looking through the script, the code plays sounds 104, 106, 105, 107,109, 108, 110 and 4, all in exactly the same manner. All of those numbers correspond to midi .snd resources, but four of them also have .aud digital samples, and I believe I'm hearing those when playing the game. So I don't think any special scripting is required. It's like the interpreter just prefers the digital audio if it's available (and the hardware supported it).
Fascinating. I wonder if the interpreter can handle up to 44100? I imagine not. Most DOS games of that era were limited to 22050.
44100 seems to work fine, I just tried it. :P
It might have more to do with the audio drivers than the interpreter, I'm not sure.
-
That seems unlikely to me. A case of extra scripting would be my first guess. But I could very well be wrong.
Except that in the opening room (110) in SQ5, I hear both digital samples and midi sounds. And looking through the script, the code plays sounds 104, 106, 105, 107,109, 108, 110 and 4, all in exactly the same manner. All of those numbers correspond to midi .snd resources, but four of them also have .aud digital samples, and I believe I'm hearing those when playing the game. So I don't think any special scripting is required. It's like the interpreter just prefers the digital audio if it's available (and the hardware supported it).
That would be the sensible way to do it. But you said you tried adding a digital alternative to a MIDI-only sound and it didn't work...? I played the opening to SQ5 when Roger is getting out of the bridge simulator. When the bridge simulator opens up it makes a "whooosh" sound. If you have AUD.DRV active in resource.cfg it plays the digital sound only, if you have AUDNONE.DRV active it plays a MIDI alternative instead as you'd expect. Is there some kind of flag? Maybe in the sound resource that tells whether or not there is an associated digital sound?
44100 seems to work fine, I just tried it. :P
It might have more to do with the audio drivers than the interpreter, I'm not sure.
Cool! Makes sense.
-
Wouldn't the move to Audio36 from AUD be to remove some of the limitations the the AUD resource had?
No, the move to Audio36 provided a link between a text message and its associated sound. It's easier to manage when you can use the same identifier for both.
Ordinary audio resources were still used for sound effects that did not have a text message equivalent.
-
Does anyone know at what point the interpreter started supporting cd audio? And how those resources were handled? (Certainly they were too big to put in the package files, so were they always just patch files, or were they access in some other manner?). I know some SCI1.1 games had CD-ROM versions, so I'm assuming they supported CD audio somehow?
-
Does anyone know at what point the interpreter started supporting cd audio? And how those resources were handled? (Certainly they were too big to put in the package files, so were they always just patch files, or were they access in some other manner?). I know some SCI1.1 games had CD-ROM versions, so I'm assuming they supported CD audio somehow?
There was support in Jones CD (1991), although the interface differs from that of later releases, according to ScummVM.
EDIT: There was a CDAUDIO.MAP file that contained offset/length pairs. Only one audio track was supported. Later versions allowed the scripts to specify track, offset and length explicitly.
-
Hmm, maybe it doesn't matter. It looks like the size for aud resources is larger than I thought. I just dropped a 30 second 22kHZ clip into SQ5. It's size is 660KB, and it played just fine... :D
-
Here is some sample output from the decompiler, for a few of the rooms/scripts in Space Quest 5.
These are amazing. Awesome work. I'm guessing once you've worked out the flow control, you could generate the source in any format? e.g. original SCI vs. SCIStudio vs. Java-ish vs. <other language here>, etc.? - There's a lot of switch statements in there, isn't there? It seems like a lot of the scripts were based around that and state changes.
I notice some of the kernels are incorrect. For instance, room 110 (the opening room) transitions palettes, and it ends up being identified as Joystick kernel call. I know various kernel functions moved/changed between SCI versions, but looking at the SCUMMVM source code, there was never any palette-related kernels that were in the Joystick slot (0x6d), so it's a bit strange.
Anyway, I'll need to provide some kind of config file to allow for differences in kernel functions in different versions.
I had wondered whether the Kernel procedure slots stayed constant or not. I realise new ones would have been added over time. I read somewhere (maybe the specs?) that a slot once allocated was fairly static, but apparently that VOCAB.999 was notoriously unreliable as a match for the game it is in. I guess that makes some sense. It's probably a file that doesn't get generated by compilation. VOCAB.997 and VOCAB.996 would be a direct output of the compilation process, since they apply to the game itself, but VOCAB.999 is related to the interpreter and would have been provided by the interpreter developers. It is possible, and maybe even probable, that it wasn't updated as often and got out of sync sometimes, particularly I'm guessing when the same game is released on a newer interpreter version.
This is a lot more powerful that Brian's decompiler was going to be, since it does control flow analysis and attempts to recover higher level constructs like if/else, compound conditions, loops and switch statements. There are still some flow control structures I can't identify though, so I'll have to leave those odd functions as assembly.
I'm curious to see some examples of assembly code that you haven't yet been able to identify. Maybe we could start a separate thread related to decompilation to discuss such examples. I'll have to grab my SQ5, if that is where you've been focussing.
-
No, the move to Audio36 provided a link between a text message and its associated sound. It's easier to manage when you can use the same identifier for both.
Ordinary audio resources were still used for sound effects that did not have a text message equivalent.
Thanks for the info. I have been wondering about the difference for some time. That would make sense given the naming convention of the Audio32 resources.
Most of the SCI1.1 CD games just used standard audio resources, either AUD or Audio36. lskovlun is probably right about Jones. I have heard rumors of a CD audio version of Mixed-up Mother Goose CD using CD-A tracks, but my copy does not have it. Mine is the red label. There was a blue label, but that that was just the international version and I don't think it had CD-A either.
-
The only other SCI game I can think of that used CD Audio other than Jones was KQ6. And even that I think only the Windows version actually called it. The DOS version had a lo-fi audio equivalent in the resources. It certainly didn't sound like CD quality audio, anyway.
-
I've written a little javascript tool that decomposes an audio36 resource name into its parts.
The results can be used with SCI Viewer (open the message file corresponding to "module"; the other fields correspond to the columns in the SCI Viewer display).
I can implement a tool that does the opposite if there is demand.
http://sprogklog.dk/sci/audio36.html (http://sprogklog.dk/sci/audio36.html)
-
Nice!
-
I can implement a tool that does the opposite if there is demand.
That would be great.
-
The only other SCI game I can think of that used CD Audio other than Jones was KQ6. And even that I think only the Windows version actually called it. The DOS version had a lo-fi audio equivalent in the resources. It certainly didn't sound like CD quality audio, anyway.
You are right in that the DOS version just used a lo-fi version. And not all releases of the CD included the CD-A track. This was probably just an oversight and the Windows game handles it by calling the lo-fi version when it can't find the CD-A track.
-
These are amazing. Awesome work. I'm guessing once you've worked out the flow control, you could generate the source in any format? e.g. original SCI vs. SCIStudio vs. Java-ish vs. <other language here>, etc.? - There's a lot of switch statements in there, isn't there? It seems like a lot of the scripts were based around that and state changes.
Yeah, it's fairly straightforward to generate in any format. I currently have code that outputs the underlying code structure in the 3 formats you mentioned, but I'm just focusing on the SCIStudio thing for now. And of course, recompiling it only works in SCIStudio-format now too. I'd do have a syntax parser for the java/c# style syntax - and it was mostly working - but I haven't picked up that code in a long time. In the end, I don't think java/c# is a great fit for SCI code, given the message-passing stuff that exists even down at the byte-code level.
As for "original SCI" syntax, that's on my radar, but isn't an immediate goal. It's similar enough to current SCIStudio syntax that writing the syntax parser might only be a few days work though. Although I'm not sure if having another "esoteric" language to code these games in is a good idea? I'd also like to have a firmer grasp on the exact syntax before bothering to get that working. And I'm not sure we will ever know...
Then again, the decompiled code might have to break a bit from SCIStudio syntax, and "original SCI" syntax could be a good way to formalize/clarify that break. One pretty frequent thing I see in the decompiled scripts is switch statements embedded in other expressions (for instance, passed as a parameter value to a function). SCI Studio doesn't handle these properly (to be fair, nor did SCI Companion prior to my latest updates), and the results crash the interpreter. It would be a bunch of extra work to restructure the code so that it is in a form that plays well with SCI Studio.
Another problem is with compound conditions (nested ands/ors). SCI Studio ignores any attempt to enforce a certain order of operations with parentheses. It basically just ignores parentheses (and so SCI Companion does this to right now, to ensure compatibility). But my decompiler generates compound conditions that need proper nesting. The only way to get the identical logic with SCI Studio syntax is to break things into multiple if statements, and I'm not sure whether I really want to bother with that extra work.
It is possible, and maybe even probable, that it wasn't updated as often and got out of sync sometimes, particularly I'm guessing when the same game is released on a newer interpreter version.
Yeah, vocab.999 isn't reliable (it's also missing from many games). For support for writing SCI1.1 games, I figure I'll finalize on a specific interpreter version (probably SQ5 or LSL6), and hardcode the set of kernels that work with that interpreter.
-
I'm curious to see some examples of assembly code that you haven't yet been able to identify. Maybe we could start a separate thread related to decompilation to discuss such examples. I'll have to grab my SQ5, if that is where you've been focussing.
I might do that eventually. In a couple of the recent examples I've come across, the actual correct code isn't too hard to figure out when looking at it by hand. It's just gaps in my decompilation algorithms. But I have encountered some truly perplexing byte code - either heavily optimized, or perhaps Sierra's parser also supported asm, and these functions were written in asm. At some point, I have to say "I've done enough work on this", and just make sure I can at least detect I wasn't able to decompile it properly, and fall back to asm. At this point, I'd say I have issues with maybe one out of every 20 or 30 functions or so.
Well, ok, here's one example. The method "advance" from SQ5 script 26.
(method (advance) // method_0076
0076:3f 04 link 4 // (var $4)
0078:87 00 lap paramTotal
007a:31 04 bnt code_0080
007c:87 01 lap param1
007e:33 02 jmp code_0082
code_0080
0080:35 01 ldi 1
code_0082
0082:a5 01 sat temp1
0084:38 0084 pushi 84 // $84 indexOf
0087:78 push1
0088:67 20 pTos highlightedIcon
008a:54 06 self 6
008c:a5 02 sat temp2
008e:8d 01 lst temp1
0090:02 add
0091:36 push
0092:63 14 pToa size
0094:0a mod
0095:a5 03 sat temp3
code_0097
0097:39 40 pushi 40 // $40 at
0099:78 push1
009a:8d 03 lst temp3
009c:54 06 self 6
009e:a5 00 sat temp0
00a0:78 push1
00a1:36 push
00a2:43 06 02 callk IsObject 2
00a5:31 2c bnt code_00d3
00a7:39 0e pushi e // $e signal
00a9:76 push0
00aa:85 00 lat temp0
00ac:4a 04 send 4
00ae:36 push
00af:35 04 ldi 4
00b1:12 and
00b2:18 not
00b3:31 1e bnt code_00d3
00b5:39 07 pushi 7 // $7 nsLeft
00b7:76 push0
00b8:85 00 lat temp0
00ba:4a 04 send 4
00bc:36 push
00bd:35 ff ldi ff
00bf:1e gt?
00c0:2f 0b bt code_00cd
00c2:39 72 pushi 72 // $72 isKindOf
00c4:78 push1
00c5:51 40 class InvI
00c7:36 push
00c8:85 00 lat temp0
00ca:4a 06 send 6
00cc:18 not
code_00cd
00cd:31 04 bnt code_00d3
00cf:33 0f jmp code_00e0
00d1:33 c4 jmp code_0097
code_00d3
00d3:8d 03 lst temp3
00d5:35 01 ldi 1
00d7:02 add
00d8:36 push
00d9:63 14 pToa size
00db:0a mod
00dc:a5 03 sat temp3
00de:33 b7 jmp code_0097
code_00e0
00e0:38 00e1 pushi e1 // $e1 highlight
00e3:7a push2
00e4:8d 00 lst temp0
00e6:78 push1
00e7:54 08 self 8
00e9:48 ret
)
If you go to https://stamm-wilbrandt.de/GraphvizFiddle/ and paste the following in the box and hit "Draw", you'll see a graph of the flow structure of the function (before any control flow analysis has been done), which makes it easier to visualize.
digraph code {
n_0078_0 [label ="0078:\nlap\nbnt\n"] [color=red];
n_0076_0 -> n_0078_0 [color=red];
n_0076_0 [label ="0076:\nlink\n"] [color=red];
n_ffff_0 -> n_0076_0 [color=red];
n_0082_0 [label ="0082:\nsat\npushi\npush1\npTos\nself\nsat\nlst\nadd\npush\npToa\nmod\nsat\n"] [color=red];
n_0080_0 -> n_0082_0 [color=red];
n_007c_0 -> n_0082_0 [color=red];
n_00c2_0 [label ="00c2:\npushi\npush1\nclass\npush\nlat\nsend\nnot\nbnt\n"] [color=red];
n_00b5_0 -> n_00c2_0 [color=red];
n_0080_0 [label ="0080:\nldi\n"] [color=red];
n_0078_0 -> n_0080_0 [color=red];
n_00e0_0 [label ="00e0:\npushi\npush2\nlst\npush1\nself\nret\n"] [color=red];
n_00cf_0 -> n_00e0_0 [color=red];
n_007c_0 [label ="007c:\nlap\njmp\n"] [color=red];
n_0078_0 -> n_007c_0 [color=red];
n_00d3_0 [label ="00d3:\nlst\nldi\nadd\npush\npToa\nmod\nsat\njmp\n"] [color=red];
n_00c2_0 -> n_00d3_0 [color=red];
n_0097_0 -> n_00d3_0 [color=red];
n_00a7_0 -> n_00d3_0 [color=red];
n_0097_0 [label ="0097:\npushi\npush1\nlst\nself\nsat\npush1\npush\ncallk\nbnt\n"] [color=red];
n_0082_0 -> n_0097_0 [color=red];
n_00d3_0 -> n_0097_0 [color=red];
n_ffff_0 [label ="ffff:\nINVALID\n"] [color=red];
ENTRY_0 -> n_ffff_0;
ENTRY_0 [label ="Main 31"];
n_00cf_0 [label ="00cf:\njmp\n"] [color=red];
n_00c2_0 -> n_00cf_0 [color=red];
n_00b5_0 -> n_00cf_0 [color=red];
n_00a7_0 [label ="00a7:\npushi\npush0\nlat\nsend\npush\nldi\nand\nnot\nbnt\n"] [color=red];
n_0097_0 -> n_00a7_0 [color=red];
n_00b5_0 [label ="00b5:\npushi\npush0\nlat\nsend\npush\nldi\ngt?\nbt\n"] [color=red];
n_00a7_0 -> n_00b5_0 [color=red];
}
-
The only other SCI game I can think of that used CD Audio other than Jones was KQ6. And even that I think only the Windows version actually called it. The DOS version had a lo-fi audio equivalent in the resources. It certainly didn't sound like CD quality audio, anyway.
You are right in that the DOS version just used a lo-fi version. And not all releases of the CD included the CD-A track. This was probably just an oversight and the Windows game handles it by calling the lo-fi version when it can't find the CD-A track.
Really? My copy of the King's Quest Collection Series KQ6 doesn't do that. In fact it errors out and crashes.
-
It has been years since I tried, but as I said, there were some releases that did not include the track. A couple of the standalone releases and the 2nd collection did not. I won't even mention the 2006 VU release. I don't remember any crashes with these. It would be a bit of a pain to test it. I would have to set up a 32-bit system or install Win3x in DOSBox to check the Win version.
-
The VU release just uses DOSBox for all the games doesn't it? So it would just use the lo-fi version?
-
It includes the Win interpreter. Out of the box it will use the ancient version of DOSBox, but can be setup to use the Win. The point is that it does not include the CD-A track. My patch for the release originally used the Win interpreter until ScummVM supported the game.
-
Code updated
-
Code updated
Any chance for an exe version that can work from the command line?
-
Right now I'm working on the workflow for decompilation (since it will not be just quite as simple as click a button and go)
Attached is a dialog showing roughly what I've got so far. The scripts are listed on the left. You can decompile them individually, or as a group. Decompiling them will - in addition to generating the source file - generate an .sco file. The .sco files (as some of you know) contain the script variable names and public procedure names for scripts (so when compiling other scripts you can reference global variables, or public procedures in other scripts).
These names don't exist in the compiled code anywhere, so it will be up to the user to give them meaningful names (I can provide guesses for variable names depending on how they are used, but procedures are more difficult). So there is a little box where you can edit the variable and procedure names for an .sco (that's the treeview in the bottom center of the dialog), and those names will be picked up if you re-decompile the script.
On the top right is the generated source code for the selected script, and on the bottom right will be status/error messages.
Of note, this will also allow you to regenerate .sco files from compiled scripts (although you'd have to put in the correct var/proc names manually) - I seem to recall some threads in here where .sco files got corrupted, so this might help.
I also found that SCI1.1 games have a lot of scripts with invalid exports (they point to nothing). Currently in SCI0 with SCISTudio/SCICompanion, if you remove public procedures or instances from a script (or move them around in the file), other scripts will reference the incorrect procedure/instance until they are also recompiled. This probably causes confusion/headaches for anyone that hits this.
This is just a guess, but I suspect that Sierra (at least for SCI 1.1) may have "fixed" the index of a public proc/instance once it was created. If the programmer later removed some, they would be replaced by '0' entries in the export table, but the other exports would retain the same index. This should actually be pretty easy to do, by simply trying to match the names of exports to those existing in the .sco file.
-
Code updated
Any chance for an exe version that can work from the command line?
That was not in my plans, no.
-
Oh well. It would have been nice for batch processing.
-
Anyone have any idea how we might re-enable the debug mode in the later SCI interpreters? Or is that something that we'd need a whole rebuilt interpreter itself for? Would the SQ4 beta come in handy here? (It has the debug mode enabled)
-
I was going to focus on SCI1.1, since I figured the more advanced the interpreter the better. But that's a good point, there is no internal debugger for any SCI1.1 games, right? That sucks.
That's actually going to make it really hard for me to validate my decompiler... I suspect I'll run into random crashes with no way to know what happened. I guess I'll have to test the decompiler mainly on SCI0 games, and just hope there aren't too many SCI1.1-specific issues.
Does SCUMMVM have a debugger? I'm pretty sure FreeSCI did, not sure if it made it through the move to SCUMMVM.
-
Debugging might be a factor in the choice of what game to base a new template on. Several SCI1.1 games still have debug enabled with the use of "magic files". SCI1 is another thing altogether. You might base it on one of the games that you can substitute the Xmas 90 ecard's SCIV.EXE. For later SCI1 removing the VERSION file from PQ3 is supposed to activate debug. As to SQ4, is there anyway to turn off debug?
-
I was going to focus on SCI1.1, since I figured the more advanced the interpreter the better. But that's a good point, there is no internal debugger for any SCI1.1 games, right? That sucks.
That's actually going to make it really hard for me to validate my decompiler... I suspect I'll run into random crashes with no way to know what happened. I guess I'll have to test the decompiler mainly on SCI0 games, and just hope there aren't too many SCI1.1-specific issues.
Does SCUMMVM have a debugger? I'm pretty sure FreeSCI did, not sure if it made it through the move to SCUMMVM.
Looking to SCI1.1 makes sense to me as well. ascetically there is little difference but having the audio capabilities of SCI1.1 is a definite plus. ScummVM does have an internal debugger, but it is specific to ScummVM. I don't see how it could help, outside of using it to run your game, but the hash (usually that of the RESOURCE.MAP) needs to be entered into the SCI detection tables in the source, which would change every time a resource was added.
-
ScummVM does have an internal debugger, but it is specific to ScummVM. I don't see how it could help, outside of using it to run your game, but the hash (usually that of the RESOURCE.MAP) needs to be entered into the SCI detection tables in the source, which would change every time a resource was added.
Why wouldn't it help? Presumably something that makes Sierra's interpreter crash would also make ScummVM's interpreter crash, or throw up some warning or error at least. I can't be in the situation of having to validate my SCI1.1 generated code without a debugger to find out exactly where things crashed.
ScummVM should detect SCI versions based on the types and format of resources it finds. I've looked over its code quite a bit when implementing my own version checking. I assume the hash is to identify specific games for special workarounds? Or are you saying it will block any fanmade games that don't have some hash that matches their resource.map or something?
[edit:]
Well, the debugger looks to be fine, I tried stepping through some SQ5 byte code.
But SCUMMVM doesn't seem to want to play the SCI Studio template game, it just crashes. It plays some of the fan-made games I tried, but it looks like it already knows about them. How does the hash thing work? It seems like there should be a way to bypass it for development. Playing a game in SCUMMVM is a lot nicer than clunky DosBOX.
-
Ugh no. I dislike ScummVM. Especially for SCI1.1 games. It doesn't get cycles or speed or something right which causes a lot of animations to play as fast as they can. Take the SQ5 intro sequence when Roger is exiting the bridge simulator. Those rats aren't supposed to run away that quickly. Try it in DOSBox and lower the CPU cycles to see what I mean. SCI1 games, on the other hand, don't suffer from this issue in ScummVM. Animations play perfectly, more or less. Another issue is that it will not play MIDI sounds if there is a digital equivalent so you're always stuck with them, even in cases where the digital files are just lo-fi versions of recorded MT-32 sounds. The better sounds are actually not digital in many cases. That problem extends right back to SCI0. Even though there's an option in the ScummVM game-context menu to disable them, it doesn't work. ScummVM is good in a pinch, but it is not the goto solution for best quality.
-
Does SCUMMVM have a debugger? I'm pretty sure FreeSCI did, not sure if it made it through the move to SCUMMVM.
It does, and it's better than anything Sierra had. ;D
With a little work, it would be possible to make it work on the source level as well.
-
Ugh no. I dislike ScummVM. Especially for SCI1.1 games. It doesn't get cycles or speed or something right which causes a lot of animations to play as fast as they can.
You know what? That's because Sierra's programmers deleted the call to Wait() from the main loop - the result being, as you note, that SCI1.1 games run as fast as they can on any processor on any operating system. We work around it by putting the delay loop in the GameIsRestarting() call instead, but there are cases where that is not enough.
When the dev environment for SCI1.1 comes out, you're free to reinsert the Wait() call (the kernel routine still exists). There may be complications that I don't know about, but we can work on those.
-
That's illuminating and exciting. Still would rather use DOSBox, though. Obviously most others wouldn't, though. And that wouldn't stop me from insuring ScummVM compatibility should there ever be differences, let me be clear.
-
Haha, fair enough, I haven't used ScummVM much, I didn't notice the mice thing. If DOSBox, "gets it right", presumably it wouldn't be too difficult to have Scumm get it right too though?
After trying DOSBox again after all these years, I was surprised it really wasn't much better than it used to be. It still "traps" my mouse inside the window. And it sometimes processes keystrokes when the window doesn't have focus... so if I switch back to DOSBox, suddenly the game goes crazy popping up messages boxes and such. It just feels... "unfinished". This makes it pretty much useless if you're switching back and forth between DOSBox and other apps (like you would be if you were developing a game).
-
Huh. I've never run into that keystroke problem. I don't mind the captured mouse thing. Especially for adventure games as it's really annoying to try and hit the very far edge of the screen and then having the mouse go too far. Ctrl+F10 releases the mouse, but then you don't control the mouse in the game until you hit it again. ScummVM does offer both modes so it's got that going for it. I've considered DOSBox finished and polished for a while now. At least for my needs.
ScummVM, on the other hand, still feels unfinished to me. Mostly only in the SCI department. I still consider DOSBox the defacto standard because as good and impressive as ScummVM's reverse engineering is for SCI, it's still not as good as the original interpreter.
-
After trying DOSBox again after all these years, I was surprised it really wasn't much better than it used to be. It still "traps" my mouse inside the window. And it sometimes processes keystrokes when the window doesn't have focus... so if I switch back to DOSBox, suddenly the game goes crazy popping up messages boxes and such. It just feels... "unfinished". This makes it pretty much useless if you're switching back and forth between DOSBox and other apps (like you would be if you were developing a game).
The mouse capture is easy. Under the SDL section of the conf set autolock to false. There are only a couple of times where it may be needed. When an event is is only triggered at the very edge of the screen and for VESA games where the cursor does not always snap to the point of entry of the mouse within the window. As MI noted, you can also do it from the keyboard with Ctrl+F9 and Ctrl+F10. Once you learn what you can do from the conf, using DOSBox becomes much easier.
I have never noticed the keyboard input problem, either. Perhaps you have not made the other window the active one? Once DOSBox is not the active window that should never happen. You can see similar problems with inactive windows in other programs. Even Office will not accept input on first click. The first click only makes it the active window.
In any case, nearly all of the complaints that I have heard about DOSBox are easily solvable or avoidable by reading and becoming familiar with the conf and makes using DOSBox a snap. Once you get it sorted out you generally get much better results than with ScummVM and DOSBox's compatibility with DOS games is quite high.
As to the development of DOSBox, it is true that the official 0.74 is getting a bit long in the tooth, but development has not slowed. The latest SVN has many improvements. Bug fixes are frequently dealt with in the beta testers forum, even if at this point those bugs are mostly from obscure games that used undocumented and unusual aspects of DOS. Then there are the unofficial builds that hold a lot of promise, like the x branch that is adding features like proper PCI emulation.
I too have issues with ScummVM, especially when it comes to SCI, not only because of lack of support for anything later than SCI1.1. I can generally get much better sound from DOSBox. AdLib emulation in ScummVM offers no advantage since the code was lifted directly from DOSBox. While SVM does have Munt built in, it is easy enough to use the Munt driver or QT app with DOSBox. There is also the daum build of DOSBox with Munt built in. Any other thing that some would cite about SVM's sound is easily had in DOSBox, too. FluidSmith and such can be used with, even if not built into DOSBox. This also has the advantage of have the latest with DOSBox while ScummVM often suffers from an ancient version of these extras. Munt does not get updated with every new build of SVM.
Another beef that I have with SVM is that they have been heavy handed with AGI and SCI. The initial implementation of SCI0 forced "undithering" on its users, since they knew better about SCI than everyone else. They also tried to usurp this community to divert game development to their forums and then advise people to use modern game development systems instead. I was even scolded for putting the Free SCI specifications document on our Wiki.
-
I guess maybe I'm just unlucky with Dosbox bugs.
If I try to bring up the briefcase menu in SQ5, and tab to another window on my desktop, then back, it will often go crazy, like the tab key is being pressed non-stop (until I hit escape). So alt-tabbing between DosBox and another window is basically broken.
Thanks for the autolock tip, that makes things a little better. autolock false should really be the default, IMO. Users shouldn't have to mess with config files.
-
Just tried Sierra SCI under FreeDOS in VirtualBox. It has exactly the same speed issues.
-
Well of course it would. It's a system speed issue, as you said. DOSBox's cycles settings makes this a non-issue. I was always confused why in ScummVM SCI1 games behaved properly and SCI1.1 didn't. Hearing that it's a SCI scripting issue makes more sense. Even so, DOSBox doesn't have this issue...
Also, Collector, CTRL+F9 quits DOSBox. :P CTRL+F10 is a toggle.
I was even scolded for putting the Free SCI specifications document on our Wiki.
To be fair, they did say it was out of date. And I wouldn't say there was any scolding. Not in that thread, anyway. I specifically recall the phrase "please consider using our SCI specifications" or something to that effect because there were numerous corrections of inaccurate information. But yeah, the undithering and attempted usurpation were not shining moments. At least they backpedaled on the undithering stuff.
-
Thanks for the autolock tip, that makes things a little better. autolock false should really be the default, IMO. Users shouldn't have to mess with config files.
Agreed. That is what I have set in my main conf file since there are far more games it is not needed than do. I was forgetting the autolock hot key was simply a toggle. I just always do it through the conf.
And MD5 was unhappy with our Wiki having the specifications doc, insisting there should be no other doc than their own. I will grant you that others (sev?) did step in to say to him that that is just the nature of the internet and also acknowledged that this community did not have access to edit their Wiki, so it was not all of them.
-
But yeah, the undithering and attempted usurpation were not shining moments. At least they backpedaled on the undithering stuff.
You do know that Matt (the FreeSCI testing guy) put together some interesting color combinations for SQ3 using the palette language we developed?
I was going to improve on it for a course on DSLs I attended, but I had to abandon it for time reasons.
Myself, I quite liked the results of Christoph's unditheritng algorithm.. I guess it's a matter of taste, and it was always a configuration option.
-
Actually, I have absolutely nothing against the undithering feature (other than preferring the original dithered look personally). I was excited to see how it could develop further and be closer to how the original dithering was perceived. I admired him for it! I and others would never have spoken against it at all in the first place had things happened differently. What turned me off was the enforcing of it to be the default option and the whole pompous attitude he had about it, claiming that it was exactly what Sierra, the artists, and everyone wanted and then proceeding to belittle me and avoid my arguments against enforcing it as the default option when I actually made valid points and twisted everything I said. Which just made the debate continue in circles needlessly with my trying to correct his misconceptions of my opinions and getting the subject back on track. The man was arrogant about it to say the least.
To this day the undithering checkbox is not and undithering checkbox at all but a dithering checkbox which is enabled to "add" dithering, like it was never there to begin with. Just more evidence of that attitude. (I am apparently blind or just plain not observant because this is apparently not true anymore so I'm redacting my statement) I understand the technicality that technically the dithered colours are their own values and could be represented as anything, but his assertion that those colours generated by his algorithm were actually something like what the artists were seeing when they drew these backgrounds and that Sierra created drivers that translated that down into the standard dithered 16-colour palette was just plain asinine.
Anyway, that's five years ago. Over and done with. I don't want to dredge it up again here. Like I said, I was looking forward to seeing how it could develop. Perhaps even to a point of enhancement where there could be some advanced combining of colours to increase the palette count to more than 256 colours by continuing to average colours and making more gradual changes instead of the flat look it currently has. The backpedalling I was referring to was the decision to change it from opt-out to opt-in.
The custom palette combinations certainly sound interesting. I'm sorry to hear it didn't get developed further. Actually, it seems like all work on the SCI side of things just stopped cold suddenly for some reason.
-
Actually, I have absolutely nothing against the undithering feature (other than preferring the original dithered look personally). I was excited to see how it could develop further and be closer to how the original dithering was perceived. I admired him for it! I and others would never have spoken against it at all in the first place had things happened differently. What turned me off was the enforcing of it to be the default option and the whole pompous attitude he had about it, claiming that it was exactly what Sierra, the artists, and everyone wanted and then proceeding to belittle me and avoid my arguments against enforcing it as the default option when I actually made valid points and twisted everything I said. Which just made the debate continue in circles needlessly with my trying to correct his misconceptions of my opinions and getting the subject back on track. The man was arrogant about it to say the least. To this day the undithering checkbox is not and undithering checkbox at all but a dithering checkbox which is enabled to "add" dithering, like it was never there to begin with. Just more evidence of that attitude. I understand the technicality that technically the dithered colours are their own values and could be represented as anything, but his assertion that those colours generated by his algorithm were actually something like what the artists were seeing when they drew these backgrounds and that Sierra created drivers that translated that down into the standard dithered 16-colour palette was just plain asinine.
Oh, I know. It wasn't just you. He was trying to belittle everyone that question having it forced on the user. No one was arguing it be removed. In the end it does not matter since as you note, it was dropped as default. It is over and done with.
Actually, it seems like all work on the SCI side of things just stopped cold suddenly for some reason.
It is mostly because they haven't made progress with SCI32, whether that is because they don't have anyone working on it and it has been shelved or it just has them stymied. Too bad as the few SCI games that I would like to be supported by the project are the Win only games. Let's face it. The FreeSCI project gave them a big leg up with SCI, but that help ended with SCI1, given that they had started on it before it was merged into SVM.
-
Troflip, I can't remember if I mentioned this or not and you had seen it. In SCI Companion 2.1.0.5, text resource lines can only be 259 characters long, yet in SCI Studio they can be as long as you want. Has this been fixed/were you aware of it? Also, the Windows copy/paste/cut shortcut keys don't work while editing text resource lines, even though you can right-click and perform these actions in the context shell menu.
One more thing, the text resource editor in SCI Studio has an entry for text line entry "names". Is there a purpose to these or are they used at all by the interpreter? Or is it merely just to make finding things easier?
-
Troflip, I can't remember if I mentioned this or not and you had seen it. In SCI Companion 2.1.0.5, text resource lines can only be 259 characters long, yet in SCI Studio they can be as long as you want. Has this been fixed/were you aware of it? Also, the Windows copy/paste/cut shortcut keys don't work while editing text resource lines, even though you can right-click and perform these actions in the context shell menu.
One more thing, the text resource editor in SCI Studio has an entry for text line entry "names". Is there a purpose to these or are they used at all by the interpreter? Or is it merely just to make finding things easier?
Yeah, I went through the forums and looked for SCI Companion bug reports when I picked this back up. The character limit has been addressed (or at least made very large).
The cut/copy/paste not working is super annoying, and I've fixed it just now. It's amazing all the hoops you have to go through to get basic stuff working like that in MFC (MFC has its own command system, and I have cut/copy/paste commands for general usage throughout SCI Companion, and they were blocking it from working in the edit control in the list - so I have to hook the keystrokes and forward them to the edit control when its active).
I just looked at the name thing in SCIStudio... it doesn't look like the names are even saved (if I save the text resource and re-open it, they are gone). So I'm not sure what its purpose is?
-
Wow. It IS amazing how much goes on under the hood. Thank you very much for the fixes. :)
-
Troflip, did you happen to address the number of cases a switch statement can have? I think it topped out at less than 20. Assembly support would be great too, though I suppose this is a non-trivial feature.
-
Troflip, did you happen to address the number of cases a switch statement can have? I think it topped out at less than 20. Assembly support would be great too, though I suppose this is a non-trivial feature.
This thread suggests the limit was with SCIStudio, not SCI Companion:
http://sciprogramming.com/community/index.php?topic=588.0
asm support isn't too difficult.
-
I might do that eventually. In a couple of the recent examples I've come across, the actual correct code isn't too hard to figure out when looking at it by hand. It's just gaps in my decompilation algorithms. But I have encountered some truly perplexing byte code - either heavily optimized, or perhaps Sierra's parser also supported asm, and these functions were written in asm. At some point, I have to say "I've done enough work on this", and just make sure I can at least detect I wasn't able to decompile it properly, and fall back to asm. At this point, I'd say I have issues with maybe one out of every 20 or 30 functions or so.
Well, ok, here's one example. The method "advance" from SQ5 script 26.
I finally had a chance to look over this. I tried working it out myself by hand. The bits before and after the loop are straightforward I guess, but the loop itself is a bit strange. It kind of looks like a for loop, but if it is a for loop then it doesn't have an end condition check. It feels like some sort of forever loop with a break statement, but there is loop initialization and re-initialization code in there, i.e. the first and third parts of a for loop. It doesn't seem to have the second part though (the condition), so I wondered whether maybe the its a "(for (initialization code) TRUE (re-initialization code) " or maybe a "(while TRUE " where the initialization code is before the while and the re-initialization code at the end of the code inside the loop. If it was something like this, we'd probably see some sort of evidence for the TRUE check though, unless the optimizer removed it. So maybe they had another type of loop that represented a forever loop and didn't require the TRUE.
The reason that I don't think the code that breaks out of the loop is the second part of the for loop (i.e. the continue looping condition) is because it seems to be in the wrong place. Normally that check would be at the start of a loop, not the end. Unless..., it is possible that everything within the loop is the conditional check and it doesn't actually have any code inside the loop itself?
I haven't yet come up with a firm idea of what I think it is but those are my initial thoughts.
-
Troflip, did you happen to address the number of cases a switch statement can have? I think it topped out at less than 20. Assembly support would be great too, though I suppose this is a non-trivial feature.
This thread suggests the limit was with SCIStudio, not SCI Companion:
http://sciprogramming.com/community/index.php?topic=588.0
asm support isn't too difficult.
Correct, companion doesn't seem to mind how big a switch is. I have had a few that are very large and haven't had any issue cycling through them or jumping to a specific case. That was an sci studio issue. I just popped open voodoo girl and the intro is sitting at 52 case statements and I don't have an issue with it.
-
I finally had a chance to look over this. I tried working it out myself by hand.
This is what I get when I work the loop out by hand. Does it look right to you?
(while (TRUE)
= temp0 self:at(temp3)
(if (IsObject(temp0) and (not (& (send temp0:signal) 4))
(if ((> (send temp0:nsLeft) -1) or (not (send temp0:isKindOf(InvI))))
break
continue // Impossible to reach
)
)
(= temp3 (% (+ 1 temp3) size))
)
Having the "continue" (which is not supported in SCI Companion or SCI Studio) doesn't really make sense, since it's impossible to reach it.
Another weird thing, which I've noticed occasionally in other scripts, is the "bt code_00cd" branches if true to "bnt code_00d3". The bnt is basically a no-op, since the branch will never be taken. The bt may as well just have branched to the instruction following the bnt. I suspect this is just an artifact of how Sierra compiled compound if statements, and it made no difference in actual functionality, so it wasn't changed.
-
Yeah, that definitely seems to match, exactly as far as I can tell. What I had was almost the equivalent using a for loop. But your version with the while loop matches it exactly. One thing I wasn't happy with about the for loop was the jmp to the top of the loop without executing the re-initialization code, which wouldn't happen in a for loop (the jmp I'm talking about is the redundant one, but its presence still suggests it isn't a for loop). A continue in a for loop would still execute the re-initialization bit, but not when its a while loop like how you've got it. So that solves that problem. It still feels like we're missing something though. The break followed by a continue suggests that something else is going on. Perhaps the original source had something different, maybe different keywords with slightly different behaviour, some optimisations might also be involved, but what you've got has to be the equivalent. It matches what the byte code is doing. I guess as long as what is generated is equivalent to the byte code, then it would be okay.
The extra jmp in the byte code is also unreachable, so it feels right in a way that the decompiled code also has unreachable code. But maybe the decompiler could drop it out to be cleaner? Without the continue, it is still equivalent. Maybe it could use the presence of it to determine that it isn't a for loop and then it ignores it after that.
Regarding for vs while loops, I noticed from the SQ5 decompiled scripts that they don't have any for loops in them. From what I can see, some of the while loops appear to be for loops in disguise.
Regarding your last point, it seems like there are a number of artifacts like the one you mentioned that the decompiler can probably ignore. I guess it has to know about them but can then ignore them once identified.
-
The break followed by a continue suggests that something else is going on. Perhaps the original source had something different, maybe different keywords with slightly different behaviour, some optimisations might also be involved, but what you've got has to be the equivalent. It matches what the byte code is doing. I guess as long as what is generated is equivalent to the byte code, then it would be okay.
I agree with you there. Surely this provides some extra clues regarding the original syntax, or maybe just their compiler's optimizations. But in the end, as long as the generated decompiled code is correct, that's good enough.
The extra jmp in the byte code is also unreachable, so it feels right in a way that the decompiled code also has unreachable code. But maybe the decompiler could drop it out to be cleaner? Without the continue, it is still equivalent.
Oh yes, I would drop it out.
Regarding for vs while loops, I noticed from the SQ5 decompiled scripts that they don't have any for loops in them. From what I can see, some of the while loops appear to be for loops in disguise.
A while loop and a for loop are pretty much indistinguishable, so I just turn any loop of that type into a while loop. My decompiler never generates for loops. You could play a guessing game to determine what went in the original init expression and loop expression, but there isn't really much point.
-
I've made changes so that that method in question can now be decompiled. The result looks like this:
(method (advance param1)
(var temp0, temp1, temp2, temp3)
= temp1
(if (paramTotal)
param1
)(else
1
)
= temp3 (% (+ temp1 (= temp2 (self:indexOf(highlightedIcon)))) size)
(while (TRUE)
= temp0 (self:at(temp3))
(if ((IsObject(temp0) and not (& (send temp0:signal) $0004)) and ((> (send temp0:nsLeft) -1) or not (send temp0:isKindOf(InvI))))
break
)
= temp3 (% (+ temp3 1) size)
)
(self:highlight(temp0 1))
)
Ideally, it would be nice to pull the "(= temp2 (self:indexOf(highlightedIcon)))" out of the expression and into a separate line. I think I *might* be able to do that.
Another method in that same script ("retreat", instead of "advance"), looks like it might have a genuine "continue" statement in it (instead of just the unreachable one). It fails to decompile, but I haven't investigated too deeply as to why just yet. The control flow graph for that one is really complicated.
-
I had a quick look at that script. Glancing over the byte code, it looks like it's function is to do the reverse of the advance method, which makes sense. So given that, I would have thought that the original source for the two methods would be very similar but iterating in the other direction, with temp3 being decremented at the start and on each iteration. A quick scan over it and this seems to be the case. So if the continue seems to be different in this case, it is probably an artifact of some sort and it might shed more light on the structure of the advance method as well.
ScrollableInventory is extending Inv in script 995. The same methods in Inv in script 995 look quite similar in structure. I wonder if it might help to look at that one in conjunction with script 26. Presumably they copied the same source for the method and made a couple of tweaks.
I just had an unrelated thought triggered by the above. Looking at subclass names might be a way of determining the original long names for some classes. For example, ScrollableInventory extends Inv. This to me suggests that the original long name for Inv is Inventory, which is fairly obvious in this case but we might find other examples like this that could shed some light on original class names.
-
So if the continue seems to be different in this case, it is probably an artifact of some sort and it might shed more light on the structure of the advance method as well.
The difference comes at the end. The code at the end of retreat looks like this:
(if (condition)
continue
)
doSomeStuff
) // end of infinite loop
That could still be rewritten like this:
(if (condition)
)(else
doSomeStuff
)
) // end of infinite loop
So it's not quite absolute proof that the original syntax supported a continue statement, it might just have been a compiler "optimization" that produced this code.
-
Today I compiled my first SCI1 script (SQ5). I am just focusing on recompiling the decompiled version of script 100. After checking that the script and heap resources looked fairly consistent with the original, and looked normal in SV.exe, I tried running the game.
It crashed in both Sierra's interpreter and ScummVM. Luckily with Scumm's debugging console I was able to track down the problem (see my other post in the LEA thread), and made a fix and it then worked in Scumm.
Unfortunately, it still crashes the Sierra interpreter. So *something* is different... *somewhere*.
-
Title screen of SQ5 with two menu entries swapped, and the background color of one of them changed.
-
:D :D
-
Title screen of SQ5 with two menu entries swapped, and the background color of one of them changed.
So does that mean you figured out the interpreter issue or is this a scumm shot
-
I figured out the issue, I posted about it in one of the other threads. Looks like many (all?) of the opcodes that don't have "wide" or "short" versions are only valid if they are the "wide" version (e.g. they don't have the last bit set). This is different than SCI0, and might indicate they were making (or made) room for other opcodes?
-
Have you had to make many changes to the compiler for SCI1/SCI1.1?
-
Awesome to see changes are possible on even a small level! :)
-
Have you had to make many changes to the compiler for SCI1/SCI1.1?
Specifically for the code generation for the compiler, I wouldn't say many, no.
I had to add asm support for when the decompiler fails (although that's unrelated to SCI1). A few opcodes changed behavior, so I had to make some small changes there. I had to support using if statements and switch statements as epxressions.
Reading/Writing the script resources is completely different in SCI1.1 though. And there are 9 default properties for a class instead of 4, so I had to change anywhere my code made that assumption. Though it's not strictly related to the compiler, those were a lot more significant changes.
There are still a few more changes to make. Script local variables can contain pointers to strings and objects, so I need to support that in the syntax. And I'd like to do do something about the and/or conditions. SCI Studio ignores all parentheses for grouping and/ors together, but that is counter to nearly every programming language, and the decompiler generates code that relies on those parentheses. This will be a breaking change - I don't know if the SCI Studio template game would be affected or not. Not sure what I'm gonna do about this yet.
-
If you are talking about Brian's SCI1 template, it is not quite complete anyway. If the SCI0 template what about a new template? Or I suppose you could have two compilers, the old one and the new one and have the GUI call the one that matches the interpreter of the game being compiled. This could give the best backwards compatibility for old projects.
-
I was talking about the SCI0 template. There's no functioning version of SCI Studio that can compile SCI1, so no worries there.
But yeah, ideally I'd like to keep syntax compatibility for SCI0 as much as possible between SCI Companion and SCI Studio.
In SCI Studio (and SCI Companion, currently) the following code executes the branch and prints "hi".
(= a FALSE)
(= b TRUE)
(= c TRUE)
(if (a and (b or c)) // SCI Studio treats this as (a and b or c)
Print("Hi")
)
It shouldn't though. And my decompiler will construct compound conditions like that that it expects to evaluate to false.
-
I was able to compile the main script in SQ5 and it "works"!. That's pretty significant. I say works, because it works until someone calls an export in main and gets the wrong export, since I'm not preserving the "mystery" empty slots in the export table. Assuming that's the problem, it should be an easy fix. But it works enough to be able to walk around in the game a bit.
-
Wonderful!!
-
I've now compiled most of the "core" decompiled scripts in SQ5 and been able to run the game with no apparent bugs (I'm sure there are still some/many, but they are not apparent in just walking around a handful of screens, using the inventory, bringing up dialogs, etc..).
The decompiler still has some cases where it produces bad code, but I am not going to spend the time fixing it. It's 99% there, and I can keep a small list of places that produce known bad code.
So the next step is to try to distill SQ5 down to a bare-bones template game. I'd rather use the LSL6 interpreter since it's a little newer and we know it supports 16-bit audio. But the bare-bones game is going to include at least some residual "look and feel" (i.e. the UI) code from the game it was sourced from, and the UI from LSL6 seems too stylized. Hopefully the same base code will work on the LSL6 interpreter, we'll see.
-
I would think that it would mostly be a matter of the graphics that would be the biggest difference. I agree that for a template game the UI should be more generalized rather than stylized.
-
Exciting! To make things possibily easier, I wouldn't mind helping to modify some graphics for a template game for a more neutral/generic style. We're going to need all sorts of VGA things too like Ego, cursors, test inventory object (maybe?), etc. Many of those being outside my skill set. Maybe we could get something similar to the SCI0 template game's Ego (blue shirt, gray pants) but in VGA. Maybe captured somehow? Anyone have a blue tshirt and grey pants? lol
Here's a question, how is the color/style of the GUI windows set? They're not based on Views, right?
-
I think they are views since they are animated. You could check with SV to be sure. Once we have some VGA tools we can use for the task we could have a community contest for graphics for the VGA template. That could be fun. It wouldn't be so bad to have a few different styles of UI for a developer to choose from depending on the nature of his game. Ego will have to have loops for moving diagonally.
-
The buttons yes, but the actual GUI window borders and colours? Great idea about the community contest! Of course, that's perfect.
-
The buttons yes, but the actual GUI window borders and colours? Great idea about the community contest! Of course, that's perfect.
From playing around with the decompiled scripts, mainly from sq4 but I see alot of the same basic scripts in sq5 as well, there is a BorderWindow script which is used to generate the primary print statements and whatnot. Inside of that script, is also an InsetWindow class, which kind of lets you put a bordered window inside of a bordered window.
I got this more or less working in sci0, the bordered window came out perfect during the titlescreen but somewhere between it and initrooms the windows that came out in the actual playable room lost the correct border colors on the left and right side :P but anyway... each of which can be set separately as well the overall border width and the underlying window shadow.
topBordColor 7
lftBordColor 6
rgtBordColor 8
botBordColor 3
bevelWid 3
shadowWid 2
So Basicly, in main where we have
(send gTheWindow:
color(gWndColor)
back(gWndBack)
)
...
(instance theWindow of SysWindow
(properties)
(method (open)
(if(< Graph(grGET_COLOURS) 9)
(if( (< color 7) or (== color 8) )
= color clBLACK
= back clWHITE
)(else
= color clWHITE
= back clBLACK
)
)
(super:open())
)
)
The instance would change from a syswindow to an instance of borderwindow, and then all those new attributes could be set in the init bit that is posted first.
As for the system options, not sure what else to call it, the window with the save, restore, speed, volume sliders etc. All of the elements of that window are graphical in that they make use of views but from what I can tell they appear inside a type of borderwindow. The finer points on sticking clickable views and whatnot for that one are still beyond me.
-
And a lot of the games only had the GUI bar visible when the cursor was at the top. I think that some even had a sliding from the top bar. And if you look at all of the pic resources of the SCI1-1.1 games they did not include the bar, thought with perhaps a black bar at the top.
-
I think they are views since they are animated. You could check with SV to be sure. Once we have some VGA tools we can use for the task we could have a community contest for graphics for the VGA template. That could be fun. It wouldn't be so bad to have a few different styles of UI for a developer to choose from depending on the nature of his game. Ego will have to have loops for moving diagonally.
That's a great idea.
Once I have the basic SCI 1.1 template game working (I doubt it will take very long), I can release an alpha build of SCI Companion, and people can try it out and help figure out what all the various classes do and how they should be used (in addition to making sample view/pic resources). There's a lot of stuff in there I don't understand!
-
Here's what the message editor is looking like so far...
-
I thought of a useful idea for debugging games. It seems like it would be possible to have the ability to print debug messages and have SCI Companion pick them up and display them while you're running the game. From what I understand, SCI Audio writes to a file, and a separate process reads from it in order to know what mp3 to play. Seems like this debug functionality could be implemented in a similar way. Given the lack of a built-in debugger in the SCI 1.1 interpreter, it seems this would be pretty useful.
-
Perhaps Gumby's SCI Logging is a better fit for your purposes. http://sciprogramming.com/fangames.php?action=review&id=189
-
I've spent the last few hours trying to get the SQ5-based template game running on the LSL6 interpreter, but with no luck. I don't think it's even getting to the play method of the main game class, which should be the entry point of the game. There's no error, the program just closes. In Scumm it works fine.
The only thing it DOES show is an orange hand cursor for a split second. Originally I assume this must mean that it at least succeed in starting the game, but I think this cursor must be actually built into the interpreter.
- The original SQ5 shows a grey arrow briefly, then a grey hand briefly (before starting the title screen, which has no cursor).
- My template game (both running on SQ5 interpreter and LSL6 interpreter) show an orange hand (before going to the title scren, or exiting, respectively). If I modify the cursor that looks identical to it (but it grey), view 997, the orange hand doesn't change shape.
- ScummVM just goes straight to the title screen without showing any initial cursors
That's why I think the cursor must be built into the interpreter. However, it must be using a palette from the game, given that it ends up being a different color. I'm not really sure what's going on here.
Another weird thing is if I remove the interp.err file from the directory, the exits even more quickly (without showing the cursor at all). The interpreters are obviously very picky about what exists where.
Anyone have any ideas?
What I did was I took the LSL6 folder, replaced the resource.map and resource.000 with those from my template game. Then I exported the 65535.map resource from LSL6 (which list the entries in resource.sfx) and imported it into the template game. I also deleted the patch resources (i.e. the instrument patches) from the template game and replaced them with those from LSL6, just in case that made a difference.
-
Sierra's interpreters are indeed very picky about which games they work with. In particular, a resource called vocab.994 tells the interpreter where to find certain properties of certain classes for quick access. It needs to match both the interpreter and the game; recreating it would be quite a task. The timing loop performed during game initialization is one place where this is used. Now, vocab.994 has the same length in LSL6 and SQ5, but they are different according to SV. You may be able to transfer it between the two games, but don't count on it. ScummVM ignores this resource.
- My template game (both running on SQ5 interpreter and LSL6 interpreter) show an orange hand (before going to the title scren, or exiting, respectively). If I modify the cursor that looks identical to it (but it grey), view 997, the orange hand doesn't change shape.
I'm not quite sure what you are trying to say here.
- ScummVM just goes straight to the title screen without showing any initial cursors
This is probably a speed issue. ScummVM does show the cursor if you break in the debugger (--debugflags=OnStartup is nice...)
That's why I think the cursor must be built into the interpreter.
There was code in some SCI01 interpreters (and perhaps SCI1) to display a view before handing control to the scripts, but it is not there in LSL6.
-
I'm not quite sure what you are trying to say here.
Basically I'm saying that the orange cursor I see must be built into the interpreter, since it doesn't appear in any of the game's resources.
I tried putting a Wait(120) at the beginning of the play method in script 0. In Sierra's interpreter, I see (and can move) the cursor for 2 seconds before the game starts (except in the case of my LSL6-SQ5 mashup, in which case it still exits immediately). ScummVM doesn't show the cursor, so I don't think it's a timing issue.
-
Sierra's interpreters are indeed very picky about which games they work with. In particular, a resource called vocab.994 tells the interpreter where to find certain properties of certain classes for quick access. It needs to match both the interpreter and the game; recreating it would be quite a task.
Help me understand this 994 resource a bit better. If I understand correctly, looking in SV.exe, the number in the left column (which just increases sequentially) is an interpreter-specific thing. Like in LSL6, 16 might be "Motion.x", but in SQ5, it might be "Actor.cycler".
Then the actual data (the number in the right column) refers to the index in an object at which that property would be found? So if you had:
16 61
The LSL6 interpreter would say, for example, "I'll find the x property at index 61 in this object which should be a Motion class".
Is that roughly correct?
If my understanding is correct, then comparing the LSL6 and SQ5 vocab.994, I see a few ranges of items where the property index number is just off by one. This would mean that some class in LSL6 had an extra property added (somewhere between index 10 (which is not off by one) and 33 (which is)), and so any entries that referred to properties after that class would have a value of one higher in LSL6 (it looks like the "case" property was added to Feature, so that might account for that).
Since all I see are a few ranges where things are off-by-one, it also suggests that the interpreter-specific list of properties in both interpreters is the same (otherwise I would expect things to be wildly different). If that's true, then I'd want to keep the SQ5 vocab.994, since it will match the object hierarchy from the decompiled SQ5 scripts.
-
The LSL6 interpreter would say, for example, "I'll find the x property at index 61 in this object which should be a Motion class".
Is that roughly correct?
That is about right, except the interpreter can't tell whether it's looking at an instance of the right class or the right property. Mismatches here will lead to chaos, though I would expect crashes or odd behavior rather than a clean exit. Does DOSBox somehow treat crashing processes differently than real DOS?
Other properties than those referred to in that table are also used, but the lookup is done via ordinary selector numbers. Even method calls. Any failures here should lead to an Oops! error, though.
I can think of a few other failure sources, but they should all lead to crashes or odd behavior, and they all require the scripts to run in the first place. I suspect you are mistaken, and they do.
Have you tried using File objects or kernel calls to trace execution? I'm thinking you could instrument specific functions to write a text string to file; that way you don't have to make sure things are set up properly for Print. The LSL6 interpreter does have support for a second monochrome monitor - and a kernel call to write to it - but I have no idea how to convince DOSBox to emulate one. Otherwise, that might have been the easiest way.
-
Yeah, I tried writing something to a file as the first thing in the play method (the play in the Game instance in script 0 is the first code that's run, correct?), but it was never created. And like I said, the DOSBox still exited immediately if I put a Wait(120) there. So the play method is never even executed.
I guess if I really wanted to try to make this work, I could start debugging the interpreter with the DOSBox debugger.
-
Does anyone know how the interp.err file (which is mandatory) is used? Would those errors be logged somewhere by the interpreter? That might help me find the problem.
Edit: ok, well I just answered that myself. I was always running DOSBox with -exit. If I remove that, then I get the error causing the problem:
Stampver error: 360-4294962636
Script #: 0, IP: 0
Which is E_VER_STAMP_MISMATCH in the interp.err file. Now as to how to fix it...
I'm guessing IP means instruction pointer? 0 probably indicates the game code has not started executing yet, which corresponds with my observations.
-
I'm guessing IP means instruction pointer? 0 probably indicates the game code has not started executing yet, which corresponds with my observations.
Yes, the -exit flag would explain things. :)
Anyway, this has two parts: There is an interpreter version stamp inside the .EXE, and another somewhere in the game. Looking at the interpreter, it seems to be read from the RESOURCE.MAP file, right after the initial index pointers. So you would have something like (in hex):
80 (view) 0004 81 (pic) 017c 82 (script) 0362 etc. FF FF (8 bit garbage) (32-bit version stamp)
The version stamp in this case should be 139C hex. (360+0x1234).
Doing this, however, causes the game to crash hard; but I think it does enter the script code now.
EDIT: I was doing this by changing the SQ5 resources to match the other interpreter, but I must have overwritten the pointer to 0.V56 in the map (the list of views came to overlap with the version stamp). So a simple hex edit won't do. Sigh.
-
Ok, I changed my code that outputs resource.map to insert the version stamp there. And now it gets into the game! Eventually it throws up a 100.msg not found because rm100 event handler falls back to doVerb (I didn't notice at first, but ScummVM says missing message resource too, but it doesn't crash). This is different behavior than on the SQ5 interpreter, so *something* is different. Maybe GetEvent returned different data, I don't know yet. Adding a 100.msg worked around the issue, and I was able to get into my template game's first screen and walk a character around, look at my inventory, etc...
-
Excellent news!!!
-
So the difference is that the first event received is evMOUSERELEASE, instead of evMOUSEBUTTON.
It looks like this is just a difference in the interpreters. Playing the unadulterated LSL6, you'll notice (in DOSBox), focus isn't set on the game right away (the windows cursor is still shown), and the first mouse down just gives focus to the game. But in unadulterated SQ5, the windows cursor is not there - the game already has focus. So it receives the first button down.
-
The Windows cursor will only show if you have autolock set to true and DOSBox has not yet captured the cursor. If it is set to false or DOSBox has already captured the mouse there simply is no cursor until you click in the game or hit enter. In either case the cursor flashes briefly at the very start of the game and then disappears. It looks like they were simply trying to hide the cursor for the credits and the first click bypasses the intro.
-
I may have an "alpha" release of SCI Companion available later tonight, with a SCI 1.1 template game functional enough to play around with (I even managed to make my own palette cycling title screen!)
Unfortunately I'm having problem with audio resources, most likely due to mixing SQ5 with the LSL6 interpreter. Sound effects just sound like big buzzing sounds!
-
:D Can't wait to play with it!
-
Here's a link (http://icefallgames.com/Downloads/SCICompanion.zip)
I won't keep it up there for too long (there are still some Sierra view resources in there, so I don't want to keep it up there).
You should be able to Create New Game, and choose SCI 1.1 template, and it should run (and compile).
Of course, you'll need DosBox, and right now the cmd file that runs it has a hard-coded path to c:\Program Files (x86)\DOSBox-0.74
You'll notice the terrible audio problem when you enter the first room (Feel free to remove brookSound and recompile :-) ).
A few more notes:
- snd resources are not supported for SCI 1.1, in fact trying to open them might crash. However, snd resources are supported for SCI0! You can import midi and set cues and stuff. Aud resources are fine. You can drag wav files into the audio resource view and it will add them, and you should be able to preview them (of course, they aren't working properly in Sierra's interpreter (ScummVM is fine)).
- I have barely tested anything with this release, so I'm sure there are lots of bugs. I haven't been focusing on SCI1 at all, so it's possible I've made some assumptions to make things work well with SCI1.1, and broken other VGA-ish resources in SCI1.
- You should be able to edit SCI1.1 views, palettes, pics, messages, and of course scripts.
- right now there is still sort of a need to occasionally "rebuild resources". For SCI 1+ there are no longer any duplicate resources in the resource.map, but they are still in the package files (just haven't bothered to code that up yet). There is no ill effect, except your package file will get larger and larger the more times you save a resources (and SV.exe will show the old resources, which will in turn crash it when it tries to cross-reference mismatched heaps and scripts)
If you want to play around with the Decompiler, it's in the script menu under "manage decompilation". Generally you would start with "Set Filenames" to give things good filenames, and then you can shift-click to select all scripts and click Decompile. As it decompiles them, it will find better names for global variables, so you might want to them Decompile them all a second time to fix up the scripts with the proper global variables.
Finally, the main thing I hope people do is play around with the SCI 1.1 template game, and see what the various classes do. For instance, why does the main character spin around when he changes direction in the first room (110), but not the second room (105)? (which is accessible by walking south from the first room - you have to click right on the bottom edge of the screen). What about setting up poly paths, and trying path navigation? What's the best way to set up interactive objects or areas of the screen?
The left-hand pane has quick links to switch between message and script resources (which will be a common thing, as message resources are pretty core to SCI1.1). In the first room I added one object that responds to the look verb. Try to add messages that make it respond to other things. Maybe play around with trying to get different talkers working?
If anyone wants to take a stab at making some resources for the template game (like a main character resource that can be used legally), that would be wonderful.
-
Oh, and this is how I went about making the color cycling title screen (it took a while to figure out a workflow, during which I implemented a gradient creation feature in the palette editor).
- I made an image in photoshop with a red-blue gradient that defined the cycling range (and I left the background black) (see attached image)
- Then I created a new pic in SCI Companion, and clicked on the "edit palette" button (just above the palette in the left-hand pane). Then I selected a range of colors (from 64 to 254) by shifting clicking in the palette editor dialog. That enables the Gradient button.
- I choose pure red and pure blue for Color A and B, gradient type "A-B", then hit ok
- So now the pic has a red-blue gradient in its palette. From here, I can right click on the pic, and choose "import bitmap to pic". (For VGA pics, this will actually insert the image into the pic directly, instead of converting it to vector). By choosing "Map to current pic palette", then Accept, I now have a pic with an image whose color values vary smoothly across the image. So the red/blue gradient was just a temporary thing so that I could map the color indices to what I needed
- Then I went back and edited the palette again. I selected the same range of colors, but this time chose a "B-A-B" gradient, and put in whatever two colors I wanted. So now, the left and right side of the image might appear the same green, but they are actually two different color indices. This is what lets me cycle the palette continuously and smoothly.
- Finally, I call Palette(palANIMATE startColor endColor -1) in the room's doit method.
-
Finally, the main thing I hope people do is play around with the SCI 1.1 template game, and see what the various classes do. For instance, why does the main character spin around when he changes direction in the first room (110), but not the second room (105)?
Actually, it doesn't work either if you exit to the second room and then go back to the first one. And the reason is simple: the ego setup code is inconsistent and incomplete.
The instance responsible for ego's turning is stopGroop, and it happens to be set in the game's init (why?!?) but not in the subsequent room inits. The result of this is that it is reset to 0 as soon as you exit the first room. I tried reworking the room inits to use SetUpEgo consistently, and put this line in SetUpEgo:
(send gEgo:setLoop(stopGroop))Then it worked (on the other hand, I had to take out the setCycle call because it referred to a nonexistent view; I'm sure the more artistically minded among us could fix that more properly by actually making a view...).
-
Ok, the audio issue is fixed by switching audio drivers in resource.cfg. I changed it from audblast.drv to audisny.drv, and now I hear the sounds just fine. Are there any recommended drivers? Can I assume that one that works with DOSBox on my machine will work with DOSBox on any machine?
-
This is very good work!
For the polygons/paths, I would suggest some sort of way to show them overlaid on the pic they belong to. Maybe by highlighting a list of numbers in the source and clicking an icon, maybe locating polygons automatically via the decompilation and showing them in a list. I'm sure others could come up with other ways of implementing it. It's probably best if there is some degree of commonality with the placement of objects (you seem to have such a feature planned?)...
-
Yey!!
Here's a question, how would one set hotspots for the VIEW-based cursors in 1.1?
EDIT: One other, I was going to attempt to make a VGA ego view but there doesn't seem to be a way to export palettes, unfortunately. Would make editing some sprites easier by being able to use a third-party image editor like PSP.
-
I also have a suggestion. You have the functionality to import animation frames over multiple files. Is it possible that you can import animation frames from an animated GIF as well? I ask because SCI Viewer can export SCI loop animations as a GIFs. I'm working with an image editor similar to Deluxe Paint that can edit 8-bit images more easily and edit each animation frame in a GIF. I'm using Sierra views as a reference so that export feature from SCI Viewer is welcome. It would speed up production all the more if SCI Companion was able to import in the same way, seeing as that's how I'm editing them.
-
W-D40 ego view!
I found your audio problem. It is a mismatched SB driver. You used the one from LSL6, but if you use the one from SQ5 it works. Not sure if this limits the quality of the sound resource.
-
I am not sure if we want to start a new thread for some of this stuff or not, but I have started in the main script and just going down through it.
I see the cursors are now set up to views. gCursor points to 999 which is the arrow, and gInvisibleCursor points to 997 which is the hand... 996 is actually a transparent view.
Should the invisible cursor point to 996 instead or is the variable name actually supposed to be something like gLoadingCursor?
Edit: Nevermind, it looks lik in the public class of the Game, the invisible cursor is reset to align with view 996... Theoretically, couldn't the line in the public class be removed if we reset the default to just point to 996 initially? Paranoid about breaking things already... This is going to be a lot to digest. But in a good way
-
EDIT: One other, I was going to attempt to make a VGA ego view but there doesn't seem to be a way to export palettes, unfortunately. Would make editing some sprites easier by being able to use a third-party image editor like PSP.
Oops! Yeah, that functionality is on a list somewhere, but I forgot about it for this release. Not only that, but the way to edit embedded view palettes is not obvious in this release (I want to revamp the entire left pane for views, so I delayed putting it in there). To get to the embedded palette, choose View->Edit Palette. And then try clicking on the Export button which.... does absolutely nothing right now ;)
(I was also working on gif import at one point).
I found your audio problem. It is a mismatched SB driver. You used the one from LSL6, but if you use the one from SQ5 it works. Not sure if this limits the quality of the sound resource.
Yup, see above, I found that by switching to auddisny.drv instead (from LSL6), the audio came back. I don't know if it's mismatched though. Yes, the audblast.drv was from LSL6, but it *should* be, right? since that matches the interpreter and audio format. There's nothing in the game code itself that matters (the Sound class is nearly identical).
I am not sure if we want to start a new thread for some of this stuff or not, but I have started in the main script and just going down through it.
Rather than dirty up this thread, I'll start two new threads in a minute here: SCI 1.1 Template Game discussion, and SCI Companion discussion...
I ask because SCI Viewer can export SCI loop animations as a GIFs.
It can?? I see the option to save as a .bmp, but not .gif.
-
If you select export on a View loop that has more than one cel you can change the file type. It has selections for BMP and GIF. Exports the whole loop. Again, with the version without a version number.
-
Ah, indeed, I found it. It turns out it's not hard to import gif sequences. However, my whole image sequence importing workflow hasn't been updated for VGA (so that's something I need to do - how to resolve palette conflicts, etc...). But it works fine with EGA! I exported the ego from LSL6 using SCI Viewer, and imported the gif into SQ3:
-
That is so cool. :)
I'm looking forward to trying this out when I get a chance.
-
I found your audio problem. It is a mismatched SB driver. You used the one from LSL6, but if you use the one from SQ5 it works. Not sure if this limits the quality of the sound resource.
Yup, see above, I found that by switching to auddisny.drv instead (from LSL6), the audio came back. I don't know if it's mismatched though. Yes, the audblast.drv was from LSL6, but it *should* be, right? since that matches the interpreter and audio format. There's nothing in the game code itself that matters (the Sound class is nearly identical).
Switching drivers in the RESOURCE.CFG is an old way to bypass SB audio glitches, usually using Thunderboard instead. The reason that I said mismatched is that I have done a fair amount of experimentation with alternate and hacked drivers, usually to solve minor SB problems of popping, occasional static or initialization issues (not all SB initialization problems can be solved with GOSiERRA.) That exact same buzzing, memory issues, looping sound and failures to initialize are very typical problems with the use of incompatible drivers between SCI versions.
-
I have basic playback of SCI1+ sound resources working now. Shouldn't be too hard to get midi import and saving working too (given I already have that for SCI0).
-
Do you have a way to work with PATCH files? I'd like to support the MT-32 in my games specifically. Does the PATCH format differ very much between SCI0 and SCI1/1.1?
-
I don't know anything about patch files. What should they let you do, add different kinds of instruments? I don't think the specs are documented anywhere...
As for MT-32, the SCI1 games I've looked at seem to support it, so I'm not sure what would be missing?
-
I don't know anything about patch files. What should they let you do, add different kinds of instruments? I don't think the specs are documented anywhere...
They are driver specific, so general support would be quite a task (and unnecessary). In practice, support for one or two might do.
-
Why not just use the patch resources from LSL6 if that is where the drivers for the template game are from?
-
The MT-32 PATCH file is for user-programmed System Exclusive instruments (and also the LCD messages on the MT-32). NewRisingSun created a tool for me that allowed converting SYX files with custom instruments for the MT-32 into SCI0's PATCH format so I could use my own user-programmed instruments (he also made one for the Adlib PATCH file to convert patch banks created with the old Adlib InsMaker program). This was a staple of Sierra games. Every game had unique instruments programmed by the composer (mostly Ken Allen). To use another game's PATCH files would work...but it is limiting to a composer like me. I'm not interested in General MIDI. MT-32 sounds better.
Maybe I should hit him up again...he hasn't responded to any of my recent PMs, though.
-
Do we know for sure that the patch resource format changed between SCI0 and later versions? Maybe you can still use that tool, and plop the resulting patch in a SCI1 game? Should be easy to test out anyway.
-
Maybe I should hit him up again...he hasn't responded to any of my recent PMs, though.
He has been on VOGONS lately and responds to PMs there. You can try shooting him a PM there.
-
That's where I was PMing him. Way back around when he first released that KQ4 patch.
They're not the same format. During my early years I would experiment a lot with files with the old DOS SCI Decoder programs. PATCH files don't work between SCI0, SCI1, or even SCI1.1 files.