more colours!!!
(c) poisoned cyberjack//triebkraftne
trying to do something impressive for the 'weed', i haven't expected such a good results. a lot of people asked me at the party 'is it multicolour?'. meanwhile, it is all that simple this is just packed fullscreen animation. packed well, indeed...
outrage of colour, seen at the screen, is not the result of engine's work, but a correctly done original picture. gd//tbk//4d is the one to answer how it could be done, he rendered it in lightwave 7.5. after that i converted avi files, using bmp2scr_1.75 by lcd. i worked only with the screens received from such a conversion.
that's all i had to tell you :). but because of a good mood i'll speak about the packer itself...
the demo features 198 coloured screens, shown within a little amount of time. this occupies 1.368.576 bytes in not packed form. 290k in zip (hrust does nearly the same). laser compact packed it takes a little less space, but it still makes no sense because of huge size. that's why original packer was used to compress it all in 80k, i.e. each screen is about 400 bytes long!!! and who cares about quality loss :)
diver//4d brought up this idea long time ago in 2001. why not combine hi-res and low-res, pixel graphics and attributes in the engine itself, to obtain a lot of colour and high speed. i didn't fulfil it in full scale, still, but it would be a lie to say that i'm trying to do this from dusk till down.
and now, a bit of history... two years ago diver came with idea to make a demo, absolutely unprecendental on speccy. to make the hardware do its maximum without multicolour technique, everything have to be done using perverse combinations of low-res and hi-res, attrs and pixels. don't forget, this is the main powerful feature of speccy, otherwise it could lose the other computers, released later and having better specifications at start. because of averagely high resolution of coloured screen and very high speed of screen updating (maybe not so, but the size of screen data is small), western authors released games till the middle of nineties, when majority of the other home computers were almost dead. for now this feature is practically out of use - either people are working with pixels (vectors, dots, chunks 4x4), or with attributes, but the same way as with chunks (8x8, various forms of multicolour). the real combining is never used - it's too hard to code and the purposes of use are far too specific.
but diver is a keen minded person ;) he invented a lot of ideas (more than a half of which is unrealisable as i see it ;) we doesn't succeed with that demo, being busy with other projects (harm demo, moorhuhn game), and because of diver's army service...
i didn't forget those ideas, but there was no time to shape it out. and finally i came to it only this year, making up detroyt. there was no effect in the middle, i had an idea, but was pressed by the lack of time and there was no memory for animation. thinking for a while, i found my old chunk engine, cut everything about real-time calcs, fixed bugs, redone it for 2 colours and got a part with a flying pinions as a result. just to mention - 230 screens occupied 22.5k.
nearly this time in april i've got an idea to do a colour animation. but confronted with difficulties - it was hard to make detroyt's engine use colours, packing was bad and decompression speed was below 5 frames (the threshold we set). that's why i spit upon all this tortures with chunks depacking, shit with c2p, and did everything as simple as it could be just compressed all screens. but, truly saying i used chunks, therefore something left from the old method...
an idea behind this mythical engine is simple, although its perverse. we are building a screen in a chunk buffer (not dealing with screen addressing problems or working with bits) 1x1 or 2x2 (i've chosen this variant as it is optimal by speed and amount of stored data - chunks 2x2 roxx!!! ). but it can't be done as it is (don't ask me why - its clearly seen), that's why i used some tweaking - processed the screen in two passes. on the first we are counting only height's colours - 33x25 chars grid. for the massive coloured objects there would be a lot (more than a half) chars, where all four heights have the same colour. such chars c2p fills with this colour and forgets about it. the rest has to be detailed - we count edges of chars (2 pixel step in my case), after that we find the needed chunk (or sprite if its easier to understand), and finally putting it in a char cell on the screen. it's more complex with colour but i decided to use colours of first two heights and forget about it... this is the short explanation of an idea behind the new wonderful coloured engine, that is not realised till today :)))
there wasn't time, nor desire to complete it (laziness is the main reason :) one thing i did till the end - drawn all chunks (it could be generated, but 'handmade' is our main principle :). the main problem is the second pass on the chunk screen its too abstruse :((( therefore there is no blasting real-time in our last demos - just very cool crunching...
how it was done in detroyt: at first, depacks the colour grid for the char's heights, then, using the four heights of the char, the type of the sprite is defined. we got 16 types of sprites, 2 of it were not drown at all (black filled chars were instead of it :), and the next two are just chars filled with paper=ink. 12 types left, for everyone of them i have drawn 16 sprites by hand. number o sprite (4 bits) is taken from the packed data. i'll not explain what is what :) the screen with the sprites is applied. if someone is extremely interested contact me.
'weed' features no grid and no sprite definition. we get colour for every char and the number of sprite, if needed, right after depacking. i just couldn't understand how to redraw sprites and took it from the previous product. because of that there are 163 of them, not 256 :) why not 192? some are the same, i just erased it...
definition of type and sprite number at the packing stage is simplified too. no attention paid to the char's heights colour, everything counts with the banal moving through all variants. sprite, having minimal differences is the needed one. it is logical if we are talking about machine logics - human would choose the form appropriating one...
you will find two sources in attachment. my_batch - my private source designed to assemble the demo. it was used exactly in this form. no comments, everything was done specially for our needs. colourful - source designed to be understood (as much as it could). i wrote comments these days, so not laugh too much. also, do not pay attention at the awful code - it just works, that counts. i really didn't know that someone would need it :)
both are in storm assembler format. i don't know how users of the other asms would convert it - practically it is impossible. and i just can't write the other way now :(((
don't be confused by the multiple repeats of some lines in some places :) unwarping of the inner loops adversely affect the amount and modification ability of the code, but very good on readability and speed, simplifies the coding at last - and sometimes i am just running out of registers...
'check' procedure is called before packing, it sets the screen in the state, consumed by the packer - all empty chars coloured ink=paper. due to a distinctive feature of pc converter bmp2scr, completely filled chars are not being looked for, because it never happens.
there is another trick... in some chars only 1-2 pixels could be set. fitting (wisely) sprites are not being found all the time, resulting bugs on the screen. at the moment of party version i went through this, adding 2 sprites - one completely filled, and second - empty. that not really helped - can be approved by peculiar people who have seen it. after the party i wrote normal optimiser, it just cleans such chars out. 'optim' procedure is doing that. p_min parameter sets quantity of threshold pixels to clean the char. checking goes for the less and for the larger quantity of pixels (1-2 and 62-63 pix if p_min=2). setting this parameter to 32 turns the picture to clean attributes. some people like it that way :)))
'check' and 'optim' are doing overlapping work, but i didn't correct it.
also a simple rle packer with the strange logic was used. block of packed data represents itself as a continuously bit field, where commands and arguments are placed. commands consist of 2 bits, accordingly to that there could be 4 of them:
00 - new colour, 3b - colour code 01 - new sprite, 8b - number of sprite 10 - chain, 4b - chain length 11 - one filled char
more detailed...
work with colour is going like that - we have two colours, paper and ink. 'new colour' command sets new value of ink, while paper becomes equal to an old value of ink. that scheme proved to be more appropriate and optimal.
sprite... draws sprite with the right number, colour is set by the current values.
one filled char - ink=paper_current, paper=paper_current, while current colours are not changing.
chain - sequence of filled chars. length is set by the 4 bits, that number was chosen by the experimental way, more or less was found unprofitable.
i described the packing algorithm, depacking is the same. all work is going on with structured data, being described above. it could be written the other way, i would not be surprised if it would be simplier and faster than my version. we just were convenient with this work - speed of compression isn't that high, but there is no need to compress something too often, decompression is better - confines in 3 frames, opposingly to our delay - 5.
except of the sources, mentioned above, you can find some screens for testing in attachment. and a small program, demonstrating this method, for those, who haven't seen our demo :)))
wbw, poisoned cyberjack//triebkraftne