Using TransGIF etc

Just been ‘looking’ at TransGIF – seems ok with OvationPro/(Impression 26bit) but palette doesn’t seem quite right with Ovation.

Is it possible for programs to keep the original file format – and only convert to sprite for display purposes ie on screen?

With using PNG – would keep the total file size down.

Bit like EasiWriter seems to do.

Is it possible for programs to keep the original file format – and only convert to sprite for display purposes ie on screen?

The thing is, programs ought to only need to understand the image formats that the underlying operating system understands. So Ovation deals with JPEG, Sprite, DrawFile and Artworks (not native, but pretty ubiquitous these days).
That’s why there are filters. To convert a non-native image into a native one. Sure, it would be nice to have OvationPro accept anything I can throw at it, but does this mean that every program will need routines to handle PNG and GIF and…?

Wouldn’t it be better to expand SpriteExtend (as has been done for JPEGs) to provide these formats natively? Then, when software is updated to support these new capabilities, such support would be “load file, chuck it at OS routines”.

Having the OS Handle PNG’s as standard – like JPEG’s would be very useful.
Is the latest version of SpriteExtend soft loadable?

Dropping a GIF onto ‘!Ovation’ 1.52RM (not Pro) – the colours come out wrong – the file saved from !Ovation – works in !Draw !Paint & !OvationPro.
In !Paint the background is shown in lines – down across the picture.
(Transparency?)

Anyone here – want to try out the !TransGif converter?

Another thing – are there any spare spaces in ‘CMOS’ – that I could use?

Is the latest version of SpriteExtend soft loadable?

Yes. You should be able to find a softload version in the hard disc image (in !Boot.RO350Hook.Boot.PreDesk). It’s only really there to help RISC OS 3.5 owners (no SpriteExtend in ROM) but it should work on other RISC OS versions too (at least everything 3.5+)

In !Paint the background is shown in lines – down across the picture.
(Transparency?)

Probably. If you zoom in/out then it will be more obvious (the image will scale but the lines will stay the same size).

Another thing – are there any spare spaces in ‘CMOS’ – that I could use?

CMOS bytes 30-45 (inclusive) are reserved for use by users.

https://www.riscosopen.org/wiki/documentation/show/OS_Byte%20CMOS%20Settings

Dropping a GIF onto ‘!Ovation 1.52RM (not Pro) – the colours come out wrong – the file saved from !Ovation

Ovation accepts GIF? That’s new to me.

Can you zip up the convertor and GIF and mail it to me? I’ll have a look and see what’s going on (but no guarantees, mind you).

In !Paint the background is shown in lines – down across the picture.
(Transparency?)

Sounds like an interlaced GIF and the decoder is only decoding the first “frame” and not going back to fill in the spaces.

Followup…

Yup. Ovation will search for a Transloader for any filetype it doesn’t understand, which is pretty cool.

You may need to edit the !Setup file for the !TransFSI transloader, as that will claim GIFs.

The current version of TransGIF uses unaligned loads. It does not suffice to turn off alignment faults, you’ll need a processor capable of performing the ARMv5 rotated load behaviour – the Iyonix and the Pi1 can.
Don’t worry if you did try it with alignment faults turned off and your computer hang up. It is completely recoverable – just use Alt-Break to invoke the task killer. ;)
Aaaaand….I’ve already been mailed a fix. :-)

The colour issue mentioned above was easy to figure out once I had a test file in front of me. The clue is in the fact that there are a load of blotches of green and red in the sprite in Ovation, but these colours don’t exist in the GIF.
What it is, is the GIF convertor is creating sprites with a full, custom, 256 colour palette. Ovation, on the other hand, appears to interpret 256 colour sprites as having the “traditional” style of palette – if you recall it was 64 colours arranged in groups of four shades of each colour.

I would test my theory by throwing a test sprite at Ovation, but it appears that there is no facility within !Paint to create sprites with a full 256 colour palette. Making a 256 colour sprite gives the 64×4 palette and the “Edit palette” option is disabled.

By the way, !Paint says that a sprite with a Full 256 colour palette has a compatibility level with Arthur. Are you sure? It needs ColourTrans, so we’re looking at RISC OS 3 native, or RISC OS 2 with a softload ColourTrans…

Oh, and those lines in !Paint, that’s how the mask is shown. I forgot. Been a while since I’ve used Paint, crappy memory, etc etc excuse etc.

More followup…

Okay, c.wz → sprite_put_scaled() is where the sprite is plotted.

Setting R5 to gcol_action + 16 will plot the sprite correctly as it tells the OS to use the (full) palette instead of a pixel translation table. So I’ll need to determine if either the sprite pointer or the mask pointer is to offset +&82C (header + 2K palette data) and if it is, then set bit 4.
This will only work on RISC OS 3.5 or later, and it’ll only work for 32K/16M colour modes; it needs a different method to generate the translation table for 256 colour modes; but since a full 256 colour sprite is not going to display correctly in a 256 colour mode (it’s an approximation at best), I’ll leave it as-is. Don’t want to mess up too much stuff.

Will also need to test this with PDF printing to ensure it works correctly during printing.

…

As a side effect of tracking this down, I noticed that the frame border colour is completely broken (in 16M colour modes?). Create an empty frame, set the frame to be 2mm yellow. Observe the lovely shade of mute Hello Kitty. Hmmm… Should take a look at the interesting translation table creation code in c.frame → plotspos()

Sprite colours – fixed.

Tested with PrintPDF, it appears to print using the correct colours (as well as can be expected given the printer driver outputs a square blob for each pixel…), it was only naff on-screen. So now the on-screen works for high colour modes.

You’ll have to forgive me, I got up at 5am this morning (and it’s now 1am the next day) so I didn’t look at the frame colour issue, and given that nobody seems to have noticed this in… well… if it’s a 16M mode issue, perhaps the entire history of the RiscPC and later? Anyway, I didn’t look at this, and I’m not sure when I’ll have the time to do so.

No updated archive (yet). If you want to test the executable, you can pull it directly from my copy of Ovation: http://heyrick.ddns.net/ovation/!RunImageS (settype it &FF8).

so I didn’t look at the frame colour issue, and given that nobody seems to have noticed this in… well… if it’s a 16M mode issue, perhaps the entire history of the RiscPC and later?

Vague recollection from years ago that it was a known issue. David fixed things in the OvPro builds but the rights to the original Ovation were with Beebug and they had lost interest.

Frame colours – fixed. Tested on-screen on Pi in 256, 64K, 16M modes. And printing to PDF using standard drivers (which seem to require old style palette stuff despite coping with full colour JPEGs – huh?).

As an aside, I spent some time tracking down why Ovation was crashing the machine horribly. Turns out I’d had a dyslexic moment and was calling OS_ReadModeVariable as SWI &53… oops!!! ¹

Now it’s sorted, seems to be working well.

Any other pet bugs that need splatting?

The Ovation executable link given just above is my live copy on my Pi, privided by WebJames- so if you pick it up now, it’ll have all of these changes present.²

¹ ReadModeVariable is &35. What I was calling as OS_SetMemMapEntries (!) and telling it that the request block was at &FFFFFFFF. Unsurpringly, it blew up.

² There is, of course, the (small) danger that you can pick up a ‘broken’ copy or one that does ‘debug stuff’, or even gibberish if you happen to try downloading it at the point where the application is being built. Just saying…