chunks 2x2
by poisoned cyberjack/tbk
new trend in demomaking
greets to everybody, who reckon himself a coder or some kind of such! today i'm gonna amaze you :)
the modern demomaking (spectrum of course) is based mainly on chunk engines. and that's right other way it would be very difficuilt to realize some interesting things. i'm not going to explain anything, it was made sometime ago before me. moreover, the choice has been already done.
also, i don't want to explain what is a 'chunk'. try to find some information in any other sourses, cos i'm trying to tell something more important and such 'remembrance' is out of my plans here.
so, at the beginning i'd say, that there are different kinds of chunks. on spectrum it's usually 4x4 (pixel - refresh, dogma, inbetween and multicolour - eye ache 1/2, rage, stellar contour) cos it's the most optimal ratio between the screen resolution and its dimensions. the 8x8 kind of chunks, attribute (any demo of 95-97) and pixel-attribute (emergency, 63bit3, smile_4k), due to low resolution look poorer, cos it's harder to make something good in 32x24. by the way, here i mean 3d coding, cos it's the most difficuilt (and therefore, the most interesting) coder's abilities application.
all this has been tested long time ago (in 97) and is boring almost for everybody. maybe there is an alternative?
and there is a kind of alternative and it's well-known for a long time too. remember higher state/ 3sc, over the top/ enigma, matricks/ baze? yes, i'm talking about 2x2 chunks.
many coders, who are far from amateurs now, can smile distrustfully. of course, at first sight there is not so much use of such dimensions of chunks, cos screen enlarges four times comparing with 4x4 (and therefore, a frame will be drawn 4 times slower) - and it's not so easy to put such screen in memory. the use of windowed mode is not an exit. besides, the main feature of this chunks is 5 colours, and it's not enough for illumination realization in 3d effects (phong, goraud and even flat looks awfully). alongside with all this drawbacks, c2p is slower, cos reading has to be more often than writing (again comparing with 4x4).
but! i shouldn't pay waste your time (and mine, which is much valuable), if i haven't realize 2x2 chunks in our demo, which we couldn't finish for cafe'2002 and still we can't finish it :((( so, here we go...
the most easily solving thing problem is the lack of colours. of course it's dithering. in 2000 we made a c2p routine for chunks 2x2 with baze/3sc which he used in his matricks with 16 colour dithering (but his personal c2p is slower). c2p is following:
sp - chunk screen de - 1st line on spectrum screen (#401f) bc - 2nd line on spectrum screen (#4120) pop hl ld a,(hl) pop hl ld l,(hl) ld h,a ldd ld a,(hl) ld (bc),a ?????: 10+7+10+7+4+16+7+7= 68tct
the main feature of this procedure is ldd command that turnes the picture horizontally, cos sp increases and bc and de decrease. chunks of %---xxxx0 type. for dithering it's necessary to put the gfx tables in different memory banks and to work with a single screen. i think there's no use to explain it's all well-known :) if you have some questions - email me.
as you can see, such speed is high enough - the whole screen can be drawn in 3 frames. but the problem of a too large screen remains - so that's not a full solution.
experimenting with different engines and filters, a wonderful thought has visited me :) what if we will process not a whole screen, but just a part of it, and the rest of it will fill applying, for example, linear interpolation? then there will be no use in a slowly working filter (ala sair00s) that helps to hide the drawbacks of the engine - so we get the benefit in speed and screen usage. there's some similarity with amiga gfx mode ham8 (as i see), where's the colour of a group of pixels depends on the colour of nodal pixel - and the latest demos work not in 640x480 or 320x240 resolution but much lesser. as i'm not an amiga freak (at all), i could say a nonsense it's not the point :) we're talking about spectrum.
what i call a 'linear interpolation'? i calculate every second chunk in horizontal direction, and the rest of them are average between two certain.
for example:
Usually made: !c0! c1! c2! c3! c4! c5! c6! c7! c8! I make like: !c0! --! c2! --! c4! --! c6! --! c8! (c0+c2)/2 (c4+c6)/2
as a result, a picture is a little blured, and i like that :) anyway, it a bit risky to trace the chunked screen, cos due to the low resolution and simplified shaders the screen is usually ugly :) in the last demos sair00s acts like this with 2 screens - but i could use only one.
there's no benefit in speed in using a separate operation for interpolation, cos it's not too fast (get 2 numbers from ram, then addition, then according to the table recieving the result and then put it into ram - about 40 tacts per chunk). that's why i tried to combine interpolation with c2p:
sp - chunk screen de - spectrum screen h - previous chunk pop bc ld a,(bc) ld l,a ld a,(hl) ld (de),a inc h inc d ldi dec d ld h,b ?????: 10+7+4+7+7+4+4+16+4+4= 67tct
mmmm... i'll try to exaplain. to draw a plot (8x2 pixels) we have to consider 3 chunks:
! ! ! ! -- c0 -- c1 ! -- c2 -- c3 ! ! ! ! ^ ^ ^so we have 16 tables (cos chunk can be of different colour in previous plot), and graphics adress can be calculated as (for the second plot):
c1*#0100 + c2*#0010 + c3
chunks of %1100 kind, i.e. #e0-#fe. in the end of the sector there's a table of low graphic adresses, i.e. from #e0e0, #e2e0, etc. and the gfx is placed within the rest of 32 sectors.
as you can see - gfx and multiplication table are placed on the same adresses. i avoided it by excluding of 2 colours :) so i have 14 colours instead of 16. but it's more comfortable to work with 16 colours, that's why i combined 0 with 1 and 14 with 15 (the multiplication table has the same values). however, it is possible to make real 16 colours, but it will slow down c2p, so i've picked out this method.
dithering i make with 2 memory banks with different chunked gfx for even and uneven lines. it uses a lot of memory and works with one screen :)))
finally, what do we have? comparing with chunks 4x4 screen increased twice (not four), the fullscreen is traced in 3 frames approx., we don't need additional filter, the quality of the screen is much higher i.e. we loose in speed, but win in quality. this engine is quite efficient, and we tried to proove it in our demo.
in attachment you can find the sources of chunked gfx generator and c2p with strom syntax :(( and a small engine demonstration.
respect to all spectrum's coders and adventurer's readers!!!
(c) triebkraft
and here is an optimized version of this engine, made by jtn/4d. read and think :)
pop hl ;10 l,(hl) ;7 ld a,h ;4 exa ;4 ld h,a ;4 ldd ;16 ld a,(hl) ;7 ld (bc),a ;7 ;=59t!!!!!!!!!!!