Adventurer #15 31 июля 2004

Программирование

Tutorials - More color! Description packer color video from the demo Weed.

More color!

poisoned cyberjack / / triebkraftNE

Trying to do something spectacular for our demos WeeD, I
even did not expect what will happen as well. Many came
me with the question - multicolor or what? Meanwhile, 
everything is simple - it's all on full-screen color 
animation:) True, well packed, but still ...


Riot of color visible on the screen - the result is not the 
engine, and right to make the original image. How to do it,

better not ask me, and at GD / / tbk / / 4d, which is all that
render in lightwave 7.5 on the PC. After that I convert them
from AVIs using BMP2SCR_1.75 by LCD. And only with
Spectrum obtained after color screens, I
worked ...

That's basically all I needed to tell you:) But
about the good mood I'll still on his
packer ...

In Deme for a little time showing 198 color
full-screen screenshots. All it takes 1,368,576 bytes not
packed form and about 290 K in zip'e (hrust about the same
shakes). If the laser compact'om pack will be slightly less
that do not play a big role, since it is still a very, very
a lot. Therefore, using a packer, who squeezed those 198
screens in the 80K, that is, each screen on average takes 400
B! Albeit with the loss of quality:)

Idea tossed diver / / 4d in the far in 2001 - and why not
combine hi-res and low-res, pixel graphics and attributes in
engine itself, get a lot of color and great speed.
Realize it until the end I could not until now (although I will 
not amuse the people, arguing that doing this for the night 
until the morning). 

And now a little history ... A couple of years ago has matured 
diver'a DeMouy idea to make absolutely unprecedented in the 
Spectrum. Squeeze Spectrum of all that is possible - and 
without multicolor, all for through various perverted by 
matching low-res and hi-res, attributes and pixels. After all, 
do not forget that this is precisely the contain all the power 
of Spectrum - otherwise he would have lost at the start other 
computers, which came later, and in many respects furnish our 
zx. Because of the relatively high-resolution color screen and 
a very high speed screen updates (even if speed is not great, 
but the volume is small), Western writers and did the game 
until mid-90s, while many others home computers were already 
dead. And now this feature hardly used - or are working only 
with the pixels (Vector, point, 4x4 chunks), or attributes, but 
again, as a chunk (8x8, multicolor sorts). But the real 
combination not used in almost never - is too complicated it all

koditsya too for a particular purpose it can be
use. But diver'a head cooks well, and he was able to
come up with a lot of ideas (though more than half of which, in 
my glance to realize the impossible:). Deme but we had no luck 
as because of our employment (Harm demo, Moorhuhn game), and 
because of the fact that Alexei is currently in the army ...


Little idea about these I have not forgotten, but his hands did 
not reach to bring all this to mind. And he remembered about it 
only this year, during debugging our spring stuff DetroYT. 
Lacked effect in middle - or rather the idea was, but kodit was 
no time, and on Animation did not have enough memory. Few 
pomuchavshis, I raised my unfinished chankovy Engin, cut all 
their ways to realtaymovy kalkulyayting, all fixed a bug, 
remade under the 2 color, and as a result - see part of flying

gears. For information - 230 screens took 22.5K.

Almost at the same time in April and the idea - to make the 
color Animation. However, a number of difficulties - from Engin 
DetroYT'a under color altered reluctantly packing received any, 
and the rate of extraction has fallen below 5 frames (as set by 
us threshold). So I spit saliva all this anguish with

unpacking chunks hemorrhoids with c2p, and made everything so 
easy, as far as possible - simply packed with all the screens:)

However, for this I still use the same chunk,
therefore, something of that approach remains to ...

The idea of ​​this mythical chankovogo engine is simple in 
principle, although and extrim to the heap. We are rebuilding 
the screen in chankovy buffer (ie is without maety addressable 
screen and work with bats) 1x1 or 2x2 (I chose this option as a 
more optimal speed and volume data - chanky 2x2 roxx !!!). But 
since this done in pure form can not (do not ask why - and so 
all clear), then had to distort - to handle the screen in two

passage. On the first pass, we cheat just vertex colors -
Grid 33h25 familiarity. For major non-ferrous things get
many (more than half accurate) familiarity, in which all four
vertices are the same color. Such familiarity c2p just
paints that color by setting the required attributes and
forget about them. All others must specify -
cheat edge familiarity (in my case, with increments of 2 pixels)
then find the right chunk (or sprite - as you are easier to
understanding), which we derive in this familiarity on the 
screen. C color more difficult - but I decided to take the 
color of the first two vertices and steam ... That's summarized 
the idea of ​​a new full-color wonder-engine, which is not 
implemented so far:))) 

To finish all this to mind was not enough time and desire 
(laziness - Eternal otmaz:) The only thing I did almost to the 
end - it painted chunks (we could and Generate, but our 
principle handmade:) The main problem with the secondary 
passage for chankovomu screen - too technical and confusing all 
out: (((So unprecedented realtime in our last demah and does 
not smell - just very kryuyutaya packing ...


In DetroYT'e do: unpack grid colors for
vertices of familiarity. Then the four vertices of familiarity
determined what type of sprite should draw. Receive 16
types of sprites, and I must say that the two I have not 
painted a very (Instead of them were black familiarity:), and 
two are simply familiarity painted paper = ink. The remaining 12

kinds of sprites, each of which I hand painted on 16
sprites. Number sprite (4 bit) to get out of packed
data. Explain what, why and how, perhaps I will not:)
Attached a screen on which these sprites are drawn. Who
very much interested - contact me.

In WeeD'e no grid no, no definition of either. For
each familiarity after unpacking, we obtain the color and, if 
necessary, number of the sprite. Sprites count or redraw I was

a little unclear as why the sprites were taken from
previous product. That is why they are not 256, and 163:) Why
not 192? Because some of them slightly similar (read -
completely), and I installed them with peace of mind threw ...

Determining the type and number of sprites on the stage of 
packing too simplified. At the vertex colors do not pay any

attention, all counted trivial enumeration of all the options.
Sprite, which has the minimum number of distinct
pixels, and is considered necessary. In principle, it is 
logical, but it machine logic - people would choose the least 
suitable for form ...


In the Appendix you will find two source. MY_BATCH - my
private source, is designed to build demos. In this form
he used. What's what - no comments, everything was done for
their needs. COLORFULL - the source, as given by
cultural form (as possible). Comments I wrote
now, therefore, do not laugh much. Also, do not worry
special attention to the horrendous code - works, and this is 
important! Not I knew, in fact, that it wants a:)


Both the source code in the format of Storm Assembler by 
X-Trade. How to be asmov other fans, I do not know, as the 
conversion virtually impossible. And I'm in a different way 
now, no longer write I: (((


Let you do not mind repetition of some lines in the
some places:) The disclosure of internal cycles of bad
affects the volume and modifiability of code, but very
well at speed and readability, simplifies coding at the end
ends - and sometimes just does not register enough ...



Before packing procedure is called Check, which leads
screen in the desired form for the packer - all empty 
familiarity fills ink = paper. Due to the mi-converter

bmp2scr fully encapsulated familiarity are not searched because 
they do not never obtained.


There is still a trick ... In some familiarity may
be 1.2 pixel. Suitable (reasonable) sprites are
not always, resulting in a variety of glitches on the screen.
At the time of party-version I got around this by adding a 
sprite set of two sprites - completely empty and completely 
flooded, although this is not really helped - selected 
companions, who saw this creature, it will confirm. After the 
party, I wrote normal optimizer, which are easy familiarity

clears. Procedure Optim - it all and does it. Parameter P_min as
time and specifies the number of pixels, which is less 
familiarity cleared. Since the check is in the smaller side, 
and in large (1-2 and 62-63 pixels for p_min = 2), the 
installation parameter equal to 32 will make the whole picture 
in the net attributes. Some like it:)))


Check and Optim are doing a little work intersect, but
correct I did not.

Also applied a simple rle-packer with a strange logic. Block
packed data is a continuous bit field
which contains the commands and their arguments. Teams 
2hbitovye, according to their entire 4 pieces:


00 - new color, 3b - the color code 01 - sprite, 8b - sprite 
number 10 - chain, 4b - the length of the chain of 11 - 
single-stained familiarity


A little more ... Working with color is so - we have two
color, paper and ink. Team "a new color" sets the new value
ink, and paper becomes the old ink. Such a scheme
was the most profitable. Sprite ... Draw a sprite to the desired
number, color sets the current color. Single-stained
familiarity - ink = paper_current, paper = paper_current, while
current colors are not changed. Chain - a sequence of filled
familiarity. Length is given by four bits, this number is chosen
empirically, a more or less the bit was
use unprofitable.

Packing algorithm I described is similar to decompression. All 
work comes with a data structure which is shown above. Can

write in their own way, did not surprise me if it will be 
easier and faster than me. Just us all arranged this creation

- Speed ​​of the packing is low, but not every five minutes to
that the thread pack and unpack even better - fits in
3 frame for our delay in 5. And everyone knows that the best 
enemy good:)


In addition to the above application source code can be found
a few screenshots for testing, as well as a small bonus
program from demonstrating this method of packing / unpacking -
especially for those who have not seen our demos:)))

wbw, poisoned cyberjack / / triebkraft