217
fff00000ff00fe008033307f001
^4|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|

                     ^2{5FANATIX FANATICS READ ON!!{

                         ^1[5By JAG of FANATIX.[0

^4|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|

^1 Well, well, well...

^2  We received a letter a while ago from Len and Anne Tucker asking us
^2to do an article on how to put a demo together.  It was no easy task,
^2but here is our attempt...
  
^5  Once  you  have got your Amiga ready, and bought a copy of AMOS (an
^5original copy), you are ready to begin.

^7  First,  you  need  an idea of what you want to happen in the demo -
^7what  effects  you  want  to  incorporate etc.  If you don't have any
^7ideas, then there are 3 things to try.

^1  1.  Look through any assembly demos you have.  See if there are any
^1effects or ideas you like that could be emulated by AMOS in some way.
^1Look  carefully,  seemingly  difficult  effects  can be achieved very
^1simply if you think about it!

^2  2.   This  is  a favourite of mine.  Load up DPaint, and mess about
^2with  it  for  a while.  This is how I got the idea for the spotlight
^2effect in our Blue demo from Megademo 5 (hype, plug).

^5  3.   Look  through  your  program  disks  to  see  if  you have any
^5interesting  routines  that  haven't  been  used  yet.   They  can be
^5sellotaped together to make good demos.

^7  Right,  now  you  have your ideas, so it is time to work out how to
^7put them into AMOS (if necessary).  Take time, there is usually a way
^7round  things.   Stars,  for  example, can be done in a few different
^7ways:

^1  -  Plot  them  on a double buffered screen.  Blank the image at the
^1back,  redraw  it,  then  switch the screens.  This will avoid people
^1seeing  the  stars  being  erased  and  updated.  Unfortunately, this
^1method is messy and slow anyway!

^2  -  Bobs.  This is a bad idea too if you want smooth stars.  Use too
^2many  and  they will begin to jerk.  But if you slow down the updates
^2(UPDATE EVERY n), they will judder.  Not so good.

^5  -  Sprites.   These  are  a  good  idea  if  you want a multi level
^5parallax  starfield that doesn't require double buffering and doesn't
^5interfere  with  the  screen  it  is  on.   Try  to move them totally
^5independantly  with AMAL, and remember to use the SYNCHRO commands if
^5you  use  more than 16.  Also, remember the restrictions of width and
^5heights  imposed  by  sprites.  If you get this wrong, processor time
^5will be wasted on sprites that won't appear properly, if at all!

^7  -  Colour  cycling.   Very  useful  because  they  use  hardly  any
^7processor  time  at  all.   Unfortunately,  they  tie  up many colour
^7registers, and too few colours can mean a starfield that looks like a
^7plot pattern, or goes too fast!  You should draw them with DPaint, or
^7write a routine to do it from AMOS.  On the other hand, you could get
^7hold  of the Fanatix Starfield Maker V1.0 when it is finished (before
^7Christmas I hope).

^1    To get the idea of how colour cycled stars work, draw a line with
^1a  pixel of each colour in the palette, and change all but one of the
^1colours to black.  Now cycle the screen.

^2  Once  you  have  worked out how the effects will be done, write the
^2seperate routines to run them.  This can be tricky, but should not be
^2too  taxing  if you have thought out the problems properly.  Make the
^2routines as either procedures, or bits you can GOSUB to.

^5  So,  now  you  have  the  seperate routines for the effects in your
^5demo, and it is time to put them together.

^7  The  best  thing  to  do is to try and create a basic version of an
^7interrupt  system for your routines.  Put them after the main loop as
^7the  procedures, or the GOSUB loops.  Take all the WAIT VBL's you may
^7have used out of the routines and do your main loop.  Then put 1 WAIT
^7VBL  at  the  end  of your main loop, remembering that colour cycling
^7should  start  before the loop is reached.  Here is an example of all
^7this for a demo with a scrolling message and some VU bars:


^6  Shift Up 1,1,31,1                     - Start colour cycling if used
^6  Do
^6    Gosub VUS
^6    Gosub MESSAGE
^6    Wait Vbl                            - This should be the ONLY one!
^6    If Mouse Key=1 Then Goto DIE        - Check for mouse click to end      Loop                                     demo.

^6  VUS:
^6  ...........                           - Put the VU bar routine here. 
^6  ...........
^6  ...........
^6 Return  

^6  MESSAGE:
^6  ...........                            - Put the message scrolling    
^6  ...........                             routine here.      
^6  ...........
^6  Return

^6  DIE:
^6  ...........                           - Close down demo, fade music                                                etc....

  
^1  Yes,  I  know  it  is bad programming practice to use GOSUBs rather
^1than  Procedures,  but I prefer to have global variables as standard,
^1it  can  also  save  you  from a full variable buffer.  Sure, you can
^1increase the size, but that leaves you with less memory, and if there
^1is a problem with the program, it could keep filling up regardless!!

^2  And now for some hints and tips for putting your demos together.

^5  -  Always  use  a  smaller  amount of colours if some are not being
^5used.   A  16  colour  screen is updated faster than a 32 colour one!
^5N.B.   This  does  not  really matter if the screen concerned is only
^5used for colour cycling of static GFX etc.

^7  -  Instead  of storing fonts on a seperate screen behind the others
^7and  using  SCREEN  COPY (as in the Sentinel scrollcode supplied with
^7AMOS),  cut out the font beforehand, and store the individual letters
^7in  a  sprite bank, according to their ASCII values.  E.g.  Store the
^7letter A as image 65.  You can then use the following line to get the
^7right number for a character from your scroll string.  E.g.--

^2                         B=Asc(Mid$(T$,CH,1))

^1  Where  T$  contains your message, CH is the position in the string,
^1and  B  will  be the number of the sprite image you require.  You can
^1then use Paste Bob x,y,B to place the letter.

^2  -  Always  remember  to  specify  which  screen the routine you are
^2running  refers  to.  On a SCROLL based routine, if you forget to set
^2the  current  screen  to the right one, strange things can, and will,
^2happen.   When  I  used to use the SCROLL method for moving messages,
^2the  logo  once  went  zooming along the screen at Mach 3, only to be
^2replaced by corrupt letters using the wrong palette!!!

^5  -  Try  to  optimise  your  routines as far as possible.  Take, for
^5example,  this routine to move a number between 0 and 360 at any step
^5size:

^7                  Add X,XI : If X>360 Then Add X,-360

^1  This  is  much faster than using If - Then statements a lot, and is
^1much  more accurate if you want to get Sine values.  Degrees run from
^11 - 360, and if the routine uses the wrong number after reaching 360,
^1you may get a jerk in movement!!  Don't worry if you don't understand
^1all this.

^2  - Which reminds me, remember to specify Degrees if you are going to
^2use Sine functions etc.  AMOS uses Radians (avoid!!) as default.

^5  -  If  you are intending to use any trigonometry functions, to save
^5disk swapping later on, type in:

                               ^7A=Sin (40) 

^1  The  number  is not important, but the line will cause AMOS to load
^1in the maths libraries.

^2  - When you are using a Dual Playfield, before using the command use
^2a  Wait  Vbl, or the display may get corrupted.  Also, use the Screen
^2Display  command  if  needed BEFORE you DUAL PLAYFIELD, or again, you
^2will  get  a  corrupted  display!  Which leads me to the worst of the
^2Dual  Playfield problems:  THE 16 PIXEL JERK as I like to call it.  I
^2don't  know  if  this will happen to other people, but it plagues me.
^2If you are using SCREEN OFFSET on a Dual Playfield screen, at certain
^2values  the  the playfield you are not moving jerks 16 pixels across,
^2and  back  again when you go to another value.  Mess around a bit and
^2you  can  identify  the problem values and avoid them.  Luckily, they
^2are at even intervals (16, or 12 I think), so you can plan ahead, and
^2use step increases of the offset to avoid them.

^5  Using  even numbers to increase when you start from 1 is the way to
^5avoid the jerk.

^7  Right  now,  you should have enough help to get started with decent
^7demos now, so I hope to see more demo groups appearing in the future,
^7and I hope this article was of some use to you!!


                                             ^3JAG from FANATIX in 1991.

^4  P.S. Feel free to contact us at:

^4           Fanatix
^4            29 Cambridge Road
^4             Huntingdon
^4              Cambs
^4               PE18 8BT. 

^4   Or  you  can phone (0480) 411568, but there is no guarantee that I
^4won't  just  put  the  phone  straight back on the hook.  I am a busy
^4person  at  the moment!  You could phone Chaos, but he would probably
^4just laugh at you...

^4 And  I don't feel like giving his phone number away.  He is only the
^4GFX'er anyway!
   
^1  P.P.S.   Buy  our  demos,  Megademo  6 should be released sooner or
^1later, and you will be able to identify some of the techniques I have
^1revealed here.

^2  P.P.P.S.   Greets so Cybornetics, The Beholder, Sandra Sharkey, Len
^2and  Anne  Tucker,  Francois  Lionet  (Please fix the Dual Playfield)
^2etc...

^6  P.P.P.P.S.   We  are  looking for a GOOD musician, if you think you
^6fit  the  bill, and would like to join us, then send some examples of
^6your work to the above address...

^4|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
\