Ticket #247 (Fixed)Thu Aug 19 16:07:39 UTC 2010
Amusing oddities with SpriteExtend and JPEG
| Reported by: | Martin Bazley (331) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Martin Bazley (331):
As with a lot of such bugs, I first encountered this one when working on a new version of MBBack. It concerns the plotting of JPEGs in 8bpp modes.
Consider the following program:
<pre>
spr_output%=FALSE
ON ERROR PROCerror
in$=“Landscape_0175/jpg”
out$=“JPEG”
SYS “JPEG_FileInfo”,1,in$ TO ,,width%,height%
DIM s% 6000000
!s%=6000000:s%!4=0:s%!8=16:s%!12=16
REM * Try setting R3 to 0 or 1
SYS “OS_SpriteOp”,15+256,s%,“jpeg”,1,width%,height%,(4<<27)(90<<14)(90<<1)1
SYS “OS_SpriteOp”,60256,s%,“jpeg” TO r0%,r1%,r2%,r3%:spr_output%=TRUE
REM * Try setting R4 to 0, 1 or 3
SYS “JPEG_PlotFileScaled”,in$,0,0,0,3
SYS “OS_SpriteOp”,r0%,r1%,r2%,r3%:spr_output%=FALSE
SYS “OS_SpriteOp”,12+256,s%,out$
END
DEF PROCerror
IF spr_output% SYS “OS_SpriteOp”,r0%,r1%,r2%,r3%:spr_output%=FALSE
REPORT:PRINT " at line ";ERL:END
ENDPROC
</pre>
The two comments indicate the two relevant parts.
- Creating a sprite without a palette (by passing R3=0 to OS_SpriteOp 15) causes the colours to seriously mess up, giving the general impression that one’s monitor could do with a trip to the Betty Ford Clinic.
- Setting both the dithering and the error diffusion flags (R4=%11) on entry to JPEG_PlotFileScaled results in a rather attractive square interference pattern which wouldn’t be out of place on the Electric Light Show.
Both reproduced on RISC OS 5.16. RO6.20 behaved as expected in all circumstances.
I’m hoping I’ll be able to add the JPEG I used to this ticket after I file it.
Changelog:
Modified by Martin Bazley (331) Thu, August 19 2010 - 16:09:36 GMT
- Attachment added: Landscape_0175.jpg
GODAMMIT I FRICKING HATE TEXTILE!!! Anyway, the attachment.
Modified by Sprow (202) Thu, August 19 2010 - 22:14:16 GMT
Crucially, the version of SpriteExtend isn’t mentioned.
Version 1.21 works fine (Risc PC) with the supplied JPEG and test program, which suggests it’s not something that was fixed in RISC OS 6.20 per se.
What hardware is this being tested on?
Modified by Martin Bazley (331) Sat, August 21 2010 - 19:17:52 GMT
- Attachment added: output.zip
Of course, it matters these days, doesn’t it! ;-)
Just successfully reproduced on an Iyonix (RO5.16) with SpriteExtend 1.21 (19 Jan 2010). Zipped output from the above parameters attached.
Could not reproduce on StrongARM RiscPC (RO6.20) with SpriteExtend 1.91 (15 Sep 2009).
Zip also contains BASIC file with above program for everyone’s convenience.
Modified by Sprow (202) Wed, September 01 2010 - 20:54:49 GMT
- Status changed from Open to Fixed
Fixed in SpriteExtend 1.23.
Note also: when using OS_SpriteOp 15 with the ‘include palette’ bit set, the kernel just reads the first N (where N=number of colours in the sprite) entries from the current mode’s palette and puts those in the sprite file. So, creating an 8bpp sprite with palette whilst in a 24bpp mode will result in the first 256 colours of the 16M of the current mode being used as the palette.
To get a default palette for the number of colours of the sprite in question independant of the current mode, create the sprite with no palette then add the palette using OS_SpriteOp 37.
