Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - lskovlun

Pages: 1 ... 32 33 [34]
SCI Community How To's & Tutorials / Re: Using timers
« on: February 13, 2007, 06:29:06 AM »
Come to think of it, I don't think you even need to do that. All you need is a Script (capital s)that is guaranteed to survive when the script (small s) goes away. The thing going on during a room change is a kind of garbage collection. It checks whether the client property is NULL before doing anything (note that #delete and #dispose are distinct methods).

SCI Community How To's & Tutorials / Re: Using timers
« on: February 12, 2007, 03:27:14 PM »
There is a way, actually. You need to combine the use of the Timer class with a region. I believe I described those in a post on Mega-Tokyo long ago. I can't find the post right now, but I did find a post by cloudee1 saying you have written one as well. If that is the case, I don't need to go back and dig it up (I'd write a summary here, but my recollection of it is spotty).

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
(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, and the line that says:

(if (not seconds)

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)
        (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).

Actually, this is the usual way of skipping past/ending the intro in SCI games. The template game is modeled after LSL3; that one is an anomaly. Most other games don't use an INITROOMS script at all - I'm surprised you'd try this, though.


SCI Syntax Help / Re: Ideas to create Keypad from SQ1
« on: January 17, 2007, 04:08:47 PM »
I have uploaded the package in the SCI How-To section.
(jtyler125: This package is different from the one I sent to you earlier. Use this one instead, as a number of bugs have been fixed)


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.


SCI Syntax Help / Re: Ideas to create Keypad from SQ1
« on: January 17, 2007, 03:55:23 AM »
Yeah, post it for everyone to see!

I would. The problem is, it's a package consisting of several source files and a pdf with the documentation. Of course, I could put up a .zip as an attachment, perhaps with the most important code in the message body or something.
Also, I seem to have misplaced the views I used for testing when I wrote the code originally (which is four years ago);
I am not going to make those myself (I am a coder, not a graphic artist).


SCI Syntax Help / Re: Ideas to create Keypad from SQ1
« on: January 16, 2007, 03:38:45 PM »
Hi jtyler125,

I wrote a piece of code (and documentation, even) many years ago that does this. If I could get your e-mail address, I'll send it to you.

Best regards,


I am still working on deciphering SCI01 (so don't give up hope yet).  There are some strange querks that I have run into of which is a different object model on the SCI01 interpreters.
You keep saying this. Could you elaborate, please? And if you have any specific questions, please don't hesitate to ask; the SCI01/SCI1 support in FreeSCI is quite solid already, if I say so myself. I may already have covered the things you're looking at.

I think it is possible still.  I do remember that there was a possiblity of using FreeSCI interpreter (and using the old SCI0 script logic with SCI1 resources).  That would be an "easier" path that I haven't persued yet.
If you are considering reimplementation, that would be easier. However, we don't have SCI1.1 support yet (QfG3 is SCI1.1), and it's not a high priority for me either. The jump from SCI1 to SCI1.1 is comparatively larger than the one from SCI0 to SCI1:
  • The script format changed. I'd like to do this concurrently with savegames to avoid doing the same work twice.
  • View scaling was introduced. At first, it may seem like we can postpone this, but control lines, hit tests and such may force us to implement it early.
  • Separate resource bundles and resource handling for new resource types (audio36, sync36, message). Our resource manager should be able to handle this.
  • Implementation of format parsers and new kernel calls.
So using FreeSCI on a game like QfG3 will not work directly.

One thing to remember though, in whatever room your character got the item, if you checked to see whether or not gEgo had it before initing it, then the item will reappear there since your character no longer has the item.
That would be because this is the wrong way of doing that. In these cases, you really want to test whether an object is in the room or not. An inventory object has an owner property and an ownedBy() method. The way Sierra used to do things was set the owner field to the number of the room the object is in. The (ego get:), (ego put:) and (ego has:) methods simply use this property. You can then test for ownership by doing:
Code: [Select]
(if (send anItem:ownedBy(gRoomNumber)) ...)This allows items to move around  in the game. You can also use objects as owners, if you prefer; indeed, this is already done when an item is in the player's inventory.

Oh, and you'd want to know about
Code: [Select]
(send gEgo:put(anItem gRoomNumber))too.


The Games and other Sierra Adventure stuff / Re: VGA SCI with Parser!
« on: December 26, 2006, 05:24:38 PM »

It is true that we had to take savegames out when designing Glutton. On the other hand, you say that FreeSCI is more forgiving than Sierra SCI for developers. I'd say that depends on what you're doing; for example, some Sierra games use the StrAt kernel call for accessing arrays. We have had to include special code for this case (among others) in FreeSCI, because it abuses the particular implementation of StrAt (in FreeSCI, a variable is really 32 bits wide instead of 16). Glutton in its original incarnation would have aborted with a VM error here. Similarly, Christoph implemented type checking of arguments to kernel functions; we have had to relax this checking somewhat as we discovered other kinds of abuse.

I still think you are overstating the case when you say that Sierra changed their object model. If you are dealing with parser based games, you could easily use the template game we have already, with the changes I outlined earlier. The major changes only come in when we consider the point-and-click stuff; we still have state machines, room objects, actors, views, etc. working like they did in SCI0.

Your last comment ("if I just insert bytes for commands (like loading the palette)") makes it sound like your biggest problem is with Brian's compiler being designed for a particular interpreter version. I can only say it has worked for me (I used the PQ3 interpreter and class hierarchy) -- the crash I got could have been debugged if I had spent more time on it than I did. I had a simple program, written in an afternoon, that made SCI Studio-compatible .SCO files out of the original game and linked my own code against them. Since I used the files from an original game, I had none of the problems you'd have to solve in adapting Brian's template.


The Games and other Sierra Adventure stuff / Re: VGA SCI with Parser!
« on: December 25, 2006, 02:40:22 PM »

If Glutton was further along, what do you mean "further along"?! :)
Regarding the object model in SCI1, the differences are not that huge, especially if you use the text parser interface. I have successfully written small scripts for SCI1 interpreters (don't ask - it was a very ugly hack). I failed to make it work with Sierra's interpreters (it is quite difficult to debug without a working debug window), but it worked in FreeSCI. The memory model is different, so your memory woes are likely to disappear, provided you use text resources correctly (that feature in Sierra's original compiler which generated code to handle text resources automatically would be cool here).

What would have to be done in order to make the current template game SCI1 compatible would be this:

  • Add new (dummy?) classes and selectors as required by the SCI kernel interface.
  • Create a vocab.994 file compatible with the chosen interpreter (SCI studio does not have an editor for this file; would have to be done manually).
  • Look at the FreeSCI code and figure out how the kernel/script interface changed. Some of these changes are subtle (e.g. the Motion class), but I believe we have most of them covered. Change the template game appropriately.

Pages: 1 ... 32 33 [34]

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.097 seconds with 21 queries.