Motion piQtures

[tcat]

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

[dilwyn]

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

_com (for compressed) or _rle perhaps?

Name - just call them RLE Extensions for now.

[Outsoft]

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'm using "Retrospecs" IOS utility for convert ZX/QL/SAM images from PC/iPhone/Web photos and It works very well!

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

[pjw]

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.

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.

[mk79]

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.

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.

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.

Cheers, Marcel

[tcat]

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!

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

first pic from `miao' sequence after rle compression

Tom

[tcat]

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

[Cristian]

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.

Great job!!

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.

Surely it would be great!

[pjw]

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.

Surely it would be great!

Great, but alter the code so source data can be at another address than the QL screen base..
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?

[BSJR]

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.

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.

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.

Cheers, Marcel

SQRview can convert GD2 PIC files to RLE compressed SPRs but at the moment mode 4 or 8 are excluded from compression.
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