Code - Scripting in demo: synchronizing effects to music and more.

Scripting in demo
Alone Coder 

The interestingness of the demo greatly depends on the si─
synchronization with music, rhythm and flooring─
no movement. Good editing usually
not visible. But it’s clearly visible when it’s flat─
hot and hits the eyes. This is especially true
synchronization.
 As in cinema, editing can take up more
more time than collecting material (in our
in the case of writing the code itself).
 What solutions can be proposed?

                  * * *

   On the Spectrum we are very far from writing─
we'll move forward with one mouse (and if we get there, then
the value of such demos will be small). Creak─
Everyone does it themselves.
   Our regular readers could already pose─
get acquainted with the kernal from JtN (ACNews #54),
which binds each part of the demo to
certain second and gives it to her ka─
any data. This is the simplest type of installation─
Ms. There he wasarranged via a stack, where by─
the addresses of the procedures and all the necessary data were placed─
new Each part on commandret goes
to the next one on this stack.
   Of course, we cannot describe every
sneeze of each effect through such a common
script (even if you place it in the page
Nitsa), and this is not required. For this
there is a separate setting for each
effect.
   The most classic type of department settings
flax effect - rhythmic movement. You can
adjust the rhythm of movement to the rhythm of the music and
get a satisfactory result. But
It's hard to look at this for long. It's unlikely that we
we can write enough effects to
change scenes every 5 seconds as mentioned─
chickpea movie (implying that we are all-
we are still writing a demo, and not converting animation),
so we need to do the movement in more different ways─
figurative.
   Effects can jump to drums or
change the direction of movement, objects on the screen─
wounds can fly in at the right time and fly away─
Therefore, color schemes may vary, to─
effects construction, new objects appear
etc. All this without violating the basic rhythm─
ma. For example, for a tunnel in Dizzzruptor
the music was specially written in the 4th theme─
ne to get into the rhythm of the squares.
   The trajectories themselves can be customized
in different ways, starting from the simplest -
straight lines, parabolas and sines. So, lastly─
her parts Nedodemopseudo─ was used
random linear motion, for which─
the average time of betrayal was selected─
tion and initial value for the generator
pseudorandom numbers. In the panoramic part
The Board II used sections of blue─ 
soid and random numbers for lightning.  B
Wolfenstein-parts of Critical Error were for─
recording keystrokes. In The Board too
recording, but edited manually.  B
panoramic parts of the New Wave 48K demo were
passages between key points. And in her
in the finale the scrolling text itself was specially
prepared to match the mu─
language at seven different points.
   There are many options. The more manual re─
editing, the more work the owl needs─
solve and the better the result can be. B
cube for Mission Highly Improbable everything
was registered manually for a month in a row, in total─
hey, we can watch without getting too tired
this one effect lasts for 70 seconds :)

                  * * *

   The script processing procedure is logical for you─
call at the beginning of the frame construction. At the same time
we use the global timer value
(timer), which ticks when interrupted. On─
example, like this:

 LD HL,(timer)
 LD (oldtimer),HL
effectloop
   CALL scripting;обработка скрипта
   CALL effect;вызов эффекта
waithalt
   LD HL,(timer)
oldtimer=$+1
   LD DE,0
   LD (oldtimer),HL
   OR A
   SBC HL,DE
   JP Z,waithalt ;на случай, если эффект
        ;отрисовался меньше чем за 1 фрейм
   LD B,L
timeractionO
   CALL timeraction;обработка параметров
            ;(например, движение объектов)
   DJNZ timeractionO ;делаем это столько
              ;раз, сколько прошло фреймов
   LD HL,(timer)
effectendtime=$+1
   LD DE,0      ;времяend of effect
 OR A
 JP C,effectloop;turn the effect to
                    ;this time

   More accurate, but slower grafting─
ZKA for any computer speed─
This occurs when calling scripting before each
timeraction, provided that inscripting 
and timeraction we will not manipulate
value (timer), and personally inc─
restorable counter - otherwise slow─
On other computers this value will be repeated─
scramble, and then change abruptly.
   Call scripting and timeraction outside pre─
ripping allows you to have a common handler
interruptions throughout the demo and not
be afraid of exceeding the processor time.

                  * * *

   You can register scripts (time, value)─
but for each effect parameter, but so we
we risk limiting the number of parameters and de─
make the effect monotonous.
   A more flexible option was in the intro
ZX-Guide #4.5: the script contains time, hell─ 
res variable and its new value. You can
register several changes with one and
same timestamp (thereused
time relative to the previous point, which
proved to be inconvenient compared to ab─
solar time).  In particular, such
the script can replace addresses in CALL
effect and CALL timeraction, that is, you can 
completely change the entire effect.
   It will be even more universal to call production
free procedures - immediately, and not waitingCALL
effect. Such a script will consist of:
mails (time, address), and the procedure can
do anything - from changing a parameter or
addresses of some handler before cleaning
screen. A typical handler for such a script
looks like this (from New View 48K):

scripting
curscripttime=$+1
 LD DE,0
 LD HL,(timer);ticks on interrupt
 OR A
 SBC HL,DE
 RET C
curscriptaddr=$+1
LDHL,script
   LD E,(HL)
   INC HL
   LD D,(HL)
   INC HL
   LD C,(HL)
   INC HL
   LD B,(HL)
   INC HL
   LD (curscripttime),BC
   LD (curscriptaddr),HL
   EX DE,HL
   JP (HL)

   Сам скрипт выглядит примерно так:

script
   DW initcube
   DW 192,startcube   ;после наступления
             ;192 фрейма вызовем startcube
   DW 192+96,spincube ;после наступления
           ;192+96 фрейма вызовем spincube
И т.д.

   Можно  реализовать  и  считывание пара─
метра  для процедуры (соответственно, надо
будетadd this parameter to each
I write a line of script) - add after
LD (curscripttime),BC:

LD C,(HL)
INC HL
LD B,(HL)
INC HL

   The result is an unexpected order (address
procedures, next event time, couple─
procedure meter), but no one interferes with reality─
call a script line through a macro - like this
It will be easier to change its format. (One
An example of scripting through macros is given
in the "Games" section.) An example of such a macro:

oldtimeaddr=0 ;the first event does not contain
 ;time
 MACRO event time,proc,data
 DW proc;procedure address
_=$
IF oldtimeaddr
ORG oldtimeaddr;time field in
                    ;previous entry
 DW time
 ORG _;fieldtime of current recording
ENDIF
oldtimeaddr=_
 DW #ffff ;in case of the last entry
              ;in the script
DW data;procedure parameter
ENDM

   If we call the processing procedure
script at the beginning of the frame and the frame is built up to─
lgo, then in the simplest version of the two already
ready events (if they occur very
close to each other) the second may be
deferred until next frame. This is not death─
specifically. But you can fix this using your method─
call scripting in a loop - add after
RET C:

 LD HL,scripting
PUSH HL

   In this case, you can write several
calls with the same timestamp.

    For synchronization by specifying the address─
owl procedures (compared to the backside method─
variable addresses) has its own drawback─
current - when prototyping effects in the language
high level use this script
it is impossible. It will be possible to script only by─
after transfer to the target platform.Another drawback, already compared to
table of values - if the effect is valid─
flax is long, then look through it every
times from the very beginning it is inconvenient. But this one is not─
We will overcome prosperity. I do this: events,
tied to one key point (at
time of it or in subsequent movements), I
I write it with an expression in the time field.
For example, (48*3)+32+diamondbasetime+192
(example from the same New View 48K). When not─
If necessary, I can turn off part of the script
conditional compilation and move this key─
new point at the beginning of the time axis.
   If several independent ones are scripted
elements, then in many calls you can
get confused. In this case, you can use─
create several scripts and several processes─
durscripting - call each of them in
beginning of the frame.  Can be made separate
a script, for example, to sort through an image─
ny, it will be called by the procedure in
main script and will not contain me─
current of time.

                  * * *

   There is a problem with the time reserve─
menu to switch between effects. If
the demo is moving quite tightly, then there may be pauses
be noticeable if these pauses themselves do not help─
threesome to the music. If this is not possible,
then the best solution is to adjust the first frame
new effect for accent in music, and pre─
previous effectlet it end with nes─
how many frames ahead of schedule.
   To pick up and fix this co─
number of frames, we mainly prescribe
script (which is in the kernel) and start time─
la, and the end time of the effect. In the simplest
In this case, you can simply read
her number from the stack, which fulfills the role
kernal script.
   This way you can not only find the optimal
pauses, universal for all types of machines,
but also make several launch options─
flatter, for example, under49 Hz and 50 Hz. That’s how it was
made in The Board II, because...
General Sound growth does not depend on speed
the computer itself. With very aggressive
Sinka may need different launchers─
boxes for real and emulator (where the sound comes
with a delay) - maybe even several
options. But the demo files themselves will remain
identical.
   With this type of synchronization, it is important to learn─
guess what if the effect is too late to launch─
Hey, he shouldn't move all that much
frames, how late he was. Ideally
the effect should work the same as on fast─
three cars, but skipping the first frames─
ditch Unfortunately, this is not always possible.
The simplest solution is to tie the entire demo
(including local scripts) to glo─
ball timer. Of course not necessary
set global time to local time
scripts (DWbasetime+time, procedure ),
the script processor can take it into account, and
the start time of the effect (exactly the one
should be; real - in the timer) he doesn’t care─
Edited by Kernal.
   Another solution is to dissolve─
forge (or initialize) the following
part while extinguishing the previous one. For
this must be done without extinguishing
effect - to take a little time
(you can use straight folding─
screen angle). Another classic
option - while unpacking the parts for now─
call some picture or, because
static is very harmful to the dema, use the floor─
stripes, the same unfolding
rectangle or something like that. K
Unfortunately, this makes the game more drawn out─
that one. It would be possible to use at crossings─
multitasking, if the parts are not necessary─
cover each other's memory. In this case
we will loseFPS (if we are talking about effects, and
not about animation).
   The ideal kernal would look like reda─
key point vector that can be launched─
tit in real life with the demo, rewinding
back and forth (along with music) for the present─
swarm these points, and then save the result─
tat to file. But here the same problems with
limiting the number of parameters. Let's say we
we want to fly through space, into this
time, let's say, stars fall (and many more
whatoccurs). The span is described by the coordinate─
natami and camera rotations on key points─
chkam, we just need to implement it in kernal
splines. But shooting stars will have to
first add it to the code, then enter them
key points in the kernal, so that
old customized trajectory from this to─
The addition did not break.
   I see this solution: the kernal will be
send camera and character coordinates to the effect─
tia with numbers, and the effect will be according to number─
trigger the corresponding events
code (drop a star, blink a flashlight, start─
push a car down the street...).But this kind of decision─
There is a problem - how to configure it yourself
events? We will get completely different re─
results with stars falling quickly or
slowly, at one angle or another, with
acceleration or deceleration... It turns out that
the kernal must also configure the numbering─
ny variables (and no matter how the effect falls out─
due to an erroneous variable value!)
or even generate numbered tracks─
torii. In order not to drown in the rooms, he will come─
Xia export to kernal symbolic
names - and also somehow automated─
start this process.
   So there is still a lot of work to be done.

                  * * *

   Even good effects can be ruined
poor installation, which also happens in demos
promoted authors. A good installation with
Syncom may take months and may be
really boring work, even if it's
timedistribute between writing pieces
code.
   But if you find yourself in the demoscene, then you need to
choose: either waste your time creating
giving THINGS, or wasting even more time─
me for self-promotion on the Internet, otherwise
the result will be small... Even if not
raise the question of morality, at least in the short term─
In the long term, the latter win, in the true sense─
rical - the first.  After all, it is valuable
the product, not its advertising! But there are also three─
those who are just having fun. Unfortunately─
I mean, all means are good when it comes to entertainment,
especially if the person having fun is not burdened by those
the most moral principles. If a person
not consciously disposed to do good,
then the only thing that stops him from doing evil is
threat of punishment. There is always a question -
where are we going?