Kevin, On Sun, Nov 20, 2005 at 04:37:14PM -0800, kevin wrote: > Hi Christopher, I'm not really an IRC chat type guy, plus I doubt that > anybody is listening heavily on irc under the subject for SCI stuff at this > late date.
No worries, there are always people there (I at least am almost always logged in, even though I don't always check what's going on ;-) > But here is what I can do for this project, I am a old-timer 2d/3d game > programmer and I only need the resources to reconstruct a game, don't > really need to worry about pixel scaling problems, or sound issues, or > game save problems. What do you mean by "reconstruct" here? Should I imagine this as something similar to what the Tierra guys are doing? > As I am planning on resurecting some existing code > that will do everything the sierra engine did and more. The only real > challenge will be interpretting the script language. Well, you probably won't find ready-made systems that properly support their sound cueing system and the text parser (if you want to go for SCI0), though you can probably get their z-buffered graphics system out of OpenGL with some tickling. > I am thinking that > it will be a matter of post-processing it into Lua. And re-creating code > for all the hooks of the original script into whatever the resources > formating needs are. So your goal is effectively to replace the virtual machine part with a binary (dynamic? static?) from SCI bytecode into Lua bytecode? Lua is a dynamically typed language with support for dynamic dispatch, so I see no inherent issues on that end. Sierra's array support may be a little awkward in that context, but that too can be solved (by treating everything as an array during the translation). Note, however, that it is possible in SCI to get references to the stack and to points in the current "script", and to use these references for strings. With a little bit of keeping-your-fingers-crossed, you may be able to emulate that with a hashmap, though. My understanding is that "Conquest of the Longbow" uses a dialogue system for which some amont of closeness to the original VM is neccessary; I'm not sure which low-level hacks are used here. I'm not sure if this will buy you anything over using the FreeSCI VM, but it is a different and somewhat interesting challenge in its own right, so I see why you might want to prefer that approach. > Absolutely the first step in porting any game over, is to make sure > before beginning, that all the resources are separated and the format > understood. We seem to have a fairly decent understanding of them at this point (at least Lars has). > Forget about writing game emulation code until all the > resources are extracted and their format understood. I'd rather not. That's a bit detrimental to motivation. In general, though, I believe that all of the SCI1-and-below stuff and possibly all SCI1.1 resources (not sure about compression) are understood, the exception being some subtleties of the Said() kernel call. > I do have time to hook up a very powerful 2D game engine that can be used > to play sierra games and even allow you to Mod the games. And even play > them at higher resolutions than even the resources were designed for. Great! Note that the FreeSCI graphics subsystem has full support for graphics with a bit depth of up to 24 (8 red, 8 green, 8 blue) and 8 bits of transparency (though we only have very limited support in the graphics backends for drawing this). To avoid duplication of work, I highly recommend that you have a look at what we've done so far. FreeSCI's graphics subsystem currently improves SCI graphics in the following ways (check the README for info on how to set this up in your config file): - Scaling pixmaps by a handful of filters - Modifying graphics in the configuration file by changing the specific palette used by pixmaps - Scaling SCI0 background graphics (which are vector graphics with flood filling) Here's an example of what all of that put together looks like: http://www.teksolv.de/~jameson/palette-config-demo.png It's not perfect, and any help would be appreciated, but I believe that we have the infrastructure to accomodate for many other options, such as completely replacing cels or pics. If you're interested in re-using our graphics subsystem, please feel free to do so and to ask any questions you might run across! > But I am hoping that somebody has already extracted (or can just re-run > the extraction tools) and can provide all the resources separately. Sciunpack will extract everything for you. Within the FreeSCI engine, you can use the resource manager to access data "as if you had decompressed it". Let me know if you would like details and I'll look up the header files for you. > Because I dont have the time to hack and poke at the resource files to > figure out how they are put together. Does anybody on this list have a > harddisk full of the separated resources? namely kq5 which I am most > familiar? I haven't tried sciunpack with non-SCI01 games, I'm afraid, but at least for SCI1 games it should work. > If somebody could do that, then I could quickly reconstruct the game. The > minimum I would need is... > > Background images Those are the so-called 'pic' resourcs. > Sprite images Those are 'cels', grouped in 'loops' grouped in 'view' resources. > sound files (midi, and wav) 'sound' resources (SCI1 may have additional wave resources, I keep forgetting). I'm not sure if KQ5 already had GM support; earlier games didn't (GM hadn't been defined), so you will also need instrument maps to estimate the approximate GM instruments (or to derive the proper MT-32 instruments, or the proper AdLib settings); cf. 'patch' resourcs. > hotspot files (tells the script what to do when areas are clicked) There is no such thing in SCI, to my understanding (Lars, feel free to correct me here). Polygons (not implemented in FreeSCI) are (sometimes?) used for this task; these are stored as part of 'script' resources (they can be updated dynamically). Also, the control map (maybe even the priority map?) is sometimes used for this purpose in SCI0, i.e. it's stored implicitly in 'pic' resources. > path following files (tells script where avatars can and cannot go) cf. hotspot, above. Where someone can go is defined both by polys (where present) and by the control map, though scripts can override this in many ways. > Script files Class definitions, objects, external objects and functions, locals, relocation pointers (for the linker) etc. are stored in 'script' (and, in SCI1.1, also in 'heap') resources. > Or better yet, the resource file is so well understood, that the original > resource file could be left as is, and the engine could pull these > on-demand (just like the original game). I strongly recommend that you have a look (a) at our documentation and (b) at our header files (which are intended as API documentation). It seems to me that you might save yourself a lot of worries by making sure that you know at least the more interesting chunks of the functionality already provided by FreeSCI. I recommend that you get the latest version of our SCI documentation from CVS and build it from there (only LaTeX is needed for that); if that's an issue, let me know and I'll update the pdf I have at http://www-plan.cs.colorado.edu/creichen/freesci/sci.pdf Also, please do not ask for game data or offer game data on this mailing list or in the IRC channel. The Sierra games are still under copyright by whoever owns them these days (Vivendi, I think), and redistributing them without permission is illegal-- and one of our most fundamental goals in FreeSCI has remained to remain legal (which is also why we're not using decompiled sources as basis for our implementation). -- Christoph _______________________________________________ FreeSCI-develop mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freesci-develop
