Programming - Opening a Screen in a Window

Hi, I’m trying to get an old RiscPC program working on a
PineBook, and also (hopefully) on the Pi range of machines.

The problem I’m having it that it’s trying to load a 640 by
480 pixel, 32K sprite in full screen mode, and it’s generating
the error

Screen mode not available.

I don’t know whether you can get this to work on a Pi using
AnyMode, but on a large monitor a screen at that resolution
is likely to look very ropey.

The two instructions that I’ve tried to do it are

OSCLI"SCREENLOAD “game_dir$”Image8": OFF

AND

SYS “OS_SpriteOp”,3,,game_dir$+"image8": OFF

However, neither of them works on a PineBook.

What I would really like to do is to change the screen load
instruction, so that the programme loads in a WINDOW, instead
of trying to go full screen, with all the screen mode problems
that‘s causing on more modern hardware.

According to the PRM, OS_SpriteOp 3 doesn’t seem to have an option
for opening in a window.

Does anybody know how to specify a screen load of a background
sprite inside a window?

Jon Robinson, Leeds

Does anybody know how to specify a screen load of a background
sprite inside a window?

By reading your question, I assume your program is not using the Desktop. In this case to open a sprite in a window I’d start to convert your program to a Desktop program (read about Wimp_Initialise, templates etc.).

Alternatively, if you want to leave your program as it is now, I’d suggest to use !GraphTask and run your program inside it.

You can find !graphTask here: https://armclub.org.uk/free/

Hope this helps.

So many different issues in making old single tasking game code work on modern kit.

I’d suggest a conversation with Jon Abbott would pay dividends.
Assuming he’s not hibernating for the holiday period, he may turn up round here or over on the Software Preservation Project forum pages

I’m afraid !GraphTask doesn’t support sprites, its for old BBC Micro style VDU graphics. Things which either address the screen directly or require * or SWI calls such as sprite or drawfile plotting won’t work.

@Jon Robinson

You could try scaling up or down the image using !ChangeFSI to a mode more suitable for your setup. If it looks bad then nothing to lose. Obviously don’t overwrite the original.

!SmallTsk might do what you want for numbered Modes.

Doing a search on Android “riscosopen !SmallTsk” gives results – but doesn’t allow the page to be displayed.

Something about riscosopen ending in “org.uk”

Something about riscosopen ending in “org.uk”

I will put money on only the home page being redirected to the correct domain!

I will put money on only the home page being redirected to the correct domain!

Seems that way, but it looks as if it’s being done as a redirect on the site itself since one must accept the big blatant privacy warning before the redirect happens.

Shouldn’t this be a CNAME or alias or something, so it’s done at DNS level and you just arrive at the right place automagically?

To Steve Pampling

Do you know how to get in touch with Jon Abbott directly?

I can’t find an email address on his Software Preservation page.

Regards

Jon

If I can get in touch with Jon, this shouldn’t be too difficult to do.

Apart from loading a background sprite in full screen mode, the program is just using a few PUTLINEs to write text to the screen.

Jon Robinson

Do you know how to get in touch with Jon Abbott directly

I’m afraid not. Someone else here may have contact details though.

Have you tried registering and posting on the jaspp forums?

The problem I’m having it that it’s trying to load a 640 by
480 pixel, 32K sprite in full screen mode, and it’s generating
the error

Screen mode not available.

An apparently simple thing can turn out to be a minor nightmare. A search of the forum found this. Suitably thus enlightened I did manage to *ScreenLoad a Mode28 sprite into a Mode 28 display having exited the Desktop. So far attempts with more colours have been less successful, or complete failures to be more accurate. There is a Sprite Mode, Screen Mode mismatch hazard, or maybe a bug.

To add to my above post, a minor outbreak of simplistic understanding. ScreenLoad is the counterpart to ScreenSave. Exit the DeskTop, which here goes to the configured MODE 28. Set the Mode to 1920 1080 C16M, do something to get some text on the screen then ScreenSave, clear the screen then ScreenLoad. That works. It reinforces the point that a suitable Mode must be available for whatever is about to be ScreenLoad’d.

And there’s more. There seems to be an unhelpful Titanium-ism. Trying to ScreenLoad a C16M sprite on the Titanium with the Mode set with :-

 MODE  "X1920 Y1080 C16M LTRGB"
 

However the sprite, which reports itself as 16M BRG, does not load with a “screen mode not available” error.

It works on the RPi400 where the LTRGB is not required.

It reinforces the point that a suitable Mode must be available for whatever is about to be ScreenLoad’d.

You’d think that in these days of oozles of RAM, it would be a reasonable option for the OS to create a DA, load the file there and OS_SpriteOp it scaled and translated appropriately for the Mode currently in use if that doesn’t match the one in the sprite.

ScreenLoad is old, it’s been around since forever, and basically just dumps the sprite data into screen memory.

For other modes than the one the sprite was created in, you’ll need tu suss the scaling (XEig/YEig), and the colours. ColourTrans can help with the second part.

It would be reasonable to have something smarter, but RISC OS is like Lego. You have the bricks, it’s up to you to make something out of them. ;)

it would be a reasonable option for the OS to create a DA, load the file there and OS_SpriteOp it scaled and translated appropriately for the Mode currently in use if that doesn’t match the one in the sprite.

A little more archaeology shows that the sprite can be fitted to the screen. On the RPi400 the 1920×1080 C16M test sprite is scaled to display in a MODE 28 screen but the converse does not apply. Starting with a 1920X1080 screen a Mode 28 sprite does change the screen mode to 640×480.

*Screenload Does what it has always done since Arthur, which is not really what you would want it to do in RISC OS.

On my system, an emulator with a custom module that can select any size screen you want, *ScreenLoading a sprite of width 15 pixels does exactly what you fear it would do when given the power to do so. [That’s why my monitor hates me, anyway]

It is likely, these days, that you are already running in a mode with more than enough colours to display the sprite, and using a monitor that unlike a CRT cannot really scale smaller modes pleasantly, so there’s a good argument for making *ScreenLoad do something more RISC OS ish now:

• Load sprite into memory
• Ask ColourTrans for a suitable translation table when necessary
• Ask ReadVduVariables for the necessary pixel scaling
• Clear screen
• Scale sprite onto screen
• Discard memory
• Arrange for “Press a key to…” to be displayed before returning to the desktop

There’s an argument for attempting to switch to a high BPP first if the sprite requires is, but ScreenLoad really should not fail. It’s not rocket science.