Looks like we managed to beat our previous record once again: Just over two years since 0.3.4 was released. I guess we all are getting older, more mature, more dedicated to our other projects, and more lazy overall... but before I go off into mindless rambling, le tme rather summarise what's new, and what's improved. First, we have a new port: FreeSCI now works on the GP32 handheld, thanks to Walter van Niftrik's dedicated work. Work on other handhelds is underway and will be announced when it's ready. Unless you're a member of the GP32 user crowd, the change you're most likely to notice instead are Hugues Valois' new game selection screen: If you have a properly configured ~/.freesci/config (or platform-specific equivalent) but don't specify a game name or directory as parameter to FreeSCI, Hugues' game selection screen will now pop up and ask you to choose one of your registered games. The next most noticeable change is the default sound setup: We now no longer default to GM output, but instead to OPL/2 software emulation. On many platforms, timing is still suboptimal; this we hope to address eventually by backporting the Glutton sound subsystem. Other changes are optimised background image drawing (for the "unsophisticated" case, important for low-power and low-res devices), support for the "Show()" kernel call (for walking around on the priority and control maps, useful primarily for SCI game developers), and the usual lot of bug fixes. That's it for this iteration; enjoy! --- 0.3.4 --- One year in between releases-- we're not really getting better in this respect. Anyway, FreeSCI has seen quite a number of changes-- particularly bugfixes-- in that year, but also ports to support some previously un- supported architectures and platforms, such as Ruediger Hanke's MorphOS port, Walter van Niftrik's port to the Dreamcast platform, and Rainer Canavan's sound drivers for IRIX. Furthermore, a number of new graphics drivers have been added and, most importantly, Solomon introduced a PCM based adlib-emulation driven sound output driver-- while this doesn't resolve the sound timing problems present on some platforms (these are being worked on in our new and unstable development branch). In general, what you should expect from this release should be more stability (or initial support for your platform, depending on which kind of system you are running on), plus some sound output (if you are using a purely PCM-based system). That's it-- share and enjoy! --- 0.3.3 --- Keeping with the tradition, let's have a look at how long we took this time. 7 months, approximately; that's a lot of time; about 1/150th of a person's average lifetime, time that could have been spent differently... ah, who am I fooling, we didn't spend _all_ of these 7 months hacking at the code (we need to sleep and eat, too, you know). But, back to the matters at hand. You want to know what changed and, to be honest, there are few large ones, but an unusually high amount of smaller bug fixes and polishments. Many long-standing bugs have been fixed or were replaced with more interesting ones. You will find that almost all SCI0 adventure games have been completed now; many of them were still unbeatable in the previous release. Win32 users will see a particularly large difference- thanks to Alex Angas' and Matt Hargett's continued attempts, this platform now seems to have a sound server that is actually useable, meaning that you should now be able to get decent sound support there. FreeSCI has also been ported to BeOS by Claudio Matsuoka, and to Linux on the Compaq iPaq, by Greg Gilbert. Also, we now have an excellent graphical configuration tool that takes all the complexity from editing your ~/.freesci/config by hand, contributed by Rune Orsval- if you're new to FreeSCI, this is probably exactly what you're looking for. On the feature front, we have implemented an LRU resource manager- this should help a lot with conserving memory, particularly for larger games- but the most noticeable change it introduces is a vastly accellerated game startup. Well, that's about it; I'll leave the list of smaller changes and bug fixes for you to discover on your own, it's too long to list it here anyway. --- 0.3.2 --- Slightly more than half the time we needed from 0.3.0 to 0.3.1 has passed, and the list has been more active than ever. I guess the dry days of the gfx subsystem implementation period are pretty much over; but there's still much that needs or can be done- for graphics support, but particularly with regard to sound support. Yes, we have it- finally, you no longer have to start and stop Tom Lewandowski's Sierra Soundtrack mp3s manually while running FreeSCI. The new sound subsystem, planned and structurally implemented by Rickard Lind and finalized by Solomon Peachy (who also added a considerable amount of other features) was the last missing feature that separated FreeSCI from Sierra SCI (the SCI0 one, that is). However, our MT-32 to General MIDI mappings are still experimental, and there is no sound support for anything other than MT-32 or General MIDI- it's great for those of us who have an MT-32, but sound cards without sequencers are pretty common, so we will have to look into getting digital sound output working in future versions. Graphics have been improved a bit, too- trilinear filtering and background picture antialiasing, mostly. While the DOS port is now officially orphaned, Matt Hargett managed to get the Win32 port to build and run (with sound support), using Solomon's SDL graphics driver and sound server. This means that FreeSCI finally is available for Win32 again! While I would hope that this procedure works on BeOS, too, I don't think so with regard to MacOS- the SDL sound server uses pre-emptive multi- threading, which simply isn't present on MacOS. Oh well, we can't save all of the world with one release. Another nice feature is savegame quickloading: By specifying a savegame name (which is not identical to the name you entered in the F5 savegame menu; run 'sciv -l' to get a list of valid names) after the game name when starting the interpreter, you can now skip the intro and jump directly to whereever you left off. --- 0.3.1 --- Looking at the previous releases, it would appear that more and more time passes between them. However, more and more work gets done between them as well. Also, considering the current amount of traffic on the mailing list, it seems likely that 0.3.2 will take much less time than 0.3.1. OK, let's skip the introspection and auguration; let's get to the interesting stuff. Some things that used to work in 0.3.0 no longer do so in 0.3.1; this is unfortunate in most cases, but I will try to explain why that is. Due to a re-design of the graphics subsystem, the on-screen console was completely broken. Using the off-screen console, it's still possible to debug the game, though, and that should suffice for most people. Also, this re-design broke the existing DOS and Win32 drivers, and, ultimately, support for these platforms. FreeSCI 0.3.1 is UNIX only, although we're working hard to remedy the situation for the next release. So much for broken stuff. Of course, FreeSCI didn't just get worse- we wouldn't be releasing a new version of it then. Not without a backup plan, anyway. This release contains the usual amount of bugfixes- including fixes for a huge number of memory leaks- and, as hinted above, a completely re- designed graphics subsystem. This new subsystem fixes many of the known bugs and problems in a large number of games, increases the overall game speed at only a minuscle increase of memory usage, and adds functionality to scale the display almost arbitrarily (note that the increase in memory usage may get rather less minuscle if you do that too much). Also, several options were added to better control the way SCI0 background images are rendered. Finally, we are proud to announce that the first SCI game ever has been completed on FreeSCI: Ben Esacove finished Space Quest 3 with a post- 0.3.0 CVS snapshot (and managed to point out a bunch of bugs along the way). For the next release, we'll be working on sound, general bugfixing, porting to non-UNIXish platforms (any volunteers for DOS? RiscOS? AmigaOS? MacOS?), and further reducing memory usage. --- 0.3.0 --- Finally, 0.3.0 has been released! This release took particularly long, mostly because of a major break from january to early april. Anyway, it might be argued that it was worth it: This is the first release with a fully functional text parser, plus, we have fixed all major (and many minor) bugs, implemented the menu bar, added all missing kernel functions- except for debug functions that aren't really used by SCI games, and made sure in-game saving and restoring works. Also, Rink Springer has ported FreeSCI to ia32/DOS (the platform the original SCI runs on, for those who forgot). Also, an experimental glx target was written for platforms without libggi installed; using it, FreeSCI can now be made to compile (using the native cc) and run on mips/Irix systems, although this target and platform should still be considered experimental. As promised in the FAQ, 0.3.0 has all interpreter features required to run and complete SCI0 games. At least in theory; so far, no reports of games having been finished have arrived. We believe that what we have should be everything Sierra SCI had, though; maybe YOU can be the first person ever to finish an SCI adventure with FreeSCI! For the next releases, we will be re-implementing the graphics subsystem for more efficient graphics, and add sound support. --- 0.2.5 --- This release took somewhat longer than the previous ones; partially because of a 1.5 month break in the development cycle, but also because the daily CVS snapshots provided by Claudio Matsuoka invalidated the need to push out releases at semi-regular intervals. So, what's new? Quite a lot, actually: Input support has been implemented, many of the missing kernel functions were written, it is now possible to save and restore the game state, and a "NULL" sound server that handles sound cues was implemented. At least for the UNIXish platforms, as ia32/ Win32 doesn't take fork()s, pipe()s and related stuff too well. ia32/Win32? Indeed, FreeSCI has been ported to Windows by Dmitry Jemerov. The port uses DirectX for drawing and can handle both windowed and full-screen mode; it is integrated into the FreeSCI source tree (a separate binary has been provided by Dmitry for those Windows users who aren't fortunate enough to have VisualC++ installed, though). Meanwhile, FreeSCI has been tested with success on ia32/FreeBSD and ia32/NetBSD, so the number of supported platforms has doubled since the last release. --- 0.2.4: --- 0.2.4 has arrived, and we're still not finished ;-) Seriosly, though, this is the first release of FreeSCI that displays and animates graphics according to the directions given by SCI scripts (at least it works for some games). Since input support has not yet been implemented, games that require interaction early on (like QfG or LSL2) don't show very much yet; other games, like SQ3, already animate some of their graphics. We have implemented more than half of the SCI kernel functionality since the last release, fixed countless bugs, and prepared sound and graphics for the next millenium. Well, for the next release, at least. During the rewrite of the graphics system, the demo program was broken in such a way that it made no sense to support it any further in the current form. It is not part of this distribution, and is unlikely to return in later releases, since most of its functionality are provided by the main executable as well; the missing features (displaying arbitrary pic and view resources) might return in an independant pic viewer later on. --- 0.2.3: --- So you've decided to have a look at the 0.2.3 release of FreeSCI. It's been quite a while since the last public release, so we decided to come up with something bigger this time. The most noticeable change is the existance of a complete (that's what we hope, anyway) implementation of the SCI virtual machine. Now all that remains to be implemented are the 0x70 kernel functions to glue the VM and the graphics, sound, and input code together. Special thanks go out to Lars Skovlund (once again) for providing the information required to build this! Have a look at the README for a list of all currently available debugging commands (and feel free to add your own, even though script_debug.c is somewhat of a mess right now). Other news include the support of alternate base palettes for pic drawing (as used by EGA Quest for Glory for day/night pictures), a fixed sci opcode table in script.c, improvements in sound mapping, and support for ports (clipped rectangular sub-spaces of the game screen, used for windows and similar stuff). There have been substantial additions to the documentation as well, most of which were contributed by Lars. Concerning the next version: There are lots of small and simple kernel functions in SCI. If you want to help but don't have a lot of time at your hands, try to figure out what they do (e.g. by examining them with the built-in debugger of the original SCI engine (activate with LShift-Rshift-TabMinus)) and either drop us a note or implement it yourself. --- 0.2.2: --- So this is the 0.2.2 release. Well, it's mostly a bug fix release, though a few things have been added. Most notably, Magnus Reftel was able to build a heap based on Lars Skovlund's specs (Lars built a heap as well, but we decided not to use it in order to remain as far as possible from the original code (Lars had used disassembled code as a basis for his work)). Thanks to Lars for his work, anyway- he helped to understand us most of the memory management stuff. The heap still has to be integrated, but that'll have time until later. Other user-visible changes include several bug fixes resulting in at least partial Linux-Alpha support, a change to sciunpack which makes the tool add the two-byte header SCI0 games expect (to ease abusing the original SCI engines for experimental purposes), a resource grepper for the command line, and, yes, the end of GII involvement in tools/console.c. It now operates by using libreadline (which requires libcurses) for input operations; IMHO, it's much more useable now. At the moment, it looks as if we're going CVS thanks to Chris Lansdown's generous offer; this should result in better and more recent updates. There will still be "official" development releases, though, for those people who don't want to get entangled in the dark side of CVS. Also, the helpful guys from Linuxgames.com and Telefragged, who are hosting us now, are working to get a mailing list up and running; this should be beneficial to develop- ment as well. --- 0.2.1: --- Another version has been thrown out of the window into the cold night outside... Well, here are the news and changes: The picture drawing stuff has had some bugs fixed; it works /almost/ perfectly now. It should only take one more improvement of the filling code to get things absolutely right. Sound is now mapped automagically. This means that initializing the sound engine will abuse the patch.002 resource to create a midi mapping. It's far from being perfect (for example, instruments that aren't mapped are mapped to the GM equivalent of their instrument number, which is sub- ideal). More work will be required, but this appears to be heading in the right direction. (Unfortunately, neither Camelot nor QfG2 have a patch.002; some other way of mapping instruments will have to be figured out for them). All types of SCI01 compression are now supported (as well as the SCI1 cursors). So QfG2 support will be very close once the VM's up and running :-) (Thanks to Ravi from the SCI message board, who noted that the missing SCI1 type 1 compression simply is SCI0 type 2 compression ;) Speaking of the VM, Magnus has done some major research and implementation sessions which resulted in both improved object loading code and in the beginning of the VM (including several of the SCI opcodes and three kernel functions). The structure looks good, so this will soon become a real VM :-) He has built a python-based class browser as well. It hasn't been merged yet, but it should compile stand-alone (the source is located in src/python.tar.gz). Swig (http://www.swig.org) is required for compilation. --- 0.2.0: --- Sooo... what's new for this version? Well, several things are. First off, Magnus' code disassembly and class analysis code has reached the stage where everything that's known has been added, so it's time to experiment with it. This means that work on the VM, the heart of all this, can start immediately :-) As a matter of fact, it has already started, but don't let that tiny fact distract you from this dramatical moment. Also, some input stuff (using ggi/gii) has been written. However, per- formance sucked badly when I tested it with the current display routines, so the displaying was re-written to take advantage of some of libggi's more advanced features. Performance is much better now, the mouse pointer should move almost fluently on most modern machines. To have a look at it (and to check out the on-screen command console), try qg1demo. CTRL-` (with ` being the same apostrophe that you use to bring up the Quake console brings it up. Try the 'list' and 'man' commands to find out what you can do. As for the sound: I now believe that some of the patch resources contain names for the instruments used in the game. This fact might be used to create better midi maps :-) They appear to contain sound effects as well; if we want those to work, it'll be neccessary to write an internal midi player, or to use gsi's upcoming software synth feature. --- 0.1.5: --- So the last version didn't work; the auto-detection code reported that the resources were not loaded successfully even though they were. Sorry for not double-checking this code. However, these are development releases, so something like this may very well happen again. Anyway, this release is just a small fix of those problems (and a few other problems related to gsi which made freesci programs behave unfriendly towars other gsi-using programs). Also, a new way of drawing graphics has been added- 'interpolation mode'. Originally, Sierra simulated having more than 16 colors by using simple dithering techniques. In 'dithering mode', i.e. if sci_graphics_interpolate is 0, freesci programs will render pictures in an (almost) identical way. However, if sci_graphics_interpolate is set to something else, picture resources will be drawn in 256 colors, each of which is calculated by inter- polating the rgb values of the two original EGA colors that were used for dithering (to be precise, dithering color 0 is taken to be slightly more important (3/5) than color 1 (2/5)) I can't say for sure which way looks better, so, in the future, both modes will be supported (with dithered mode being given preferrence). You can compare the results of drawing in either mode on the screenshots page of the freesci homepage. --- 0.1.4: --- The good news is: Sound support is in. The bad news is: It doesn't work. Not completely, anyway; Sierra adheres somewhat to the MIDI specs (some minor quirks, most of which Ravi already discovered), but they appear to have used a proprietary MIDI instrument mapping. This isn't really surprising; AFAIK GM wasn't written at the time they released the first SCI0 games. Anyway, sound support can be found in the new subdirectory src/sound. Sound can be extracted or even played (if GSI is available), but the results sound somewhat different to what we used to expect. The instrument map is located in src/sound/midi.c; please feel free to modify and test it in whatever way you seem fit. BTW, it is absolutely possible that each Sierra game uses a different instrument mapping, or that parts of these can be found in the mysterious 'patch' resources. Also, percussions don't seem to work exactly as in the original games (try QfG1s sound.001). A good way to proceed might be to extract the music files from the QfG 1 remake and compare them to the originals- since the music file format has changed between SCI0 and SCI01, this might both reveal the differences and eventually produce useable instrument mappings (if QfG1 uses GM maps...) Another piece of good news: SCI1 decompression works, at least for methods 2 and 3 (and, of course, 0). Method 1 (which is used in SCI01) doesn't, but it's possible that this is just a variant of the SCI0 method 1 (plain SCI0 method 1 doesn't quite work). Method 4 hasn't been ported yet, but DOS source code from Carl's decoder is available. (FYI: Since I haven't been able to completely decompress something, I'm not absolutely sure if these methods work. Please try them as hard as you can.) On the tools front, unpack and resourcelist have been merged into sciunpack, which comes with facilities to convert sound resources to midi files and pictures into png files (the new graphics/graphics_png.c could also be used to make screenshots from a running SCI game if we had one running). And, while I'm at it, the ggi people have fixed the endianness bug that made colors look screwed when displaying from big endian machines to little endian machines. If you happen to use both little endian and big endian machines, you should upgrade your version of libggi. Addendum: If you want to see the sound player in action (and have your GSI set up correctly), try the QfG1 demo. It doesn't loop the music as it should yet, but it proves that GSI support *is* working ;-) (BTW: The "Erana's Peace" theme currently is the best-working song. You should not expect the other MIDIs to sound nearly as good.) --- 0.1.3: --- Even more portability fixes. FreeSCI has now been successfully tested on sparc-sun-solaris2.5 over an X connection. However, the colors are messed up; I *think* that it could be a bug in libggi; this is currently under investigation. Views should draw much faster now. Also, they are reversed if a certain flag is set. A cause for a segfault/coredump in decompress.c has been cured: It would behave strangely if a resource had a size of 0, which, apparently, is possible. resource.c now starts at resource.001, if resource.000 is not available. Some games (SQ3) seem to come without a resource.000, so this was neccessary. BTW, SQ3 appears to work now. It is now possible to specify the locations of libggi and libglib (as well as their header files) during configure time. --- 0.1.2: --- Additional portability fixes; test runs on big-endian machines will happen Real Soon Now. The data types gu?int(8|16) from glib.h now superceed the u?int(8|16) types generated by autoconf magic. Stability fixes all over resource.c and decompress.c (those were badly needed) seem to prevent any memory leaks, at least on my machine. Configure now accepts additional paths for ggi. Although configure --help claims so, those aren't specific to ggi- yet. On the graphics front, crashes caused by the filling code re-filling any white objects (like clouds) seem to have disappeared, even though filling isn't perfect yet (this appears to derive from a bug deep down in the understanding of how the oritginal SCI interpreter handles filling). Lines now seem to behave exactly like their Sierra ancestors, so the Infamous Incomplete Image of the brigands' fortress from QG1 is now obsolete. This means that graphics should generally be *much* better. --- 0.1.1: --- New portability stuff (using automake/autoconf) has been introduced. The data types (u)int8 and (u)int16 can now be used to specify (unsigned) 8 or 16 bit data types. (u)int8 currently only checks if char is 8 bit and aborts if it isn't, however. am/ac also define BIGENDIAN_WORDS if we are in a big-endian world. Magnus' getInt16() (formerly getInt()) should be used whenever two resource bytes are converted into an int16; this function is defined as a macro if we are little-endian, but it also properly translates those two bytes if we are not. The /src/test directory now contains two new utilities: scriptdump and voc- dump. While scriptdump appears to work nicely, I've had problems with vocdump (testing qg1). It only works for kernel message table 1. Magnus reports that he's had problems with qg1, too, but that Conquest of Camelot works properly. For those interested in looking into it, the sources are in src/core/vocabulary.c. Background graphics still don't work perfectly. But I'll have to look into this at a later time. By the way, the core and graphics files now get build as libraries. It looks somewhat nicer this way.