Author Topic: Possible new version of SCI Companion  (Read 98157 times)

0 Members and 1 Guest are viewing this topic.

Offline Collector

Re: Possible new version of SCI Companion
« Reply #30 on: March 19, 2015, 08:06:23 PM »
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?
KQII Remake Pic

Offline MusicallyInspired

Re: Possible new version of SCI Companion
« Reply #31 on: March 20, 2015, 09:33:00 AM »
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.
Brass Lantern Prop Competition

Offline troflip

Re: Possible new version of SCI Companion
« Reply #32 on: March 20, 2015, 01:19:39 PM »
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).
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline MusicallyInspired

Re: Possible new version of SCI Companion
« Reply #33 on: March 20, 2015, 02:16:38 PM »
Nice! Great progress!
Brass Lantern Prop Competition

Offline troflip

Re: Possible new version of SCI Companion
« Reply #34 on: March 21, 2015, 05:12:43 PM »
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.
« Last Edit: March 21, 2015, 06:34:49 PM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline MusicallyInspired

Re: Possible new version of SCI Companion
« Reply #35 on: March 22, 2015, 03:09:31 PM »
I never keep backups anyway in my SCI0 games. I delete the extras as soon as I save.
Brass Lantern Prop Competition

Offline Collector

Re: Possible new version of SCI Companion
« Reply #36 on: March 22, 2015, 04:36:40 PM »
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".
« Last Edit: March 23, 2015, 05:47:53 PM by Collector »
KQII Remake Pic

Offline troflip

Re: Possible new version of SCI Companion
« Reply #37 on: March 22, 2015, 05:04:18 PM »
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):



Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Collector

Re: Possible new version of SCI Companion
« Reply #38 on: March 23, 2015, 04:28:09 AM »
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.
KQII Remake Pic

Offline MusicallyInspired

Re: Possible new version of SCI Companion
« Reply #39 on: March 23, 2015, 09:33:37 AM »
Great ideas!
Brass Lantern Prop Competition

Offline OmerMor

Re: Possible new version of SCI Companion
« Reply #40 on: March 23, 2015, 02:24:38 PM »
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!"  ;)

Offline Collector

Re: Possible new version of SCI Companion
« Reply #41 on: March 23, 2015, 05:44:05 PM »
Reminds me of the old AGIVS program for AGI development.
KQII Remake Pic

Offline troflip

Re: Possible new version of SCI Companion
« Reply #42 on: March 26, 2015, 12:17:04 AM »
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):




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...
« Last Edit: March 26, 2015, 12:22:09 AM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Collector

Re: Possible new version of SCI Companion
« Reply #43 on: March 26, 2015, 02:49:30 AM »
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.
KQII Remake Pic

Offline troflip

Re: Possible new version of SCI Companion
« Reply #44 on: March 26, 2015, 03:22:45 AM »
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.
Check out my website: http://icefallgames.com
Groundhog Day Competition


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.038 seconds with 22 queries.