The Sinclair QL Forum

A smoke and nicotine option can be added if people want it

Seriously, I think these effects work best when in full screen mode (F11), and on lower QL screen resolutions. But, it does take me back to how my BBQL looked on my Microvitec CUB in the mid 80s

Some more info on the shaders update:

This change enables optional support for OpenGL Shader Language (GLSL) shaders within sQLux. These shaders run on the GPU and introduce display artifacts similar to those seen when using a BBQL with a 1980s CRT monitor. Artifacts that can be emulated include:
+ Scan lines
+ Shadow mask
+ Bloom
+ Screen curvature

As shaders run on the GPU, the speed of the emulator is not impacted.

Instructions on how to build and run are included in a new doc file shaders.md https://github.com/SinclairQL/sQLux/blo ... shaders.md.

In summary, if you can already build from code the previous version of sQLux, then the following steps are needed:
1) Pull the latest sQLux master from git
2) Update submodules, (git submodule update --init --recursive) to get the shader support library (sdl-gpu)
3) Configure using CMake including the option to support shaders (-DSUPPORT_SHADERS=TRUE)
4) make
5) Enable shaders in sqlux.ini (SHADER=2) and set the path to the demo shader file (SHADER_FILE = ../shaders/crt-pi.glsl)
6) Launch sQLux

If you'd rather not have the emulated curved screen then you can set SHADER=1. To disable shaders completely set SHADER=0

If running on a Raspberry Pi other than a Pi4, then you will need to enable hardware acceleration, as discussed earlier in this thread.

XorA and I have tested it on Windows, Linux (Ubuntu) Mac, Pi3 and Pi4, but the more people that try it out the better. All feedback gratefully received.

Thanks!

Hi,

I updated my sQLux distro with the shaders options. Very nice work.

Can the Shaders command defined in the "crt-pi.glsl" file, be used with a window within the main display, so a curved window could be defined?

Derek_Stewart wrote:Hi,

I updated my sQLux distro with the shaders options. Very nice work.

Can the Shaders command defined in the "crt-pi.glsl" file, be used with a window within the main display, so a curved window could be defined?

Hi Derek,

I'm glad the shaders work for you

The shaders are designed to post process the whole QL display, so they can (for example) simulate a curved CRT. They do not have knowledge of windows defined using the SBasic WINDOW command (or equivalent). In theory one could write a shader that only acted on part of the display; I guess that shader could generate a result similar to sticking a lens in front of part of the CRT and so generate a curved "image within the image". However, the effect would not be moveable in response to (for example) a SBasic WINDOW command.

Cheers,

Ian

Hi Folks,

It is a simple matter to map text to any curved or plane surface, as seen from the images attatched.

But writing a shader to map textures would require accurately Peeking into a SuperBasic window, (or buffer).

Peeking the screen is awkward in view of the QLs method of accessing Pixels.....

If anyone has written a function to find the colour of a pixel at any screen position, I would be prepared to write a prototype shader for the QL.

I did once map the screen of the 'WEST' cartridge onto a flying carpet, but it was not pixel perfect, for the reason mentioned !

Steve.

stevepoole wrote: If anyone has written a function to find the colour of a pixel at any screen position, I would be prepared to write a prototype shader for the QL.

There is PIXEL% function in DIY Toolkit - Vol G

Syntax PIXEL% ( [#ch,] x1,y1 )
Location PIXEL (DIY Toolkit - Vol G)
This function can be used to read the colour of a point in absolute co-ordinates on the screen with reference to the specified window channel (if any - default #1).
This function will work in MODE 4, 8 and 12 (on the THOR XVI, if you have v0.9+). The main limitation on this function is that the point must appear within the specified window, so x1 and y1 cannot exceed the width or height of the specified window (in pixels), or be less than zero.

Also there is RPIX% - http://www.knoware.no/txt/RPIX.htm
natcol% = RPIX%([#ch; ] xpos%, ypos%)

Returns the native colour of pixel at xpos%, ypos% relative to
channel #ch (defaults to #1)


rgbcol = RPIX24([#ch; ] xpos%, ypos%)

Returns the RGB colour code of pixel at xpos%, ypos% relative to
channel #ch (defaults to #1)

Hi,

You could also try RPIXL in the QPTR toolkit, does the same thing, and probably written before all the above.

Derek_Stewart wrote:Hi,

You could also try RPIXL in the QPTR toolkit, does the same thing, and probably written before all the above.

considering this is sQLux could also add an extension to it to do this in emulator space much faster.

XorA wrote:

Derek_Stewart wrote:Hi,

You could also try RPIXL in the QPTR toolkit, does the same thing, and probably written before all the above.

considering this is sQLux could also add an extension to it to do this in emulator space much faster.

HI,

Sounds interesting, can you outline how the emulator space cab be extended?

Hi Folks,

Following the various suggestions about getting Pixel colours, I have cobbled together a prototype shader for 3d perspective windowing.

It works fine using the DIY Tk PIXEL% under SGC, but on QPC2 it does not seem to fathom out where in memory to look, and returns garbage values. (Screen set to 512x256).

Per's RPIX% seems to get that problem right, but the returned (16 bit ?) colours cannot be reused as INK values for shading...

So, is there a way of getting the original 256 INK colours from the 16 bit returned values when using QPC2?

The prototype is slow under QDOS, faster with SMSQ/E, but nips along under QPC2. But I need to find the solutions to these colour problems...

Any suggestions ? Steve.
________________________