PutAPixelHereV ?

Hi,

Writing from work (so no references handy) – just wondered if there’s a vector on pixel plotting? Just kicking around the idea that if such a vector exists, to intercept it to muck around with BBGGRR to see if it is possible to get correct colours on Beagle’s TV output… I just hope stuff (Wimp, SpriteOp, etc) uses legal calls instead of poking into screen memory!

You have got to be joking right?

hlineaddr is as low level as it goes. Vectorise individual pixel writes? You’re off your trolley! ;-)

I just hope stuff (Wimp, SpriteOp, etc) uses legal calls instead of poking into screen memory!

And what are you hoping Santa will bring you?

Many applications write into screen memory. Sorry.

BBGGRR will have to be a new sprite type.

Vectorise individual pixel writes? You’re off your trolley! ;-)

Well, worth asking… Though, I suppose if there was an easy way, it’d already have been done. ;-)

And what are you hoping Santa will bring you?

I’m considering getting myself a Yamaha PSR E333. I wonder if there’s a hope in hell of plugging it in to RISC OS?

Many applications write into screen memory. Sorry.

Hmmm… So, fiddle with the memory map, get accesses to display memory to fault so the value can be picked up, mucked with, and written back. Or just swear at TI for making the s-video work in a rather different way to the HD video.

BBGGRR will have to be a new sprite type.

?? I thought our displays were BBGGRR and that’s where the problem starts? Thing is, if there is anything that pokes into video memory directly, it may make numerous assumptions such as pixel colour format. Now, in theory it shouldn’t be too difficult because RISC OS already supports 2 colour, 4 colour, 16 colour, 256 colour, 32/64K, 16M, and some greyscale (dependent on hardware support, of course). Surely if we could do stuff like greyscale and get it looking correct, we could have a mode type that flips the byte order around?

Surely if we could do stuff like greyscale and get it looking correct, we could have a mode type that flips the byte order around?

The greyscale modes are just ordinary palettised modes, but with the default palette being greyscale instead of colour. It only works because every piece of (well-written) software will at some level be using rendering APIs that do palette lookups to find the closest palette entry to whatever colour is being requested.

Messing with colours in true colour modes (RGB ordering, forcing alpha channel to certain values, etc.) is a bit trickier.

I think the closest thing we’ve got to an API that would be able to deal with this is ColourTrans and its support for colour calibration tables. And then you’ve got to contend with all the software which spots that its running in a true-colour mode and decides to just write to screen directly!