Motion piQtures
Re: Motion piQtures
Hi Dilwyn,
I will try to code something really basic, and share here, perhaps we can then improve further.
I wonder what should we call these routines, also what extension in place of `_scr' we may use?
Tomas
I will try to code something really basic, and share here, perhaps we can then improve further.
I wonder what should we call these routines, also what extension in place of `_scr' we may use?
Tomas
Re: Motion piQtures
_com (for compressed) or _rle perhaps?tcat wrote:Hi Dilwyn,
I will try to code something really basic, and share here, perhaps we can then improve further.
I wonder what should we call these routines, also what extension in place of `_scr' we may use?
Tomas
Name - just call them RLE Extensions for now.
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: Motion piQtures
I'm using "Retrospecs" IOS utility for convert ZX/QL/SAM images from PC/iPhone/Web photos and It works very well!tcat wrote:Hi Dilwyn,
I will try to code something really basic, and share here, perhaps we can then improve further.
I wonder what should we call these routines, also what extension in place of `_scr' we may use?
Tomas
But there are some bugs and I'm in contact with the author for solve it all.
I will write in private for check it together
Re: Motion piQtures
Actually, Im looking into this right now. But the more the merrier! The task Ive set myself is to take a screen file, RLE compress it and convert it to a mode 0 sprite, then save it as a binary _spr file or as ready-to-eat assembler. (And this has to fit in between between looking after my aged, bed-ridden mum, who right now is shouting "Get me out of this bed!" so I better go..) Will be interesting to see how much this method can compress the demo screens weve seen recently.dilwyn wrote:All that's needed is a quick and easy to use routine to convert 32k screens and pic files to RLE compressed GD2 sprites and you're away!
But implementing a 'standard' simple compression routine such as RLE for 32k screens and PIC files might be quite interesting in itself.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Motion piQtures
It's been 13 years since I wrote the RLE support for SMSQ/E, but while I think mode 4 RLE sprites are probably supported (I don't think anybody has ever tried, but the code is pretty mode agnostic), I'm pretty sure it was never implemented for PTR_GEN because it lacked the concept of the "sprite cache" every SMSQ/E version had to have anyway (to do the on-the-fly colour conversion). Just FYI.pjw wrote:Actually, Im looking into this right now. But the more the merrier! The task Ive set myself is to take a screen file, RLE compress it and convert it to a mode 0 sprite, then save it as a binary _spr file or as ready-to-eat assembler.dilwyn wrote:All that's needed is a quick and easy to use routine to convert 32k screens and pic files to RLE compressed GD2 sprites and you're away!
But implementing a 'standard' simple compression routine such as RLE for 32k screens and PIC files might be quite interesting in itself.
Cheers, Marcel
Re: Motion piQtures
Hi,
I have seen here all magnificent stuff, here is my humble attempt at screen compression.
Could the `rle' size be trusted at all?
EDIT: decompression routine added, some code corrections - WORKS!
Tom
I have seen here all magnificent stuff, here is my humble attempt at screen compression.
Could the `rle' size be trusted at all?
EDIT: decompression routine added, some code corrections - WORKS!
Code: Select all
; RLE screen de/compression routines
; ==================================
; From CALL in SuperBASIC
; RLE encode - use CALL [start],[^image]
; RLE decode - use CALL [start+2],[^image],[size]
; on entry D1=ptr to image
; D2=image size
; on exit [start+4].w=new image size
; NOTE
; as std QL screen is organised by words in 4/8 modes
; compression is done by finding subsequent equal words
start bra.s rlenc ;RLE encode
bra.s rldec ;RLE decode
rlesz ds.w 1 ;new size
; Screen compression routine
rlenc movea.l #$20000,a1 ;Screen start
movea.l #$28000-2,a2 ;Screen end
movea.l d1,a3 ;image address
; Screen loop
scr_loop cmpa.l a1,a2 ;End of screen?
blt.s exit ;Yes, exit
moveq #1,d3 ;Else, init word run
; Start of rle sequence
rle_beg move.w (a1)+,d4 ;Compare this and
cmp.w (a1),d4 ; subsequent words if equal?
bne.s rle_end ;No, end sequence
addq.w #1,d3 ;Yes, increment word run count
cmpa.l a1,a2 ;End of screen?
blt.s rle_end ;Yes, end sequence
bra.s rle_beg ;Else, read next word in run
; End of rle sequence
rle_end move.w d4,(a3)+ ;Copy single word from screen
cmp.w #1,d3 ;Do we have repeated run >1?
bls.s scr_loop ;No, goto next run
move.w d4,(a3)+ ;Yes, duplicate word to mark run
move.w d3,(a3)+ ;Copy run count
bra.s scr_loop ;Goto next run
; Screen decompression routine
rldec movea.l #$20000,a1 ;Screen start
movea.l d1,a3 ;image start
lea -2(a3,d2.l),a4 ;image end
; Image loop
img_loop cmpa.l a3,a4 ;End of image?
blt.s exit2 ;Yes, exit
;Else
move.w (a3)+,d4 ;Compare this and
cmp.w (a3),d4 ; subsequent words if equal?
beq.s rle_exp ;Yes, expand rle run
move.w d4,(a1)+ ;No, copy word to screen
bra.s img_loop ;Goto next run
; Expand rle sequence
rle_exp move.w 2(a3),d3 ;Fetch run count
subq.w #1,d3 ;-1 for DBcc
rle_run move.w d4,(a1)+ ;Duplicate word to screen
dbf d3,rle_run ; until run count -1
addq.l #4,a3 ;Skip over 2 words
bra.s img_loop ;Goto next run
; All complete
exit suba.l d1,a3 ;a3=a3-d1
lea rlesz,a0 ;Save
move.w a3,(a0) ; new image size
exit2 clr.l d0 ;No error code
rts ;Return to BASIC
end
Last edited by tcat on Thu Dec 22, 2016 7:43 pm, edited 1 time in total.
Re: Motion piQtures
Hi,
RLE de/compress routines tested on plain JS-ROM QL, QDOS v1.10 - WORKS!!!
On `miaou' screen, the new size after compression is - 16754 bytes, before compression 32768 bytes.
On average there seems 50% compression ratio.
If there were some interest, I will put the code into SuperBASIC program, with machine code in DATA lines. So we can all have a go. The code itself has only 108 bytes. Perhaps can be refined or optimised further?
Cheers
Tom
RLE de/compress routines tested on plain JS-ROM QL, QDOS v1.10 - WORKS!!!
On `miaou' screen, the new size after compression is - 16754 bytes, before compression 32768 bytes.
On average there seems 50% compression ratio.
If there were some interest, I will put the code into SuperBASIC program, with machine code in DATA lines. So we can all have a go. The code itself has only 108 bytes. Perhaps can be refined or optimised further?
Cheers
Tom
Re: Motion piQtures
Great job!!tcat wrote:Hi,
RLE de/compress routines tested on plain JS-ROM QL, QDOS v1.10 - WORKS!!!
On `miaou' screen, the new size after compression is - 16754 bytes, before compression 32768 bytes.
On average there seems 50% compression ratio.
Surely it would be great!tcat wrote:If there were some interest, I will put the code into SuperBASIC program, with machine code in DATA lines. So we can all have a go.
Re: Motion piQtures
Great, but alter the code so source data can be at another address than the QL screen base..Cristian wrote:Surely it would be great!tcat wrote:If there were some interest, I will put the code into SuperBASIC program, with machine code in DATA lines. So we can all have a go.
Id be interested to know whether the SMSQ/ptrgen RLE de-compressor copes with the resulting data. I havent had a chance to fiddle with this yet. Anyone tried?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: Motion piQtures
SQRview can convert GD2 PIC files to RLE compressed SPRs but at the moment mode 4 or 8 are excluded from compression.mk79 wrote:It's been 13 years since I wrote the RLE support for SMSQ/E, but while I think mode 4 RLE sprites are probably supported (I don't think anybody has ever tried, but the code is pretty mode agnostic), I'm pretty sure it was never implemented for PTR_GEN because it lacked the concept of the "sprite cache" every SMSQ/E version had to have anyway (to do the on-the-fly colour conversion). Just FYI.pjw wrote:Actually, Im looking into this right now. But the more the merrier! The task Ive set myself is to take a screen file, RLE compress it and convert it to a mode 0 sprite, then save it as a binary _spr file or as ready-to-eat assembler.dilwyn wrote:All that's needed is a quick and easy to use routine to convert 32k screens and pic files to RLE compressed GD2 sprites and you're away!
But implementing a 'standard' simple compression routine such as RLE for 32k screens and PIC files might be quite interesting in itself.
Cheers, Marcel
I have done some testing and can produce RLE2 compressed SPRs in m4 or m8. On viewing them the old image is not fully returned, recognisable but with strange artefacts.
Unpacking them to a PIC before viewing shows minor errors in the m4 but the m8 seems OK.
So this shows a fault in my program and an SMSQ/E limitation, these need to be investigated further.
Bob