dredds 2019-04-28 10:55
Some features I would like
1) ability to get the current data read position so that I can later pass it to the RESTORE command. I’m thinking that this could be provided in a backward compatible way by using the RESTORE keyword as an expression.
POS = RESTORE
READ a, b, c
2) the ability to use a label (or subprogram address) in the right hand side of an expression. This could be used for random access to data, building jump tables, etc.
Timo 2019-04-28 11:52
1) I don't really want to try to improve the classic BASIC in its core features, there is just too much to do ;) Also this wouldn't be an easy fix in my implementation. I recommend reading your data to arrays where you can do all these things. The first classic BASIC didn't have file access, so they used DATA as an alternative, but I think it was not meant to be used for random access.
2) I don't really understand what you mean, could you give an example (maybe pseudo code)?
Timo 2019-04-28 11:58
Seems I like starting sentences with "I don't really..."
S3B4 2019-04-28 12:32
I think in the second one he means using sub programs like how you could use some functions on normal coding. So if he makes a sub called PLUS1(x) that returns x+1 he can do Y=PLUS1(1). But he could mean something else.
was8bit 2019-04-28 13:53
@dredds, what you are wanting is advanced database functions..
This can be done with my NX TOOL "MESSAGE FILE PRO TOOL" which has a demo "MESSAGE FILE TOOL DEMO"
Basically it holds I think up to 1000 lines of data that can be 20 digits or characters long.... you use the tool to enter the data which is stored in your game as a FILE (like character designer and background designer does) and the DEMO shows you can access your data by entry #
The data is retrieved as a block of 20 characters per read, you can further organize your own data so perhaps the one read can hold 5 blocks each with 4 characters of data per block for example...
But, YOU have to write the code that will process each 20 character line read.... this isn't a database persay, it just lets you enter a ton of 20 character lines of data as a permanent file in your game without having to mess with tons of DATA statements....
You may recall ANY line of data at ANY time you want, you can even recall the same line of data multiple times.. the data is retrieved by LINE NUMBER, and you get 20 characters back from that line of data..
So, effectively your data is 20 characters wide, and over 1000 characters high, and you retrieve any portion of it one line at a time...
was8bit 2019-04-28 13:56
Alternatively, for smaller data volumes, you can read your data and use POKE to store data manually, one character or digit at a time, into NX memory,and then use PEEK to randomly read back one character or digit at a time...
dredds 2019-04-28 13:57 (Edited)
Example of using functions or labels in the right hand side of expressions.
Suppose I am writing a maze game in which ghost sprites either roam the maze or flee from the player.
I can write a subprogram for each behaviour.
I would like to store the current behaviour for each ghost in an array. Eg
FOR I = 0 TO 3
GHOSTS(I) = GHOST_ROAM
And be able to change that when something happens to make the ghost flee...
GHOSTS(N) = GHOST_FLEE
Or stop fleeing...
GHOSTS(N) = GHOST_ROAM
This is something one could do in some BASIC dialects on 80s microcomputers.
dredds 2019-04-28 14:00
@was8bit that looks like just what I’m thinking of.
In general I think the ROM files are a better approach to data statements.
was8bit 2019-04-28 14:03
IF GHOSTS(N)=1 THEN CALL GHOST_ROAM(N) ELSE IF GHOSTS(N)=2 THEN CALL GHOST_FLEE(N)
was8bit 2019-04-28 14:05 (Edited)
My TOOl: It's a VERY basic data storage system.. designed for HUGE volume, with rapid fast basic retrieval... entry and retrieval is based on 1 line at a time :)
dredds 2019-04-28 14:09
@was8bit that’s what I’m doing right now but as the number of behaviours increases it gets more and more error prone to keep track of how numbers map to subroutines. I reached the limit of my mental ability to keep track of it all in the Infiltrator game :-)
was8bit 2019-04-28 14:10 (Edited)
With my tool, one "could" craft each line for whatever data they wanted, as random text as my demo has, or you can create your own format, like break down the 20 character line into smaller predetermined blocks of data...
So, if you formatted the 20 characters into 10 blocks of 2, one line could hold 10 2digit numbers, or if broke down into 4 blocks of 5, one line could hold 4 5character long words...
was8bit 2019-04-28 14:15
Then you can try organizing the numbers into blocks of 10
So, anything 10-19 relates to shades or sequences or steps in one mode..
10= initialize FLEE
11= begin FLEE
12= do FLEE 2
13= do FLEE 3
14= check FLEE
You might even pass this number to the FLEE sub...
IF GN>=10 AND GN<=19 THEN CALL GHOST_FLEE(N,GN)
was8bit 2019-04-28 14:26
If you have more than 10 things for each mode, do them in blocks of 100
100-199 = FLEE
200-299 = ROAM
Timo 2019-04-29 17:36
Using subprograms as values sounds too complex for me from the point of implementing it. Could get confusing for users, too.
Old BASICs had the "ON" command:
ON N GOSUB ONE, TWO, THREE, FOUR, FIVE
or ON N CALL ...
But then all values have to be in order. I think desbyc missed this command already. Would it help anyone else? It's easier to implement and it's classic standard.
was8bit 2019-04-29 18:37 (Edited)
ON N GOSUB LABEL1, LABEL2, etc
ON N CALL SUB1(), SUB2(), etc.
Would be easier than
IF N=1 THEN GOSUB/CALL NAME OR IF N=2 THEN GOSUB/CALL NAME, etc.
And sequential with 1,2,3,4,5,etc. is OK so long as empty options are allowed... as in..
ON N GOSUB L1,L2,,,,,,,L10,L11,L12,L13,,,,,,L20,L21
If that was possible, (with GOTO or GOSUB or CALL allowed) I could TOTALY use that format.. it would make for cleaner, better organized code :)