MAX SYMBOLS error

[Michael_Lee]

On retrospect, that makes so much sense that I can't believe I didn't think of that.

The coolness of Axe just went up by over 9000.

[Deep Thought]

Wait, I can mix and match strings and hex?

So would this be valid?:

Code: Select All | Copy To Clipboard

1 2 3

"Hello[20574F524C44]"->Str1 Disp Str1>Char

and would it display

Code: Select All | Copy To Clipboard

1 2	HELLO WORLD

?

Data is the same no matter what form you store it in. So

Code: Select All | Copy To Clipboard

1 2

"HELLO"

is exactly the same as

Code: Select All | Copy To Clipboard

1 2	Data(72,69,76,76,79)

and

Code: Select All | Copy To Clipboard

1 2	[48454C4C4F]

but not

Code: Select All | Copy To Clipboard

1 2	"HELLO"→Str1

since the store adds an extra [00] to the end.

[squidgetx]

Interesting thing about the MAX SYMBOLS error: it seems (to me) that it also has to do with how many times you call a subroutine/pointer

For example, today while working on Ash:Phoenix, I realized that I am multiplying by 23 quite a lot. Multiplying by 23 is very inefficient, so I decided to add a subroutine to multiply by 23. So I replaced all *23's with sub(23)'s, intending for the subroutine to be Lbl 23 : *23 : Return Since I'm lazy, I decided to compile first before adding the subroutine label so that when it gave me a missing label error, I could hit prgm to scroll to the bottom of the program and add the subroutine instead of scrolling manually.

It gave me a MAX SYMBOL error, which was strange because I had not added any new labels since the last compile It was stranger when I hit prgm to goto the error. Axe scrolled down, not to a label, but to a subroutine call (specifically, the line sub(R,0,,30,20))

Yeah...so now I'm kinda confused lol

Btw, removing all the sub(23)'s and re-replacing them with *23's led to a valid compile.

If you have 150 labels, your compiled code probably shouldn't fit in RAM anyways.

It did (16324 bytes)

[Builderboy]

*23?  Interesting, also if its speed you are optimizing for speed, you can do A*16+(A*7  instead of A*23, which will give you a large speed boost if you are multiplying by 23 a lot

[Runer112]

Even better: A*12*2-A

And why are you multiplying by 23 so much anyways? Just wondering if it could be avoided altogether.

[squidgetx]

That number just happens to be how large the move database entries are (13 bytes for name, 1/2 for class, 1/2 for power, 6 for boosts, 1 for MP damage, 1 for HP heal, 1 for accuracy). I suppose I could add a null byte at the end of each entry which would end up costing around 100 bytes of archive space in the move appvar, but I think that *24 is probably way way better than *23 and would save a decent bit in the executable. (Or I could take class and power out of nibbles and put them into their own bytes..but man, that would screw up all the offsets...maybe it's worth it though) (It's not for speed btw)

The MAX SYMBOLS thing is weird though..does anyone know anything about that?

[Runer112]

For that matter it might be better to make class and power whole bytes, as that would make each entry size 24 and probably make the retrieval of those two values a lot easier/smaller/faster.

[ztrumpet]

I think you had 153 labels beforehand, and the edition of the Lbl R (or its call) added another, #154.  Again, this is just my speculation.

[squidgetx]

No, that label (and its call) had been there for a long, long time. I compiled, it worked fine. I added nothing besides sub(23)'s, not even a Lbl 23. I gto a MAX SYMBOLS error. Removing the sub(23)'s led to an error-free compile.

[graphmastur]

No, that label (and its call) had been there for a long, long time. I compiled, it worked fine. I added nothing besides sub(23)'s, not even a Lbl 23. I gto a MAX SYMBOLS error. Removing the sub(23)'s led to an error-free compile.

Well, then the compiler probably saw that and said "oh, I should add a label entry for that. We'll figure out where it is in pass 2"

[squidgetx]

That could explain it i guess. Perhaps that particular sub(R was the first time I used it in the program...

[Quigibo]

If the subroutine is at the end of your code, it can't kick those calls out of the table until it finally encounters the label.  Putting the subroutines at the start of the program can fix that if you use them often enough.  Just make the first line of code a goto to skip over your subroutines.

Or better yet, put them in an include library so they don't crowd as much.

[Binder News]

thanks