QStar1 revisited - High Colour mode

[Derek_Stewart]

I have playing Qstar1 on my Q68 issue 5, in 512,384 Mode 33, plays really well, sound work great, on 23" DP VGA monitor.

No joystick on Q68, maybe enhancement soon.

A high score list would be nice.

[Andrew]

A high score list would be nice.

There is a sort-of a high score list, saved in file best.dat.
The game saves the "high score" = the minimum number of moves that was ever needed to complete the level.

[Tinyfpga]

I like your Qstar game. I looked at the source code but it is way to complex for me to understand, which is a pity, because as you can see it messes up my screen and I thought I might have a go at fixing the problem.
The area of my screen which is affected is an odd 908x562 at 32x15 pixels.

The game , as mentioned on the opening screen, certainly tested my mental acuity. By level 7 it had been reduced to zero.
The origin of the game intrigued me, so I looked for a PC version to see how yours would compare. The PC version is so difficult to play that I got stuck on an embarrassingly low level of two. Also your version is better looking.

I would love to be able to write such a game and would thus be interested to know if you would be willing to create a tutorial on how to create an animated character together with some fixed sprites in a moveable window.

Did you bypass SMSQ/E to create this game? If so might it not be possible to extend Sbasic for game creation?

[dilwyn]

If you mean the black area top left of the screen, that looks as though the game might be opening some form of "temporary" screen when no channel is open, e.g. if the author is using SCR_XLIM and SCR_YLIM to check for screen sizes before opening any windows. I seem to remember mentioning this in response to something else a few weeks ago, but have forgotten what it was about now.

This happened in one of my own programs which did this. The temporary screen happened to appear in exactly the same place as its main window opened by default, so I'd never noticed it until someone moved the window out of the way, spotted it, asked, then I realised that some SBASIC commands had a habit of opening windows when they needed to do something window-based.

It's possible that if it's a temporary blank window, as it gets partially overlaid that the system is not saving and restoring in the background. You may find that as you close the game window, it takes the temporary window with it.

No idea if that's what's happening in this particular case, mind you, I'm vaguely speculating, but like all vague answers it might give an idea where to look next even if it's not the answer in itself.

BTW, is that an SMS2 (as opposed to SMSQ) display?

[Andrew]

I like your Qstar game. I looked at the source code but it is way to complex for me to understand, which is a pity, because as you can see it messes up my screen and I thought I might have a go at fixing the problem.
The area of my screen which is affected is an odd 908x562 at 32x15 pixels.

I really have no idea why this is happening!
My program opens all windows that it uses and it is compiled with Turbo with 0 windows open.
The first opened window is 512x384 pixels, centered on screen.
If anyone can help with this, please let me know - I am really stumped.

Also your version is better looking.

Thank you! Drawing the sprites and selecting the COLOUR_PAL colours took a lot of time. There are sites on the net where you can find sprites, but they still need a lot of work to make them suitable for QL.

I would love to be able to write such a game and would thus be interested to know if you would be willing to create a tutorial on how to create an animated character together with some fixed sprites in a moveable window.

Did you bypass SMSQ/E to create this game? If so might it not be possible to extend Sbasic for game creation?
Qstar.jpg

Most of the code is QDOS code and it needs minimal changes to compile for QDOS mode 8 or SMSQE High Colour.
I will write an animation tutorial.
See the attached sprite sheet - it gives you an idea on how animation is made.

Now, regarding the moveable window: I have to think a bit on how to do that.
I can use WMOV to move the window.
But the game uses some precalculated screen addresses and writes the sprites directly to screen memory, so each time the window moves the program will have to recalculate these data tables.
Also, another solution, would be to use SMSQE sprites and pjw's tookits - but then the code will be only for SMSQE and QDOS PE and it will not run on plain QDOS.
I tried to have my games playable also on unexpanded QLs, from microdrive, as many people seem to use only this.

[Andrew]

If you mean the black area top left of the screen, that looks as though the game might be opening some form of "temporary" screen when no channel is open, e.g. if the author is using SCR_XLIM and SCR_YLIM to check for screen sizes before opening any windows. I seem to remember mentioning this in response to something else a few weeks ago, but have forgotten what it was about now.

This happened in one of my own programs which did this. The temporary screen happened to appear in exactly the same place as its main window opened by default, so I'd never noticed it until someone moved the window out of the way, spotted it, asked, then I realised that some SBASIC commands had a habit of opening windows when they needed to do something window-based.

It's possible that if it's a temporary blank window, as it gets partially overlaid that the system is not saving and restoring in the background. You may find that as you close the game window, it takes the temporary window with it.

No idea if that's what's happening in this particular case, mind you, I'm vaguely speculating, but like all vague answers it might give an idea where to look next even if it's not the answer in itself.

BTW, is that an SMS2 (as opposed to SMSQ) display?

Oh, yes!! You nailed it! And yes, you mentioned it not long time ago, but I forgot!
Yes, I call SCR_XLIM and SCR_YLIM to check for screen sizes before opening any windows.
And I have no idea for a workaround, as I need to know the screen limits before opening a window that is centered on screen!

[Tinyfpga]

Dilwyn posted:-BTW, is that an SMS2 (as opposed to SMSQ) display?

Sadly not. The last time SMS2 ran at high resolutions (1024 x768) was on a modified Atari Mega STE.
I say sadly because I preferred SMS2 to SMSQ.

I carried on using networked Atari STs running SMS2 until about 2008. I then reluctantly moved to running SMSQ on QPC1.

Because SMSQ is a derivative of SMS2, (it is remarkably compatible) it was very easy to translate my high resolution SMS2 setup into SMSQ.
Once one removes (and I mean only visually) and ignores (except for booting) the Interpreted Basic user interface, there is almost no difference between the two operating systems.

I tried SMSQ on a Q60 but it had a lower display resolution that the Mega STE so I gave up using it.

As my name implies my favourite SMS hardware is FPGA based. I have SMS2 running at 640 X 480 on a Mist in B&W, and SMSQ running at 1024 x 768 in B&W on a Q68.

The image posted above is of my "SMS2" setup using SMSQ/E on a PC laptop running QPC2.

As you say Qstar modifies my screen only whilst it is running. Using Rjob to kill the game also crashes QPC or SMSQ/E. I can't tell which it is.
These Qstar side effects do not spoil the game. It takes less than 1 second to restart my setup.

[dilwyn]

Ah, OK, your memory is better than mine, Andrew, I'd forgotten what we were talking about when this came up.

You only need to do the code below if your program starts with no windows open. SCR_XLIM etc need an open primary channel.

In my program, to avoid this, I open a tiny temporary window somewhere before SCR_XLIM and SCR_YLIM get a chance to do so, get the info from SCR_XLIM/SCR_YLIM/SCR_LLEN etc, then close that before opening the main windows.

I don't remember the full details and whether this works only in Sbasic or SuperBASIC as well

Something like this (from memory, so knowing me it will most probably be wrong and you'll have to tweak it)

Code: Select all

v$ = VER$
dw=512:dh=256:rem BBQL screen
dllen=128:rem display line length
screenbase=131072: REM BBQL screen address
IF v$ = "HBA" THEN
  REM only do this for SMSQ/E and when compiled and when #0 is not already open
  OPEN #0,CON_0x0a0x0
  dw=SCR_XLIM
  dh=SCR_YLIM
  dllen=SCR_LLEN
  screenbase=SCR_BASE
  CLOSE #0
END IF
REM now open the windows your program needs

The advantage of opening a temporary small window in a not very visible area like top left corner is that it's less noticeable than a big black empty window, and the flash when it opens and closes will be less noticeable than the temp window that these commands open, which I *think* is the same size as you get from something like OPEN #3,CON or SCR. If your program uses #0, don't CLOSE and reOPEN it, just WINDOW it to the size and location afterward.

Not all older versions of SMSQ/E accept a 0x0 window, you might have to use 2x1 or 10x10 or something for the temporary #0, anything small enough to avoid the big black empty window.

[Andrew]

Using Rjob to kill the game also crashes QPC or SMSQ/E. I can't tell which it is.

On my sytems I can use RJOB to remove QStar1 without any side effects!

[Tinyfpga]

On my systems I can use RJOB to remove QStar1 without any side effects!

Ok. Although I don't mind the "effect", I will test my claim again.