stay
move
view
pan
turn
lean
roll
text print
text centerprint
text finale
subtitle
sound
palette
fade
eyes
text stufftext
A lot of tweaking and minor bug-fixing has been done on ReMaic since the v3 release over a year ago, and a fair amount of new functionality has been added. This happened incrementally as new features and fixes were desired for QdQ releases. Following the release of Scourge done Slick, I finally managed to buckle down and do one last revision and tidying of ReMaic to produce this v4 release. This is intended to be the last public version of ReMaic, unless I've introduced some disastrous new bugs that will need fixing.
If you've used ReMaic v3, you'll want to know what has changed since the last release. You should look out for these icons:
If you are using ReMaic v3 for some reason, you are recommended to download the latest version, v4 - but if you wish, you can also consult the old v3-specific version of this document.
ReMaic is a utility for changing the camera viewpoint in a Quake demo or movie that you have recorded. It is run from a shell and works with a source text file of instructions, so using it is a bit like compiling a program; the process doesn't have any fancy menu-driven GUI.
The program was originally designed and written in order to take
normal single-player Quake runs that had been made using the usual
console command record
, and to reshoot them from a
perspective other than that of the player. This was used to make the
Quake done
Quick movies. Most extensions to ReMaic
(recent examples would be sounds and camera rolls) were also first
implemented because we wanted to use them at QdQ, and its origins
as an internal tool still show in the program.
However, I have made quite an effort to make ReMaic suitable for public release, and I hope that Quake players everywhere will enjoy using ReMaic to make films of their most interesting single-player and deathmatch demos. It is also a useful tool for proper "Quake movies." Movies that are shot "live" on a multiplayer server tend to have somewhat jerky camera-work. If you use ReMaic, you can record your footage and then add the optimal camera-work to it later.
ReMaic should be pronounced "Remake", for obvious pun-related reasons. "ReMaic" is an acronym for "Reshoot Existing Movie, Altering Its Camera", and I apologise profusely for this. ReMaic was originally known as CamDem, and is referred to by that name in the text file for The Elder Whirled, the first ever thing that QdQ released.
The most recent version of the documentation that you are now reading is that on the ReMaic web page. If you are reading a local copy, and having problems, do check the current version since some updates may have been made since the version that you are reading. You can also check the latest news on ReMaic.
ReMaic can be downloaded as a
*.zip
file - which contains
ReMaic.html
.
ReMaic.bat
.
original.dem
example.cam
.
example.dem
ReMaic is written as a Perl script,
not a stand-alone executable. This
means you must download
and install a Perl interpreter from CPAN in order to use it. I am
sorry for this inconvenience, but
<evangelism>
Perl is a wonderfully useful language that
everybody should have on their machines anyway.</evangelism>
No, really, it's great. You'll probably find it easiest to download an
executable directly from the ports
directory at CPAN.
Most of you PC-users probably want
win32/ActiveState/Release/Pw32i314.exe
. In times of
trouble, if the mirrors fail, you can get the same file directly from
this directory.
But if things have changed around since I wrote this or you are using
a different platform then you'll have to figure out what you need
yourself. My honest guess is that if you can't manage to work out how
to install Perl, you'll probably have problems working out how to use
ReMaic.
ReMaic also makes use of Uwe Girlich's brilliant demo compiler and decompiler, LMPC. You will have to download and install LMPC if you do not already have it. Note that for PC machines, it's the standard DOS version that runs in the shell that you want, not the Windows version.
You should place LMPC and Perl somewhere in your path; that should be enough for them to work with ReMaic. However, if you have problems in this area, then as a last resort just place everything (i.e. LMPC, Perl, ReMaic and any files you are working on) in the same directory and run everything from there.
(ReMaic.cfg
file to allow users to specify where they had installed LMPC, but in
retrospect this complication probably caused as many problems as it
solved. The v4 release will use any ReMaic.cfg
that you
already have, but it won't try to make any new ones. Put LMPC somewhere
in your path instead.)
To install ReMaic, just download and unzip it.
To run ReMaic, you can either either explicitly call Perl on the ReMaic Perl script:
perl -w ReMaic.bat [optional switches] [filename arguments]
or, if you are running on a PC, you can simply call the batch-file directly
if it is in the current directory:
ReMaic [optional switches] [filename arguments]
ReMaic.bat
somewhere in your path and be
able to run ReMaic from anywhere, you will want to amend the
Perl invocation line
perl -w ReMaic.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
near the top of the ReMaic.bat
batch-file to reflect the
exact location of the file on your own system, e.g.
perl -w c:\quake\utils\ReMaic.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
Under Unix, add the appropriate hash-bang line, e.g.
#!/usr/bin/perl -w /quake/utils/ReMaic.bat
to the ReMaic.bat
Perl script to run it without explicitly
invoking Perl.
For the rest of the documentation, for the sake of consistency, I
shall assume you are using one of the methods that lets you
invoke ReMaic as "ReMaic
" without
mentioning Perl explicitly.
The filename arguments and optional switches you can pass as inputs to ReMaic are explained in section 4.
Other authors have written some useful bits and pieces for using in association with ReMaic. All these utilities are written by other people, so please don't contact me asking for help with them. Their authors will be much better placed to give you the answers you require.
Yonatan Donner wrote a utility called AutoCam which will help you to produce ReMaic screenplays automatically on levels for which a file of camera information has been prepared. Check it out and see if it could help you. There is also a companion program to AutoCam by Andrew Smith, AutoMAP, that you can find via the AutoCam page.
Andrew Smith also wrote a GUI front-end to demo-processing for the QdQ team that has since been publically released. If you don't like using ReMaic from a command-line prompt, check out QdQFront, and you can co-ordinate all your processing with this friendly utility.
There are two utilities by Stefan Schwoon that were first developed for internal QdQ use along with ReMaic and later given a public release. Both can assist in a ReMaic-based recamming production process.
-w
for faster-than-LMPC decompilation, -t
for time-stamping demos, -j
, -c
,
-m
and --damage
for view tidying,
-b
and -u
for production effects, and
-v
, -f
, --setview
and the
separate reduce
program for final compression.
There are also many other demo utilities around that are not directly related to the ReMaicing process but that any movie editor will probably want to have around. These include demcut (which comes with LMPC), KeyGrip, Film@11, and DEMentED (does DEMentED for Quake have an official URL anywhere?)
When you use the Quake engine to record a demo, it notes down the important events in the world surrounding you. These include the positions of other entities, the sounds that are played, and other assorted effects. The demo also notes the direction you were looking in. On playback, Quake remodels the world from the list of events that it has and displays it from the recorded perspective, using the game engine to render the scene just as if you were there for the first time.
This means that we can change the perspective from which a demo is seen quite easily, since the events themselves that make up the demo are not very dependent on your perspective when you recorded it. (But note that there is some dependency.)
ReMaic adds a new viewing entity to an existing demo. I call this entity the camera. It then sets the perspective from which the events in the reshot movie should be shown to be that of the camera. This perspective is determined by three main variables:
ReMaic reshoots a demo by taking a list of timed instructions that
tell it how to move the camera and how to aim it (i.e. how to move its
target, and whether to add any additional roll.)
This list of instructions is contained in a file
*.cam
which I refer to as a
screenplay. You should create the *.cam
screenplay files with your favourite text editor. (If you are an
inexperienced DOS user who is now asking "What's a text editor?"
then type edit
to start a simple but adequate such
program.)
Most instructions in a screenplay either affect the camera position, or the camera target. There are also one or two other instructions as well.
Each instruction in a screenplay is labelled with a time at which it should occur. When ReMaic reshoots a movie, it checks the time that is associated with each frame of the existing movie, and it activates a new screenplay instruction as soon as the time in the movie reaches (or passes) the time that labels the instruction in the screenplay.
You can also include comments in screenplays by preceding them with a
hash #
character. A screenplay file is thus made from
lines of the form
time instruction # optional-comment
This syntax is best understood by looking at an
example.
There are two instructions that control where the camera position is.
stay
This instruction tells the camera to remain at some specified position.
stay
at a new position, this will effect a cut to the new
position. For this reason, the instruction cut
may
be used as a synonym for stay
.
move
This instruction tells the camera to start moving smoothly towards some specified destination position.
end move
to specify
the end time of a move. This simply tells the camera to
stay
at the destination position having
finished the move
and arrived there at the
specified time.
Understanding the distinction between the stay
instruction (which tells the camera to be somewhere)
and the move
instruction (which tells the camera to start
going somewhere, arriving at a certain later time) is
the key to writing screenplays that do what you want them to. Other pairs
of ReMaic instructions, such as view
and
pan
, lean
and roll
, and
palette
and fade
, also act in a similar way.
There are many illustrations of the use of these instructions in the
example file.
There are three instructions that control where the camera target is.
The first two are directly analagous to stay
and
move
except that they control the camera target rather
than the camera position. The third is a special effect for use when
the second does not produce appropriate behaviour.
view
This instruction tells the camera target to remain at some specified position. In other words, the camera stays aimed at that position.
view
a new position, this will effect a sudden angle
cut to the new position, as was the case for the
stay
instruction.
pan
This instruction tells the camera to start smoothly moving the target point at which it is aimed towards some destination. In other words, the camera aim will move to the new position over a period of time.
end pan
to specify
the end time for a pan
. This simply tells the
camera to view
whatever it is looking at once
it has aimed itself at the new destination. turn
rather than pan
.turn
This instruction tells the camera to start smoothly changing the angle at which it points in order to end up pointing at some target.
pan
. The only
difference is that with panning it is the point that the camera
is looking at that is moved between the start point and the end
destination.
turn
, it is the angle that the camera
looks in that is smoothly changed.
pan
. If this doesn't do what
you require and you realise that it is because of a rapid change
in the relationship of the camera and target position, try
turn
instead.
end turn
instruction.
As should be clear from reading the above, positions in ReMaic that a
camera may stay
at, move
to,
view
, pan
or turn
towards are
quite flexible things. They can be static, or they can move relative
to some other entity. I now describe the exact forms that positions
may take.
Every position is made up of three co-ordinates. In ReMaic, each
co-ordinate is specified by a separate expression. If only one
expression is given, rather than three, then this just means the same
expression should be used for all three co-ordinates. This just allows
us to abbreviate long commands such as, say, move p~0.3 p~0.3
p~0.3
to the shorter but equivalent move p~0.3
.
The simplest kind of expression for a co-ordinate is an absolute
value. This is a just a real number; it may be a decimal fraction. For
example, 23.6 100 -30
specifies an absolute position.
To find the co-ordinates of an absolute position which you want to
use, you must run Quake on the map in question and then move to the
position using whichever cheats and so forth you desire. In vanilla
Quake, to get at the co-ordinates you need to type
edict 1
in the console. This will give you the various
statistics for entity 1 - that's you, the player. One of these will be
your origin
, which is where you currently are. That will
give you the co-ordinates you require.
Most people who use ReMaic regularly have developed
macros, external programs, and progs.dat
modifications
to make this process easier. I haven't gotten around to a public
release of some kind of official mod to do this fairly simple task,
but last time I looked there was something by insane knocking about
on Yonatan's
AutoCam pages that should do the job.
Sometimes you will want to refer to the current value of some
co-ordinate, which may be calculated from a complicated expression
whose value changes over time, as an absolute, unchanging, static
co-ordinate. You can use the expression now
for this
value. So, for example, stay now
will stop the camera
wherever it is. (Of course, this instruction is an abbreviation for
stay now now now
, which specifies the current x, y and
z-coordinates.)
Often you will want to specify a position that is relative to some
Quake entity. The most common example is the player who recorded a
single-player demo, but other entities such other players, monsters
and weapons can also be used. The expression e
n, where n
is an integer, represents the appropriate co-ordinate of entity
n. p
is an abbreviation for e1
since entity
1 is always the player in a single-player game.
Thus to aim the camera at the player, you would say view
p
. This instruction (which is short for view p p
p
, representing the current x, y and z-coordinates of the
player) will make the target of the camera be the origin (or position)
of the player. Whilst this instruction remains active, the camera will
now turn to point at the player wherever they may go.
Sometimes you want to talk about not where some entity is,
but where it was some time ago. You can do this by adding the
suffix ~
t to the entity expression, where t is a time as
a real number of seconds. Thus, for example, e14~0.3
is
the appropriate co-ordinate of entity 14, 0.3 seconds ago.
(ReMaic won't look into the future, since it processes a movie as it reads it. Thus you can't refer to where an entity will be in a certain amount of time, only where it has already travelled. The gain in functionality didn't seem to make up for the inconvenience and slowdown that parsing the whole input demo before writing any of the output one would have caused, sorry.)
The main use for the ~
construct is for creating the sort
of shots that are associated with filming patches known as
chase-cameras. If you set the camera target to be the player (with
view p
) and set the camera position to be where the
player was, say, 0.3 seconds ago (with stay p~0.3
), then
the camera will chase the player and keep them in view. Many demos
look pretty good with a screenplay file that simply has those two
instructions at time 0 and nothing else.
This simple chase-cam will fail to behave nicely in two circumstances. One is where the player doubles-back or stands still. In this case, the camera may end up moving through the player, which can produce an ugly effect, or even coinciding with the player, which looks very strange. The second problem occurs when the position of the player changes instantaneously, for example because they have teleported. The delay until the chasing camera catches up can cause odd things to happen in the mean time. You should use other instructions to say what you want the camera to be doing during those kind of occasions.
One thing you may be wondering is how you can find out what number a particular entity in your demo has. Maybe you want the camera to look at a particular zombie at one point - how do you find out what its number is?
The most straightforward way to do this is to have a look at the
*.ls
file that LMPC produces for your demo and that
ReMaic actually uses to
process the movie. All entities will be spawned during the
first frame with a spawnbaseline
message, and LMPC
annotates these with the names of the models that are used for
them. So you'll want one of those entities whose model is annotated
with the filename zombie.mdl
. You can also get a quick
list of all entity names and numbers straight from a demo using
Demix.
To find out which zombie is the one you're interested in, you'll have
to work a bit harder. One way is to note where it is at a
particular time, find out the co-ordinates of that point, and then see
which zombie entity is closest to those co-ordinates at the time in
question within the demo. This requires a little bit of technical
nous, and some common sense detective work and some patience, but
you shouldn't be playing with individual entities unless you understand
the Quake demo format a little bit, basically. Another approach for
working out which entity is which is to use Demix with the
-r
switch to remove each one in turn.
Any co-ordinate expression can be modifed by a final absolute
offset. Thus a x-coordinate of now-100
is 100 units
behind the current co-ordinate. I find that a chase-cam that is also
slightly above the player gives nicer results than one directly behind
them. So I often use a position of p~0.3 p~0.3 p+30
or
similar for my chase-cameras when I film things.
There are two instructions that control what the camera roll is.
They are indirectly analagous to stay
and
move
except that they control the camera roll angle
rather than the camera position.
Camera roll is less important than targetting, and in general, you can safely ignore this functionality and leave the camera roll angle at the default of 0 throughout a demo unless you have some special effect in mind. (Possible effects include leaning the camera on turns, shaking the horizon to indicate e.g. earthquakes, or performing a spin.)
lean
This instruction tells the camera roll to remain at some specified angle.
lean -80
.
lean
at a new angle, this will effect a sudden change
to the new angle, just as was the case for the
stay
and view
instructions.
roll
This instruction tells the camera to start smoothly changing the angle at which it is rolled towards some new value. In other words, the camera roll will turn to the new angle over a period of time.
end roll
to specify
the end time for a roll
. This simply tells the
camera to continue to lean
at whatever angle it
has reached at the end of the roll. As well as letting you refilm a demo, ReMaic also allows the insertion of some other scripted actions, such as the printing of new text messages. You can use this features for such things as credits, comments and subtitles. There are three main ways to print text in a Quake demo, plus a special feature to enable subtitles that can be switched on or off as the user desires.
These screenplay instructions (and some others also, such as the
sound
instruction) take string arguments. String arguments
are written as text between some double-quotes, e.g.
"This is an example string"
. There are a few simple
things you should know about strings in ReMaic:
\n
. E.g.
"This string would be written\non two lines"
\"
. E.g.
"In this string, \"this phrase\" is in quotes."
`
where you might normally
expect to use a forwardquote '
to avoid this
problem with apostrophes in console print
ed messages.
text print
The screenplay instruction text print
takes a string
argument and displays it at the top of the screen and in the console.
con_notifytime
seconds
after it was printed.
demtool -m
.
text centerprint
The screenplay instruction text centerprint
takes a string
argument and displays it centred horizontally and vertically in the
middle of the screen.
scr_centertime
seconds after it was printed.
demtool -c
.
vid_mode
s. Using no more than eighteen newlines
in any string should ensure you avoid any problems.
centerprint
, not centreprint
!
text finale
Finale texts are used during the "major" Quake intermissions. The
"Congratulations" LMP
bar is shown at the top of the screen,
and the finale text is gradually printed on the screen. You can write
your own finale messages with the ReMaic screenplay
instruction text finale
.
scr_printspeed
variable and you
are advised to increase it from its default value of 8 since this
is tediously slow.
text finale ""
finale into the screenplay
just after the one you want to remove starts to print. Or set
scr_printspeed
to 0...
text
centerprint
is also relevant here.
The same limitation on the number of lines it
is safe to display without causing a crash also applies.
text
instruction could be used in this way!
subtitle
This is a combination of special screenplay syntax and macro
definitions to enable the implementation of switchable subtitles in a
Quake demo. If you use it, you should set the alias
print_subtitle
to determine whether or not texts produced
by the subtitle
instruction will be displayed during
demo playback. Setting alias print_subtitle subtitle
will
cause the texts to be printed. Setting it to some other "null" value,
e.g. alias print_subtitle echo
, will cause them to be
suppressed. If you don't set print_subtitle
at all, Quake
will complain about the undefined alias when you run a demo that has
had ReMaic subtitles added to it.
echo
command, so the same provisos apply
for them as for text print
instructions.
Z_Malloc
crash if you use a
very large number of subtitles and do not increase your
-zone
setting in early versions of Quake.
subtitle "example"
is syntactic sugar for
text stufftext "alias subtitle echo
\"example\";\nprint_subtitle\n"
.
Earlier versions of ReMaic had no support for the addition
of precached sound effects and music, although a very primitive hack
along the lines of text stufftext "play example/sound\n"
could be used if you were really desperate. V4 offers proper support,
although using sounds in Quake to their full capacity requires a little
knowledge on the part of the user as to how the Quake sound-engine works.
Every sound effect in Quake is a mono, 8 bit, 11KHz WAV sample. Looping samples are allowed, so you can make use of this for repetitive music samples. Quake will handle some better quality formats of sample, but it will convert them to the above format before playing them, so please don't waste our memory and download time by using these more advanced formats for your sounds. The Quake format does not give good quality, and so you'll need to do some careful production work on your samples to make them sound nice at this sample-rate. However, it can be done; check the original id sounds, or Tony Oetzmann's work on the vocals in Scourge done Slick.
Quake has only eight channels on which to play sounds, and it can be difficult to predict which sounds will take priority. So when adding sounds to an existing noisy demo, be prepared to muck around a bit with channels and sourcing.
Every sound effect is sourced at a particular position in the Quake world. A sound is played quieter the further the camera is away from its source; however this can be overridden by playing with attenuation properties. The stereo balance for the sound is also determined by the position of its source relative to the camera; this is unfortunately the case even for non-attenuated sounds.
Each sound is also tied to a particular Quake entity. Each entity potentially has eight independent sound channels on which the sound can be played, although eventually all entities share the same eight Quake engine sound channel resources. Most of the time you'll want to allow Quake to select the channel a sound is played on itself.
Although the entity acting as the original source for a sound may move once the sound has started, the sound source position will not move with it. Therefore if you play a long sample, and either the camera or the entity supposedly making the sound move whilst the sample plays, you will get some unwanted "drift" effects. You can partially solve these problems through making a good choice of source entity, and maybe setting some special attenuation values.
Quake allows several kinds of attenuation to be specified for sound effects:
ATTN_NONE
. Sounds with this special attenuation
do not get quieter as they get further from the camera. Useful
especially for "background music" samples.
ATTN_NORM
. The default. Sound volume decreases
very gradually with distance.
ATTN_IDLE
. Used for e.g. idling monsters.
A quicker decrease in sound volume with distance than
ATTN_NORM
. Good for inducing distance-implemented
fades on looping samples.
ATTN_STATIC
. Used for spawnstatic
ambient sound effects. Sounds with this attenuation can only be
heard quite close to their source.
Sounds can also be scaled down in volume, from the original default volume multiplier of 1 down towards 0. However, there's no way to increase the volume of a sound, so you are advised to record them as loud as possible without introducing distortion and then scale them downwards.
sound
This is the ReMaic screenplay instruction for inserting a sound message into a demo. It has the following syntax:
sound entity "file" fx*
entity
is the entity that should be
used to source the sound. The position that this entity has at
the time the sound starts playing is the one that will be used.
e
n, and p
is an abbreviation for entity 1, the player.
file
is the name of the sound effect.
sound/file.wav
in all the standard
game directories. For example, "misc/talk"
is the
name of the standard chat noise.
play
command. If
play file
works from the Quake console,
then sound "file"
should work in a
ReMaic screenplay.
fx
modifiers are optional; none or
any combination of them can be used. They each consist of a
single letter followed immediately by a numerical value, e.g.
sound e5 "example/sound" a0 c4 v0.7
a
n, where n = 0, 1, 2 or 3.
By default, ReMaic sets sounds
to have an attenuation of 1 (ATTN_NORM
), unless
no entity was specified for the source, in which case the sound
is sourced on the camera with attenuation 0 (ATTN_NONE
.)
Possible attenuations were explained in section 3.6.1.
c
n, for n = 1 .. 7.
Most of the time you can omit this and let Quake select an
appropriate channel.
misc/null
empty sound using the same source and
channel. This can be useful for terminating looping samples.
v
n, for n between 0 and 1.
This simply scales the volume of the sound by the specified
amount.
Something that movies tend to need but that I never got around to implementing before in ReMaic is shifts of the colour palette. So I figured I'd better implement some functionality to do this before this final release.
Be warned: palette fades do not work under GLQuake, and so you
should try to ensure that your movie doesn't rely too heavily on a fade,
or GL viewers are going to be very confused. (The same goes for
fov
effects, by the way.)
Quake has a console variable v_cshift
which store a
"palette shift" that can alter or even override the colours in which
the engine renders things. The shift is made up of four values, each
between 0 and 255. The first three represent the red, green and blue
colour axes, and the last represents the degree of the shift. Zero
means the shift will have no effect, whilst 255 means it will dominate
completely (so that every pixel will be displayed as the RGB colour
the other three values specify.) Colours can be changed gradually
between these two limits (the normal colour and the one specified by
the RGB fields) by using values between 0 and 255 for the degree of the
shift.
ReMaic lets you specify new values for the palette shift, or fade gradually between the current value and a new one. Palette values are given as four space-separated values for red, green, blue and degree of shift. You can also omit the three values for red, green and blue, and just give that for the degree of the shift: in this case the RGB values default to "0 0 0".
palette
This instruction sets the palette shift to the value specified.
0
(which is short for 0 0 0 0
)
is the normal unshifted rendering. A value of 255
(which is short for 0 0 0 255
) blacks out the screen
entirely.
palette 0
instruction
at the start of your demo by default to get rid of any previously
existing effects (e.g. from fade-outs on whatever played before.)
But you can immediately override this palette value with something
different if you need to.
fade
This instruction tells ReMaic to start smoothly changing the palette value in order to end up with the newly specified value.
move
,
pan
, turn
and roll
) do.
The palette starts at whatever value it currently has and
reaches the specified value just in time for the next
palette instruction.
end fade
instruction
in just the way you might expect.
There are two other instructions that you can use in a ReMaic screenplay.
eyes
The instruction eyes
sets the perspective used in the
reshot movie to be the same as that in the original demo. The camera
and target will continue to be updated, but they will not be used
until the next instruction that controls the camera position.
On a normally recorded demo, this will return the view to the usual first-person perspective, with the weapon reappearing in front of you and the "jogging" up and down effect that you are used to.
You should probably move the camera in to catch up with the player
using an instruction like move p~0.05
before using an
eyes
instruction so that the cut between the two
perspectives is fairly smooth.
text stufftext
This screenplay instruction takes a string, as do the other text
commands, and sends it to the console to be run there as a command.
So, for example,
text stufftext "bf\n"
would cause the familiar brief flash effect to occur.
text stufftext "viewsize 120\n"
Note that there may be arguments for letting viewers choose their
own parameters in some cases though, especially in case they are
running on a low-end machine.
text stufftext
to change include:
crosshair
con_notifytime
, scr_centertime
and scr_printspeed
, for controlling how your
printed texts are displayed.
fov
(but remember this will not work in GL!)
ReMaic can be called with optional command line switches that precede its regular filename arguments. Their uses are explained at the end of this section.
Apart from the optional switches, ReMaic can be called with up to three filename arguments. It needs an original demo as input, a file to use as a screenplay, and a name for the output, which will be made by reshooting the original demo using the screenplay. It tries to use sensible defaults if it is not given all three arguments. If you do not provide extensions in the filenames you give (and generally you should not bother), it again tries to use sensible defaults.
ReMaic works with demos in *.ls
format - these are text
listings that are produced by LMPC as a result of decompiling the
binary *.dem
file format that Quake uses. ReMaic first
looks for an *.ls
file that matches the input you give
it. If it doesn't find one, it looks for a *.dem
file and
calls LMPC to decompile it. Once it has produced an output file, also
in the *.ls
format, it calls LMPC to recompile this file
into a binary *.dem
. Finally on the extensions front,
screenplay files have the extension *.cam
by default.
Calling ReMaic with no arguments gives some immediate help on the syntax needed to invoke the program and the syntax used in screenplay files.
Calling ReMaic with one argument:
ReMaic input
means it will try to use input.cam
as a screenplay file,
converting an original demo input.ls
to produce a reshot
demo out.ls
which LMPC compiles to make
out.dem
.
Calling ReMaic with two arguments:
ReMaic input camera
means it will try to use camera.cam
as a screenplay file,
converting the original demo input.ls
to produce a reshot
demo camera.ls
which LMPC compiles to make
camera.dem
.
Calling ReMaic with three arguments does what you expect it to:
ReMaic input camera output
means it will try to use camera.cam
as a screenplay file,
converting the original demo input.ls
to produce a reshot
demo output.ls
which LMPC compiles to make
output.dem
.
Switches are given by preceding a single character with either
/
or -
. There are three switches recommended
for use with ReMaic.
/D
switch instructs ReMaic to
use DemTool rather than
LMPC to decompile a demo into an *.ls
file.
This is a good switch to use if you can, since DemTool
works faster than LMPC. You'll still need LMPC for the recompilation,
though.
/I
switch instructs ReMaic to
ignore intermissions. Intermissions have strange effects on the
camera view (see section 6) and normally ReMaic
will switch back to the standard intermission view when it
detects one. This switch overrides this. (In v3 the default
behaviour was the other way around.)
/L
switch instructs ReMaic to write
a log file, ReMaic.log
, which details how it
processed your screenplay and demo. If you are brave enough,
this can be useful in tracking down problems with your screenplay,
or submitting bug reports about ReMaic itself
(although, of course, ReMaic is supposed to be
bug-free by now...)
Four other switches remain from previous versions of ReMaic, but their uses are all deprecated. (This means you are advised not to use them, and do something else instead, since the author thinks it will work better; in all cases, using DemTool instead is recommended. But if you are used to using the switches, and want to continue, they should still function OK.)
/b
switch adds some special effects that make
the player bleed according to how much health they have. (You
are now advised to use demtool -b
instead; it does
this better and faster.)
/c
switch removes all the centerprinted messages
that are in the input demo so that your own
text centerprint
s aren't overwritten. (You
are now advised to use demtool -c
instead.)
/d
switch removes the damage messages from a
demo; these cause the screen to redden when the player is
damaged and may not be appropriate for a recammed demo. (You
are now advised to use demtool --damage
instead,
and also try -j
for removal of the view kicks.)
/t
switch centerprints the time on each frame
so that you can measure the passing of time in a demo more
accurately than you can using Quake's own clock, which only
shows whole seconds. This can be useful for working out the
precise timings of screenplay instructions. (You are now
advised to use demtool -t
instead though.)
Two old switches are now irrelevant since the behaviour of ReMaic has been changed to no longer require them.
/i
switch
is now the default, and instead you must
use /I
if you want to turn it off.
/n
switch is not needed any more. Some demos need
a dummy block inserted before their first serverinfo
block if they are to playback properly in early versions of Quake,
due to a bug in the way the cdtrack
message is parsed.
This used to confuse ReMaic unless /n
was
used to tell it to ignore the header block; however, it should now copy
all demo blocks that precede serverinfo
unchanged.
The comprehensive description of all the screenplay commands and input options above may well have you feeling a bit lost by now, especially if you've never before used ReMaic in practice. But with any luck, inspecting the example screenplay provided, and running the demo it works on and the movie it produces, will make everything a lot clearer.
The original demo is a recording of Yonatan Donner completing E3M2 (The Vaults Of Zin) in 0:58. (Not quite the outstanding time nowadays that it was back when he made this. Heh, he's probably very embarassed by this old demo now.)
I took a screenplay that he wrote to film this demo, fiddled with it a bit to show more of the possible effects, and added lots of commentary in order to demonstrate how you can combine all the above instructions to make a nice screenplay that produces a great movie.
The original movie is named original.dem
, the camera file
is named example.cam
and the reshot movie is
example.dem
. You could produce the reshot movie from the
original by calling the program as follows:
ReMaic original example
When Quake records a demo, it does not record every event that happens anywhere in the level. The events it records are those that are visible from the VISibility leaf in which the player doing the recording can be found. It can be difficult to know for sure precisely what this will include and what it will leave out. However, a good approximation is that it includes anything that the player could see by looking in any direction from their current position, and also to some extent round the corners of any openings that are visible.
If you move the camera too far away from the viewpoint of the original demo when you use ReMaic, especially if you go around corners so that you can longer see the player who made the recording, then you may see entities appearing from and disappearing into thin air as they move into and out of the recording player's VISibility leaf, causing their positions to start or stop being recorded in the original demo.
This doesn't happen very often, because normally you will want to film the same events that were seen in the original demo! But it is something of which you should be aware. If you notice the problem occuring, the obvious solution is to change the camera view so that the entity that is affected is no longer in the picture. If you are feeling more ambitious, then you can use Demix to mix in the missing entities. (This is easy for static entities, but next to impossible for dynamic ones, as you don't know how they moved whilst they were not recorded.)
If you are filming an existing normal demo (rather than a specially created movie) with ReMaic, then it may contain an intermission. The Quake engine behaves a little strangely during an intermission - it always displays the picture from the angle that is used by the standard intermission viewpoint, no matter what the demo is instructing it to do.
For this reason, it is normally a good idea to switch back to the
normal demo view with the eyes
command when the
intermission starts.
/I
switch to override this.
If you do this, you will still be able to move the camera around during the
intermission - it's just that whatever you tell ReMaic to point
it at, Quake will always use the angle used in the original demo when it
plays back. Good luck.
The camera is inserted into the demo as entity 449, since I believe that this was the last available dynamic entity in early versions of the game. However, it is plausible that some demo might want to use this entity for something else, especially since later versions of Quake can use even higher-numbered entities.
If this does occur, and ReMaic overwrites some important
entity with the camera, and you want to fix the problem yourself,
it should be very easy: just find an unused entity number and modify
the Perl script ReMaic.bat
so that the constant
$CAMERA
is set to be this other number, rather than
449. This initialisation occurs very near the top of the script.
ReMaic was written by Anthony Bailey, and I guess that means it's his copyright 1997/98 and so forth. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.