Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

for discussion of bbc basic for windows/sdl, brandy and more
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

hoglet wrote:
Mon Feb 15, 2021 10:42 am
This seems a change of behaviour from the old 8-bit OSARGS A=0 Y=0, which returned the current filing system number.
That would make much more sense (to me)!
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.
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

There has been some useful cross-fertilisation between BBC BASIC for SDL 2.0 and Matrix Brandy. For example BBCSDL has borrowed OSWORD 139 and 140 (and VDU 23,18,3...) from Matrix Brandy, and Matrix Brandy has adopted 8-bit and 64-bit integer variables from BBCSDL/BB4W. Other features have been added to both at pretty much the same time (such as using SYS as a function).

Do you think that further convergence would be (a) desirable and (b) practical?
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Sun Mar 14, 2021 11:01 am
There has been some useful cross-fertilisation between BBC BASIC for SDL 2.0 and Matrix Brandy. For example BBCSDL has borrowed OSWORD 139 and 140 (and VDU 23,18,3...) from Matrix Brandy, and Matrix Brandy has adopted 8-bit and 64-bit integer variables from BBCSDL/BB4W. Other features have been added to both at pretty much the same time (such as using SYS as a function).

Do you think that further convergence would be (a) desirable and (b) practical?
I absolutely do think so, of course where it is practical and desirable to do so. For example the SYS as a function, while our implementations do very different things (yours the address of the library syscall, mine the RISC OS SWI number) they have the same desired effect in that the syscall (be it a function address or RISC OS SWI) can be replaced with its number thus bypassing the delays used to look up the number/address.

It has occurred to me (though I wouldn't begin to know how to do this as I don't know the first thing about 3D programming!) that via the "Brandy_dlcall" functionality it wouldn't be impossible to import libSDL2 and perform some basic actions, of course it would be in a separate window. There are other features that may not make sense (or may not be feasible), such as Matrix Brandy's pixel-accurate GCOL action support, or the Tektronix output added to the text-mode build in Linux (though, saying that there is a BASIC teklib in the distro which predates Matrix Brandy, though enhanced, that BB4C could perhaps use with some modification) but that is such a niche thing it is probably not worth the effort.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Sun Mar 14, 2021 11:14 am
It has occurred to me (though I wouldn't begin to know how to do this as I don't know the first thing about 3D programming!) that via the "Brandy_dlcall" functionality it wouldn't be impossible to import libSDL2 and perform some basic actions, of course it would be in a separate window.
The same thought occurred to me. But does it have to be in a separate window? I think you expose the native handle of your main output window, and I assume that's a regular window in whichever OS it happens to be running, so is there any reason in principle why you couldn't use (for example) SDL_CreateWindowFrom() and SDL_GL_CreateContext() to get an OpenGL context for your existing window? You wouldn't be able to show BBC BASIC 2D graphics and OpenGL 3D graphics at the same time, but nor can I!

However, since (in my BASICs at least) 3D graphics are not built into the core language, but are instead implemented in libraries, they don't necessarily require any further 'convergence' between the dialects and their interpreters at all. So long as the necessary interfaces are already there (which I believe they are, in the form of SYS and the necessary data structures to pass data to and from API functions in shared libraries) somebody could write a 3D library for Matrix Brandy now. It could be compatible with mine, or not, depending on the whim of whoever implemented it. The same goes for shader graphics, Box2D and anything else achievable by means of a library.

Indeed this is a good argument (one of many, in my opinion) for extending capabilities by means of libraries rather than extensions to the language, when that is possible and efficient. So I'm more interested in convergence in respect of core language features, because that can't be achieved by means of libraries and necessarily requires changes in the BASIC interpreters themselves. Naturally structures are top of my list for something currently implemented in BBCSDL that I'd like to see in Matrix Brandy. :wink:

I know you've expressed some scepticism about the practicality of adding structures to Matrix Brandy because of how deeply you would have to delve into the upstream code to achieve it, and I fully understand that. Although not faced with quite the same kind of challenge, it was also a daunting prospect for me, not least that before being able to test accessing structure members I first needed to have a way to create structures, and before being able to test the creation of structures I needed a way to access their members! This vicious circle stalled progress for a long time.

The way I broke the log-jam was to first create a BASIC program for creating structures (on the heap) instead of using DIM! I could fiddle with that BASIC program until I was satisfied that it was creating the structures properly, without needing to make any changes to the interpreter at all. Once I had a tested way of creating structures I could then concentrate on the code which accessed their members. Finally, once that was working, I could return to incorporating structure creation using DIM.

I wonder if a similar approach would make structures in Matrix Brandy more tractable?
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.
User avatar
jgharston
Posts: 4399
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by jgharston »

Richard Russell wrote:
Mon Feb 15, 2021 9:12 am
Soruk wrote:
Mon Feb 15, 2021 8:20 am
Under the lid, PTR#n is a call to OSARGS with A%=0, X%=n Y%=n, where X%=0 Y%=0 returns the temporary filing system number
I've never heard of a "temporary filing system", it's not a concept that I've encountered on any other platform. 'Temporary directory' or 'temporary drive', yes, but it's hard to imagine what the purpose of a 'temporary filing system' would be! Tellingly, a Google search for that phrase comes up with only references to RISC OS, and suggests that I possibly meant "temporary filling system"! :wink:
A better way of describing OSARGS 0,0 is returning the *current* filing system, 4=DFS, 5=NET, 8=ADFS, etc. It's unneccessary confusion to describe it as returning the temporary filing system. Strictly speaking, under the lid, that is what it returns as if it's called within a *-somefs-command or *somefs:command sequence, then that -somefs- temporary filing system is the current filing system, but it's much clearer to describe it as, well, the current filing system, because at the time of calling, it is what is the current filing system, regardless of whether it was selected with *somefs or with *-somefs-.

PTR#0 and EXT#0 shouldn't error. They should return cleanly.
When reading PTR and EXT from 8-bit BASIC, the data parameter is BASIC's integer store, which will be set to the channel as the last item evaluated. That means that PTR#0 and EXT#0 pass a data value of zero; OSARGS 0,0 and OSARGS 2,0 do not change the data word; this means that in 8-bit BASICs PTR#0 and EXT#0 return zero, being the unchanged data word set to the channel.

This means that other BASIC have the ability to use PTR#0 and EXT#0 to return information specific to that implementation. Some BASICs or operating systems allow other special handles to return specific information. Some operating systems allow BPUT#0 and BGET#0 to access the VDU and keyboard, so allow PTR#0, EXT#0 and EOF#0 to access keyboard or VDU information.
As an example, BBC BASIC on the Z88 and NCxx return something from PTR#0 and EXT#0, but I'd have to dig mine out to check what, and EOF#0 returns if there is OSRDCH input pending, eg IF NOT EOF#0 THEN A%=GET

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4399
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by jgharston »

hoglet wrote:
Mon Feb 15, 2021 10:42 am
Richard Russell wrote:
Mon Feb 15, 2021 10:17 am
I don't see how that fits in with the concept of the temporary filing system, as in "returns the temporary filing system number", which implies it's something persistent rather than set on a per-command basis.
I'm also a bit confused here...

The RISCOS documentation for OSARGS R0=0 R1=0 does say it returns the temporary filing system number.
https://www.riscosopen.org/wiki/documen ... S_Args%200

This seems a change of behaviour from the old 8-bit OSARGS A=0 Y=0, which returned the current filing system number.
It's not a change in behaviour, it's a change in terminolgy, pure and simply, and an unneccessary and - clearly - misleading change.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.36
(C) Copyright J.G.Harston 1989,2005-2020
>_
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

jgharston wrote:
Sun Mar 14, 2021 7:02 pm
It's not a change in behaviour, it's a change in terminolgy, pure and simply, and an unneccessary and - clearly - misleading change.
I goofed the explanation (in two ways!) but stand by my modification making PTR#0 return 0. I'll check what EXT#0 does...

Edit: RISC OS 3.71 and 5.28 both give error 222 (invalid handle) for EXT#0, which is different to the BBC/Master which return 0. Matrix Brandy follows RISC OS here.
Matrix Brandy BASIC VI (work in progress)
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Sun Mar 14, 2021 12:50 pm
Soruk wrote:
Sun Mar 14, 2021 11:14 am
It has occurred to me (though I wouldn't begin to know how to do this as I don't know the first thing about 3D programming!) that via the "Brandy_dlcall" functionality it wouldn't be impossible to import libSDL2 and perform some basic actions, of course it would be in a separate window.
The same thought occurred to me. But does it have to be in a separate window? I think you expose the native handle of your main output window, and I assume that's a regular window in whichever OS it happens to be running, so is there any reason in principle why you couldn't use (for example) SDL_CreateWindowFrom() and SDL_GL_CreateContext() to get an OpenGL context for your existing window? You wouldn't be able to show BBC BASIC 2D graphics and OpenGL 3D graphics at the same time, but nor can I!
Thinking more about this, SDL2 itself may not work as it offers several functions with the same names as SDL 1.2. However, the dlcall capability isn't only in the SDL builds, so perversely this approach is actually more likely to work from the text-mode builds!
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Sun Mar 14, 2021 8:47 pm
SDL2 itself may not work as it offers several functions with the same names as SDL 1.2.
In principle there shouldn't be an issue with functions having the same name if you call them by address (both dlsym in Linux and GetProcAddress in Windows take a handle to a shared object, which will be different for SDL 1.2 and SDL 2.0).
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.
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

jgharston wrote:
Sun Mar 14, 2021 6:59 pm
PTR#0 and EXT#0 shouldn't error. They should return cleanly.
Typically dogmatic! You know perfectly well that my BASICs do error in that case, so evidently you consider them broken. Perhaps there's an element of playing to the gallery, because that is no doubt also the opinion of Michael and most other members here. :cry:
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Sun Mar 14, 2021 10:16 pm
jgharston wrote:
Sun Mar 14, 2021 6:59 pm
PTR#0 and EXT#0 shouldn't error. They should return cleanly.
Typically dogmatic! You know perfectly well that my BASICs do error in that case, so evidently you consider them broken. Perhaps there's an element of playing to the gallery, because that is no doubt also the opinion of Michael and most other members here. :cry:
In both Matrix Brandy and RISC OS (3.71 and 5.28), PTR#0 does not error, but EXT#0 does.
Matrix Brandy BASIC VI (work in progress)
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Sun Mar 14, 2021 10:02 pm
Soruk wrote:
Sun Mar 14, 2021 8:47 pm
SDL2 itself may not work as it offers several functions with the same names as SDL 1.2.
In principle there shouldn't be an issue with functions having the same name if you call them by address (both dlsym in Linux and GetProcAddress in Windows take a handle to a shared object, which will be different for SDL 1.2 and SDL 2.0).
Good call. (Pun not intended.) I've extended SYS "Brandy_dlgetaddr" to accept the library handle as an optional second parameter. I've opted to do it this way rather than put it as a required additional parameter to "Brandy_dlcall" as some symbold take a lot of parameters anyway and it would effectively make the parameter mandatory (or at least R1 being left blank). So, on Linux, something like this should work...

Code: Select all

SYS "Brandy_dlopen","libSDL2.so" TO sdl2hndl%%
SYS "Brandy_dlgetaddr","SDL_some_sdl2_function", sdl2hndl%% TO some_sdl2_function%%
...
SYS "Brandy_dlcalladdr", some_sd2_function%%, parmeters.... [TO return%%]
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Mon Mar 15, 2021 12:35 am
In both Matrix Brandy and RISC OS (3.71 and 5.28), PTR#0 does not error, but EXT#0 does.
If I have understood correctly, PTR#0 has been 'borrowed' to return a value that identifies the 'current' filing system (not a concept I am familiar with on the platforms I use). Presumably this is because it is so commonly needed that it was felt desirable to provide a 'simple' way of retrieving it, although it's far from obvious to me why it's so useful.

What I cannot accept is that it follows that every other version of BBC BASIC, including mine, must therefore return a value of some kind from PTR#0, rather than reporting an error.
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Something that has been bugging me since I put SDL updates to its own thread, I found that in fullscreen mode Matrix Brandy would stop responding to the keyboard after a while. This has now been fixed. It seems by only pulling the event types I specifically needed from the queue, the queue filled up with events I didn't care about blocking new events from being added. So, now I'm pulling all events, and ignoring those I'm not interested in, and this seems to have done the trick.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Tue May 25, 2021 6:30 am
Right now there are too many BBCSDL-isms such as the MODE-mixing which isn't possible under Matrix Brandy.
I know very little about the internals of Matrix Brandy except that it uses SDL 1.2 rather than SDL 2.0 for rendering. If you were to switch to using SDL 2.0, which could have other advantages (such as improved compatibility with Apple Macs), would that make it easier to support a similar kind of 'MODE-mixing'? Or is there a more fundamental reason why it "isn't possible"?

In BBCSDL (and BBC BASIC for Windows for that matter) all MODEs are bitmaps under the hood so there's no fundamental reason why one shouldn't draw graphics in MODE 7. The only reason it doesn't 'just work' is that for compatibility reasons the VDU codes which would normally have that effect (e.g. VDU 25 which is PLOT) are disabled in MODE 7.
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Tue May 25, 2021 9:54 am
Soruk wrote:
Tue May 25, 2021 6:30 am
Right now there are too many BBCSDL-isms such as the MODE-mixing which isn't possible under Matrix Brandy.
I know very little about the internals of Matrix Brandy except that it uses SDL 1.2 rather than SDL 2.0 for rendering. If you were to switch to using SDL 2.0, which could have other advantages (such as improved compatibility with Apple Macs), would that make it easier to support a similar kind of 'MODE-mixing'? Or is there a more fundamental reason why it "isn't possible"?

In BBCSDL (and BBC BASIC for Windows for that matter) all MODEs are bitmaps under the hood so there's no fundamental reason why one shouldn't draw graphics in MODE 7. The only reason it doesn't 'just work' is that for compatibility reasons the VDU codes which would normally have that effect (e.g. VDU 25 which is PLOT) are disabled in MODE 7.
In Matrix Brandy, in addition to the pixel frame buffer, there is also the 1000-byte character frame buffer. The screen is rendered at least one line at a time (so PRINT TAB'ing Teletext control codes or just poking them into the screen memory have the correct effects), but with VDU141 a single change could cascade down the entire screen, and re-rendering the pixel buffer replaces what was previously there, so even if there was line drawing it would be obliterated.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Wed May 26, 2021 9:36 am
In Matrix Brandy, in addition to the pixel frame buffer, there is also the 1000-byte character frame buffer.
Indeed, and there is a similar buffer in BB4W/BBCSDL too, since it is essential to allow the MODE 7 screen to be rendered (its pointer is exposed as @chrmap%).
with VDU141 a single change could cascade down the entire screen, and re-rendering the pixel buffer replaces what was previously there, so even if there was line drawing it would be obliterated.
Absolutely, and again exactly the same is true of my BASICs. But the 'cascading' effect that you describe is extremely rare and generally only happens on test pages designed to illustrate it. In any case, the solution is simply to draw any required graphics again!

Supporting graphics in MODE 7, if only 'unofficially', should allow Forthstone to make his Telepaint program compatible with Matrix Brandy.
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Wed May 26, 2021 10:05 am
Soruk wrote:
Wed May 26, 2021 9:36 am
In Matrix Brandy, in addition to the pixel frame buffer, there is also the 1000-byte character frame buffer.
Indeed, and there is a similar buffer in BB4W/BBCSDL too, since it is essential to allow the MODE 7 screen to be rendered (its pointer is exposed as @chrmap%).
with VDU141 a single change could cascade down the entire screen, and re-rendering the pixel buffer replaces what was previously there, so even if there was line drawing it would be obliterated.
Absolutely, and again exactly the same is true of my BASICs. But the 'cascading' effect that you describe is extremely rare and generally only happens on test pages designed to illustrate it. In any case, the solution is simply to draw any required graphics again!

Supporting graphics in MODE 7, if only 'unofficially', should allow Forthstone to make his Telepaint program compatible with Matrix Brandy.
I've had a brief look at this, and it is not as easy as it first seems. In MODE 7 I use two screen banks, usually all content is written into both, but flashing characters are only inserted into one, and a timer-based routine blits the bank to be displayed into the on-screen bank. Thus, any PLOT drawing (which goes to the scaled-display bank (this allows for the different pixel sizes across the traditional BBC modes, and the 1x1 pixels introduced on the Archimedes) and this is not used in MODE 7. And, for display accuracy I am recalculating the screen possibly more often than is actually needed but even drawing to the Teletext mode frame buffer the drawing doesn't stay long. When I implemented MODE 7 way back when, this kind of capability was never envisaged so the way it was designed certainly doesn't lend itself to this kind of hack.

Edit: I suppose the following might work, but requires a temporary file, and do something like this...

Code: Select all

*NewMode 77 640 500 16 1 1
MODE 7
REM do something
*ScreenSave /path/to/tempfile
MODE 77
*ScreenLoad /path/to/tempfile
REM do your drawing...
Note that this does not preserve your MODE 7 character buffer if you're not already maintaining a copy, you need to separately back that up (usually from &7C00, but best practice to get it via parameter R4 of SYS"Brandy_GetVideoDriver")

Edit 2: I realise instead of *NEWMODE I should be able to do MODE 640,500,4 - but due to a bug (fix just checked in, and nightlies rebuilt) it would select MODE 7! (Similarly MODE 320,250,1 would select MODE 6, and MODE 640,250,1 would select MODE 3). Now it will only select a graphics-capable mode, or construct a new one if no existing mode matches the requirement.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Thu May 27, 2021 10:06 pm
In MODE 7 I use two screen banks, usually all content is written into both, but flashing characters are only inserted into one, and a timer-based routine blits the bank to be displayed into the on-screen bank.
That's a very neat, and efficient, way of handling flashing. It never occurred to me; my flashing characters are implemented in a naïve way, i.e. they are alternately rendered as themselves and as spaces, which is quite a slow process if there are a lot of them. Fortunately there are generally only a few flashing characters because otherwise it could trigger an epileptic fit!
Edit: I suppose the following might work, but requires a temporary file, and do something like this...
That is exactly what FourthStone was doing previously. Unfortunately, in BBCSDL, MODE causes the window to be centered on the screen so if the user has moved the window it gets moved back to where it was, which is (very) annoying. We discussed the possibility of modifying BBCSDL so that, as a special case, if the new MODE has identical dimensions to the old MODE the window position would remain unchanged, but I suggested the system he is now using as an alternative that doesn't need any modifications to BBCSDL.
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Fri May 28, 2021 5:40 pm
That is exactly what FourthStone was doing previously. Unfortunately, in BBCSDL, MODE causes the window to be centered on the screen so if the user has moved the window it gets moved back to where it was, which is (very) annoying. We discussed the possibility of modifying BBCSDL so that, as a special case, if the new MODE has identical dimensions to the old MODE the window position would remain unchanged, but I suggested the system he is now using as an alternative that doesn't need any modifications to BBCSDL.
I recall the discussion.

Out of curiosity, on a mode change do you completely destroy the window and re-create it? I'm guessing this because of the behaviour you describe of the window being re-centred as if deleted and recreated.

The approach I've taken (which at least for SDL 1.2!) is to do

Code: Select all

SDL_FreeSurface(surface);
surface=SDL_SetVideoMode(x, y, 32, sdl_flags);
This causes the window to change size but, at least under Windows and a few different Linux window managers, the top left of the window stays where it is. I'm not sure how this approach maps to SDL 2, also if I have understood correctly you use textures rather than 2D surfaces.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Sat May 29, 2021 9:26 am
Out of curiosity, on a mode change do you completely destroy the window and re-create it?
No, this is the code:

Code: Select all

	SDL_DisplayMode dm ;
	SDL_SetWindowSize (hwndProg, wx, wy) ;
	SDL_GetDesktopDisplayMode (0, &dm) ;
	SDL_SetWindowPosition (hwndProg, (dm.w - wx) >> 1, (dm.h - wy) >> 1) ;
The centering is explicit, as you can see, and is simply to ensure that, if possible, the new (possibly larger) MODE doesn't extend beyond the edges of the screen.
This causes the window to change size but, at least under Windows and a few different Linux window managers, the top left of the window stays where it is.
But I don't want the top-left of the window to stay where it is if the result will be that the window is no longer visible in its entirety. As discussed with FourthStone there are various alternative approaches I could adopt, such as leaving the window position unchanged if the new window has the same size as (or perhaps is smaller than) the old window. Or calculating whether the new window will fit in its entirely on the screen and only move it if it won't. But these are more complicated than what I do at the moment, and have the potential for causing surprise if the window sometimes moves and sometimes doesn't.

But I am open to arguments that it should be changed.
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Soruk »

Richard Russell wrote:
Sat May 29, 2021 10:27 am
Soruk wrote:
Sat May 29, 2021 9:26 am
Out of curiosity, on a mode change do you completely destroy the window and re-create it?
No, this is the code:

Code: Select all

	SDL_DisplayMode dm ;
	SDL_SetWindowSize (hwndProg, wx, wy) ;
	SDL_GetDesktopDisplayMode (0, &dm) ;
	SDL_SetWindowPosition (hwndProg, (dm.w - wx) >> 1, (dm.h - wy) >> 1) ;
The centering is explicit, as you can see, and is simply to ensure that, if possible, the new (possibly larger) MODE doesn't extend beyond the edges of the screen.
This causes the window to change size but, at least under Windows and a few different Linux window managers, the top left of the window stays where it is.
But I don't want the top-left of the window to stay where it is if the result will be that the window is no longer visible in its entirety. As discussed with FourthStone there are various alternative approaches I could adopt, such as leaving the window position unchanged if the new window has the same size as (or perhaps is smaller than) the old window. Or calculating whether the new window will fit in its entirely on the screen and only move it if it won't. But these are more complicated than what I do at the moment, and have the potential for causing surprise if the window sometimes moves and sometimes doesn't.

But I am open to arguments that it should be changed.
OK, your explanation makes perfect sense.

I would, however, argue that should the new mode be the same size or smaller than the current one then the window shouldn't be moved as in these cases we know it will fit on screen (unless the user has explicitly moved the window to be partially off-screen).
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

Post by Richard Russell »

Soruk wrote:
Sat May 29, 2021 12:11 pm
I would, however, argue that should the new mode be the same size or smaller than the current one then the window shouldn't be moved as in these cases we know it will fit on screen (unless the user has explicitly moved the window to be partially off-screen).
There is, as always, the additional factor of compatibility with BBC BASIC for Windows (which has worked the same way for 20 years!) to consider. That does move the window so that it is entirely within the screen bounds, even if the old and new window sizes are the same (or indeed it's the same MODE number) e.g. if the user has deliberately moved it. So if I do make a change I'd prefer it to remain consistent with that behaviour.
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.
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Richard Russell »

Richard Russell wrote:
Wed Nov 14, 2018 2:57 pm

Code: Select all

 -110 (left Windows key)
 -111 (right Windows key)
 -112 (context menu key)
 -126 (f13)
 -127 (f14)
 -128 (f15)
Clearly even if I wanted to, which I don't, I can't retrospectively change them to something different after 18 years
I'd completely forgotten about this issue (from 2018) until a web search triggered by another thread led me back here. The most practical workaround would seem to be for the left Windows key to be tested in BASIC as:

Code: Select all

      IF INKEY(-110) OR INKEY(-126) THEN ,,,
which will work in BB4W, BBCSDL and Matrix Brandy.
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.
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Richard Russell »

Something looks wrong here (Matrix Brandy 1.22.10 for 64-bit Windows):

Code: Select all

      a%% = 2000000^3
      Number is out of range
2000000^3 is &6F05B59D3B200000 which is in range for a signed 64-bit integer so I don't think an error should occur (and it doesn't in my BASICs).
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.
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Richard Russell »

Richard Russell wrote:
Fri Jun 11, 2021 10:12 am
Something looks wrong here
On further investigation:

Code: Select all

      a%% = 2^62 + 512 : REM No error but sets a%% to 2^62!
      a%% = 2^62 + 513 : REM Gives 'Number is out of range'
Neither statement is working correctly, but the first is failing silently whilst the second is reporting an error. :?
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Soruk »

Richard Russell wrote:
Fri Jun 11, 2021 12:56 pm
Richard Russell wrote:
Fri Jun 11, 2021 10:12 am
Something looks wrong here
On further investigation:

Code: Select all

      a%% = 2^62 + 512 : REM No error but sets a%% to 2^62!
      a%% = 2^62 + 513 : REM Gives 'Number is out of range'
Neither statement is working correctly, but the first is failing silently whilst the second is reporting an error. :?
Thank you for these, I've fixed this, and updated the nightly builds. Problem was I was doing power in float64 space, and thus didn't have the precision to handle big numbers accurately. While Matrix Brandy has no larger float type (and switching would introduce incompatibilities with BASIC VI), I'm now doing power in a higher space (long double - this fix will not work on a Raspberry Pi as long double is still 64-bit so will have some inaccuracies). 32-bit x86 Linux and MinGW uses 96 bits for long double, 64-bit uses 128 bits. Having said that, your examples above work correctly on the RPi as I'm now making the power function return an int64 if both inputs are ints and the result is in range.

Also, as a reminder, in Matrix Brandy you need to use SYS"Brandy_Hex64",1 to enable handling of 64-bit hex strings. Otherwise they're handled as signed 32-bit and the output is truncated to 32 bits.

I'm seeing other little oddities, due to maths limitations on the RasPi, e.g.

Code: Select all

>SYS"Brandy_Hex64",1
>a%%=2^62+513
>a=a%%
>PRINT~a,~a%%
4000000000000400    4000000000000201
>PRINT a-a%%
       0
>
This also affects your build on the RasPi (using a# instead of a to force a float on yours, I'm aware that 'a' is a variant on yours and in the above example would be an int64 so a and a%% would indeed be identical.)
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Richard Russell »

Soruk wrote:
Sat Jun 12, 2021 1:12 pm
Problem was I was doing power in float64 space, and thus didn't have the precision to handle big numbers accurately.
In my BASICs integer powers are computed using the square-and-multiply technique, so if multiplication works correctly, irrespective of the data type, so should raise-to-power. In other words 2000000^3 must necessarily give the same result as (2000000*2000000)*2000000 because that's exactly how it is computed internally. That seems to me to be the least risky approach.
this fix will not work on a Raspberry Pi
Obviously if you try to store a 64-bit integer in a 64-bit 'double' variable it will lose precision, is that all you mean by "will not work"? Or are there circumstances in which an expression which involves only 64-bit integers can give an incorrect result?
32-bit x86 Linux and MinGW uses 96 bits for long double, 64-bit uses 128 bits
They allocate 96-bits and 128-bits (12 bytes and 16 bytes) of memory respectively, because alignment requirements dictate that, but they both use 80-bit floats for 'long double'; the remaining bits are unused. My BASICs would not work otherwise, because floats being 80-bits is fundamental to their architecture (for example variant arrays allocate 10-bytes per element, always).
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.
Soruk
Posts: 917
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Soruk »

Richard Russell wrote:
Sat Jun 12, 2021 2:22 pm
Soruk wrote:
Sat Jun 12, 2021 1:12 pm
Problem was I was doing power in float64 space, and thus didn't have the precision to handle big numbers accurately.
In my BASICs integer powers are computed using the square-and-multiply technique, so if multiplication works correctly, irrespective of the data type, so should raise-to-power. In other words 2000000^3 must necessarily give the same result as (2000000*2000000)*2000000 because that's exactly how it is computed internally. That seems to me to be the least risky approach.
I might look into coding this.
Richard Russell wrote:
Sat Jun 12, 2021 2:22 pm
this fix will not work on a Raspberry Pi
Obviously if you try to store a 64-bit integer in a 64-bit 'double' variable it will lose precision, is that all you mean by "will not work"? Or are there circumstances in which an expression which involves only 64-bit integers can give an incorrect result?
Yes, my fix is to use the long double version of pow(), namely powl() and convert the response to int64 or double, but that will have no effect on the RasPi as a double and long double are the same. However, your example above where the loss of accuracy of working in "double" space is evident, no longer manifests itself on the RPi as 2^62 can be cleanly represented, and I now have it return an int64 if both inputs are int and the result is within the range of values that can be stored as an int64 (otherwise a double is returned). Since the 2^62 is now returned as an int64, adding 512 and 513 yields the correct response. (I'm struggling to think if an example of power (in "double" space) where the inputs are ints and wouldn't be cleanly represented in int64 space (when within range), I may have actually sorted the issue by making it return an int64 instead of double when appropriate.)
Richard Russell wrote:
Sat Jun 12, 2021 2:22 pm
32-bit x86 Linux and MinGW uses 96 bits for long double, 64-bit uses 128 bits
They allocate 96-bits and 128-bits (12 bytes and 16 bytes) of memory respectively, because alignment requirements dictate that, but they both use 80-bit floats for 'long double'; the remaining bits are unused. My BASICs would not work otherwise, because floats being 80-bits is fundamental to their architecture (for example variant arrays allocate 10-bytes per element, always).
OK, fair point. I was just going on a quick sizeof() test, which would indeed show the memory allocation, hiding the fact 16 or 48 bits are wasted.
Matrix Brandy BASIC VI (work in progress)
User avatar
Richard Russell
Posts: 2337
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Matrix Brandy BASIC V for Linux with SDL: V1.21.16 released

Post by Richard Russell »

Soruk wrote:
Sat Jun 12, 2021 8:00 pm
I may have actually sorted the issue by making it return an int64 instead of double when appropriate.
That would be good, but I'm not convinced. Testing the latest 64-bit Windows build (Git commit 37996cf) I'm getting this:

Code: Select all

      SYS "Brandy_Hex64",1
      PRINT ~23^13
      6FEB266931A75C0
but my BASICs (both 32 and 64-bit versions, which use completely different code) reckon the answer is &6FEB266931A75B7. #-o
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 “modern implementations of classic programming languages”