From
Mark Antonov
→
To
All
20 September 2006
Hello TomCaT
throw sprites on the screens, and then press them with LaserCompact =)
From
TomCaT
→
To
All
20 September 2006
Hello, All
I want to make a beautiful intro for Saboteur 2 based solely on her
own picture. For this you need a good packer (preferably by
selection for a window, not the entire screen).
From
TomCaT
→
To
All
21 September 2006
Hello, The Exploited
Sanx, of course, but you need a pack for the windows. At least acquaintances.
From
TomCaT
→
To
All
21 September 2006
Hello Vitamin
Thanks, I'll try. And the instructions for calling this on the screen in the BGE package?
From
TomCaT
→
To
All
21 September 2006
Hello Vitamin
yeah, everything seems clear. Only the difference byte - does not change until the mask
will indicate? Or do you need something else besides XOR to obtain data?..
From
Gavrilov Vitaly
→
To
All
21 September 2006
Hello TomCaT
http://zxdocs.fatal.ru/formats/B/BIT.zip
If necessary, I can post the results of the plugin, there is an output there
From
Gavrilov Vitaly
→
To
All
21 September 2006
Hello TomCaT
Try my bge plugin for cutting sprites with packaging. Native compression in
It’s not very good, but the file can contain several sprites and compresses well
regular code packers
From
TomCaT
→
To
All
21 September 2006
Hello TomCaT
Yes, and the input value A has no effect?
From
TomCaT
→
To
All
21 September 2006
Hello Vitamin
brr...
I'm confused now
Is this A that is put in DE not stored anywhere? it turns out best
bytes 255-0-255-0, or 130-125-130-125 are packed, i.e. negative-positive-negative?
Are such sequences common? It’s somehow strange if the code
watch. Or did I get it wrong... Does it work?
From
Gavrilov Vitaly
→
To
All
21 September 2006
Hello TomCaT
No, it doesn't change. Here is the source, you may have to tweak something for optimization.
The initial data byte and the difference are equal to zero, i.e. one zero byte
An empty familiar place is encoded. There may be a different direction for unpacking the mask
(you will have to replace RR C with RL C).
;unpacking one familiar place
;HL- address in memory
;DE - address of the first line of the familiarity
DEPACKPLC ;HL->DE
LD C,(HL); took the mask of a familiar place
INC HL
EX AF,AF'
XOR A ;start byte
LD B,A ;initial difference
MCO EX AF,AF'
RR C ; select the next bit
JR NC,OLBB
LD B,(HL); new difference - update
INC HL
OLBB ;output data
XOR B
LD(DE),A
INC D
EX AF,AF'
LD A,D
AND 7
JR NZ,MCO
RET
From
TomCaT
→
To
All
21 September 2006
Hello, SAM style
Let's go 8). Only the source codes of package packers are not 5 sectors each, maybe? Because
You can’t publish everything in a topic...
(I actually thought that there were ready-made programs for this... I should write some
a passable jmaker for a familiar window, with its own service and a minimum of parameters --
window, m.b. choosing a method and a file is all you need, in general... with help. one of
local algorithms)
From
Gavrilov Vitaly
→
To
All
21 September 2006
Hello TomCaT
I hurt myself a little. You need to put EX AF,AF' before the MCO mark (this is me on the fly
wrote). Well, you can also reverse the cycle and get rid of these exchanges altogether.
Tom> it turns out that bytes 255-0-255-0 are best packed, or
Tom> 130-125-130-125, i.e. negative-positive-negative? Are they like that?
Tom> sequences occur frequently?
If the original image is a floyd-steinberg conversion, then the compression
will be worthless (as well as any other packer), but if it is according to the method
threshold or ordered then everything is great. Plugin for bge (supplied in
included with qhts or downloaded from the site http://zxdocs.fatal.ru (section
projects). There you can see how much a set of images will weigh in
compressed and decompressed form. On average, the winnings are 1.5-2 times. And this is when
sufficiently high unpacking speed. Well, plus the final data is good
packed with a crunch.
PS. Videostudio also uses this method, it came from there))
From
TomCaT
→
To
All
21 September 2006
Hello Vitamin
Well, if it works, then the algorithm is correct. Although I still don't understand
why does simple XOR give such a gain... and oh well. I'll try tomorrow...
P.S. two EX AF in a row... is there any other way? After all, it's only at the end
check if you got to the bottom? You need one more eight-bit reg., and into it
unit and its RLC, then the end will be determined, and the savings... Maybe the address is one in
SP put?
From
Alexandr Sinyakov
→
To
All
21 September 2006
Hello TomCaT
I can give you five more packaging methods that are used in AniE along with
with the one described by Vitamin. The maximum compression reaches 64 times (empty
familiarity is encoded into 1 bit).
From
Alexandr Sinyakov
→
To
All
22 September 2006
Hello TomCaT
procedures for packing and unpacking one familiar place
1.
┌─- code ───
; hl - address on screen
; de - where we pack
PACK1 push de
inc de
ld bc,#8000
xor a
lab_1 cp (hl)
jr z,lab_2
ld a,(hl)
ld(de),a
inc de
scf
lab_2 rr b
inc h
jr nc,lab_1
ex(sp),hl
ld(hl),b
pop hl
ret
; de - address on the screen where we unpack
; hl - from where we unpack
DEPACK1 ld b,(hl)
inc hl
ld c,8
xor a
depa_1 rr b
jr nc,depa_2
ld a,(hl)
inc hl
depa_2 ld (de),a
inc d
dec c
jr nz,depa_1
ret
└── code ───
this better packs sequences of identical bytes
I’ll explain further on my fingers, because what I coded for this option
not fully understood even by myself, and besides, it is voluminous
both in Vitamin's version and in the one written above, the packaged familiar place represents
is the following: (flags,[data])
if a familiar place is empty, it is represented by only one zero byte. I have
the following idea was born - we take 8 acquaintances in a row, pack them (either of two
methods) and compose another flag byte (denoted by flag2) - if
familiarity is empty (flag = 0), then we reset the bit in flag2 and this familiarity in
we don’t output the stream (so the empty familiarity is compressed into 1 bit), and if not
empty - set the bit in flag2 and output the packed familiarity to the stream
entirely.the flow will then look like this:
flag2,([flags],[data] - up to 8 times),flag2,...
Here are 2 more packaging methods:
and one more. experimental, in theory it presses better than others.
take 4 familiar places and compose flag2 in this way
- if the familiar place is empty, we push 00 into flag2 and nothing goes into the stream
- if the familiarity is full (8 bytes #ff), put 01 in flag2, nothing in the stream
- ? in theory, we need to find another common familiar place that will
match 10 in flag2
- otherwise we pack the familiar place (using the selected method), put it in flag2 11 and issue
packed familiar place into the stream
Eh... I didn’t quite understand what I said, but if anything is unclear, I’ll try to remember
more details
Attached is a packaging program in another crazy format.
1. The picture is scanned for complete familiarity
2. Based on the scan, the 1st layer (bit layer) is created
3. all detected familiar places from the picture are erased
4. the rest is packed using one of two methods (and therefore as empty acquaintances
became larger, and they pack best, so does the compression ratio
increases)
File: NEWGFXP.rar http://zx.pk.ru/attachment.php?attachmentid=3829
From
TomCaT
→
To
All
22 September 2006
Hello, SAM style
No, I understand everything. :) I understood it even better than Vitamin’s mechanism. Thanks a lot.
In general, as I understand it, it’s good to make a dictionary of 2^n repeating
input stream is familiar. Then in two passes (or so) if there is memory
for calculations for the dictionary, you have to squeeze hard...
For example, is it possible to do this? flag byte 1+7 bits. 1 bit indicates a letter of the alphabet
or to a foreign character, the rest or the letter number (all 0 is always empty, 1 --
always complete), or repetition bits of subsequent bytes of the foreign character. When
In this case, one bit is lost, for the first or last byte - i.e. he is no longer
participates in repetition. But then we make do with one flag byte per
familiar place...
(Clive himself ordered the dictionary to be placed on IX... ;) )
I'll try to write a separate WiPack on this basis - compressing familiarity
window (sprite, in general) -- and WiDepack, which requires the sprite number in the file, window
inside the sprite (optional) and output coordinates. With all this the intro should sort of
go out as planned. The speed, of course, what else will there be...
From
Gavrilov Vitaly
→
To
All
22 September 2006
Hello TomCaT
You can modify the bitstream method as follows:
0 - empty familiar place
10- familiarity compressed using the zeropack method (SAM style)
11- familiarity compressed using the bitpack method (Vitamin)
The decoder, unlike the encoder, is quite simple.
I also wrote a packer of sprites with a mask, and a smart one - familiar places with a solid
I didn’t remember the mask at all. Just for gamez and other things
From
Alexandr Sinyakov
→
To
All
22 September 2006
Hello Vitamin
Vit> I also wrote a sprite packer with a mask, and a smart one - familiar places with
Vit> with a solid mask were not remembered at all. Just for gamez and other things
I used this feature in Nocturne to compress character sprites: v2_wink2;
Differed; empty familiar places with a solid mask (except for the type in the stream, nothing
went), empty familiar spaces with a non-continuous mask (in the stream - type + mask), non-empty
familiar places with an empty mask (type+image), empty familiar places with an empty mask
(type only) and all others (type+image+mask)
From
Dmitry Pyankov
→
To
All
22 September 2006
Hello Vitamin
2 TomCaT; How; option - try multsystem2; If; there is a sequence
screens. This is a "correction" of the laser comlact version, seems to be the fourth one for compression
namely sequences of screens.
From
TomCaT
→
To
All
22 September 2006
Hello Vitamin
Vit> You can modify the bitstream method as follows:
Vit> 0- empty familiarity
Vit> 10-familiarity compressed using the zeropack method (SAM style)
Vit> 11- familiarity compressed using the bitpack method (Vitamin)
Vit>
interesting. Alternatively, a mixture of methods. But the coder will be there, probably.
Vit> the decoder, unlike the encoder, turns out to be quite simple.
as always
Vit> I also wrote a sprite packer with a mask, and a smart one - familiar places with
Vit> with a solid mask were not remembered at all. Just for gamez and other things
interesting too. At least with one eye... Oh well, I won’t be greedy. I'll take it
some of the above.
From
Gavrilov Vitaly
→
To
All
22 September 2006
Hello TomCaT
Tom> interesting. Alternatively, a mixture of methods. But the coder will be there, yuyuyuy
Tom> probably.
yay, I have an encoder in the studio - there is one data stream (a mask separates familiarity and
offsets) and the flow of attributes (the mask also separates offsets and colors). how am I
there it was perverted in order to pack... I had to twist it through intermediate buffers,
there is no other way.
and I can throw in a sprite engine - I also wrote a plugin for the BGE for it, on
The output immediately gives the Alasmov file with the data. though it doesn't support attributes
(were not needed)
From
Gavrilov Vitaly
→
To
All
25 September 2006
Hello, SAM style
I stored alternating familiarity data (+ mask) and offsets from previous ones
acquaintance And this whole thing is encoded in the header mask. It turned out good
optimization for output speed - set the starting address on the screen and it outputs
all while playing purely on offsets. Everything is like in the same VS (you seem to have screwed the player,
I think I watched it :))