QSTAR 2

[dilwyn]

Dilwyn,

That's one of the (the main) reasons why I'm not sure whether the header preservation methods we have devised over the years are really of any help at all or just create even more confusion. I sometimes think it 's the latter.

Quite so.

[bwinkel67]

When I started to create the DStar clone my target was set to:

• pretend it's 1984: write all code from scratch (not port some version created for other machine)

...

Please let me know when you will post the video on your channel. Thank you!

Hi Andrew,

I did a quick mock-up of what I was thinking of. It runs on an unexpanded QL via MDV. Granted it requires a fully formatted cartridge (it has zero-K free, and that's with a trimmed down English-only readme_txt), which is not too realistic with a real physical one since they never get all 256 sectors. Then again, I did this without modifying any of your code, and I also added ToolKit 2 so it is guaranteed to run (that adds 17K of space).

QStar3.zip

(52.47 KiB) Downloaded 3 times

I'm sure lots of space could be saved if this was done in source. Plus, no need to have two sprites_dat files, etc...and it would be much faster since the wrapper BASIC boot program spends time renaming files. But that's sort of what I was thinking in having one game with two options, where each option was independent of the other.

Video will likely come out in the summer as I have a bit of a queue presently. I basically played it, with some commentary, through 4 levels, since I really loved level 4 (and struggled solving it).

Again, great game!


Note, besides renaming files, this is the change I made (ie. the boot program):

Code: Select all

10 REMark Loader for QStar
15 DIM qr$(4,11):qr$(1)="QStar_exe":qr$(2)="best_dat":qr$(3)="levels_dat":qr$(4)="sprites_dat"
20 DIM q1$(4,12):q1$(1)="QStar1_exe":q1$(2)="best1_dat":q1$(3)="levels1_dat":q1$(4)="sprites1_dat"
25 DIM q2$(4,12):q2$(1)="QStar2_exe":q2$(2)="best2_dat":q2$(3)="levels2_dat":q2$(4)="sprites2_dat"
30 PRINT #0,"Device? ";:INPUT #0,dev$
35 m=RESPR(17396):LBYTES dev$&"tk2_bin",m:CALL m+1380
40 MODE 8:INK #1,2:PAPER #1,205:WINDOW #1,512,256,0,0:CSIZE #1,2,1:CLS #1
45 LBYTES dev$&"title_dat",131072
50 AT 4,4:PRINT "Two modes of play:"
55 AT 6,4:PRINT "F1 - Switch player (25 levels)"
60 AT 7,4:PRINT "F2 - Switch positions (10 levels)"
65 key=CODE(INKEY$(-1)):IF key=232 THEN GO TO 90:END IF :IF key=236 THEN GO TO 125:END IF :GO TO 65
70 :
75 REMark Message
80 AT 9,4:PRINT "Preparing game, please wait..."
85 RETurn 
90 REMark Setup QStar1
95 GO SUB 75
100 IF FTEST(dev$&q2$(1))<>0 THEN GO SUB 150
105 IF FTEST(dev$&qr$(1))<>0 THEN GO SUB 110: END IF :GO TO 160
110 FOR i=1 TO 4: RENAME dev$&q1$(i) TO dev$&qr$(i):NEXT i: RETurn 
115 FOR i=1 TO 4: RENAME dev$&qr$(i) TO dev$&q1$(i):NEXT i: RETurn 
120 :
125 REMark Setup QStar2
130 GO SUB 75
135 IF FTEST(dev$&q1$(1))<>0 THEN GO SUB 115
140 IF FTEST(dev$&qr$(1))<>0 THEN GO SUB 145: END IF :GO TO 160
145 FOR i=1 TO 4: RENAME dev$&q2$(i) TO dev$&qr$(i):NEXT i: RETurn 
150 FOR i=1 TO 4: RENAME dev$&qr$(i) TO dev$&q2$(i):NEXT i: RETurn 
155 :
160 REMark Run QStar
165 EXEC_W dev$&qr$(1);dev$

[Derek_Stewart]

Hi,

while soft loading Toolkit 2 is a reasonable thing to do, how do you know whether Toolkit 2 is not already on the system the game is being played?

[bwinkel67]

Hi,

while soft loading Toolkit 2 is a reasonable thing to do, how do you know whether Toolkit 2 is not already on the system the game is being played?

I soft load TK2 all the time on a machine that has it in ROM and there's never been a problem.

[tofro]

In most cases, it is just better to link TK2 (or any other used toolkit) into the compiled binary instead of loading it in BOOT. That means once your program is done, it will be gone again. With your approach, you might be ending up filling your memory with multiple copies of TK2 (which won't hurt, but will consume memory, of course) after running multiple times.

[bwinkel67]

In most cases, it is just better to link TK2 (or any other used toolkit) into the compiled binary instead of loading it in BOOT. That means once your program is done, it will be gone again. With your approach, you might be ending up filling your memory with multiple copies of TK2 (which won't hurt, but will consume memory, of course) after running multiple times.

It's not my program, I just wrote a wrapper for combining to different variants into one. I tend not to run into these issues since my QL isn't like my Windows or Linux serer and so I tend to reboot it after running some software, esp a game.

[pjw]

In most cases, it is just better to link TK2 (or any other used toolkit) into the compiled binary instead of loading it in BOOT. That means once your program is done, it will be gone again. With your approach, you might be ending up filling your memory with multiple copies of TK2 (which won't hurt, but will consume memory, of course) after running multiple times.

I have to disagree here. There are (IMHO) two different kinds of toolkits: "Systems toolkits" and "ad hoc" ones. Systems toolkits are what one would expect most users to have loaded at boot, the main one being TK2. For every program using some TK2 commands to have TK2 compiled with their code seems, at the very least, wasteful. Perhaps in a one-trick-horse setting like back in the bad old days of MSDOS, where you load one program, reboot and then load the next, this makes sense.

I load a lot of programs residentially at boot. I tend to avoid programs that include Qlib_run, TK2, Turbo_TK, Ptrmen_cde, Qptr, .. as their inclusion doesnt bode well for the quality of the rest of the program! I tend to load those toolkits and a few more myself at boot time.

If you need to check for the presence of some needed toolkit to avoid loading it multiple times, you could worse than check for a known command in that toolkit using the free and easy FindKey command (see under this topic: https://www.qlforum.co.uk/viewtopic.php?p=56331, eg IF NOT FindKey("Q_L"): PRINT "Please load Qlib_run": STOP or something..

People here have a wide variety of setups, from meagre 128Kb 512x256x4 BBQLs to 128Mb 1920x1080x64k QPC2s. Fair enough if one is only catering for the former, so poking around in undocumented or "fixed" memory locations and the like. But Qdos/SMSQ was designed for better things, and it doesnt take a lot of effort, just a bit of knowhow and imagination, to enable anything that could run on a BBQL to run on a high-end SMSQ/E setup (although, clearly, not necessarily the other way around).

[Andrew]

There are (IMHO) two different kinds of toolkits: "Systems toolkits" and "ad hoc" ones. Systems toolkits are what one would expect most users to have loaded at boot, the main one being TK2.

I agree with this. TK2 is a toolkit that should be present on all machines.

.. and it doesnt take a lot of effort, just a bit of knowhow and imagination, to enable anything that could run on a BBQL to run on a high-end SMSQ/E setup (although, clearly, not necessarily the other way around).

And that is the conundrum: you either exclude low-end machines or high-end machines.
When it comes to graphics and colors, a program that takes advantage of high resolution and colors will usually be too large to run on an unexpanded QL.

[tofro]

I load a lot of programs residentially at boot. I tend to avoid programs that include Qlib_run, TK2, Turbo_TK, Ptrmen_cde, Qptr, .. as their inclusion doesnt bode well for the quality of the rest of the program! I tend to load those toolkits and a few more myself at boot time.

That's what you and I do, Per. But starters kick off the naked machine, throw in a disk and expect it to run. Other than wasting a bit of memory, the added toolkit really doesn't hurt, but makes things easier - And, this one is a game - you're not expected to have it run in the background all day.

[bwinkel67]

Interesting thread, and it seems to be a repeat of one that tofro pointed to (https://www.qlforum.co.uk/viewtopic.php?p=56331) in his response to mine, so the topic of "to-or-not-to" comes up quite often. I don't personally use TK2 very much but have no problem if it is required since it is one of the more common toolkits. I use ICE, which is less common. Maybe tofro's point for me goes more with a compiler library that I need to include. But in the end, as long as I can get the program to run I'm happy :-/

Since this was a mock-up of an idea for Andrew's games that I was trying to demonstrate, I wasn't looking to refine it. Soft-loading TK2 is just something I do for all of my little integration programs which you can see in my Workbench 2.0 mock-up on the QL as well (https://www.qlforum.co.uk/viewtopic.php ... 2.0#p56440). I mean, look at my splash page for Andrew's game...very Psion-like but doesn't do the beautiful font and art choices that Andrew picked justice.

If I were to deliver something I wrote needing TK2, without asking an annoying question, not sure what would be the best way. Peeking memory only works if you are making assumptions about the memory size, right? I mean a 512K machine is going to store its respr in a different place. I don't know if ROM will move around but that perhaps is safer to check. Then there are the different types of operating systems you could be running. So there might just not be a good way to do it so maybe besides asking for "Device? " on the command shell (#0) I might include that annoying questions about TK2 after all.