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

Pages: 1 ... 3 4 [5] 6 7 ... 113
The Games and other Sierra Adventure stuff / Re: What are we working on?
« on: November 06, 2021, 08:11:32 PM »
Congratulations on that!

The Games and other Sierra Adventure stuff / Re: What are we working on?
« on: November 05, 2021, 08:13:29 PM »
Except it's more than just the slider. I have things change to reflect the new setting, on the fly.

The Games and other Sierra Adventure stuff / Re: What are we working on?
« on: November 05, 2021, 07:54:56 PM »
as well as a setting in the control panel to adjust the mature content.
If you would like to see how I did that exact thing in The Dating Pool I'll be happy to share the relevant code with you.

SCI Development Tools / Re: SCI Decompiler?
« on: November 01, 2021, 06:36:53 AM »
I've seen the original Sierra code, from SCI0 to 2. I don't know what Jeff Stephenson would say about Companion's scripts but I can honestly say it's this close, if you disregard extra stuff like the &getpoly and verbs macros.

Code: [Select]
(define X an entire snippet of code)

(class Example kindof Object
;"kindof" instead of "of", though "of" was used later on
; exactly like in Companion, though some versions of SC allow one of two type markers
; list of forward-declared method names
(method (DoAThing with &tmp i)
; exactly like in Companion
; and maybe two or three other little gotchas.

Edit: the (methods) block is supported but ignored, and kindof is considered synonymous to of. Also, sends can have commas, like (bluh foo: 42, bar: 4), but where Sierra's compiler allows trailing commas (bar: 4,), Companion does not.

SCI Syntax Help / Re: evKEYBOARD question
« on: October 31, 2021, 05:07:40 PM »
I have no idea why the decompiler thought $0100 should return true in this situation, but I guess that doesn't really matter.
Any non-zero value is considered true. Having the actual true being 1 is just convention. So it's not so much that "$0100 returns true", but "if this expression yields a non-zero result, then do this."

SCI Syntax Help / Re: evKEYBOARD question
« on: October 31, 2021, 03:48:00 PM »
If you want it extra readable, use something like (| cBROWN cLGREY) instead of $00C0. That will compile to the same thing.

(& (ego onControl: 1) $0120) means "get me all the bits in $0120 and whatever ego is standing on that are both set". If none of them are (ego is standing on only black?) then the result will be zero, a false-y value. If ego stands on dark gray ($0100), the result will be $0100, which is truth-y. If ego stands on magenta ($0020), the result will be $0020, which is also truth-y. Therefore, this condition will be true if ego is standing on magenta or dark gray. The code, as decompiled, makes sense. To replace it with "equals $0020" is to change the entire logical meaning of the check.

SCI Syntax Help / Re: evKEYBOARD question
« on: October 31, 2021, 10:51:54 AM »
Going by the list from SYSTEM.SH you just posted and completely ignoring the Studio defines:

$00C0 is $0080 cLGREY plus $0040 cBROWN. If you tell isOnControl to use the entire footprint instead of only the hotspot, and stand on both a gray and brown control pixel, you'll get $00C0. If you tell it to use only the hotspot and then stand exactly on the gray pixel, it'll return only $0080.

$0120 is $0100 cGREY plus $0020 cMAGENTA. There can be no invalid values since each possible control color you can stand on has its own unique bit. Since there are sixteen possible control colors and all numeric values in SCI are 16-bit, you literally cannot specify an invalid set.

SCI Syntax Help / Re: evKEYBOARD question
« on: October 30, 2021, 04:09:21 PM »
First of all, -24576 is $A000.

Second, you don't want to use the cl___ constants here. Actors can stand on multiple colors, so you want ctl___ (ctl for control, not cl for color), which can be combined. As such, $A000 is not a defined color either because it's ctlWHITE | ctlFUCHSIA. Likewise 8192 or $2000 is ctlFUCHSIA, not clMAGENTA.

I had all devices enabled on channels 0 and 1. (initial voices chan0: 1 chan1: 3)
Code: [Select]
0x0000  00 01 FF 03 FF 00 00...
Disabling Adlib on chan1, with no other changes alters the 5th byte
Code: [Select]
0x0000  00 01 FF 03 FB 00 00...

All devices enabled would be 0xFF. "And Not" AdLib (4) would be 0xFB. So that makes some sense... guess I'll have to experiment with implementing this now.

Good, good. Thanks for clearing that up cos I don't like my meals too salty.

Having looked closely at Doomie's data, there's one thing I'd like to confirm first: what devices are those two channels set to play on?

Back on the laptop, will study Doomie's findings later.

The thing about Ravi's writeup is that at least the part I referenced doesn't match my hypothesis:
The upper 4 bits of that byte specify how many voices each logical MIDI channel will be playing. The lower 4 bits specify which drivers should react on that channel. Bit 0 set means AdLib shall react. Bit 1 set means PCjr shall react. MT32 will react on all channels. Bit 3 signals the control channel.
Not only does that imply AdLib's channelMask is 0x01 (it's 0x04) but I wasn't aware the PCJr was able to run SCI so that's something I'd prefer to take heavily salted.

I'll have to look again when I'm back on my laptop instead of my phone but I think you might be on to something, Doomie.

Just gotta confirm where the value goes, then.

Extra field in the side bar, then?

Pages: 1 ... 3 4 [5] 6 7 ... 113

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

Page created in 0.114 seconds with 21 queries.