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 ... 35 36 [37] 38 39 ... 48
541
SCI Development Tools / Re: Changes to SCI 1.1 template game
« on: July 22, 2015, 05:20:44 AM »
Curious. Why would you need to replace 994.voc?

It's the one that defines the offsets at which certain property selectors are found in objects (you were the one who explained it to me!).
Ha ha, yes I did. I think the question I was getting at is why does the version from LSL6 work? Coincidence?

542
SCI Development Tools / Re: Changes to SCI 1.1 template game
« on: July 22, 2015, 03:50:05 AM »
Playing around with my "explore SCI1.1" game, I found it would be nice to have the "case" property on Features (and Views/Props/Actors). This lets you display a different message (when interacting with an object) depending on the state an object is in, without having to override the doVerb method and call gTestMessager:say directly (or changing the noun at runtime).

I was able to get it to work by added the case property (actually _case), changing a couple of lines of code in Feature.sc, and using the LSL6 994.voc (instead of the SQ5 994.voc, which is what the template game is currently using). What do people think about making these changes in the template game?
Curious. Why would you need to replace 994.voc?

543
SCI Development Tools / Re: Changes to SCI 1.1 template game
« on: July 21, 2015, 01:15:05 AM »
Cat something? Oh, I am so looking forward to this. I loved the Katta in the QfG series.

544
It's not something that's inherent to SCI1.1, it's the way you script your game.
Not true. Earlier SCI games used to call Wait in the main loop. This synchronizes the game loop against the system clock while still keeping the speed adjustable.
Later SCI games omit this statement, letting games run as fast as they can and putting a strong burden on the programmer that he wouldn't need to bear otherwise. It's a deliberate decision on the part of the system programmers, and it's bad design. I'd say it's inherent.

In fact, I've just noticed that the NRS patches for at least one game add a Wait statement in the main loop (although not where Sierra used to have it).

545
SCI Community How To's & Tutorials / Re: Palette room example
« on: July 10, 2015, 11:26:09 AM »
This may have been fixed already, but in some games, calls to PalVary are annotated as Intersections. Even LSL6, which is used for the template game. But if you are using it already, then I suppose it's OK.
(and yes, there is the problem of different games mapping kernel functions differently)

546
SCI Community How To's & Tutorials / Re: Palette room example
« on: July 10, 2015, 08:26:14 AM »
Here it is...

From the main room, walk through the door to the north into the "palette room". It shows off palette cycling, palette transitioning, and palette intensity variations. Also some cool tricks with assigning regions of the palette to different parts of the picture, which will be much easier with the next update to SCI Companion  ;)
Does it also show off PalVary (aka "Intersections")? You do mention transitioning, but I think that it would be a good idea to fix this name for discoverability...

547
I mean, I can see the benefit of Scumm behaving this way. It alerts to a game doing something potentially incorrect. I don't think this merits any changes in Scumm.

Yeah, adding a zero is a clever alternative (although that requires people to update their game). I can also just re-work the code in those two functions to not need to do this. I'm using memPOKE just so I can return an additional value from that function in a parameter. But I can just as easily make the needed calculation in the calling function.
Too bad. I liked the approach of returning the next pointer via Memory().

548
We're placing a pointer (which points *past* the local var buffer for room 110) into the address specified by nextPoly. Somehow, ScummVM knows this value is a pointer and not just a number (I have no idea how  :)), and complains. Even though we will never actually read from this location. Hmmm....
I laughed at this... right, so it seems that the allow-any third parameter for Memory() doesn't actually let you through if there's an invalid pointer. Part of me wants to argue that this is correct behavior (fail fast) - on the other hand the lenient behavior would be consistent with how C++ iterators (for instance) work.
This kernel signature seems to work but I have not tested it broadly:
Code: [Select]
        { MAP_CALL(Memory),            SIG_EVERYWHERE,           "i(.)([!ir])", NULL,            kMemory_workarounds }, // subop
there are actually a few different ways to solve this. An easy one on the script side would be to always put a zero at the end of the polygon array, that way the pointer will be valid.

549
I was thinking of a 24-style split screen display. I don't know if that's even doable, though I suspect not.

550
The kernel call you need is called SetPort. There is a long form and a short form, and for this you need the long form. Something like:
Code: [Select]
        SetPort(0 0 200 320 0 0)
and
Code: [Select]
                SetPort(0 0 190 320 10 0)
to reset it afterwards (which you absolutely must do). The short form is used to draw things like dialog box borders (the reason being that they are logically outside the extent of the dialog box) and custom menu bars.

Both of these only affect future draw commands. So you'd typically sandwich a super:init() or a drawPic between two SetPort calls.

551
This is abuse, I tell you! Abuuuse!
Seconded.  ;D It can get much worse though... picture this stuff combined with Memory and odd pointer voodoo.

552
Maybe not for games as such. It could be useful for toolmaking though.

553
SCI Development Tools / Re: MT-32 Patch Weirdness *solved* (sort of)
« on: July 03, 2015, 11:23:55 PM »
That's the point. It is designed for the "MPU interface" and so doesn't use sysexes at all (unless you put them in your MIDI data; not sure how that'd work).

554
SCI Development Tools / Re: MT-32 Patch Weirdness *solved* (sort of)
« on: July 03, 2015, 09:02:10 PM »
Hey,

The mt32.drv file in LB2 has the descriptive name "Roland MT-32, MT-100, LAPC-I, CM-32L, or CM-64".
The m32.drv file in LSL6 has the descriptive name "Roland MT32 with MPU interface" (no hyphen in the model name!)

So they are obviously different - but they both use patch.001 (and not patch.004 as the GM driver does).

555
Right, so the backtrace with symbols looks like this:
Code: [Select]
=>0 0x0053ece1 PicCommandSidePane::_SyncPolyChoice+0x51() in scicompanion (0x0032ca70)
  1 0x0053ec73 PicCommandSidePane::UpdateNonView+0x162(pObject=0x32cac0) in scicompanion (0x0032ca8c)
  2 0x0053ef80 PicCommandSidePane::SetDocument+0x4f(pDoc=(nil)) in scicompanion (0x0032caf4)
  3 0x00466a4f CMainFrame::_RefreshToolboxPanelOnDeactivate+0x6e(pWnd=0x196c9c0) in scicompanion (0x0032cb18)
...
Unfortunately, Winedbg does not understand the line number info, so I used IDA Pro to locate the faulting instruction instead (see image). PicCommandSidePane... and this happens in all the editors.  :o
Looks like it should be skipping this code under normal circumstances? Is there a stale INI file or registry setting I need to get rid of somewhere?

Pages: 1 ... 35 36 [37] 38 39 ... 48

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

Page created in 0.05 seconds with 20 queries.