Topics

1

SCI Development Tools / Wolfenstein 3D fizzlefade (SCI-related)

« on: May 05, 2021, 01:38:33 PM »

So today I learned why Sierra's DISSOLVE algorithm (aka dpOPEN_CHECKBOARD) works. Shame on me for not realizing earlier, but I'm not a graphics guy. It is described here in terms of Wolfenstein 3D, but it is easy to see that it is the same thing.

https://fabiensanglard.net/fizzlefade/index.php

2

SCI Development Tools / SCI1 interp with parser

« on: April 07, 2019, 09:43:59 PM »

Sluicebox, who has written a large number of script patches for ScummVM, has uncovered SCI versions from the SCI1 timeframe with a parser! For Amiga, unfortunately  but they are later than what was previously thought to exist. Also, 16-color graphics (I guess?).

https://github.com/scummvm/scummvm/pull/1578

3

Everything-Else / Telltale Games are shutting down

« on: September 21, 2018, 08:09:30 PM »

Not SCI related, but Carl Muckenhoupt ended up with Telltale in case you missed it. His SCI Decoder was so very influential back in 1999 when I got started on SCI. And now they're closing.

 

4

The Games and other Sierra Adventure stuff / Bits and pieces of SCUMM being revealed...

« on: March 24, 2016, 07:08:55 AM »

Aric Wilmunder is getting ready to publish some of the old SCUMM documentation on his site at http://wilmunder.com/Arics_World/Games.html
Cue the inevitable comparisons  There is even talk of code.

5

The Games and other Sierra Adventure stuff / SCI32 Shirt

« on: February 27, 2016, 07:43:35 PM »

Putting it here, just because. For those who haven't seen it yet:

https://www.facebook.com/photo.php?fbid=10206928157020660&set=a.1755697530478.2094731.1180140987&type=3&theater

6

The Games and other Sierra Adventure stuff / GK2, day 4 [spoilers]

« on: June 30, 2015, 09:08:19 PM »

So I've been working on this list of required actions on day 4. 14 at each location - it's no wonder that people seem to get stuck often. The numbers are the flags that the game requires to be set in order to progress.

Code: [Select]

Neuschwanstein (14 flags)

L = look (cursor), T = tour tape

579    Entry hall T
628    Small door T
580    Entry Hall Paintings left T
581    Entry Hall Paintings right T
582    Bedroom, either screen T
589    Bed closeup, first time T
590    Bed closeup, second time T
592    Bedroom painting (right) T
583    Study T
584    Chapel T
585    St Louis & Seraphim T
586    Living room T
587    Grotto T
588    Singer's Hall T
1031    Wolf Painting L

Herrenchiemsee (12 flags)

The game is very fussy here. For the entries marked Video, you must
see a video of Grace reflecting on what she sees.
For the others, it is enough that the player has seen the text.

995    "The people need to see you at the throne"
996    "You spoke so movingly of your torment"
997    Video "What were his last wishes?"
999    "If any more correspondneces come from Louis, they are to
    be burnt immediately"
1000    "Remember that when the Great Friend arrives at
    Neuschwanstein and we retreat to the hall"
624    Video "Grace sees, recognizes sleigh painting"
1002    "A group of men demand to take the king in custody"
1003    "Ludwig knows the conspirators will return"
1004    "At Berg, Ludwig seems more cooperative and coherent."
1005    "Ludwig's funeral procession marches through the streets of
    Munich."
278     Asked clerk to see diary
279     Asked clerk about new Wagner opera

278 and 279 above in turn require

622     Video "I've got to see that diary!"
623     "Even after Wagner's death, Ludwig still showed signs of obsession with the composer"


7

SCI Development Tools / Secondary monochrome monitors (and translation project support)

« on: May 31, 2015, 04:23:50 AM »

In the latest SCI1.1 versions (LSL6, some demos), it is possible to write text to a secondary monochrome monitor.
There is no official support in DOSBox, but there is an unofficial patch, available from http://www.vogons.org/viewtopic.php?f=32&t=26110&start=20, which adds this. It was a bit of a hassle, but I managed to make it work. Now, using the DbugStr kernel call, you can print any (heap) string to the secondary display.

Another thing that you can do with this (hinted at in the subject line) is that you can turn on a special mode where the Message kernel call will print text strings from an xlate resource (extension trn) on the second monitor as the corresponding strings are fetched from the ordinary message resources. The file formats are identical, except that the first byte is 94 hex rather than 8F hex.

To enable this mode, add the following line to resource.cfg. Note that doing so will bomb you to DOS if some of the XLATE files do not exist.

Code: [Select]

xlate = .You can substitute any directory for the dot.

8

SCI Community How To's & Tutorials / Using timers

« on: January 29, 2007, 05:48:58 PM »

The Timer class in the template game has gone largely unused, and that
is a shame. So here's my attempt at explaining how to use it.

First, there is no need to instantiate an object unless you want to
change the timeout later on. The class methods are designed to take
care of that. Second, the Timer class works by cueing a script when it
expires. I can't recall whether that's in the documentation or not,
but it simply means incrementing the current state number by 1 and
calling changeState. Third, the only real advantage of the Timer class
is its mutator methods. All other functionality is available directly
in the Script class, so if your timing needs are simple, you don't
need this class at all.

Next, I'll describe the architecture of Timer (and Script, in this
regard) objects. There are actually two separate properties devoted
for timing: They are called 'cycles' ('cycleCnt' in the Timer class) and
'seconds'. The difference between them is (obviously) their
resolution and, consequently, also their range. A cycle in SCI
parlance is 1/60th of a second. Thus, the maximum range of a timer if
you choose to use the cycle counter is about 18 minutes. If you choose
to use the second counter, the range is about 45 hours.

The mutator functions I hinted at above are called setCycles, set, and
setReal, respectively. The first one is simple; it takes a cycle count
(which you would have to calculate yourself) and starts a new timer
with that timeout. You would call it like so:

(Timer:setCycle(RoomScript 30))

where RoomScript is the script that will be cued when the timer
expires. The timeout will be half a second (30/60).

The set method is a bit smarter. It automatically calculates the
correct cycle count given a count of seconds, minutes, and hours. This
method also adjusts the final count for the currently set game speed,
which is not always what you want. And it uses the cycle
counter (see above for a description); the real range of the Timer
class may vary if you use this method. You would use it like so:

(Timer:set(RoomScript 30))

for a thirty-second delay.

Finally, there's the setReal method. Like set, it
performs all calculations on its own, but it uses the seconds
counter, and it does not adjust for game speed. Thus, it is
ideal for game events that depend on how much "real time" passes.
However, it does not work out of the box due to a typo in the template
game. To fix it, find the doit method of the timer class (in
Timer.sc), and the line that says:

(if (not seconds)
    CueClient()
)

Fix the first line so it reads:

(if (not --seconds)

and you're all set.

Finally, the cases where you don't need a Timer object. As I've
mentioned, the Script class has comparable properties (but no methods)
to the Timer class. So you can simply use your room script and the
cycles and seconds properties directly, if you are so inclined. This
is what Sierra did in most cases; you don't really see the Timer class
used much in the games. You would simply do

(instance RoomScript of Script
     (method (changeState newState)
        (super:changeState(newState))
        (switch (newState)
           (case 1
            = seconds 15)
           (case 2
            Print("Time's up!")))))

When using the Timer class, you would similarly put your initialization code in case 1 above (or in a room's init method).

9

SCI Community How To's & Tutorials / A generic Keypad class

« on: January 17, 2007, 04:06:54 PM »

Code in the attached file, along with documentation. Note that I use the ego view for buttons (as I said, I am not a graphic artist). The first the buttons from the left are number buttons, and add the numbers 1, 2 and 3 to the keypad text. The next button cancels, the one after that is backspace, and the last one OK. It would be great if someone would help me make better graphics for the demo code. Instructions are in the documentation. You will also need to add the word 'keypad' to your vocabulary.

Lars