Future-proofing the VDU drivers
tymaja (278) 143 posts |
As my port of the RISC OS VDU drivers (into C) progresses, one thing stands out… When using VDU calls to plot things, many of the VDU calls use ‘limited size’ values for critical variables. The two best examples are: Set a text window : a byte is used for the column / row positions. This limits the width / height of a text window to 255 × 8 = 2048 pixel wide screen modes; Set a graphics window (or plot some graphics to the screen) – two (usually signed) bytes are used, giving a range of -32768 to 32768. Once eigenvalues of ‘1’ are used, this becomes -16384 to 16384 approx. Overall, we are limited to a maximum resolution of approx 16383×16383 before things begin to break down. With 4k and 8k displays becoming a thing, we are not that far from coming up against this (it gets worse because the VDU drivers also plot ‘offscreen’ (so you can draw a line that starts and ends outside the graphics window) – that would be the first functionality to ‘break’ as display resolutions increase. On a more positive note, the VDU drivers, internally, use 32-bit variables for the most part (including for text and graphics windows etc), so the issue really is just ‘how to send larger values to the VDU drivers without breaking backward compatibility’. OS_WriteC and OS_WriteI are used a lot to send data to the drivers at present. OS_Plot is a good thing when used for the graphics drivers though :) I don’t know the answer to this, but it is something to think about – as the drivers themselves can handle larger screen sizes with few modifications, but the interface to the drivers (single or double bytes) limits the screen sizes available. |
Simon Willcocks (1499) 506 posts |
Unless I’m mistaken, OS_Plot sometimes just posts VDU codes. I think we can assume that legacy software using VDU codes would have their minds blown by wall-sized 2000 pixel per inch display with billions of colours. They’d be happier being told they are working with a much less capable display. Give them a sandbox to play in and they will be happy. If you’re writing a Wimp program, you don’t use VDU 4 plotting, do you? |
tymaja (278) 143 posts |
OS_Plot does send VDU codes, but a benefit is that the ‘clamping to 16 bits’ happens internally; the user submit signed 32-bit numbers, so no major API change would be needed there RE: VDU / sandboxing – true – although, currently (RISC OS 32), the drivers are used by the Wimp for pretty much everything – line drawing, sprite backgrounds, moving rectangles, setting display mode etc. Also, the VDU drivers are quite ‘advanced’ compared to many other platforms’ ‘basic display output’ functionality (Linux terminal etc). In my rewrite, I am making sure that 32-bit signed values are passed throughout, so it really only is the passing of data to the drivers that is an issue – even OS_ReadVduVariables will return 32-bit values for window widths etc; I will think about this more; even if RISC OS moves to compositing, it will still need to draw stuff to those composited windows, and the VDU drivers can handle huge displays internally, and it would be trivial to add 64-bit colour support, for example, if that became a thing! In a way, this may overlap to some degree with the Unicode problem; if the solution there was to use ‘more than 8 bits to encode a character’, then a way to send >8bits at a time to (whatever is processing strings) will be needed. Desktop-wide Unicode support may well solve the issue (especially as you can switch off outline fonts for the desktop!). |
tymaja (278) 143 posts |
Am working on this bit of code again; and the specifics are: The routine is SWIPlot, in Kernel.s.vdu.vduswis; It has a direct entry into the ‘main code’ (BL EntryFromSWIPlot). However, it only gets there if If it manages to get through all of that, then it sign-extends the X and Y values, and takes the ‘EntryFromSwiPlot’ path; So, to fully future-proof OS_Plot would require some work. What is good is the sign extension – it uses 32 bit values throughout, so it really only is the interface layer that needs upgrading in the future :) |
nemo (145) 2496 posts |
Until there’s a backwards-compatible PlotV, OS_Plot must pass through WrchV. Currently all coordinates go via It is possible to get an initial X,Y plot coordinate to any 32b value via relative plots and use of the graphics Origin, but that won’t help with subsequent plots for operations such as Triangle and Ellipse. My VDUExtend module provides wider coordinates: 24b coords go via 32b coords go via pairs of I also have a module that turns OS_Plots into Draw_Fill calls which effectively have ~24b coords (in OS units). This has the advantage of working with all existing Printer Drivers (which the new VDU sequences don’t, until implemented). |