Declaring static data that doesn't take up dynmem space

Authoring Dialog
1

Because we’re limited to unsigned integers (BTW, please please please at least let us have signed integers someday!), and things like tangents and square roots are Right Out, I’m having to use lookup tables to enable a part of a game that involves ranges and bearings. So I’ve got this:

(global variable (bearings table [[45 63 72 76 79 81 82 83 84 85]
		 		                  [27 45 56 63 68 72 74 76 77 79]
				                  [18 34 45 53 59 63 67 69 72 73]
				                  [14 27 37 45 51 56 60 63 66 68]
				                  [11 22 31 39 45 50 54 58 61 63]
				                  [ 9 18 27 34 40 45 49 53 56 59]
				                  [ 8 16 23 30 36 41 45 49 52 55]
				                  [ 7 14 21 27 32 37 41 45 48 48]
				                  [ 6 13 18 24 29 34 38 42 45 48]
				                  [ 5 11 17 22 27 31 35 42 42 45]]))

…which is taking up 200 bytes worth of dynamic memory, but it isn’t actually a variable, and should be able to sit in static memory. (And would do, if I were writing this in ZIL.)

If I drop the “global variable” bit and do

(bearings table [[45 63 ...] ... [ ... 42 45]])

that would be a predicate with one parameter, which becomes a per-object flag, and the list isn’t an object, so that should barf.

If I write

(bearings table $Table)       ($Table = [[45 63 ...] ... [... 42 45]])

…is that the pattern that I’m supposed to be following? (A short section in the manual on how to do this would be a spiffy addition.)

Dialog Wishlist
2

well, I’m actually a Naval Historian, and coding this type of thing is part and parcel of my research, but I use proper languages (C, Fortran, Pascal, and for those frequent quick’n dirty work, python, perl, even old interpreted basic) and not IF languages.

If you’re writing a parser-based Naval IF, count me as potential ßtester… at your risk ! :wink: )

Best regards from Italy,
dott. Piergiorgio.

2 Likes
3

If “naval” includes outer space, I may take you up on that. :slight_smile:

(I also have an idea for doing “serious” training games for cruising sailboats at some point, which might be of interest if outer space isn’t.)

4

Oh, hang on, that second pattern,

(bearings table [[45 63 ...] ... [ ... 42 45]])

…actually works. Which, I guess, makes sense, since the third pattern should unify to the second. (It’s taking me a little while to start to wrap my head around what’s going on under the covers.) So is that the recommended pattern for declaring static data, then?

5

And now that I’ve filled out the table to 20x20, I get

Error: trek.dg, line 251: Rule too complex. Try breaking it into smaller parts.

…but it worked just fine when the table was partially filled out with zeroes. Is there some hard-coded limit that I’m exceeding? Reintroducing the third pattern of

(bearings table $Table)  ($Table = [[45 63 ...] ... [... 42 45]])

…fixes it, interestingly.

1 Like
6

I came across this thread again while poking at this issue. If the compiler can handle the huge list of lists in a rule body, just not in a rule head, then I agree this is an outright bug—there’s no reason one of them should need more temporary space than the other. Ideally literals would be compiled the same way in both cases.

So, five years later, enjoy this reassurance that this issue will hopefully be fixed in 1c/01!

1 Like