Prev: No lock for bt instruction ?
Next: 1 lane, 2 lane, 3 lane processor cost ?
From: Skybuck Flying on 18 May 2010 12:41
Ok,

Roy beat me to it in redcode, which I translated to pascal/delphi.

And the (*hint kept secret :)*) "inserting point"/pointer idea is indeed
possible.

However as I described in a follow-up post... I still have a trick up my
sleeve to try and do bit compression as well with rle which as I stated will
be kept secret unless somebody can understand it as well.. it's not very
hard... but can you figure it out by yourself ? ;) :)

Anyway... it was interesting to see Roy's Redcode version translated to
Pascal.

It uses 10 pointers.

Since redcode has no registers but just memory which is used as pointers
it's quite interesting.

The only other variable is a loop variable.

10 pointers does seem a bit much though...

I wonder if it can be improved to use less pointers...

Bye,
Skybuck.

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:9337f$4bf1f2a7$54190f09$7034(a)cache5.tilbu1.nb.home.nl...
> After RLE there would be further bit compression, that's why single pass
> without temporarely storage for the RLE output would not be possible.
>
> However RLE for RGB interleaved is probably possible if a temporarely
> buffer is used.
>
> The encoder can then ofcourse keep track of "inserting points" in the
> temporarely buffer.
>
> Then later the temporarely buffer can be further compressed into
> bitfields.
>
> This does require more memory and more bandwidth... so zero copy goes out
> the window ! ;)
>
> And this was an attempt at zero copy as well you know... did mention it...
> but that was what it was about ;)
>
> No extra buffers, just one output buffer ;) <- Probably not possible for
> RLE RGB interleaved...
>
> But with extra buffers anything becomes possible ofcourse ! ;)
>
> Bye,
> Skybuck =D
>
>
>


From: Skybuck Flying on 19 May 2010 03:27
> Ok,
>
> Roy beat me to it in redcode, which I translated to pascal/delphi.

Hmm, nope, not really, Roy's algorithm has a compression inefficiency...

It simply moves 3 records forward for the individual r,g,b streams.

Therefore the streams themselfes are not compacted and empty color's with
empty counts could potentially occur in a highly compressed
stream which then becomes not highly compressed.

It's quite funny to see another programmer being bitten by the RLE algorithm
! ;) =D

Bye,
Skybuck =D


From: pabloreda on 19 May 2010 21:52
Hey Skybuck !!

You know forth ? my dialect is :r4

this code compress and decompress to RLE (not interleaved)

|------------ Grabar de BMP a simple RLE
#memc
#memc>

:,comp | v --
memc> !+ 'memc> ! ;

#cnt
#colact

:scanlast | --
colact cnt ( 255 >? )( over $ff000000 or ,comp 255 - )
24 << or ,comp ;

:scanconv | adr -- adr+
@+ $ffffff and | adr+ color
colact =? ( 1 'cnt +! drop ; )
scanlast
:scanini | color --
$ffffff and 'colact ! 1 'cnt ! ;

|------- SAVE
::bitmap.grabar | "bmps/test.bmr" --
bmp.bm @+ scanini
bmp.alto bmp.ancho * 2dup 2 << + dup 'memc ! 'memc> !
( 1- 1? )( >r scanconv r> ) 2drop
scanlast
memc memc> over - rot save
;

|-------------- LOAD simple RLE
::bitmap.cargar | "bmps/test.bmr" --
here swap load dup 'memc> ! >r
here ( memc> <? )( @+
dup $ffffff and swap 24 >> $ff and | color cant
( 1? )( over r!+ 1- ) 2drop
) drop
rdrop
;

-------------------------------------------------------------------------------

Bye,
PHREDA
http://code.google.com/p/reda4/
From: Skybuck Flying on 20 May 2010 11:35
I have come up with a solution which requires no extra storage overhead...
it does require writing/reading in a different way.

The RLE algorithm probably has a certain property which can be exploited =D

You'll have to figure it out for yourself because again I am keeping it a
secret :)

I am not yet 100% but 99.9% sure... the proof is in the pudding as they say
;)

If it works then it's a nice solution... no extra bandwidth, no extra
buffers, a single pass, and just a different way of writing/reading, the
different reading/writing technique should offer the same kind of
performance as the normal way of writing/reading me thinks, it's a bit
tricky but nothing to difficult ;)

Bye,
Skybuck.


From: Skybuck Flying on 20 May 2010 11:37

"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message
news:7af2$4bf556ac$54190f09$13209(a)cache6.tilbu1.nb.home.nl...
>I have come up with a solution which requires no extra storage overhead...
>it does require writing/reading in a different way.
>
> The RLE algorithm probably has a certain property which can be exploited
> =D
>
> You'll have to figure it out for yourself because again I am keeping it a
> secret :)
>
> I am not yet 100% but 99.9% sure... the proof is in the pudding as they
> say ;)
>
> If it works then it's a nice solution... no extra bandwidth, no extra
> buffers, a single pass, and just a different way of writing/reading, the

And ofcourse "bit compression" that is what it is all about ofcourse... that
was the original problem... that is now solved as well.

So I forgot to mention the most important thing as well...

This new solution should work for the bit compression as well ! ;) =D

> different reading/writing technique should offer the same kind of
> performance as the normal way of writing/reading me thinks, it's a bit
> tricky but nothing to difficult ;)

Bye,
Skybuck.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: No lock for bt instruction ?
Next: 1 lane, 2 lane, 3 lane processor cost ?