eca00000ff23fe0080666001f70
^7"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"

^6           A   T R I P   D O W N   M E M O R Y   L A N E .

^7"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"

^5 In  the  last  issue  of  TA we took a look at the ways in which you
^5could  improve  the  presentation of your programs.  This time we are
^5going to look at ways of saving memory in your programs.

^6 You  might well be asking "Why bother?  It fits on the disk and runs
^6in 1 meg."

^5 Well,  as  you progress from writing small programs to full games or
^5utility  programs,  the need to save memory becomes apparent.  If you
^5have  more  than  1 meg of memory, then it will be all to easy to get
^5carried away whilst coding and end up with a 1.5meg monster program -
^5it  sounds  impressive,  but  the  vast  majority of users have 1 meg
^5maximum,  so  very few people will be able to run your program, it is
^5for  this  reason  that there are very few Commercial programs on the
^5market  needing  this  sort  of  memory.   The  exception  to this is
^5application  software  which  chews up tremendous amounts of memory -
^5Vista Pro is one example, this needs 3 meg minimum!

^5 With  the  advent  of  the  1  meg  standard  Amiga, resticting your
^5programs  for  1/2 meg users is not so important.  We recently phoned
^5Commodore regarding this, and although there are no official figures,
^5they  estimate that there are more machines of 1 meg and above around
^5now  than  1/2  meg.   This  can  be backed up by the price of memory
^5upgrades which has plummeted from the £90 we paid for an extra 1/2meg
^5in December 1989 to £20 today (and ours didn't even have a clock!)

^5 There  are  times  though  that  a software house will demand that a
^5program will run in 1/2 meg - such as Fun School and the new projects
^5that we are working on for Europress at the moment.

^4 The  following  tips have been learnt during work on these projects,
^4both of which are aimed at a September release.

^2 1. Whenever possible use 16 colours in Lowres.

^4 If  you are used to using 64 colours, then this will seem very, very
^4restrictive!   We  found  the  change  from  32  to  16 colours quite
^4difficult  at  first,  but  now it's easy, as long as you choose your
^4colours  carefully,  you can get some great effects.  It may surprise
^4you  to  know  that  many commercial games are 16 colours, especially
^4`Cutie' style or educational packages - Fun School 4 is an example of
^4this. It will also speed up the running of your program slightly.

^2 2. Use an NTSC screen. ie make your display 200 pixels deep.
 
^4 This saves memory as the program needs to hold 56 lines less graphic
^4data.   It has the added advantage that users in the USA will be able
^4to  use your programs.  It must be rather frustrating for them to buy
^4a  program to find that the controls are hidden.  The Amos PD Library
^4and  TA  have  customers  in  the States.  Apparently, there is a PAL
^4Fixer program available in America, but why make it more difficult to
^4use your program?

^2 3. Set the Sprite Buffer to 18.
 
^4 This can be used if you are not using sprites or your biggest sprite
^4is  no  deeper  than  16  pixels.  You will notice that the AMOS logo
^4disappears  from  the editor screen when you do this, this is because
^4it is bigger than the limits set.  This tip saves 10k in the run-time
^4of  your  program.   It  doesn't  sound  a  lot out of your available
^4memory, but it could be the difference betwen your program running or
^4crashing.

^2 4. Aligning Bobs for animation.

^4 Rather  than  increase  the  size  of  your  bob  when  aligning for
^4animation, try and move the hot spot of the bob instead.  This is not
^4always possible, but when you can do it, it saves lots of memory.

^25. Using Mask.

^4  If  you  have a bob that is a multile of 16 pixels wide, and is a
^4solid rectangle (ie No gaps) then you will not need to use a mask.

^26. Opening Screens.

^4  When  you open a screen, don't close it again.  It is more memory
^4efficient to keep it open, clear it and use it again.

^27. Packed Pics.

^4 It is better to pack your screens using the Spack command rather
^4than using IFF screens.

^28. Squash bobs.
 
^4 If you have a large amount of bob images which are not all displayed
^4at the same time, then you can Squash them and just pull out the ones
^4you need at any one time.

^29. Set Buffer.

^4 If you have to use the Set Buffer command, then set it to the amount
^4needed, don't add any for good measure.

^210. Less Bobs.

^4 Try to use as few bobs as possible. Don't use lots of Bob numbers
^4just for the sake of saying `My prog has  hundreds of bobs!' Reuse
^4the bob numbers once they become obsolete.

^211. Amos Config.

^4 When you run the Config program you'll find a section where you can
^4set the number of bobs used. This is somewhere around 60. When you've
^4finished your program, calculate the number of bobs used, add 5 or 10
^4to be sure, alter the setting in the Config program and save the
^4Config program. This is best done just before you compile your
^4program.

^212. Screen Size.

^4 Only open screens to the depth needed. For example, if your display
^4screen is lowres and 150 deep, and your control panel is med res and
^450 pixels deep, then you need only open your display screen to 150
^4pixels and your panel screen to 50 pixels.

^4 Remember though, if you open a screen to for example 150 deep, and
^4you load in or unpack a screen which is deeper, the screen will
^4return to the larger size, this is because both the Load IFF and
^4Unpack commands shut the screen down and open a new one. Take our
^4example display screen - 320 wide, 150 deep, 16 colours. To make sure
^4that it unpacks to 150 deep every time, go into Direct Mode and load
^4in your Iff screen. Then load in load in your display screen to 0 by
^4keying in the following:-

^5Screen Open1,320,150,16,lowres:Curs Off:Flash Off:Cls0
^5Get Palette (0)
^5Screen Copy 0,0,0,320,150 To 1,0,0
^5Spack 1 to 16

^4 Now when you unpack Bank 16, it will always be 150 deep. Remember
^4that if you unpack a screen or load an IFF screen to a screen that
^4was Double Buffered, then you will have to Double Buffer it again as
^4loading and unpacking destroy the Double Buffer in existance.

^213. Screen Copy.

^4 If you have to use Screen Copy at any time in your game/program then
^4do not copy the whole screen unless you have to - just copy the area
^4you have to.

^214. Data

^4 Keep your Data lines to a minimum. If you have hundreds of lines of
^4figures, questions etc, then it is much cheaper memory wise to store
^4it as a bank and peek out the information as needed.

^215. Workbench and Cli Shutdown.

^4 Another good memory saver on runtime is the shutting down of
^4Workbench and Cli. Doing this involves 2 stages.

^4Inside your program use the command

^6 F=Intcall(-78)

^4This turns off Workbench.

^4 Next  stage - on your RUNTIME disk make sure that the RUN command and
^4the ENDCLI command are in the C Directory.  In your Startup sequence,
^4lets assume your game is called Program, this is what you do

^6run > nil: program
^6endcli

^5The spaces are important, so put them in!

^4 This shuts down Cli but will open up Workbench, hence you need the
^4Intcall in your program. This need only be done on your runtime disk.
^4Its well worth doing as it saves 30-40k and makes your program less
^4jerky and faster.

^7"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"

^4 To  end this trip down Memory Lane, here is a little routine which I
^4put  into  my  programs so that I can see how much memory is left, it
^4can also show where the memory is being gobbled up!

^4 Basically  if you press `?' (ie <shift>+?) a screen opens at the top
^4of  the  display which prints out available memory.  Pressing any key
^4gets  rid  of  it.  If you use this when you are running your program
^4you might well be surprised where the memory is being lost.

^4 Put  the  following  in  your  main loop.  If you are using your own
^4inkey variable, then use that, if not, do the following....

^6 K$=Inkey$
^6 If K$="?":Mem:Endif

^4 Now put this in with your Procedures.

^6 Procedure MEM
^6 Screen Open 7,320,30,2,lowes
^6 Print Free + Chipfree + Fast Free
^6 Clear Key
^6 Repeat
^6 K$=Inkey$
^6 Until K$<>""
^6 Screen close 7
^6 End Proc

^4 Remember  to  remove  it from your finished program to save a bit of
^4memory,  but also to avoid a strange response if the `?' character is
^4used in the program by the user.

^7"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"

^4 Please  send in ANY memory savers that you have discovered - it's an
^4area we're very interested in!

^7"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"

\