[Ohrrpgce] Callipygous

Ralph Versteegen teeemcee at gmail.com
Tue Mar 22 05:18:16 PDT 2016


On 23 March 2016 at 01:15, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 22 March 2016 at 03:11, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>
>> On Sun, Mar 20, 2016 at 9:30 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>>
>>> OK, I'm basically done; I'm putting everything else off until after
>>> release, and don't really have more time right now. James, are you
>>> planning a release candidate?
>>>
>>
>> Awesome! I Think I will declare a nightly build to be the release candidate
>> (without actually branching in svn just yet) and see if I can prod people
>> into testing.
>>
>>
>>>
>>> The only thing that still concerns me is my last todo list item:
>>>
>>> -slice errors now appearing in old games due to slice handle numbering
>>> changes. Just hiding the errors with Release Mode may not be good
>>> enough, they may be real (new) problems. The following are likely to
>>> be caused by the same problem:
>>> --Lots of suspicious pauses and script errors in Sephy's Angel
>>> Whispers (haven't checked whether actually caused by freeslice
>>> changes)
>>> --'waitslice, already deleted slice' in Karate Fight (probably no
>>> consequence)
>>
>>
>> Well... if we add a backcompat option for bringing back the old way of
>> allocating script handles, how much of a burden would it be to keep that
>> working in the future?
>>
>> My (limited) understanding of this issue is that these games were
>> incorrectly re-using slice handles for slices that had been deleted, and
>> then new slices had been created with the same handle number
>
> That's correct.
>
> Adding a backcompat setting would be a one-line addition right now,
> but I'm still not sure how much trouble it will be in future.
>
> [Begin train of thought]
>
> I did want to switch to garbage collected handles in the new script
> interpreter. In fact I want to turn all handles and ID numbers
> (including all of the constants found in an .hsi file) into typed
> objects (called "weak types" in the ancient Plan on the wiki). For
> backwards compatibility it will be necessary to allow handles to
> existing types of objects to be treated as integers, and for integers
> to be treated as handles. A further level of back-compatibility is
> ensuring that handles correspond to the same integers that they
> currently do. Finally, a question is whether this integer<-->handle
> conversion should always be allowed, or whether it should be turned on
> by backcompat bit. If the former, it can throw an error but work
> anyway.
>
> -For NPC references, the integers clearly have to remain the same.
> -I have seen several people do/think confused things with menu/menu
> item slots/handles, since they count up from 1 in a very predictable
> way (should have made them count from -418015 instead)
> -I was planning on making the assumption that no one ever does
> arithmetic on slice handles, but the problem we're talking about is
> nearly as bad as that.

Oh, and I forgot to say that emulating the old slice handle assignment
is expensive to compute, which was the whole reason I changed it. I
certainly would not want to emulate it unless conditioned on a
backcompat bit.
But integer<-->slice handle conversion, and the old slice handle
assignment are separate questions.

> Note that you might store an npc ref or slice handle as the width of a
> slice. (People would actually do that; they wouldn't store it as the
> NPC walkabout palette.)
>
> Also you can save a game today containing saved slices, and handles to
> those slices in global variables will be integers regardless of what
> version loads it.
>
> [End train of thought]
> ....
>
> I thought that we had more examples of games where we suspected that
> the change in slice handles caused error messages? I remember that you
> figured out that that was the problem in Karate Fight. (And in that
> case we determined the error was safe to ignore, IIRC.) My reason for
> suspecting a change in the engine is to blame for Angel Whispers is
> that there so many errors (and serious breakage, I think) that I doubt
> Sephy released it like that.
>
> Maybe there actually aren't many, and we would fix more games by
> adding a backcompat bit to disable alt-key filtering.
>
> It looks like we need an easier way to actually see the error messages
> in games set to Release so that we (and others) can look for them,
> such as a debug key that always works. The --errlvl commandline option
> has no effect in Release mode, that's something I meant to fix.
>
>>>
>>> Also there are some minor things, like fixing the permissible ranges
>>> and documentation for attack costs to match reality
>>>
>>> Other bugs put off:
>>> -backwards non-automatic shrink animation can crash (can test in slice
>>> editor)
>>> -double fade out in screensaver3.rpg (update palette)
>>> -fix two off-by-one bugs in battle backdrop animation ticks
>>> -window scaling when launched through steam wrong size (Citizen Kane)
>>> -sprite dissolve with transparent=no doesn't work
>>> -disable filtered alt in old games. For example in Apophenia (2010
>>> version) pressing alt instead of esc to bring up the menu doesn't work
>>> properly. (But with either alt or esc the menu flickers anyway.)
>>> -keyval repeat rate might break balance in old games? But only if they
>>> run < 18 fps. Not a new problem since Beelzebufo


More information about the Ohrrpgce mailing list