Data problems!

[Brian's Man Cave]

Hey guys, I have been trying to figure out what is going on here. Most of this works but I am getting a weird number.

 

So basically, for level one I fetch some data from a few tables (hole_one, Hole_two, Hole_three) ... this is to be used to place a graphic on the screen.

 

Based on the level it grabs a section of data. So for level 1 it grabs from the data table 0 to 5 and puts it into an array.

 

Level one works fine, everything appears. but when I try level 2, the very first data number is wrong. It should be 68, but it shows up as 629. The other numbers are fine.

 

Any thoughts on what is happening?

 

Here is the code:

 

if level = 1 then
 #data_num_1 = 0  (this is for the For statement)
 #data_num_2 = 5
end if

if level = 2 then
 #data_num_1 = 6  
 #data_num_2 = 11
end if

#h1 = 0 '---------------Reset H1 to 0   -- Hole 1 
for #ah1 = #data_num_1 to #data_num_2 
 #hole_1(#h1) = Hole_one(#ah1)        '#hole_1 is the array to store the data from the table
 #h1 = #h1 + 1
next #ah1

#h1 = 0 '---------------HOLE 2 
for #ah1 = #data_num_1 to #data_num_2 
 #hole_2(#h1) = Hole_two(#ah1)
 #h1 = #h1 + 1
next #ah1

#h1 = 0 '---------------HOLE 3 
for #ah1 = #data_num_1 to #data_num_2 
 #hole_3(#h1) = Hole_three(#ah1)
 #h1 = #h1 + 1
next #ah1

 

Hole_one:
DATA 86,0,0,0,120,61 'level 1 (0-5) 
DATA 68,0,0,0,132,53 'level 2 (6-11) 
 

Hole_two:
DATA 134,0,0,0,56,46 'level 1 (0-5)  
DATA 54,0,0,0,56,14 'level 2 (6-11)

Hole_three:
DATA 167,0,0,1,64,77  'level 1 (0-5)
DATA 75,0,0,0,128,37  'level 2 (6-11)

[+cmadruga]

Why don't you simplify it a little:

 

FOR j=0 TO 5
    hole_1(j)=Hole_data((level-1)*18+j)
    hole_2(j)=Hole_data((level-1)*18+6+j)
    hole_3(j)=Hole_data((level-1)*18+12+j)
NEXT j

 

Hole_data:
DATA 86,0,0,0,120,61
DATA 134,0,0,0,56,46
DATA 167,0,0,1,64,77
DATA 68,0,0,0,132,53
DATA 54,0,0,0,56,14
DATA 75,0,0,0,128,37
 

[+nanochess]

The most common bug is using a period instead of a comma. IntyBASIC reports it but continues parsing, so your data could be mis-aligned.

[+cmadruga]

Neither the code he posted nor the data he's using cause the problem reported.

Must be some problem with the variable getting overwritten somewhere else in his code.

 

[Brian's Man Cave]

12 hours ago, cmadruga said:

Why don't you simplify it a little:

 

FOR j=0 TO 5
    hole_1(j)=Hole_data((level-1)*18+j)
    hole_2(j)=Hole_data((level-1)*18+6+j)
    hole_3(j)=Hole_data((level-1)*18+12+j)
NEXT j

 

Hole_data:
DATA 86,0,0,0,120,61
DATA 134,0,0,0,56,46
DATA 167,0,0,1,64,77
DATA 68,0,0,0,132,53
DATA 54,0,0,0,56,14
DATA 75,0,0,0,128,37
 

This makes a lot more sense for sure!

[Brian's Man Cave]

10 hours ago, cmadruga said:

Neither the code he posted nor the data he's using cause the problem reported.

Must be some problem with the variable getting overwritten somewhere else in his code.

 

I redid the coding for level 2 and now it seems to be working. There must have been something off about it.

[+cmadruga]

3 hours ago, Brian's Man Cave said:

I redid the coding for level 2 and now it seems to be working. There must have been something off about it.

Interesting, I actually ran your code and did not see any issues.

[+DZ-Jay]

17 hours ago, cmadruga said:

Why don't you simplify it a little:

 

FOR j=0 TO 5
    hole_1(j)=Hole_data((level-1)*18+j)
    hole_2(j)=Hole_data((level-1)*18+6+j)
    hole_3(j)=Hole_data((level-1)*18+12+j)
NEXT j

 

Hole_data:
DATA 86,0,0,0,120,61
DATA 134,0,0,0,56,46
DATA 167,0,0,1,64,77
DATA 68,0,0,0,132,53
DATA 54,0,0,0,56,14
DATA 75,0,0,0,128,37
 

 

Be aware that multiplying by 18 can be costly, and it would be even costlier (and redundant) to repeat it on every iteration, for every table.

 

I recommend pre-computing the term “(level - 1) * 18” on a temporary variable and using that instead.

 

    dZ.

[Brian's Man Cave]

2 hours ago, cmadruga said:

Interesting, I actually ran your code and did not see any issues.

There was other code that I didn’t include in the sample above as it had to do with other features. I think something in that code was causing an issue 

[carlsson]

Also, additional labels cost neither RAM nor ROM. Thus if you want to be extra lean, you could use a coding trick like this. It gets a little less readable but you save both CPU cycles and a bit of ROM storage.

 

offset = (level-1) * 18

FOR j=0 TO 5
    hole_1(j)=Hole_data_zero(offset+j)
    hole_2(j)=Hole_data_six(offset+j)
    hole_3(j)=Hole_data_twelve(offset+j)
NEXT j

 

Hole_data_zero:
DATA 86,0,0,0,120,61
Hole_data_six:
DATA 134,0,0,0,56,46
Hole_data_twelve:
DATA 167,0,0,1,64,77
DATA 68,0,0,0,132,53
DATA 54,0,0,0,56,14
DATA 75,0,0,0,128,37

[+cmadruga]

An interesting question: in the context of Intellivision game programming, under what circumstances should saving CPU cycles or rom storage be prioritized over code readability. And vice-versa.

 

 

 

[+DZ-Jay]

1 hour ago, cmadruga said:

An interesting question: in the context of Intellivision game programming, under what circumstances should saving CPU cycles or rom storage be prioritized over code readability. And vice-versa.

 

 

 

I would say, it depends.  It is tricky on the Intellivision, because it is such a limited platform in so many ways, and the IntyBASIC language can sometimes be … hmm … a little less expressive or optimal than one would like.

 

Personally, I would optimize for performance over code readability only when such performance is required, and would otherwise be impossible or impractical to achieve.

 

Even then, I would only compromise the intelligibility of those parts that would provide the most obvious gains.

 

Obviously, this requires iterating over you program’s life as you encounter limitations or performance problems that force you to reconsider your current approach.

 

The good news is that, this iterative work is not wasted effort — it builds and enhances your experience as an Intellivision programmer, which will enable you to code differently — and perhaps adopt new patterns and paradigms as your “new normal” — in your next projects.

 

It is also the case that not every (seemingly) non-obvious optimization reduces intelligibility.  Sometimes it leads to more concise routines or reduced logical decisions, which can make the code easier to follow, understand, and debug.  That may depend on how atypical or convoluted the revised code is.

One thing I typically do when optimizing logical or arithmetic expressions in a way that may result in more terse code, is to wrap them around subroutines or (preferably) user-defined functions (DEF FN), with clear and carefully crafted names.

 

This allows me to include the optimized code in-line in a self-explanatory way.  The index computations above may be a good candidate for this.

In any case, I would recommend to always include enough descriptive comments to allow your future self (or anyone else that may come across it) to understand the perhaps non-obvious code, and why it was done that way.

 

   dZ.

Edited March 14, 2023 by DZ-Jay