Sprite Areas... VDU redirection to...

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
alex_farlie
Posts: 163
Joined: Sun Jul 07, 2013 10:46 pm
Contact:

Sprite Areas... VDU redirection to...

Post by alex_farlie »

On RISC OS was it possible to redirect the VDU stream to a sprite area, ( or alternatively to a specific window with the WIMP) and then use the normal VDU and PLOT commands?

I was considering if I suggested something to certain other developers of more recent implementations, but wanted to make sure I understand the older ways of doing things first.
RobC
Posts: 3103
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Sprite Areas... VDU redirection to...

Post by RobC »

Yes - OS_SpriteOp 60 does it. A quick trawl through my Programmer's Reference manuals seems to indicate that this came in with RISC OS 2 (i.e. post Arthur).
User avatar
jgharston
Posts: 4299
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Sprite Areas... VDU redirection to...

Post by jgharston »

And used in things like SmallTask which ran as a Wimp application and redirected a single-tasking application's output to the multi-tasking desktop window.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
alex_farlie
Posts: 163
Joined: Sun Jul 07, 2013 10:46 pm
Contact:

Re: Sprite Areas... VDU redirection to...

Post by alex_farlie »

RobC wrote:
Thu Jun 04, 2020 11:27 pm
Yes - OS_SpriteOp 60 does it. A quick trawl through my Programmer's Reference manuals seems to indicate that this came in with RISC OS 2 (i.e. post Arthur).
The suggestion I was going to make to other developers was that someone implements an equivalent of OS_SpriteOP as a procedure library on modern implementations of BBC BASIC.

In BBC BASIC for SDL, IMGLIB allows for a 'sprite' to be loaded from a file... ( Writing an importer for RISC OS style sprite areas would be a third party extension to it.) MUTLWIN has code to save and restore the VDU variables on a context switch. It doesn't seem unfeasible for a third-party to figure out how to combine these to have teh ability for VDU commands to be rendered on 'Surfaces' as well as 'Windows'... Hmmm...Struck out comment, see comments further..
Last edited by alex_farlie on Fri Jun 05, 2020 10:53 am, edited 1 time in total.
User avatar
Richard Russell
Posts: 2071
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Sprite Areas... VDU redirection to...

Post by Richard Russell »

alex_farlie wrote:
Fri Jun 05, 2020 8:03 am
IOn RISC OS was it possible to redirect the VDU stream to a sprite area, ( or alternatively to a specific window with the WIMP) and then use the normal VDU and PLOT commands?
Both BBC BASIC for Windows and BBC BASIC for SDL 2.0 also allow you to redirect the VDU stream to another window (their respective MULTIWIN libraries do that) or to an in-memory surface/texture. The latter approach is used in many of David Williams' games, in which he draws graphics and/or text to a surface/texture that can be subsequently 'blitted' on demand.

In both of my dialects this can be achieved because the @memhdc% system variable contains the destination Device Context (BB4W) or Renderer (BBCSDL) to which all text and graphics are drawn. By changing the bitmap (BB4W) or texture (BBCSDL) selected into @memhdc% you can redirect the output elsewhere. The only caveat is that you must be very careful to restore the original destination (e.g. on an error).

So, unless I've missed something, what you are asking for can not only already be achieved but is a technique used in many existing BB4W and BBCSDL programs; it doesn't require me or a "third party" to implement something new. Of course if you are including Matrix Brandy in your set of 'modern' BBC BASICs it may be that currently it isn't able to do all those things, but I can't comment on that.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
alex_farlie
Posts: 163
Joined: Sun Jul 07, 2013 10:46 pm
Contact:

Re: Sprite Areas... VDU redirection to...

Post by alex_farlie »

Richard Russell wrote:
Fri Jun 05, 2020 10:01 am
alex_farlie wrote:
Fri Jun 05, 2020 8:03 am
IOn RISC OS was it possible to redirect the VDU stream to a sprite area, ( or alternatively to a specific window with the WIMP) and then use the normal VDU and PLOT commands?
Both BBC BASIC for Windows and BBC BASIC for SDL 2.0 also allow you to redirect the VDU stream to another window (their respective MULTIWIN libraries do that) or to an in-memory surface/texture. The latter approach is used in many of David Williams' games, in which he draws graphics and/or text to a surface/texture that can be subsequently 'blitted' on demand.

In both of my dialects this can be achieved because the @memhdc% system variable contains the destination Device Context (BB4W) or Renderer (BBCSDL) to which all text and graphics are drawn. By changing the bitmap (BB4W) or texture (BBCSDL) selected into @memhdc% you can redirect the output elsewhere. The only caveat is that you must be very careful to restore the original destination (e.g. on an error).

So, unless I've missed something, what you are asking for can not only already be achieved but is a technique used in many existing BB4W and BBCSDL programs; it doesn't require me or a "third party" to implement something new. Of course if you are including Matrix Brandy in your set of 'modern' BBC BASICs it may be that currently it isn't able to do all those things, but I can't comment on that.
Thank you. It seems I'm over-thinking things. I need to re-read the documentation for the libraries you mention.
alex_farlie
Posts: 163
Joined: Sun Jul 07, 2013 10:46 pm
Contact:

Re: Sprite Areas... VDU redirection to...

Post by alex_farlie »

Richard Russell wrote:
Fri Jun 05, 2020 10:01 am
alex_farlie wrote:
Fri Jun 05, 2020 8:03 am
IOn RISC OS was it possible to redirect the VDU stream to a sprite area, ( or alternatively to a specific window with the WIMP) and then use the normal VDU and PLOT commands?
So, unless I've missed something, what you are asking for can not only already be achieved but is a technique used in many existing BB4W and BBCSDL programs; it doesn't require me or a "third party" to implement something new. Of course if you are including Matrix Brandy in your set of 'modern' BBC BASICs it may be that currently it isn't able to do all those things, but I can't comment on that.
Looking at the libary code, it's seems to create a 'sprite' area under BBC BASIC for SDL, what needs to be created is a new "Texture" and then selecting that into @memhdc% with "SDL_SetRenderTarget", and swapping the VDU context.. This seems like a simplified version of the code from MULTIWIN in a simplified form (as there isn't depending on the application the need to create a new window, or render context.)

A "sprite" created in this way could then be plotted using the routine in IMGLIB.

No new functions needed, as FNmake_a_sprite(w,h) and PROC_vdutosprite(x) being things I could write myself . 8)
User avatar
Richard Russell
Posts: 2071
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Sprite Areas... VDU redirection to...

Post by Richard Russell »

alex_farlie wrote:
Fri Jun 05, 2020 11:05 am
Looking at the libary code, it's seems to create a 'sprite' area under BBC BASIC for SDL, what needs to be created is a new "Texture" and then selecting that into @memhdc% with "SDL_SetRenderTarget", and swapping the VDU context.
I wasn't suggesting that you adapt the code in MULTIWIN (which redirects the output to a new window) in order to redirect the output to a new bitmap/texture; obviously these are rather different in detail. I've listed below the code to do the latter.
A "sprite" created in this way could then be plotted using the routine in IMGLIB.
Well, if you want to create a 'sprite' in a file, such as could then be plotted using IMGLIB, then no output redirection is required! To do that you can simply draw to any rectangular region of the output window (e.g. a graphics viewport) in the usual way and then *SCREENSAVE it to a file. To prevent the drawn graphic being visible, even momentarily, you can temporarily disable the output using *REFRESH OFF.

Thinking in terms of redirecting the output in that case, whether to another window or to an in-memory bitmap/texture, is an unnecessary complication and would result in cross-platform incompatibility for no reason.

Code: Select all

      REM Demo of drawing to an in-memory bitmap (BB4W) or texture (BBCSDL)

      bmw% = 160 : REM bitmap/texture width
      bmh% = 120 : REM bitmap/texture height

      REM Create the in-memory bitmap or texture:
      IF INKEY$(-256) = "W" THEN
        SYS "CreateCompatibleBitmap", @memhdc%, bmw%, bmh% TO newDest%
        newDest%% = newDest%
      ELSE
        SYS "SDL_CreateTexture", @memhdc%, &16362004, 2, bmw%, bmh% TO newDest%%
        IF @platform% AND &40 ELSE newDest%% = !^newDest%%
      ENDIF

      REM Protect from errors using an SEH block:
      ok% = FALSE
      ON ERROR LOCAL IF FALSE THEN
        *REFRESH OFF

        REM Save the original destination and select the new destination:
        IF INKEY$(-256) = "W" THEN
          SYS "SelectObject", @memhdc%, newDest%% TO oldDest%
          oldDest%% = oldDest%
        ELSE
          SYS "SDL_GetRenderTarget", @memhdc% TO oldDest%%
          SYS "SDL_SetRenderTarget", @memhdc%, newDest%%
          IF @platform% AND &40 ELSE oldDest%% = !^oldDest%%
        ENDIF

        REM Draw into the memory bitmap/texture:
        GCOL 128+11 : GCOL 4
        CLG : VDU 5,30 : PRINT "Hello world!";
        ok% = TRUE

      ENDIF : RESTORE ERROR

      REM Restore original destination:
      IF INKEY$(-256) = "W" THEN
        SYS "SelectObject", @memhdc%, oldDest%%
      ELSE
        SYS "SDL_SetRenderTarget", @memhdc%, oldDest%%
      ENDIF
      *REFRESH ON

      REM Check for an error having occurred:
      IF NOT ok% ERROR ERR, REPORT$

      REM Do something with the in-memory bitmap/texture:
      REM (left to the imagination)

      REM Delete the bitmap/texture:
      IF INKEY$(-256) = "W" THEN
        SYS "DeleteObject", newDest%%
      ELSE
        SYS "SDL_DestroyTexture", newDest%%, @memhdc%
      ENDIF
      END
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
alex_farlie
Posts: 163
Joined: Sun Jul 07, 2013 10:46 pm
Contact:

Re: Sprite Areas... VDU redirection to...

Post by alex_farlie »

Richard Russell wrote:
Fri Jun 05, 2020 11:42 am
alex_farlie wrote:
Fri Jun 05, 2020 11:05 am
Looking at the libary code, it's seems to create a 'sprite' area under BBC BASIC for SDL, what needs to be created is a new "Texture" and then selecting that into @memhdc% with "SDL_SetRenderTarget", and swapping the VDU context.
I wasn't suggesting that you adapt the code in MULTIWIN (which redirects the output to a new window) in order to redirect the output to a new bitmap/texture; obviously these are rather different in detail. I've listed below the code to do the latter.
Thank you again.

In respect of BBC BASIC for SDL, the texture "handle" returned by your code, can be supplied directly to the PROC_imgPlot routine in IMGLIB 8)

Goes off to write up a wiki-page. Are you okay with the example code above being quoted on the BBC BASIC Programmers Reference wiki?)
Last edited by alex_farlie on Fri Jun 05, 2020 12:33 pm, edited 1 time in total.
User avatar
Richard Russell
Posts: 2071
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Sprite Areas... VDU redirection to...

Post by Richard Russell »

alex_farlie wrote:
Fri Jun 05, 2020 12:01 pm
n respect of BBC BASIC for SDL, the texture "handle" returned by your code, can be supplied directly to the PROC_imgPlot routine in IMGLIB
Maybe, but it's a complicated approach (and incompatible with BB4W) compared with creating a file. Also IMGLIB won't automatically delete the texture as it would if loaded from file. I know some people have a dislike of creating temporary files, but modern Operating Systems handle file-cacheing so efficiently it's hardly any worse than keeping everything in memory.
Goes off to write up a wiki-page.
No need, I've already done it: https://www.bbcbasic.co.uk/wiki/doku.ph ... ap_texture
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
Post Reply

Return to “programming”