The Sinclair QL Forum

I really liked QLib in the day, for one main reason: it allowed computed RESTORE commands which was great if you had lots of data in DATA statements. For example, in my adventure Dreamlands, blocks of data would represent locations, objects, text responses. So to get the room data for location 12, I could derive it by something like:
I can't remember the actual code right now, but it was something like that. I think that actually the start line was a constant integer which got automatically updated in the RESTORE statements when I RENUM'ed which was a nice feature, possibly implemented by TK_2? I could be imagining that though

I think Turbo supports them too but I can't say for sure as I have never used it.

From memory, the problem with TURBO is that the restore could not just be calculated - it had to be or As then Turbo could update the initial pointer - I could be wrong however.

Which doesn't affect me at all, fortunately. My programming style was always to ALCHP and then load the data in and peek it. I did this because it was more compact than SuperBASIC on mdv, a bit quicker to load, and just fun to do.

Dave wrote:Which doesn't affect me at all, fortunately. My programming style was always to ALCHP and then load the data in and peek it. I did this because it was more compact than SuperBASIC on mdv, a bit quicker to load, and just fun to do.

And it saves memory: With READ/DATA you have to hold your data both in program code and in variables which always seemed to be a silly thing for me to do. When PEEKing, you can pick whatever you need into a temporary variable. READ (if READing a field, as intended) needs to read sequentially or use tricky RESTORE methods.

Regards,
Tobias

I also do it that way because I can traverse my data easily, and edit in place. It's great for maps, contour graphs, etc...

That said, I now need to re-write all my library procedures for that