Are you fed up with other members of your crew? Are you bored
with musicians delivering music that exceeds the available CPU
time and cause you to recode your FX again and again with each
new version of the zik? Are you thinking about hiring a killer
to get rid of your chief graphics artist because he always uses
one colour or one pixel too much or perhaps even to less? Is
your chief designer driving you crazy with his extravagant ideas
and wishes? Then it's time to fight back, don't let them ruin
your work or even your day. Make them suffer... How, well I am
about to tell you...
Imagine you have just finished your screen and it runs nicely
just below the 50 Hz border, you have also left a bit of cpu for
the not yet finished tune and then the worst possible thing
happens. Your composer delivers you another one of those 200 Hz
tunes. ARGHHH! What can you do to strike back? One idea would be
to replay the tune with just 50 Hz, which is hardly noticeable
anyway to tone deaf people ;). Keep telling you don't hear any
difference until the composer finally gives up and delivers you
50 Hz tune.
If the tune still consumes too much CPU just kill the timers,
this is either possible inside the tracker or you just mask them
after the main music routine has been called. Make sure to hide
the code in a preassembled incbin, so nothing looks suspicious
if someone dares to review the code. Sometimes it helps to
delete a whole channel from the file; this will teach the
composer to use the remaining channels wisely. To underline the
result you should always use as many timers as possible. For
example set the palette with a TiB even if it is possible within
If you get caught disabling the timers be a bit more cautious
and try to disable the timers only after each vbl it consumes
too much CPU. You can compensate that with additional screen-
buffers to average the VBLs. In addition it's important that you
never wait for the VBL to occur but start rendering the next
You asked your pixel-butcher to stick to a specific size for a
sprite or logo and he just exceeds this size and all your
prepared routines need to changed and optimized again? No way!
Just cut off the parts you don't need. If your pixel pusher
complains, just resize the graphics but make sure to use the
worst possible method for it so graphical artefacts will be
guaranteed. Never use a proper tool for that, because otherwise
your colour mangler might not notice the difference and will not
learn from it.
If your pixel-man or -woman uses too many colours, just reduce
the colours, most gfx programs have special functions to remap
the palette, missing colours will be assigned to the closest
matching colour. The result will cause a big hello when you show
your latest preview, that's for sure.
If possible use multiple tools, especially converting the
picture to a PC format and back helps to mess it up in non
explainable ways. Again if the artist complains tell him you
can't see any difference.
Your so called chief designer comes up with impossible ideas and
always wants you to implement the most complicated effects, even
if nobody will ever see the difference to a simple fake FX.
Don't give up yet, just give him the task to do the research on
the mathematical background to give you more precise information
about the desired effect. Claim you can't understand what he
means until he delivers you a mathematical formula. If he
delivers a formula, claim that it doesn't work and use all kinds
of acronyms and mathematical laws you remember from school to
make your point more believable.
If you don't like the colours your designer wants to use, use
hidden (perhaps preassembled) routines that automatically reset
the colours to your own choice. Claim it being impossible to
make that change at the current state of development. You might
also demonstrate that changing the palette in the source doesn't
lead to the desired results. Say it's all hard-coded and you
would need at least 6 month to rework the code.
Other members of your crew ask for sources all the time? Well no
problem, give them a lot of sources. Just make sure you include
every publicly available demo source into your main program and
don't forget to load all kinds of libraries. Besides that make
sure to use cryptic filenames like "X879126.S" or "BNJAFGU.S"
never use a name which is easy to understand. The same belongs
for your variable- and constant-names. If possible also use DC.W
to enter your code directly in HEX this will scare off most
musicians and pixel pushers and even more certainly your
To cover your tracks also make sure you use macros and includes
as much if possible. Also hide your macro definitions in
includes and make sure you use multiple levels of includes which
might finally lead to preassembled incbins that contain
encrypted self-decrypting code. This way you make sure nobody
understands your source or tries to change it.
Last not least always forget a few important files. If someone
asks for them tell him you cannot find that file anymore...
dCoda / Atari Bombsquad for Alive, 2005-12-15