On Tue, Mar 22, 2016 at 5:15 AM, Ralph Versteegen <[email protected]> wrote:
> On 22 March 2016 at 03:11, James Paige <[email protected]> wrote: > > > > > > On Sun, Mar 20, 2016 at 9:30 AM, Ralph Versteegen <[email protected]> > > 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. > > 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. > > I just tested Angel Whispers all the way through in the current wip build. It all ran perfectly. I assume that "release mode" was hiding errors from me, but none of them were fatal, and I was able to play every battle of the demo with no problems. > 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. > Maybe something like an in-program error console viewer? (really, a g_debug.txt viewer) > > >> > >> 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 > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
