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 - troflip

Pages: 1 [2] 3 4 ... 101
SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 13, 2019, 12:09:08 AM »
See my post a few posts up for an explanation of why this is. Basically, a procedure call takes up a few more bytes than assigning or testing a variable. You can disassemble the script to see exactly how much.

Code: [Select]

btw, why not use:
Code: [Select]
z  ; instead of (== z TRUE)


Code: [Select]
(not z)  ; instead of (== z FALSE)

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 08:26:42 PM »
I should have said: enclose the *last* statement of the procedure in a return statement.

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 06:55:23 PM »
Enclose the code in BTest in a return statement.

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 02:33:10 PM »
Yes correct, but you need to include all the places in or or whatever too (scripts that are always loaded).

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 02:17:50 PM »
Interestingly enough, if you're doing it this way in SCI0, this could end up eating up more memory, since the script code takes up heap space (I forget if that's true for SCI01 or not, but it's no longer the case for SCI1+ since script code isn't in the heap).

BTest, bSet, BClear functions themselves eat up 101 bytes. So that's a fixed cost right off the bat.
160 regular globals eat up 320 bytes, whereas [gameFlags 10] only eats up 20. So you're saving 300 bytes at a cost of 101 bytes. Still coming out ahead, except...

Except it takes 6 bytes of compiled code to call BTest or BSet.
But only 4 bytes (or possibly 5) to directly assign a global TRUE or FALSE.
And only 2 bytes (or possibly 3) to read from it.

So, read a flag 75 times in currently loaded script code and you've already lost your bytes advantage.

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 12, 2019, 02:07:52 PM »
Code: [Select]
(procedure (Btst flagEnum)
;Test a boolean game flag
(& [gameFlags (/ flagEnum 16)] (>> $8000 (mod flagEnum 16)))

If the flag you pass in is 35, then this essentially becomes:

(procedure (Btst flagEnum)
   ;Test a boolean game flag
   (& [gameFlags 2] (>> $8000 3)) ; since 35 /16 is 2, and 35 mod 16 is 3

So it's selecting the 3rd bit in the 2nd gameFlags array index. It's basically just doing integer division and modulo to turn the flag number into an array index (0 to however big the array is) and bit position (0-15).

Each statement needs to be enclosed in ().

Accessing a property on an object counts as a statement. Thus:

Code: [Select]
(someActor x?)  ; retrieves the x property from someActor

Calling a method on an object counts as a statemtn. Thus:

Code: [Select]
(someActor setMotion: statement1 statement2 statement3)

Code: [Select]
(someActor setMotion: (blah x?) (blah y?))

It's all very logical. I'm sorry the conversion doesn't work in your case... trying to compile/parse Brian's crazy syntax was super difficult, because it's all so adhoc and permissive.

SCI Syntax Help / Re: Can someone explain Flags to me?
« on: June 11, 2019, 05:59:46 PM »
When I'm defining in the script, does that take up heap space?

Define's are a compile time thing, they don't take up any extra space.

SCI Syntax Help / Re: Dialog Box Edges Hiding Objects Behind
« on: June 08, 2019, 12:56:32 AM »
That makes sense, then, I didn't realize the Views were added then replaced.  If the PVs utilize less room, do they still end up in the space in memory where the Views were before?  My limited understanding is that heap doesn't get any defragging, so do the deleted Views just leave holes which can be utilized by smaller chunks, if any arise?

If they're smaller and the PVs are allocated before the View's are disposed (but it doesn't look like they are), then they could end up in those holes.

You might just be able to create PVs directly... what happens if you just set properties on a new PV and call init on it? (PV:init adds itself to gAddToPics).

Btw, the whole reason these PVs exist (i.e. a representation of the addtopic'd view in heap memory) is so that they are re-added to the background automatically when you load a save game.

As for the animated background objects, makes sense too.  I wasn't sure after reading through the Animate kernel call if it applied to objects added to the pic

Animate does its job partially by calling the doit: method on Props and Act's, which then increment their animation cel/move themselves as necessary.

SCI Syntax Help / Re: Dialog Box Edges Hiding Objects Behind
« on: June 07, 2019, 08:43:11 PM »
The fragmentation might make sense, since you're adding a bunch of View's, then deleting them and replacing them with PV's (the class which holds information on a view that was added to the background), which consume slightly less memory. That space should be freed when you exit the room and  the PV's are disposed?

As for the setMotion thing, if you're calling addToPic:, your Act is destroyed on the next Animate cycle and replaced with a PV. I mean, the whole point of adding things to the background is that they're static. So that means no cycling, no motion, and no scripts on them.

I hate that Sierra chose to name those two very different methods the same!

I tried removing the setRegion line in the first room and then navigating to the crash room and it still crashes. gRegions still says "regions" in debugger.

It's just using the actual instance name of the regions list, which is "regions" (defined in It doesn't know anything about gRegions, the global variable that points to "regions".

EDIT 2: Something residual is definitely going on. I just painstakingly removed all lines of code that sets regions and locales and it still crashes on this one room alone with the same error. No regions or locales anywhere in the game.

Well, the room you're in is also added to the regions list. So that must be what's going on. Somehow a room is still in there but it's been unloaded. The difference in which "bad opcode" you're seeing is just a red herring... it's basically calling into code that *was* a room, but is now something else - so it's just garbage.

Anyway, with this new info, either this means:
- the room you're coming from got unloaded (as expected) but not removed from the regions list, or
- the new room you're in somehow go unloaded. (Make sure its script number isn't in the DisposeLoad call in startRoom in, or that you don't have a call to DisposeScript somewhere with that script number)

Can we see the code that calls newRoom based on the ego being inRect? It doesn't accidentally call gGame's newRoom, does it? Because (see attached) if I do that I get a stack very similar to what you're seeing:

Possibly. What does the resulting Locale code look like?

Have you tried it in ScummVM to see if it gives a better error message for the crash?

I just tried getting the Speak-O-Tron to use lipsync data in SCI Quest (room 210), and it seemed to work in the game.

Not sure why it wasn't enabled by default... (maybe I implemented the lipsync stuff after making SCI Quest? I dunno, I forget), but I tried both the Quick Lip Sync and the one in the dialog.

SCI Syntax Help / Re: Yo-yoing between two rooms
« on: May 16, 2019, 01:28:15 AM »
The Portucllis is just an actor that moves up and down. It's an SCI1.1 game.

When you say put it in the posn method do you mean inside along with "gEgo posn:"? Or in the actual method in

EDIT: I did both. Something is definitely changing the poisiton but I haven't the foggiest what it could be.

As far as placing the ego somewhere it can't be, it's inside the contained polygons on both screens. I just don't get it.

With a debugger, you could put a breakpoint on Actor:posn and see the exact send stack and immediately tell who's calling it. Unfortunately no debugger in the publicly available SCI1.1 interpreter, but ScummVM has one, and I think there is pretty good documentation on how to use it.

Otherwise, you'll just be left guessing... although you could narrow it down a bit by putting DebugPrint's between every line in your room's init, to see roughly when it's changing.

Pages: 1 [2] 3 4 ... 101

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

Page created in 0.118 seconds with 21 queries.