Community
SCI Programming => SCI Syntax Help => Topic started by: gumby on March 17, 2018, 11:17:10 AM
-
I'm having an issue which seems to be related to the number of global variables I have defined in Main (SCI 1.1 game). When I get past about 256 values (including array indices), it causes the status bar to corrupt. I've troubleshot it to the point where if I add/subtract a single global it either works/doesn't work as expected.
Is there a known limit to the number of global variables that can declared?
-
Considering... *picks a game at random* QfG3 has like 700 globals, I sincerely doubt it.
Fun fact: KQ6 has only 166.
Okay, I tried it myself with my little Fuckery project. Gave it a standard (DrawStatus) bar and the following globals after what was already there: gBarf = $DEAD
[gTestFiller 1024]
gWonk = $BEEFCompile, rebuild, run, the status bar shows up fine. Look at the heap in SV, I see global[$480] (1152), with $DEAD, a whooole lotta $0, and $BEEF at the end. And then I ran it again with the SQ5 status line, works great, sorry.
-
Thanks Kawa. So I just did another test - I've discovered that it's sensitive to the exact number of globals that I declare. If I add just one more global the problem disappears. Just for reference, when the status bar went wonky my status bar was showing the text 'icon8' in the upper left corner.
Well, I'm unblocked. Plowing ahead.
-
Sounds like you're providing an invalid (or unfilled) buffer to whatever code draws the status bar. You should be able to track it down by printing out the buffers in statusLineCode:doit.
-
Trying to track down the problem is proving to be difficult. Printing out the buffers in the status line code causes the problem to not manifest itself consistently - being an observer is changing the outcome. At one point my debug print statement was showing that the gMaxScore variable was a large number.
I can also make the problem 'go away' by increasing any of the buffers declared in the statusLineCode method by a significant enough amount (like increase temp0 from 50 to 55, or temp50 to 55 or tmpScore buffer from 8 to 18). Everything I do just moves the problem around, not convinced that any change I make actually fixes the problem. I'm doing something very wrong somewhere (maybe not even in statusLineCode) that works despite itself most of the time.
Here's my code, maybe you guys can see something that I'm overlooking:
(instance statusLineCode of Code
(properties)
(method (doit &tmp [temp0 50] [temp50 50] temp100 [tmpMoves 10] [tmpScore 8])
(= temp100 (GetPort))
(SetPort -1)
(Graph grFILL_BOX 0 0 10 320 VISUAL 5 -1 -1)
(Graph grUPDATE_BOX 0 0 10 320 VISUAL)
(Message msgGET gRoomNumber 61 0 0 1 @temp0) ; 61 = N_TITLEBAR in room messages
(Format @tmpMoves "Moves")
(Format @tmpScore "Score")
(Format @temp50 {Zork I %s %10s:%4d %8s:%3d/%3d} @temp0 @tmpMoves gMoves @tmpScore gScore gMaxScore)
(Display @temp50 dsCOORD 4 0 dsFONT gFont dsCOLOR 6)
(Display @temp50 dsCOORD 6 2 dsFONT gFont dsCOLOR 4)
(Display @temp50 dsCOORD 5 1 dsFONT gFont dsCOLOR 0)
(Graph grDRAW_LINE 0 0 0 319 7 -1 -1)
(Graph grDRAW_LINE 0 0 9 0 6 -1 -1)
(Graph grDRAW_LINE 9 0 9 319 4 -1 -1)
(Graph grDRAW_LINE 0 319 9 319 3 -1 -1)
(Graph grUPDATE_BOX 0 0 10 319 VISUAL)
(SetPort temp100)
)
)
-
Yep, this sounds like classic memory corruption behavior. Forging ahead with this issue unresolved sounds like it might cause trouble down the line. I am assuming you haven't run your game under ScummVM yet? Try it... memory management bugs manifest very differently there, and likely closer to the actual culprit.
-
Good idea, thanks. I started the game up in ScummVM and found some unrelated issues with some scaler calls (which I was able to temporarily remove) but the problem with the status bar remains. Just a 'icon8' in the upper left corner.
Guess I'll start rolling back my code and see if I can isolate when the problem crept in.
-
This seems to be an issue with the template game. I started with a brand new game and incrementally added variables to main. Here are the results:
...
[gFlags 14] ; Start of bit set. Room for 14 x 16 = 224 flags.
gEdgeDistance = 10 ; Margin around screen to make it easier to walk the ego to the edge.
gDebugOut
test1
test2
test3
test4
test5 ; LB2FTRINIT
test6
test7
test8
test9
test10
test11
test12
test13
test14 ; LB2DOVERBCODE
test15
test16
test17
test18
test19
test20
test21
test22
test23 ; CHECKICON
)
After adding 5 variables, the status bar reads LB2FTRINIT, after 14 'LB2DOVERBCODE' and after 23 'CHECKICON'. Seems like the problem goes away if I remove the Message call in statusLineCode in favor of copying a string into @temp0 (tested with adding 50 variables to Main and couldn't recreate issue) - but I may have just 'moved the problem around'.
(instance statusLineCode of Code
(properties)
(method (doit &tmp [temp0 50] [temp50 50] temp100)
(= temp100 (GetPort))
(SetPort -1)
(Graph grFILL_BOX 0 0 10 320 VISUAL 5 -1 -1)
(Graph grUPDATE_BOX 0 0 10 320 VISUAL)
;;;(Message msgGET 0 N_TITLEBAR 0 0 1 @temp0)
(StrCpy @temp0 "Dummy")
(Format @temp50 {%s %d} @temp0 gScore)
(Display @temp50 dsCOORD 4 0 dsFONT gFont dsCOLOR 6)
(Display @temp50 dsCOORD 6 2 dsFONT gFont dsCOLOR 4)
(Display @temp50 dsCOORD 5 1 dsFONT gFont dsCOLOR 0)
(Graph grDRAW_LINE 0 0 0 319 7 -1 -1)
(Graph grDRAW_LINE 0 0 9 0 6 -1 -1)
(Graph grDRAW_LINE 9 0 9 319 4 -1 -1)
(Graph grDRAW_LINE 0 319 9 319 3 -1 -1)
(Graph grUPDATE_BOX 0 0 10 319 VISUAL)
(SetPort temp100)
)
)
-
Eek, I think this might actually be an SCI Companion compiler bug!
If, after the Message call in statusLineCode:doit, you put something like (= temp1 temp2), then it should clear things up (I need to do some more investigation to see if that just "pushes the problem off", or is actually a solid workaround). It looks like the compiler is providing the wrong format string to Format, otherwise - i.e. it passes {lb2FtrInit} instead of {%s %d}.
-
So I can't really think of a robust workaround. The only workaround I can think of is to add some nop lines of code before the Format call when you notice this happening. But I did submit a proper fix to the repo:
https://github.com/icefallgames/SCICompanion/commit/e2b5891052f884180b3705c273941b69b8a9878b
I'm lazy though, so it also has other uncommitted fixes that were lying around mixed in with it. Hopefully it doesn't break anything.
-
Fun fact: it's been just over a year since the last commit.
*lets VS15 very slowly load so he can very slowly compile*
-
Workaround no-workie. I tried various flavors of no-ops, couldn't get it to clear the issue. I'll try a build next.
[Edit]: Correction, I was able to clear the issue. 'Initializing' the string works perfectly:
(StrCpy @temp50 "")
(Format @temp50 {%s %d} @temp0 gScore)
Which is strange because I vaguely remember doing this before in other circumstances, probably for the same reason (SCI0 games). This may be a really, really old bug going back to Companion 2?
-
Did the "add five vars to a fresh game" test on the new build. It passed.
-
Can someone send me a build? lol
-
Can someone send me a build? lol
Shure mate (http://helmet.kafuka.org/sci/SCICompanion.exe). Trade you for a full GM 1.pat? ;)
-
Thanks for the new build, appreciate it.
-
Workaround no-workie. I tried various flavors of no-ops, couldn't get it to clear the issue. I'll try a build next.
[Edit]: Correction, I was able to clear the issue. 'Initializing' the string works perfectly:
(StrCpy @temp50 "")
(Format @temp50 {%s %d} @temp0 gScore)
Which is strange because I vaguely remember doing this before in other circumstances, probably for the same reason (SCI0 games). This may be a really, really old bug going back to Companion 2?
Couldn't be, because it doesn't happen in SCI0: it only happens for games that use separate .scr and .hep resources. It will occur when the code offset of the lofsa/lofss instruction (which loads a string/instance/said pointer into the accumulator) in the .scr resource is the exact same number as the offset of a string for a class property value in the .hep resource.
When that happens, the wrong string pointer can get compiled into the code. So adding some more code before the offending string will cause the code offset to change (and likely the bug to go away, until it lines up with something else).
So in your case, the place that referenced the {%s %d} string ptr was at offset 2353 (for example) in the .scr resource, and the name property value for the lb2FtrInit instance was at offset 2353 in the .hep resource.
-
Can someone send me a build? lol
Shure mate (http://helmet.kafuka.org/sci/SCICompanion.exe). Trade you for a full GM 1.pat? ;)
Lol touche.
Seriously, though. The problem, the reason I've been avoiding it, is because not all of the instruments I need for a full GM patch exist in the vast library of MT-32 timbres I have. I'd need to make some from scratch and I just don't know where to begin doing that. I've been toying with just finding alternate timbres that sound close, but I don't want to do a cheap hack or be too far off-base.