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 ... 36 37 [38]
556
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)

Lars

557
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

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

Lars

559
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,

Lars

560
I am still working on deciphering SCI01 (so don't give up hope yet).  There are some strange querks that I have run into though...one 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.

561
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.

Lars

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

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.

Lars

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

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 ... 36 37 [38]

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.118 seconds with 21 queries.