Restore - Data question

[1980gamer]

I want to start reading data from over a hundred different starting points.

 

I know we can do something like this.

10 IF level =1 then restore 15000

20 IF level =2 then restore 15010

......

 

Can I use a variable?

 

10 SL=9 :: ! Selected Level
20 SLVL=15000+(SL*10)  :: ! Starting Level = 15090 in this example
30 RESTORE SLVL  :: ! restore to data line based on the level

---game code here

15080 data 1,2,3,1,2,1,3

15090 data 2,2,1,1,3,3,1

15100 data 3,2,1,1,2,3,1

 

 

[apersson850]

I don't think so. But I can't see that it takes more than a few code lines to figure out if you get an error if you try.

[1980gamer]

Just now, apersson850 said:

I don't think so. But I can't see that it takes more than a few code lines to figure out if you get an error if you try.

I may have phrased that wrong..  It didn't work for me.  But it seems it should.  As restore has overloads for file handling.  It seems this could/should work.

 

I have not tried as it does not show it in the manual...  ON x RESTORE 15090,15100 ....

 

Has anyone had a similar need to accomplish?

[RXB]

The problem is your syntax is wrong:

 

RESTORE line-number

EXAMPLE: 200 RESTORE 710

or 

RESTORE #file-number

EXAMPLE: 200 RESTORE #TEST

or

RESTORE #file-number,REC number

EXAMPLE: 200 RESTORE #AFILE,REC 77

[pixelpedant]

No, you cannot in any direct way conditionally designate the destination of a RESTORE. 

 

Under the hood (i.e., in the tokenised BASIC), as with GOTO or GOSUB, RESTORE (when used with DATA statements) accepts a single parameter, which is a word value representing the line from which (or subsequent to which) DATA shall be thereafter read.  It is not an evaluated expression. It is an immutable constant.

 

The only ways I am aware of by which to determine the location of a READ based on a variable value N is 

 

1) RESTORE to a fixed point, then loop over READs of consecutive values until you have read the Nth value.

2) Use ON N GOTO or ON N GOSUB to pass control to the Nth RESTORE statement in a series thereof, specifying the desired lines for respective values.

 

It must be noted that RESTOREing excessively is *very* undesirable, as it is very slow.  So even were one able to RESTORE more flexibly, you probably wouldn't want to.  You want to READ consecutive values if at all possible, as this is much faster. 

[retrodroid]

Just now, 1980gamer said:

I may have phrased that wrong..

"Incorrectly", you may have phrased that "incorrectly".  

 

Sorry, couldn't resist...  😁

[1980gamer]

10 minutes ago, pixelpedant said:

It must be noted that RESTOREing excessively is *very* undesirable, as it is very slow.  So even were one able to RESTORE more flexibly, you probably wouldn't want to.  You want to READ consecutive values if at all possible, as this is much faster. 

This has been my use case up until my current project.  I want to be able to have you start at level X.  But I will have 100+ levels.

Each level is 72 values ( as of now, I can see this increasing a little )

 

To start at level 10, I would need to read 720 values.  level 100 would be 7200 values.  I can see this take a little time...

However, I could READ a,b,c,d,e,f  and divide that time by 6.  I try not to have extra variables... and certainly wasted! 

 

[pixelpedant]

Why not just read this data from disk?  There you can read whatever record you want. 

[SteveB]

A compromise like:

 

ON Level/10 GOSUB 10000,10010,10020,...

FOR I=0 to Level - INT(Level/10)*10 

   READ x,x,x,x,

NEXT I

 

 

10000 RESTORE 11000 ::RETURN 

10010 RESTORE 11100 ::RETURN 

10020 RESTORE 11200 ::RETURN 

(...)

 

This would give you a reasonable speed, at maximimum you need to read 9 levels in vain...

 

[SteveB]

2 minutes ago, pixelpedant said:

Why not just read this data from disk?  There you can read whatever record you want. 

Or do it like I did in my WordSearch game ... I loaded the data into low memory and PEEKed it. Very fast, very efficient, at least for integer values, bytes or words.

[1980gamer]

3 hours ago, pixelpedant said:

Why not just read this data from disk?  There you can read whatever record you want. 

In case I want to convert it to a cart.

 

[pixelpedant]

17 minutes ago, 1980gamer said:

In case I want to convert it to a cart.

 

Well that does make a certain amount of sense, since you're already talking about using far more data than a TI BASIC program may contain.  In that your limit on the size of a TI BASIC program is ~12KB, and you're talking about storing DATA lines within the program containing 100 x 72 values per level x 3 bytes per numeric value minimum (unquoted string token, length byte, 1 numeric character) = 21.6KB in numeric DATA alone.  So if those are your criteria and compiling is the goal, I'd just write for the compiler, and accept that what you're writing is not a functional TI BASIC program and cannot be stored in the Program format, but can nonetheless (potentially) be used to produce a working compiled program written using TI-BASIC-like structures. 

[1980gamer]

4 minutes ago, pixelpedant said:

Well that does make a certain amount of sense, since you're already talking about using far more data than a TI BASIC program may contain.  In that your limit on the size of a TI BASIC program is ~12KB, and you're talking about storing DATA lines within the program containing 100 x 72 values per level x 3 bytes per numeric value minimum (unquoted string token, length byte, 1 numeric character) = 21.6KB in numeric DATA alone.  So if those are your criteria and compiling is the goal, I'd just write for the compiler, and accept that what you're writing is not a functional TI BASIC program and cannot be stored in the Program format, but can nonetheless (potentially) be used to produce a working compiled program written using TI-BASIC-like structures. 

Okay, that was over my head, but I get the gist....

 

I plan to compress the data, when I have finalized it.  I don't know what that size will be at this time.

Also, this was always going to be compiled.  The real question is,  XB or XB256?  I have wandered into XB256 with my latest needs. 

I am trying to think of ways not to need the extended character definition space.

 

Do I redefine my chars and sprites with each level?  This certainly solves many issues, while creating a host of others

For instance, if I predefined all the characters, I know I can draw ANY game board and not worry.

If I user 5 character sets, I can only have 10 chars on the screen and only 5 colors.  I have 22 "graphics"  2x2 or 16x16 sprites.

 

I am already using MAGIC  to fake the 11th char set.  as I have other non-game play graphics to display etc. LOL

 

However, when I have all the level data, I will know the MAX distinct images on a screen.

At that point,  I may re-write a chunk of the program and no longer need XB256. 

 

Though I am thinking of other reasons to use the xb256 features...