(C) Bob Skath
Since B R A C T I G R A F K A
Any programmer there are situations when he was like and
knows assembler and still can not write anything worthwhile,
and only look with envy six SMOOTH running along the curb and
sidewalk scrollers have a newfound anything MAX IWAMOTO and
compares with its squalid begushkoy size 3 * 3 pixels, which is
feverishly cringe every time in the throes of emerging new
symbol. A the thing is that the programming of such effects
(like almost all dynamic toys) is built on the principle of so-
called "fast" graphics.
Here's how, for example, the program looks
Programmer (My goodness, what I write), who had just mastered
the work with sprites, and whose head is occupied by structured
programming:
DI; While the all clear
LD HL, # 4000; It is also clear
LD DE, SPRITE; DE - address of the sprite in memory
LD BC, # 0504, B - the size of X, C - the size of Y
LOOP1 PUSH BC; save BC
PUSH HL; keep current address on the screen
LOOP2 LD A, (DE); take a byte sprite
LD (HL), A; put it on the screen
INC HL; increase the address on the screen
INC DE; increase the address on the sprite
DJNZ LOOP2; while X <> 0
POP HL; restore the address on the screen
POP BC; restore the size counter
CALL NXTLIN; define the following line in the screen
DEC C; the size of Y is over?
JR NZ, LOOP1; if not then repeat the cycle.
....
NXTLIN INC H; routine determination of subsequent
LD A, H; yuschey line in the video. At the inlet
AND 7; in HL - address of the screen. At the exit
RET NZ; desired address again in the HL.
LD A, L
ADD A, # 20
LD L, A
RET C
LD A, H
SUB 8
LD H, A
RET
Well ... Quite decent program to
display static images , but the trouble starts when this
same programmer, inspired by previous success, is trying to
remake this very program from for the withdrawal of Moving
sprites and yes even Larger, in terms of register pair HL to
the entrance, which would display images in different parts of
the screen. Here is where the fun begins ...
The image begins to distort,
blink and do everything to make the pseudo-programmer biting
elbows of fury.
So I decided to help a bit sim
people in order to alleviate their suffering to their
series of articles on this topic. The whole principle
fast graphics is that the image is not built directly on the
computer screen, and the so-called virtual screen that is
somewhere in the depths of memory machines. Picture first
construct all - for the sprite sprite overlap in
the correct sequence subroutine
similar to the above, with the difference that the virtual
buffer line Raster go one after another, and then as one
gigantic sprite is displayed.
Here's how I see, half of the readers
of this article with a cry: "Wooooow, I poooonyayayal !!!!"
famously shed a car and quickly downloaded TASM and SPRITE
EDITOR.
Well, nothing a couple of minutes they are satisfied that
everything is not so simple and clear, as seems at first. The
whole point is that the picture must have time to rebuild no
more than one interval between interrupts, otherwise it will be
a beard, and all work go awry. And it's not so easy,
This proves the simple calculation of execution time the above
program. Perhaps some of the readers who have hung their noses
and think about the impermanence of all things, but nothing -
just remember ROBOCOP'a or there WEC LE MAN. There are in fact
nothing jerks?? That means you can?? Of course you can ! Only
need to consider several points:
1. Usually not required to rebuild the entire
screen, grabs a redrawing its
part and the rest - static information (
as the number of lives, the name and MEGADEMO
etc. )
2. Need to rebuild discard any silly ideas about the structural
approach and nested loops (that you do not sort
database fields 172627373)
3. Need to think a little. And yet!
As an example, I will give a procedure
which builds familiarity picture size 26 * 128 pixels at the
top of the screen.
DI; Interrupts necessarily DI!!!
LD C, # 48; token move to another one-third
Screen
LD HL, SCR +28 +1; address output to the screen, taking
into account
O right-left
LD (ADDR1 +1), HL; Set screen address
LD IX, PICT + # 11; address of the virtual screen
Memory based read-out cross
fray
CALL ROUT1; Drawing the first third of the screen
LD C, # 50; Marker transition in the last third
Screen
LD HL, SCR1 +28 +1; address output to the screen in the
second
third
LD (ADDR1 +1), HL; Set screen address
ROUT1 LD B, 64; number of lines drawn for
one-pass procedure
LOOP2 LD (SPSAVE), SP; save SP for the correct
Released
LD SP, IX; Current Address Read
POP AF; Chi
POP DE; that
POP HL; it
EXX;
POP BC; car
POP DE; Ting
POP HL; ku
ADDR1 LD SP, 0000 It has been established to address
recording images to the screen
PUSH HL; We write
PUSH DE; raw
PUSH BC; Vai
EXX;
PUSH HL; car
PUSH DE; Ting
PUSH AF; ku
LD (ADDR2 +1), SP; Save the current address of record
LD SP, # FFF2; Set the register-
ADD IX, SP; couple IX to the next byte
LD SP, IX; virtual screen
POP AF; Chi
POP DE; that
POP HL; it
EXX;
EX AF, AF ';
POP AF; car
POP BC; Ting
POP DE; ku
POP HL;
ADDR2 LD SP, 0000 It has been established to address
recording screen
PUSH HL; Over
PUSH DE; pi
PUSH BC; raw
PUSH AF; Islands
EXX; it
EX AF, AF ';
PUSH HL; car
PUSH DE; Ting
PUSH AF; ku
LD HL, # 011A; calculate the address of the follow-
ADD HL, SP; line in the same third of the screen
LD A, H; not check out whether
CP C; we are in another third of the screen
JR C, LOOP1; or other familiarity
LD DE, # F820; If so, produce
ADD HL, DE; correction
LOOP1 LD (ADDR1 +1), HL; Save the current address for
recording screen
LD SP, 46; next line virtual
ADD IX, SP; buffer
LD SP, IX;
DJNZ LOOP2; If the cycle has not been exhausted,
repeated We say
SAVESP LD SP, 000; Restore stack
RET; Return
Well?? At first glance, cumbersome,
but it works fine. Oh, and it is clear
why such a performance? Correctly,
because at one time read and write
two bytes.
Attention is drawn to the fact that
to accelerate the work is missing here
routine determination of successive rows, and output in each
third is separate.
Thus it is possible to display
buffers of any size (but the multiple
on X two, I wonder why?) with a fairly decent speed for
animation or revive your toys.
Well ... Enough for today ... The next time I'll talk about
how fast imprint sprites in a virtual buffer
mask and without. And more ... But more about that next time.
Bob Skath. 1996. Latvia. Daugavpils.
