No Variable Space-HELP

[pngcan]

Hello Friends, I am at the very end of completing Geo's Quest Gateway to Nowhere (GQ3) and I have run into a no variable space error in the Grac2 editor. I can't continue. I checked the Amos source Edmond Clay provided in his distribution in AmosPro and see his Buffer was set at 100k. So I expanded it to 150k saved it and tried to compile it to a new WB executable but no luck. Is there anyone out there that could lend a hand, check the source, expand the buffer and compile a new working WB editor for me. I am so close to completing these next 3 chapters but can't go forward. It is the Edmond Clay GRAC2 release which includes all the AMOS source code. The source is the Graceditor2 code that the set buffer needs to be increased and then a new wb executable compiled. I am still just a rookie with AMOS (which is why I have been using Grac2) Thanks

[adrazar]

Originally Posted by pngcan

So I expanded it to 150k saved it and tried to compile it to a new WB executable but no luck.

So you succeeded in compiling it, but the new version displays the same error message? What happens if you try to run the modified program from AMOS without compiling?

[pngcan]

Hello adrazar, no I had no success in compiling it; unfortunately it just hangs. I tried running it from Amos but I keep getting a no extensions loaded error. I thought the source code Edmond provided was compete. Alas I am just getting my feet wet again in Amos after some 25, 30 years and I am a bit lost in this process at this point. Which is why for now I have been using Grac2. I have reached out to the gentlemen who are upgrading Grac to Grac 3 in hope they can assist as well.

[adrazar]

I just tried compiling the program and got the same problem as you. I can run it from the editor though. Do you have the "AMOSPro Compiler extension V 2.00" installed (right click > AMOS > About Loaded Extensions)? I skimmed through the code and saw only regular commands except two coming from that extension (Squash/Unsquash). I'm a bit curious about why the compilation fails and would like to have a look into that, but perhaps not today

[pngcan]

Hello Adrazar, yes I have the lib in the extensions folder, but it is not showing up in AMOS,Oddly, my Set Editor Setup function won't load to install it. Looks like I have a bad install of pro 2.0, or it may be a conflict with my pi4.0 setup. I'm going to try it on another non pistorm 1200 to see if I get the same problems.

[pngcan]

Well I reloaded AMOSpro 2.0 and I too can run the editor in AMOS now. Unfortunately it still will not compile, it gets to about 80% and then hangs. However, I can run the editor in AMOS and it will allow me to continue writing scripts with the buffer expanded. So although somewhat cumbersome, I can finish GQ3 this way.

[adrazar]

I now know what is throwing the compiler off the rails!
This is a condenced excerpt from the SCRIPT procedure:

Proc SCRIPT

Procedure SCRIPT
   If(S=3 or S=4 or S=6 or S=7 or S=9 or S=12 or S=62 or S=15 or S=10 or S=53 or S=54 or S=67) and NO<50
   Else If S=86
   Else If(S=5 or S=25 or S=36 or S=37 or S=38 or S=39 or S=42 or S=69) and NO<50
   Else If(S=5 or S=25 or S=36 or S=37 or S=38 or S=39 or S=42 or S=69)
   Else If S=8 and NO<50
   Else If S=8 and NO>200
   Else If S=11
   Else If S=90
   Else If(S=13 or S=44 or S=103 or S=110) and NO<50
   Else If S=21 or S=22
   Else If S=48 or S=74 or S=87
   Else If S=78
   Else If S=56 or S=57 or S=58 or S=59 or S=61 or S=64
   Else If S=70 or S=80 or S=92 and NO<50
   Else If S=18 or S=28
   Else If S=95 or S=97
   Else If S=109 and NO<50
   Else If S=112 and(NO<50 or NO>200)
   End If 
End Proc

Compiling this will cause the compiler progress bar to stop at around 20% completion.
It is possible to fix the problem by replacing some of the long or-or-or expressions with shorter expressions.
So one solution is to simplify/rewrite this part of the code.

The problem can also be solved by increasing the size of one of the internal buffers that the compiler is using during compilation.
I suppose this is the better option here, because you didn't write the code in the first place.
It can be done fairly easily from AMOS by running the following program:

FILE$="AMOSPro_System:APSystem/APCmp"
Open In 1,FILE$
SIZE=Lof(1)
Close 1
If SIZE<>$7358 Then Print "Wrong file size"; : End

Reserve As Work 10,SIZE
Bload FILE$,Start(10)
Poke Start(10)+$486,$20
Bsave FILE$,Start(10) To Start(10)+SIZE

This will increase the buffer size from 4096 bytes to 8192 bytes, which should still be a modest size.

[Arne]

I don't know what the code does (Edit: ever mind all this perhaps, if not your code), but if it deals with something like terrain collision, you could try adding some tile meta data in an array or byte bank to clarify what type each tile is (maybe using data statements), then:

Underfoot = Map(px,py)

TerrainType = WhatTypeIsThisTile(Underfoot)

Then – and this is proper dirty – you can do a fun goto switch:

Gosub SWITCH

SWITCH:
 Trap Goto TerrainType+100 : Rem Can add+100 or +whatev if needed
 If ErrTrap Then Print "Out of Bounds / Default." : Return
 100 Print "Lake" : Return
 101 Print "Rock" : Return
 102 Print "Tree" : Return
 Return

I don't know if it compiles to a proper jump table. It doesn't work in AMOS 1.3x.

Alternatively you can structure your tiles in a way... like split all impassable tiles into 0-127, then roads in a group of 16, etc, special items at 240-255. Then one can easily use bitshifts and masks, or just division and subtraction to figure out the meta data from that. It saves memory since you don't need a lookup table like above.

Edit: Just realized AMOS Pro has:

On X Goto ROCK, LAKE, TREE

This seems to run a few % faster than an If-Block (uncompiled). And faster than Goto X...? Gosub is slower than Goto, perhaps because of return-point setup.

[adrazar]

Originally Posted by Arne

(Edit: ever mind all this perhaps, if not your code)

Quite sure nobody in this thread wrote this code

I haven't looked into what S stands for, but since this is a point-and-click adventure game editor, I think it is likely to be related to button selections. However your suggestion with creating a lookup-table makes sense regardless of the meaning of S. Indeed I would have done just that (a lookup-table) if I were to simplify this code

Why not just do it

Dim T(110)
Global T()
T(3)=1 : T(4)=1 : T(6)=1 : T(7)=1 : T(9)=1 : T(10)=1 : T(12)=1 : T(15)=1 : T(53)=1 : T(54)=1 : T(62)=1 : T(67)=1
T(5)=2 : T(25)=2 : T(36)=2 : T(37)=2 : T(38)=2 : T(39)=2 : T(42)=2 : T(69)=2
T(13)=3 : T(44)=3 : T(103)=3 or T(110)=3
T(21)=4 : T(22)=4
T(48)=5 : T(74)=5 : T(87)=5
T(56)=6 : T(57)=6 : T(58)=6 : T(59)=6 : T(61)=6 : T(64)=6
T(70)=7 : T(80)=7 : T(92)=7
T(18)=8 : T(28)=8
T(95)=9 : T(97)=9
Proc SCRIPT

Procedure SCRIPT
   T=T(S)
   If T=1 and NO<50
   Else If S=86
   Else If T=2
      If NO<50
      Else
      End If
   Else If S=8 and NO<50
   Else If S=8 and NO>200
   Else If S=11
   Else If S=90
   Else If T=3 and NO<50
   Else If T=4
   Else If T=5
   Else If S=78
   Else If T=6
   Else If T=7 and NO<50
   Else If T=8
   Else If T=9
   Else If S=109 and NO<50
   Else If S=112 and(NO<50 or NO>200)
   End If 
End Proc

(ah, that's better )

Originally Posted by Arne

Edit: Just realized AMOS Pro has:

On X Goto ROCK, LAKE, TREE

This seems to run a few % faster than an If-Block (uncompiled). And faster than Goto X...? Gosub is slower than Goto, perhaps because of return-point setup.

I always do such things with On N ..., but the creative solution you presented first seems to have some benefits... (On N ... can only handle a limited number of labels, and using On N ... I usually require N to be able to take on *all* values in a given range (to avoid having to use dummy labels)...)

[pngcan]

Originally Posted by adrazar

I now know what is throwing the compiler off the rails!
This is a condenced excerpt from the SCRIPT procedure:

Proc SCRIPT

Procedure SCRIPT
   If(S=3 or S=4 or S=6 or S=7 or S=9 or S=12 or S=62 or S=15 or S=10 or S=53 or S=54 or S=67) and NO<50
   Else If S=86
   Else If(S=5 or S=25 or S=36 or S=37 or S=38 or S=39 or S=42 or S=69) and NO<50
   Else If(S=5 or S=25 or S=36 or S=37 or S=38 or S=39 or S=42 or S=69)
   Else If S=8 and NO<50
   Else If S=8 and NO>200
   Else If S=11
   Else If S=90
   Else If(S=13 or S=44 or S=103 or S=110) and NO<50
   Else If S=21 or S=22
   Else If S=48 or S=74 or S=87
   Else If S=78
   Else If S=56 or S=57 or S=58 or S=59 or S=61 or S=64
   Else If S=70 or S=80 or S=92 and NO<50
   Else If S=18 or S=28
   Else If S=95 or S=97
   Else If S=109 and NO<50
   Else If S=112 and(NO<50 or NO>200)
   End If 
End Proc

Compiling this will cause the compiler progress bar to stop at around 20% completion.
It is possible to fix the problem by replacing some of the long or-or-or expressions with shorter expressions.
So one solution is to simplify/rewrite this part of the code.

The problem can also be solved by increasing the size of one of the internal buffers that the compiler is using during compilation.
I suppose this is the better option here, because you didn't write the code in the first place.
It can be done fairly easily from AMOS by running the following program:

FILE$="AMOSPro_System:APSystem/APCmp"
Open In 1,FILE$
SIZE=Lof(1)
Close 1
If SIZE<>$7358 Then Print "Wrong file size"; : End

Reserve As Work 10,SIZE
Bload FILE$,Start(10)
Poke Start(10)+$486,$20
Bsave FILE$,Start(10) To Start(10)+SIZE

This will increase the buffer size from 4096 bytes to 8192 bytes, which should still be a modest size.

Thanks very much adrazar for all your effort in this matter. Sorry it took me so long to get back, unfortunately I haven't been well. I followed your suggested code to increase the buffer in the compiler only changing the FILE$ to see the directory my AMOS load has APCmp in and alas I keep getting a script error both in test & run. I even created a directory "AMOSPRO_System:APSystem and moved the file into there but still the same script error message. Here is my script: Am I missing something?

[adrazar]

Originally Posted by pngcan

alas I keep getting a script error both in test & run.

Meaning the program says "Wrong file size? That would imply we haven't got the same binary for the compiler. Here is one with the right size:

https://github.com/AOZ-Studio/AMOS-P...APSystem/APCmp

[adrazar]

By the way, there's one error in the picture you posted; last line should read

Bsave FILE$,Start(10) To Start(10)+SIZE

[pngcan]

Originally Posted by adrazar

By the way, there's one error in the picture you posted; last line should read

Bsave FILE$,Start(10) To Start(10)+SIZE

Thank you my friend, you are master of all that is Amos
It worked, I have a new grac2editor with a buffer of 1000k and can now continue with the completion of GQ3 - Gateway to Nowhere without having to run it through Amos. Thank you again

[adrazar]

Originally Posted by pngcan

Thank you my friend, you are master of all that is Amos

Haha, thanks for that