SCI32 Source Code

[Kawa]

I'm not sure what I did but it no longer crashes. On the flipside, it doesn't seem to take resource volumes?

[OmerMor]

Thanks so much. Have you sci0, approximately 88-90 years?

Unfortunately - not. 

[EricOakford]

Here are the SCI32 header files adapted for SCICompanion. Yes, we should add support for non-integer and complex defines, since Sierra used them. For that matter, we have information on the SCI32 kernel functions.

[Fox]

Hello there, I am new here on this forum . I tried out to compile this SCI32 source code with varying results . The code is from an early C++-Era. One needs to correct a lot of grammar failures first wenn you want to compile this on the latest (1.9) OpenWatcom-Version. I managed to fix all the error messages but still didn't get it to work with OW v1.9. It seems to work however on early versions of Watcom C++ (10.6) and MASM 6.11. Testing with the Watcom Debugger I found out that the code crashes directly after running the opcode pseudo-machine. I managed to get both the debug version with the opcode debugger and the normal version compiled.

In the c++ version of the pmachine there was a lot of inline assembly code inserted which resulted stack balance errors wenn trying to run the code. They optimized the pmachine by making inline assembly jumping statements to other parts of the program out of control of the compiler. The problem with hidden jumping to other c++code positions without the compiler knowing is that you can't be sure it clears the stack propery and jumps back to the correct position.

One can see that the code was written in a transition period moving from C to C++ language. Some stuff like const values without type specifiers are not allowed anymore in modern C++ language. The used #define statements to implement template-like functionality. It must have been very hard for the original team to develop this code. in the win3.1 and win95 it was probably not easy to debug 32-bit dos protected mode applications. People had to do with a lot of system crashes. The code had to be fast and efficient also. They of course had no other choice then to implement some stuff with assembly code. There were probably also difficulties with implementing audio drivers and stuff under protected mode. I tend to prefer however the readable C-style-code like used in the game Doom of the time era and which is more easy to port to other platforms and compilers.

I got the pmachine to work again by removing this code and translating the assembly-code-optimized version in plain traditional C-code. The only game it seems to work with is Space Quest 6. The Adlib music is flawlessly. The only problem I still have is with the audio samples. These play way to slow wit a low of clicking. There seems to be a problem with updating the sound buffers which are sent to the soundcard. The Watcom debugger is not that good compared to modern day options and it is often losing track and displaying the false source code while running, perhaps I should try with Dosbox-Debugger an IDA Pro 5.0 like the scummvm dudes do.

There perhaps is too much of the legacy stuff in this code to use it as a base for further development.  It may be more efficient to rewrite a SCI32 interpreter from ground up with modern stuff. There is however room for cool hacks like:
- changing the Pmachine to a Lua-interpreter
- Writing the game logic directly in C/C++ which can be loaded dynamically and interfaces with the kernel api
- Improve sound support, like supporting AC97 in dos mode
- Adding a proper SB16 driver with high samplerate support and auto-initializing DMA
- Adding support for modern day picture format like .PNG . GIF etc.
- improved midi support and synth emulation
- Adding a classic sierra text parser back


Greetz from Mr. Fox

[Kawa]

I too have tried to compile and run SCI32, though I hadn't tried SQ6 specifically.



As for writing an all-new SCI terp, I actually have one in the works right now, including the thing where it runs Lua game code and uses PNG. I'm just absolutely stumped on pathfinding right now.

[Fox]

I like the stuff you did with SCI16 and it inspired me to try the same with SCI32. I was hoping to get it to work without any problems so people could use it to develop SCI32 games. The original SCI32 uses DOS4GW Professional which I don't have, I don't think that makes the difference. Turning off or on some optimizing options causes that the code doesn't run. Perhaps I should try to build the windows version of SCI32.

I included here the modified source code. To compile MASM 6.11 and Watcom C++ 10.6 is needed. It worked on PCEM and Dosbox.
to compile go the extracted directory in dos and type:

wpp386.exe /3s /j /s /ox /ot math.cpp


wmake.exe


to build without debug functionality use wmake.exe SIERRA=1

The math file needs to be compiled separately because Watcom crashes on that file with all the optimizing enabled.

I am interested about your SCI-engine. Is your SCI-engine a retro-coding project (MS-DOS and son on) or do you make it for modern machines? There seems to be a dude wo made a Sierra AGI-like engine for Unity.

[Fox]

One needs to remove the DACBLAST.DRV file to remove the non-properly working digital sample playback.
Enter tilde to enter the debug menu, use / to show the debugging options. It works with SQ6 from GOG.COM. You can make a ISO from the SQ6 directory. When SQ6 is loaded as a cdrom in the D: drive then you can go to D: and type c:sciub.exe for easy testing the compiled file.

[Kawa]

I am interested about your SCI-engine. Is your SCI-engine a retro-coding project (MS-DOS and son on) or do you make it for modern machines?

My project is surprisingly not a retrocoding one. It runs in SDL2.

[Fox]

I think it would be great to have a good SCI-engine with SDL2
Even the original sierra coders commented somewhere in their code that it is garbage..
And SDL would be great for portability also (Linux, IOS, Android etc)
Good luck with your project!

[Kawa]

To be fair I'd have a better time and probably more success implementing 256-color mode (which would involve hacking the crap out of picopng among other things) or scaled sprites, than to implement pathfinding.

I copied SCI11's, it compiled fine but acted up. SCI32's likewise. ScummVM's works fine but makes me feel ethically and morally wrong. It's all on my twitter.

[MusicallyInspired]

I love this stuff it's fascinating!

[Fox]

I am looking to get this SCI32 running on Windows. It might be useful to have a working sci32.exe under Windows which can be used to run test scripts to test the pathfindung and so on. In such a way one can implement its own pathfindung algorithm which mimics the behavior. I didn't check out wether the SCI16 algorithm is the same as SCI32 algorithm. The original algorithm seems to be patented by sierra and may not be used for another few years until the patent runs out.

[lskovlun]

The original algorithm seems to be patented by sierra and may not be used for another few years until the patent runs out.

That was a concern fifteen years ago when pathfinding was being added to FreeSCI. The original patent was filed in 1990; it has long since expired. I wouldn't worry about it now. On the other hand, I wonder why Kawa would be reluctant to borrow code from ScummVM and not from the original interpreter.

EDIT: The Message kernel call was patented too. I don't think anyone ever took that seriously.

[Kawa]

I didn't check out wether the SCI16 algorithm is the same as SCI32 algorithm.

It is. Rewritten in C++, so it has things like vector structs with operator overloading, some call styles changed, a few identifiers have been renamed, and the kernel layer (KAvoidPath and such) is in the same file, and it runs on 32-bit systems even though the SCIWord typedef is still 16-bit, but it's effectively the same algo.

An acquaintance on Discord had a go at trying to understand it, so they might explain it to me and I might reimplement it in NewSCI, but then my brain shut off on the topic. I attached their GIFs, which are basically pixel art animated versions of the ASCII art in the SCI source.

[Fox]

The current AGS version uses the A*-algorithm. It is very good for 2D maps and so on, well documented and it has lots of C++ examples on the internet. The AvoidPath algorithm was optimized to run on really slow machines. It is old style C++ code which marks the transition from C where they were comfortable with. One can write it much more tight and readable with the modern C++ standard libraries. Things like sorting the nodes of a polygon can be written in one line nowadays. The C++ Boost library provides a A* library and I believe there is also a Graph library. In either way you need to make polygons around your nonwalkable areas with each algorithm so the pathfinder knows where ego can walk. The advantage of A* is that you can program it in such a way that ego can walk more naturally around a tree or something. a normal person does not walk until he hits the tree and then walks around it.