Author Topic: Maxium possible global variables / Status bar corruption?  (Read 3391 times)

0 Members and 1 Guest are viewing this topic.

Offline gumby

Maxium possible global variables / Status bar corruption?
« 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?


In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline Kawa

Re: Maxium possible global variables / Status bar corruption?
« Reply #1 on: March 17, 2018, 12:20:17 PM »
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:
Code: [Select]
gBarf = $DEAD
[gTestFiller 1024]
gWonk = $BEEF
Compile, 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.

Offline gumby

Re: Maximum possible global variables / Status bar corruption?
« Reply #2 on: March 17, 2018, 06:02:49 PM »
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.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline troflip

Re: Maxium possible global variables / Status bar corruption?
« Reply #3 on: March 17, 2018, 06:32:11 PM »
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.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline gumby

Re: Maxium possible global variables / Status bar corruption?
« Reply #4 on: March 18, 2018, 09:03:05 AM »
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:

Code: [Select]
(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)
)
)

In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline lskovlun

Re: Maxium possible global variables / Status bar corruption?
« Reply #5 on: March 18, 2018, 07:22:14 PM »
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.

Offline gumby

Re: Maxium possible global variables / Status bar corruption?
« Reply #6 on: March 19, 2018, 09:21:54 AM »
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.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline gumby

Re: Maxium possible global variables / Status bar corruption?
« Reply #7 on: March 24, 2018, 08:24:35 AM »
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:

Code: [Select]
        ...
[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'.

Code: [Select]
(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)
)
)
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline troflip

Re: Maxium possible global variables / Status bar corruption?
« Reply #8 on: March 24, 2018, 03:53:55 PM »
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}.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline troflip

Re: Maxium possible global variables / Status bar corruption?
« Reply #9 on: March 24, 2018, 10:31:11 PM »
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.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: Maxium possible global variables / Status bar corruption?
« Reply #10 on: March 25, 2018, 09:48:38 AM »
Fun fact: it's been just over a year since the last commit.

*lets VS15 very slowly load so he can very slowly compile*

Offline gumby

Re: Maxium possible global variables / Status bar corruption?
« Reply #11 on: March 25, 2018, 11:40:53 AM »
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:

Code: [Select]
    (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?
« Last Edit: March 25, 2018, 12:01:40 PM by gumby »
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline Kawa

Re: Maxium possible global variables / Status bar corruption?
« Reply #12 on: March 25, 2018, 12:31:58 PM »
Did the "add five vars to a fresh game" test on the new build. It passed.

Offline MusicallyInspired

Re: Maxium possible global variables / Status bar corruption?
« Reply #13 on: March 25, 2018, 01:52:49 PM »
Can someone send me a build? lol
Brass Lantern Prop Competition

Offline Kawa

Re: Maxium possible global variables / Status bar corruption?
« Reply #14 on: March 25, 2018, 02:03:34 PM »
Can someone send me a build? lol
Shure mate. Trade you for a full GM 1.pat? ;)


SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.122 seconds with 23 queries.