Skip to main content

                        THE ST NEWS MENU
          A TALE OF GFA PROGRAMMING AND LITTLE HAMSTERS

                       by Stefan Posthuma

 The  world must be a wonderful place for a 10-day  old  hamster.
Full of wonderful smells,  incredible food and endless  stretches
of enormous cage to explore.
 About four weeks ago,  I caught my two hamsters in the act so to
speak,  I hurried to separate the two sinners but time told me  I
was  too late.  The little black hamster (Nephilim is  her  name)
swelled  to about twice her size and one dark night I  came  home
and heard some infinately tiny noise coming from the little house
Nephilim lives in.  So I lured the hamster from her house with  a
piece of apple and peeked inside.
 There they were,  seven little pink creatures, squirming around,
making tiny noises as they called for the sweet nipples of  mama.
I quickly replaced the lid of the little house and a very worried
mother  returned and lay herself down for her siblings to  suckle
once more.

 That night I also sat down at my ST and got an idea. Actually it
was  something  that lingered in my mind for a long  time  and  I
finally  decided  to do something about it after  receiving  some
Email (my address:  stefan@spc.nl) from Lord Hackbear telling  me
how  easy  it  was to hack the hidden articles  in  the  previous
issues of ST NEWS.
 I  wanted  to write my own drop-down menus in  GfA.  This  would
solve a few problems,  first of all I wouldn't be plagued by  the
bug in TOS 1.0 that causes GEM to crash when a menu is too large.
Also,  I wanted to do cascading menus (when you highligh an  item
in  a dropdown,  another menu pops up besides it (I always  found
this  a shortcoming in GEM).  This would elmiminate the need  for
the silly submenus (remember 'Non computer stuff' and 'DeltaForce
ICCC#2'  in 6.2).  And last but not least,  it would enhance  the
control  I had over the menus,  allowing a lot more nice ways  of
getting to hidden articles.
 But before I started programming,  I did some serious  thinking,
how exactly would I go about writing something like this?

 Meanwhile,  the  baby  hamsters grew and  grew,  and  soon  they
started to get hair on their little bodies and I was able to  see
what kind of color they would become.  Now I was very curious for
the mother is pitch black (brought with me from the  Respectables
Pet  Store in Trier,  Germany) and the father (Natanga,  the  big
dopey hamster) is a traditional white-and-gold hamster.
 It  turned out to be hamsters all shades from black  to  golden,
some  of  them grey with streaks of white and others  dark  brown
with  white and golden patches.  Every night when I came  home  I
checked on them,  careful not to touch them for the strange smell
would surely excite mother too much.  In fact, when a hamster has
young and it is disturbed too much,  it will eat them in despair.
Pretty cruel huh?

 The next weekend I sat down again and did it.  But before I  did
the  programming,  I  first decided how I would  handle  multiple
resolutions,  for  ST NEWS has to work both in Monochrome  as  in
Medium Res.
 The solution I came up with is quite nifty and will work on  all
resolutions, and all screen sizes.
 What I did is,  I based my screen coordinate handlers totally on
the  size  of  the used font.  One of the first things  I  do  in
ST NEWS is checking Xbios(4) and setting some variables first:

 fw%      width of the font in pixels (8 in all ST resolutions)
 fh%      heigth of the font in pixels (8 in low/med, 16 in high)
 fc%      correction value (1 in low/med, 2 in high)
 font%    font number for GEM (DEFTEXT ,,,font%)
 sw%      width of screen in pixels
 sh%      heigth of screen in pixels

 All  of these are clear I suppose except the  correction  value.
This one is used to get the y coordinate to put text. If I draw a
box  at 100,100 and I want a line of text directly below the  top
of it, the y coordinate of the font will be 100+fh%-fc%.
 I set these variables in a SELECT Xbios(4) statement,  but  real
programmers  probably retrieve them from the Line  A  information
tables.
 So  if I want to draw a box that has to contain 3 lines of  text
and that must be 20 characters wide, the statement will be:

 BOX x%,y%,x%+fw%*20,y%+fh%*3

 You  probably want to adjust these values with two or  something
to  make sure the edges of the box don't touch the text and  make
it  look not too splendid.  If you program  carefully,  and  make
sure  you  consequently  use this method,  it will  work  on  all
resolutions.  I entirely wrote the menu routines in high res, and
it worked in medium as well as in low without modifying a  single
byte.

 After about 10 days, the little ones are big enough to walk, and
you  should see the little adorable creatures try and find  their
way around the cage.  Their eyes are still shut,  so they have to
navigate by touch and smell.  I can sit there for hours and watch
one of the tiny hamsters try and pick up a peanut the size of its
head.  It will take it in its little mouth and try to walk,  sway
dangerously  and finally fall over,  little legs  sprawling,  but
still  holding on to the peanut as its life depends  on  it.  Now
Nephilim has created a little food supply just outside the  house
and sometimes the entire family comes out to eat. I was surprised
to  see these small hamsters already put things in their  pouches
and  try to wash themselves (This requires sitting on their  hind
legs,  something  they  haven't mastered yet and they  fall  over
quite comically).  Also, you should see the feasts they have over
an apple core or a sweetcorn that I have partially eaten.
 After a while, mother decides that they've had enough and starts
carrying her children to the house one by one. You can almost see
the frustration on her face when she brings one to the house, and
turns  around to get another one,  it is already crawling out  of
the house again, ready for more adventures.

 So  I resolved the resoltion program,  on with the  actual  menu
programming.  Now  I feared that one of the drawbacks of the  new
system would be the speed.  If the program had to draw the  menus
every time they would be selected, it would be way too slow. So I
decided I would GET a menu after it was drawn the first time, and
the  next  time it was selected,  I would simply PUT  it  on  the
screen,  and  with a blitter or a fast screen  handler  installed
this  would be nice and fast.  Drawback of this is that it  costs
memory,  so the program first checks to see that there is  enough
memory free. (about 32K should be enough)
 Then  there is the issue of reading the menu items.  How do  you
make it so that you can specify the entries to be put in the menu
in  an easy way?  Well,  in Basic we use the DATA  statements  of
course,  with  menu items and some kind of identifiers  following
them to tell us what kind of item we are dealing with.
 But we also need to know exactly which item was selected,  so we
need  a  number that is returned by the menu  routine.  But  then
again,  a  special  item like a title or a  separator  cannot  be
selected,  so why not combine the two into one number? Great. Now
I think it is safe to assume that nobody is insane enough to make
a menu with more that 1,000 items so numbers >= 1000 are  special
controllers indicating special items. An example:

DATA Menu 1, 1000
DATA Item 1, 1
DATA Item 2, 2
DATA - NICE -,1003
DATA Submenu,-1
DATA Another item,3

DATA Menu 2,1000
DATA Yeah,4

DATA Submenu,1003
DATA It's not easy,5
DATA To think of,6
DATA Random menu items,7

DATA END,1002

 This  would create a menu with two dropdowns,  labeled "Menu  1"
and  "Menu  2" (original huh?).  "Menu 1" would  have  a  submenu
(cascading),  specified at the end. The number following the item
has three functions, depending on the value:

x < 0       :  call cacading menu -x
0 < x < 999 :  normal item, returns x when selected
> 999       :  1000 = dropdown title
               1001 = non-selectable item (separator)
               1002 = end of menu specification
               1003 = submenu (cascade) following

 The  only  tricky thing about this is  the  cascading  menus.  I
needed  a way to refer to them in an easy  way,  without  special
names or something.  So I number them in order of appearance, and
use that number (negative that is) to call them.  So if there was
another submenu following the one above,  it would be called with
'-2'  as number behind the calling item.  This also implies  that
submenus  can be called from within submenus.  Pretty  neat,  but
quite nasty to program, we come to that later.

 Time prevents me from finishing this article so we have to  call
this  part  I and we shall see about part II,  most  probably  in
ST NEWS 7.2...
 You  can find the complete source in the  PROGRAMS  folder.  GfA
Basic .LST file that is.

Disclaimer
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.