Conference hydra::amiga_v1

    
    I'm not familar with the RangeRand() function, but I have used 
    rand() in the following manner.  Perhaps RangeRand() is seeded
    using srand() also.  
    
    A macro like this could also be used for ranges, using my scheme.
    #define _RANGE_RAND(L,U) ( _FRAND() * ( (U) - (L) ) + (L) )
    
    Does this help?
    
    Steve
-----------------
#include <stdio.h>
#include <time.h>

#ifndef RAND_MAX
#define RAND_MAX 	2147473647 	/* assuming a 32 bit int, I suppose */
#endif

#define _FRAND() 	((float) rand()/RAND_MAX)   /* 0 < _FRAND() < 1 */
#define COUNT		10

main() 

{
    long     dummy;
    register i;

    srand( time( &dummy ) ); /* Initialize random # generator. Once/program */

    for ( i = 0; i < COUNT; i++ )     	/* Get some random numbers */
        printf( "  %f\n", _FRAND() );
    
}

    Here is a 'do-nothing' program that works fine using VAX C,
    but GURUs my Amiga using Lattice V5.0 (haven't applied my
    upgrade yet).  Any ideas what could be wrong?  It should
    be legal...  (I'll have to debug it later.)
    
/* Just playing... */

#include <stdio.h>

int print0() { printf( "Routine #0 \n" ); return(1); }
int print1() { printf( "Routine #1 \n" ); return(1); }
int print2() { printf( "Routine #2 \n" ); return(1); }
int print3() { printf( "Routine #3 \n" ); return(1); }

/* Table is an array of pointers, to functions returning int */

int (*Table[])() = { print0, print1, print2, print3, NULL };

main()

{    
    extern (*Table[])();
    int status;
    register i;

    for ( i = 0; Table[ i ]; i++ ) 
	printf( "Table[%d] == %d\n", i, Table[ i ] );   /* What's there? */

    for ( i = 0; Table[ i ]; i++ ) 
	status = (*Table[ i ])();   /* Actually call the routines in order */
}

    Although I can't find anything suspicious (or useful :-) ) about
    your program, I would urge you to upgrade to v5.02, since there
    are quite a bunch of bugs in the 5.00 release.
    After I upgraded to 5.02, most of my mysterious misbehaviors vanished.
    
    Regards,
    
    <CB>

    I will soon be getting Aztec C and was wondering if anybody out
    there knows where I can find some C routines that load IFF pictures
    and play digitized sound.
    
    Also,how does C handle sprites???
    
    matt
    

    There is an IFF shared library that has calls that will let you
    display and manage IFF ILBM files.  I don't know if it'll do sound.
    This is an Amiga library, by the way, so Lattice users, Modula-2
    users, and even BASIC users can also partake of it.  It appeared
    on the Usenet several months ago, so you might look on TAPE:: in
    the appropriate directory.  'Scuze me while I multitask and see
    if I can't find a name for you....  Try iff.library.   It's dated
    somewhere around Dec of 1988.
    
    Be aware also that Leo "The Man in the Cape" Schwab is reportedly
    working on a whiz-bang IFF library which sounds like it'll be splendid.
    
    I've never done anything with sprites in C, but I'll bet that you
    call functions in either the Intuition library, the Graphics library
    or both.  Rob Peck's _Programmer's_Guide_to_the_Amiga would be a
    good place to look.
    
    Gary

It's at:

	TAPE::USER1:[AMIGA.FISH.FF173]IFFLIB.ZOO
or
	WJG::AMIGA:IFFLIB.ZOO


Here's the readme file:



		 THE UNIVERSAL IFF LIBRARY FOR THE AMIGA

		BY CHRISTIAN A. WEBER, ZURICH/SWITZERLAND


THIS PROGRAM IS IN THE PUBLIC DOMAIN. IT MAY BE FREELY DISTRUBUTED, COPIED
AND USED FOR COMMERCIAL OR NON-COMMERCIAL PURPOSES.  IT MAY BE DISTRIBUTED
WITH OR WITHOUT THIS DOCUMENTATION FILE.

TO MAINTAIN COMPATIBILITY,  YOU SHOULD NOT MAKE ANY CHANGES ON THE LIBRARY
ITSELF. UPDATES WILL BE RELEASED BY THE AUTHOR.


WHAT IS THE IFF LIBRARY ?
-------------------------

The iff.library is an easy to  use  Amiga  library  which  gives  you  some
powerful routines to deal with IFF files, especially ILBM files (pictures).
It was fully written in Assembler and is  only  2.3 KBytes  long.  The  de-
crunching routines are the fastest I've ever seen.
To use the library, copy it to the 'libs:' directory of your startup-disks.
Since the iff.library is a standard Amiga library,  it can be used from any
programming language such as C, Assembler, Modula-2,  Pascal and many more.

I started writing this library in September 1987, and now it is really bug-
free (I hope) and it can handle any IFF files I know, including DPaint pic-
tures with stencil, HAM and halfbrite pictures, SoundFX intstruments and
many more.

If you have any questions you can leave a message to Christian Weber on
the FAUG BBS. (Writing to Switzerland takes very long and is expensive!)

				Enjoy!

    
    BTW  I've called a few of the routines in this library from
    	 Lattice C and they worked flawlessly for what I was doing
    	 (reading and writing Bitmap structures).  Saved me a lot of
    	 trouble.

    
    	Has anyone got a listing of the routines contained within this
    	wizzy library? As it sounds just what I'm looking for before I	
    	re-invent the other half of my wheel.
    
    	I am modem-less at the moment but if this library is any good
    	I could lay my paws on one for a day or two. 
    
    	Also how do I go about getting an upgrade to my Lattice C V5.0?
    	I keep hearing about others glitches with 5.0 but I haven't
        hit any (not that I'm aware of - Maybe I am just not getting
        the s/w to do very clever things?).
    
    	Regards,                       
    
    	Mark 'Megaflop' Jacob.
                 
    

Try calling Lattice (number is in the manual). Ask for update services.

Did you send in your registration card from 5.0? If so, you would have
gotten the 5.02 update free automatically.



Look in 

	WJG::AMIGA:IFFLIB.DOC

This is the doc file from IFFLIB which appears to list all the routines.


John

    I just updated to V5.02, and would suggest that everyone should
    do it as soon as they are able.  It took care of several 
    'mysterious' problems, that ulimately ended in GURUs for me.
    
    I'm looking forward to development once again.
    
    Steve

    
    Not really a beginner to C, but to C on the Amiga.
    
    Have got Lattice C 5.0 (will upgrade a.s.a.p. having read about
    the unexplained guru visits) and am working on a number of part
    time projects.
    
    My question is, is it possible to produce commercial quality
    slick graphics with C alone? Or will I have to brush the
    dust an cobwebs of my assembler?
                                
    Ooops, I should have said animated graphics in particular,
    not just pretty little HAMs.
    
    Also having played around with intuition, is there a product on
    the market (or PD) to take the "leg work" out of knocking together
    screens/windows/gadgets etc. 
    Something along the lines of an on screen editor pumping out C data
    structures/code ?   
    
    
    Mark.
    

    Re: .11
    
    Yes there is a "legwork" tool, it's called PowerWindows.
    See Note 2613 for more info.
                          
    <CB>

    
    If anyone is interested, I have an unopened copy of Powerwindows
    for sale. I got it a couple of months ago and never opened it.
    
    It costs approx. $60 mailorder. I'll sell it for $50.
    
    Send mail to NAVCOM::ARNOLD or NOVA::ARNOLD
    
    -Jeff
                                

    I do not understand how to link the compiled program. If your program
    uses 6 libraries then do you have to type in the 6 libraries when
    you link it?
    
    matt
    

>    I do not understand how to link the compiled program. If your program
>    uses 6 libraries then do you have to type in the 6 libraries when
>    you link it?
 
Things are made MUCH easier if you use the BLINK WITH <linkfile> type
statement.  Create a file named FOO.LNK (well, named anything you want, but
for the sake of keeping things from getting confusing, it's good to name it
whatever you executable will be called plus the extension ".lnk")
This file should contain the statements you normally type in after the BLINK
command.  For example, to link files FOOFILE1.o and FOOFILE2.o into image FOO,
your FOO.LNK file might look something like this:

	FROM MYLIBS:c.o+mydir:foofile1.o+mydir:foofile2.o
	TO mydir:foo
	LIB MYLIBS:lc.lib MYLIBS:amiga.lib
	BATCH
	
(This is roughly what Lattice C V5.0 puts out for you.  Your actual mileage may
vary.)

Anyway, after you've got this file made, you can link with the command:

	BLINK WITH FOO.LNK

If you're linking a lot, this certainly makes things easier.  Hope this helps.



					John

    I have this program that is suppose to display the numbers 1 to
    100. It looks like this:
    
    #define low 0
    #define hi 1
    main()
    {
    while (low < 100) {;
    low=low+hi;
    printf(low);}
    printf("hi");
    }
    
    When I try to compile the program I get a error that says "lvalue
    needed" on thje line that says "low=low+hi;".
    
    What am I doing wrong?
    
    matt
    

    
>    #define low 0
>    #define hi 1
>    main()
>    {
>    while (low < 100) {;
>    low=low+hi;
>    printf(low);}
>    printf("hi");
>    }
>    
>    When I try to compile the program I get a error that says "lvalue
>    needed" on thje line that says "low=low+hi;".
>    
>    What am I doing wrong?
>    
>    matt

#define only creates a compile time text replacement. It doen NOT create
a variable with storage that you can change. Try this:    

    
    int low=0;
    int hi=1;

    main()
    {

    while (low < 100) {
       low=low+hi;
       printf("low= %d\n",low);
    };

    }

    GREAT!!!It worked!! I still have another problem. How do you link
    a program with libraries using Aztec C. I know that you link a program
    without using C by typing "ln ****.o -lc"
    
    matt
    

Good question!  I use Lattice and have never used Aztec (Though with all
the differnces between the two and the division of PD compiled under BOTH,
it may be worth getting :-)

Anyway, there's probably a switch on the compiler command to automatically
link - that is until you start using math and need other than the standard
libraries (like sin(), cos(), exp() etc).

On Lattice C it's     LC -L xxx.c  or
		      LC -Lm xxx.c

Where L means Link after and Lm means link and include the standard math 
library.

John	

>    I do not understand how to link the compiled program. If your program
>    uses 6 libraries then do you have to type in the 6 libraries when
>    you link it?


I'm not sure how you can be using 6 libraries. If you're thinking of the
libraries like Intuition and Graphics, etc., there's no need to link them-
they're opened at runtime by OpenLibrary (in this way, they behave like
ordinary data files...)

The "typical" link command for Manx is "ln myprog -lc". The "-lc" means to
link in the c.lib library which is located in the CLIB: directory. Use the
"set" command to see what CLIB is "set" to. If you want to change it, use
"set CLIB: {some new directory}". The c.lib is for integer math. If you use
floating point, then link with m.lib. There are other libraries for extended
precision, but I don't remember off the top of my head. The "-l" parameter
can be repeated, e.g., "ln myprog -lc -lm" would link both the c.lib and m.lib
routines, but if a routine ("printf", for example) is in BOTH libraries, then
the one in c.lib is used, not the one in m.lib. Order of linking is important.

Also, read the section on the command "make" in the Manx manual. Creating a
makefile for your programs, particularly when you are linking several compiled
modules, makes the whole process much easier. 

Hope this isn't too confusing- experienced Manx users feel free to elaborate
or correct- I'm a bit of a rookie too...

I need to borrow some wisdom and insight from a few of you 'Amiga Programming
Veterans'.  I'm running into what I think are resource-related (memory &
stack) problems on my amiga.  (Having gotten most of my recent software 
experience on a VAX running VMS, I guess I've just forgotten how to program for
systems with teensy amounts of memory.)

I'm fiddling around with writing a game for the amiga (A war simulation, if I
finish it.  I've got another project I want to fool around with, but it's sort
of 'on hold pending parts' right now.)  Anyway, I'm generating a 60x120 map,
which in in an array of char.  There are three versions of the map (player's
view, computer's view, and overall view), so the structure declaration looks
something like this:

	struct map_struct
		{
		char real;	/* real map */
		char plyr;	/* player's view of map */
		char comp;	/* computer's view of map */
		char massnum;	/* index number of this mass (sea/continent) */
		} map[60][120];

This structure is external (declared outside of all routines, so available to
all routines in this module).  

Now, I'm able to generate the map (water with a certain number of roughly
island-shaped land masses), but after generating it, I want to put it through
some tests (to make sure there's only one major ocean, etc.).  In order to do
this, I've written a routine which, when given coordinates for a point, will
determine the size of the mass (either sea or island) which contains that
point.  My first attempt made this routine recursive, but the amiga 'blew it's
stack' on all but the smallest masses.  

"Okay, fair enough" I thought.  "I'll rewrite the routine non-recursively and 
fake the recursion in my code."  Simple enough task, right?  Well, in order to
do this, I needed a 'stack' on which to push x,y coordinate pais for points
that needed further checking.  So I declared two arrays,

	char xstk[60][120];
	char ystk[60][120];

for this purpose.  

Now here's the trouble.  When executing this code under the Lattice C V5.?
'codeprobe' source-level debugger, upon entering the routine which determines
the size of a mass, my amiga 'blows its stack' again... before executing a
single instruction.  Looking at the assembly-level code (even though I don't
know the first #!%&&!@^ thing about 68000 assembler), it appears that one
instruction is modifying the stack pointer by a significant amount.

It appears to me that the local variable storage is being allocated from the
stack.  Is this actually the case?!?!?!?  I wouldn't think that my 6 60x120
byte arrays are exhausting physical memory.  They should only take 43200 bytes,
and I've got a full meg.  Besides, MachII said I still had 250k left.

So, I eagerly await wisdom.  Anybody care to 'dump' some on me?  (wisdom, that
is.  ;-)


					Thanks for the help,
					John

Sounds like you need the infamous STACK command.

Before running your program (actually, I put it in S:SHELL_STARTUP) type

	STACK 20000   or some large number.

This allocates 20K bytes for your programs stack. The defualt is 4K.

With C, if you put those 2 arrays (2 x 60 x 120 = 14400 bytes) after the
 "{" in your program:

	main {
	  char arry1[60][120];
	  char arry2[60][120];

		.
		.
		.
	}

they get allocated on the stack at run-time. These are know as AUTO storage
since they are automatically allocated at run time.

That instruction is probably LINK. It bumps the stack pointer and saves
it's original value. This is your "stack local" storage allocation at work!

john

    Re .21
    
    Yes you're right the variables do come off the stack. Any variables
    declared within a function which are not specified otherwise will be
    allocated from the stack on entry to the routine at run time. 
    
    For large lumps of data this is inefficient at every time you enter the
    function the jump has to be allocated off the stack and on exit
    returned to the stack. Also when its obtained from the stack there's no
    guarentee of its contents so every element of the lump must be set up.
    
    Alternatively you can declare it as either being global data, memory
    allocated at link time and available whereever the lump is in scope or
    you can declare it as static within your function which means only that
    function will use it but the data is retained and the memory is
    allocated at link time.
    
    I've tried to be general as my expertese is in VMS and PC C coding, I
    havn't tried any C on my Amiga. If the Amiga C compiler you are using
    is anything like ANSII C then there are lots of ways of declaring data,
    each of which determine whether the storage is allocated at link or
    run time. I.E. READ THE MANUAL.

You could also get large chunks of memory by calling one of the the 
allocmem() family.

John

Whew!  Now that's service!  Put in a request before lunch and get 3 responses
by the time you get back!  Thanks!

Re: all answers...

Thanks for clearing the water for me.  I sort of thought that was what was
happening.  I think perhaps I should just declare the variables as static in
that particular routine.  My original thoughts were that I would only need the
array in this one routine and that I would rather not have it taking up space
in memory when it wasn't needed.  It seemed to be a trade-off of cpu cycles
(taken to make space for the array dynamically) vs. memory, and on a 1 meg
system, memory seemed more important.  However, since local variables must come
from stack and I don't want to have to set a HUGE stack to run this program,
I guess I'll make those variables static.  (Hmm... virtual memory can sure
spoil you, you know.)



A little related philosophical musing, if I may indulge...

Perhaps it seems like a bad call to have local variables come from
STACK... at least on the Amiga, where running out of stack can be fatal.  The C
textbook I completed a couple of months ago seemed to stress the use of local
variables to avoid wasted storage and confusion about scope.  However, on the
Amiga, large local variables exhaust stack.  So if you want your program to be
able to run in an average user's unchanged CLI (read small STACK), you have to
'waste' real memory.  Of course, you could allocate your own memory
dynamically, but wouldn't it make more sense for the compiler to do this for
you... to keep an area of memory set aside specifically for local variables
and/or to dynamically get more memory when this is exhausted?  

Actually, what sounds even better is to have dynamic STACK.  Now THERE's a
wishlist item.  I would think it would cure a lot of gurus.

Your thoughts?  (BTW, this last bit was just meant for discussions sake.  It's
		 not meant to offend anyone or to sound overly critical of 
		 the Lattice or the Commodore Amiga developers.  Please put 
		 away those knives.  :-)


					John

I'd prefer to allocate that memory dynamically using an allocmem() call. If
you only need it in one routine, let that routine allocate the memory when it
needs it, use it, then return it back to the system.
	
If you put it as global or static storage, it sits there eating up memory
as soon as you run your program - wether you use it or not.

Allocating stack is really not very expensive - 1 LINK instruction and a couple
bounds checking instructions (which are nice enough to kill your program if it 
needs more stack than it has - rather than trash whatever was below the
real stack). Everything else is an indirect off the saved SP.

By the way, stack local allocation is not Amiga or even Lattice - It's C
in general. I believe most compilers will handle stack auto variables this
way (I may be wrong).

John

I should mention that allocmem is not the best trade off if you need the 
absolute best performance since it does incur some overhead in the system
call and manipulating system data structures.

John

    Ok,I am still desperately trying to figure out the link command
    for Aztec C. Does the #include statement determine what libraries
    are going to be used. If I had a program that started like this:
    
    #include "exec/types.h"
    #include "libraries/dosextens.h"
    #include "intuition/intuition.h"
    #include "graphics/gels.h"
    #include "graphics/sprite.h"
    
    what would the syntax look like to link this program? Once I figure
    out how to link my programs then programming will be much funner.
    I am using "progrrammers guide to the amiga" to learn C.
    
    matt
    

Matt,

Hang tough, C can seem difficult at first, but once you get the hang of
it you'll be glad you did.  The "#include" preprocessor directive does
just what it says - it "includes" the contents of the file specified
right where you put the #include.  This is done at COMPILE time, so it
has nothing to do with the link phase.

Hope that makes ���,

...richard

    So to compile it I just have to type "cc <filename>" and to link
    it I type "ln <filename> -lc"???
    
    matt
    

>    So to compile it I just have to type "cc <filename>" and to link
>    it I type "ln <filename> -lc"???

Your compiler should let you compile and link all in one step.

try:

	cc -lc program.c

Do you have manuals??? If so, look at the cc command and it's options.

John    

    The single most overwhelmingly important skill (other that using
    words such as "overshelmingly") that a computer professional practices
    is reading for specific information; in our environment, we usually
    read manuals, but also journal articles random and sought for, books,
    both text and reference, and programmers cards ( ;-)
    Adults in computers must Learn to Read.
    Young people in computers usually end up professionals in law or
    medicine, but that may be an obsolescent wisdom from the previous
    decade when the only teenagers who could afford computers cold also
    afford law or medical school.
Tom

>    So to compile it I just have to type "cc <filename>" and to link
>    it I type "ln <filename> -lc"???

In a nutshell, yes.

	myprog.c -> "cc myprog.c" -> myprog.o -> "ln myprog.o -lc" -> myprog
	

    But is that all I have to type in even if the program uses libraries?
    
    matt
    

    I have been trying to compile and link a PD program that displays
    4096 colors at once when I do "cc copper.c" that wroks fine but
    when I try "ln copper.o -lc" it works for a few seconds but then
    says "Undefined Symbol: _main". Have any ideas what is wrong?
    
    Also, I have discovered that you can use different combonations
    on the cc and ln functions like:
    
    cc +l -s -o program.o32 program.c
    cc -s -o program.c program.o
    ln program.o32 -lc32 -lm32
    ln program.o32 -lc32
    ln program.o -lc -lm
    ln +cd program.o -lc
    
    What are the +cd,-lc,-lm and the 32 for??? I am very confused.
    
    matt
    

    Yes, libraries are resident in the OS and are 'opened' at run time.
    They are re-entrant, meaning they create the structures that are
    needed and can be/are used by multiple processes.  The OpenLibrary
    routine typically returns a pointer to the library, but that library
    not actually linked or even included in the final executable.
    
    Examples - graphics.library, mathffp.library, etc.
    
    ~Steve (someone correct me if I'm dreaming)

Are the 'scroll bars' on windows built into the operating system, or do you
have to program them yourself?  

I want to create a 'window' to view a 2-D char array, and I'd like to have
scroll bars like the Workbench has on its windows.  I thought there would be
a way to do this in the standard AmigaDos windowing functions, but I couldn't
find any reference to it in my "Amiga Programmer's Handbook, Part I".  It could
very well be that I just don't know what I'm looking for.

Can anybody help get me on the right track?  Perhaps a pointer to some source
code that implements this functionality?  Or maybe just a hint at what to look
for in the Handbook...  Maybe I need a different book?

(BTW, is the "Amiga Tips & Tricks book any good?  I'm thinking about picking 
that one up this afternoon, and just wanted to hear from someone who's seen it.)


					Thanks,
					John

You need to program them in.  I'd *LOVE* to have a shell with a scroll bar!

Wan't to write one?  :-)

>You need to program them in.  I'd *LOVE* to have a shell with a scroll bar!
>Wan't to write one?  :-)

Boy, you show NO MERCY on a beginner.  Sure, I'll give it a try.  I'm GOING to
try and write one, so I may as well see if I can't make it a set of C
functions.

Of course, you realize that X11R3 has scrollbar widgets.  If we'd get off our
duffs and port X to the Amiga, we could write the code using X calls and it'd
be portable to a VAXstation, right?  (Well, it works in theory anyway.)  

That reminds me, did you ever make any progress at getting the 'missing' files
in the X11R3 distribution?  If not, our office may be bringing up an Ultrix
machine in another month or so.  I could conceivably copy the kit to there, but
I think our only link to the outside world will be a 2400 baud line.  Could
take EONS to copy the code to our Ultrix machine, and then I'd have to transfer
it to my Amiga from there.  (Arg.  I get the willies just thinking about it.)

Back to the original subject... Know of any PD/ShareWare hacks that implement
scrollbars? ... that I can get to the source?  That would sure help.  (I'm a
firm believer in cut-and-paste-where-you-can.  That mile-wide lazy streak, you
know.)


					John Boy

    The Ammiga tricks and tips book is good only for amigabasic
    programmers.All programs are written in basic.
    
    mat

    
    QView is a very fast, re-entrant text viewer that uses scroll bars.  I
    don't have the source (I lost the original ARChive) but you may want to
    look at it.
    
    Ed.

    Take a look at the Fish-disk listings. A lot of programs come with
    source so you might be able to borroe the windows and scrolling from
    one of them. Also there are various C libraries which may (FF218) have
    what you want.

WJG::AMIGA:QVIEW.ARC.  It's asm (68000 assembly)!

I'm making another attempt a the X11 kit (with DOCS!) as we speak :-)

John

    1.  What does the "struct" command do???? I have seen it used alot
    but I can not understand the command the way the book tells about
    it.
    
    2.  Can I use CLI commands in C? How??
    
    3.  Is there a program that makes it easier to make bobs and sprites??
    
    matt
    

struct is like a record in basic. It let's you group other objects (oops, thats
C++ lingo) under a common name.

ex:

	struct record {
		int x;
		char string[100];
	};

Now you have a new "data type" called "record".

So use it like:

main()
{
struct record rec;

rec.x = 10;
strcpy(rec.string,"some chars");

printf(rec.x = %d, rec.string = %s\n",rec.x,rec.string);

}



You can use CLI commands from C indirectly - using the execute() Amiga
function or the fork() C function.


Bobs and sprites?  Maybe Power Windows?


John