From: njale@dhhalden.no (NJAL EIDE)
Subject: Re: Programming
Organization: Ostfold College
Date: Tue, 17 Nov 1992 10:23:26 GMT

In article <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi> oahvenla@snakemail.hut.fi (Osma Ahvenlampi) writes:
>From: oahvenla@snakemail.hut.fi (Osma Ahvenlampi)
>Subject: Re: Programming
>Date: Sun, 15 Nov 1992 11:58:40 GMT
>In article <1e4r1uINN2jt@ub.d.umn.edu> rfentima@ub.d.umn.edu (Robert Fentiman) writes:
>

>I haven't even seen AmigaVision, so I can't speak for it, but I have done some
>pretty extensive work with HyperCard (a Mac program). It is a multimedia
>program, one of the first. It is also a database, and in fact is to some extent
>marketed as a database. I have done a 1500 card application using sounds,
>text, animation and so on with it, and it wasn't very difficult. In fact, it is
>VERY easy. It has a HIGH object orientation, which makes it very simple to add
>new elements to your programs. True, I haven't seen a spreadsheet made with
>it, but that's because there are already some very powerful spreadsheets out
>there. Show me an AMOS spreadsheet.. I have seen HyperCard based games that
>beat AMOS games easily.


No, you have NOT. Maybe you have seen some intricate puzzle-games, but 
anything wich incorporate moving graphics is dead slow with Hypercard (I'm 
not meaning flip-frame animations). In fact, anything is dead slow with 
Hypercard. I've been using it with a 20 mhz Mac IIsi and I would say that a 
humble A500 with Amos blows it miles away (Hypercard, not the Mac). F.ex. 
recently I wrote a little program that should simulate the trajectory of an 
arrow. It took into consideration gravity and the angle and power at wich 
the arrow was shot. The arrow was a simple polygon of two - 2 - points, but 
still, when I was moving it above a muliti-colored bit-map, it used nearly 
two seconds a frame. I could go on-and-on telling how dreadfully slow 
Hypercard is. I'm not an expert at it. A more experienced Hypercard-user 
could probably speed up things a little bit, but then again I'm not an 
expert at Amos either, and here animating objects is quite fast. I'm sure I'
m not taking my mouth to full when I say about 50, yes fifty, times faster 
at moving objects. It probably is even more.

>
>>look at the AMOS manual.  Also consider getting the AMOS demos (like the
>>demo of AmosPro, available at many FTP sites).  AMOS has over 500
>>commands (in addition to those from the 3D support module), and AMOS Pro
>>has over 700.
>
>Oh, well that tells something about you. If you think lots of commands make
>a language powerful, boy, are you lost... You said that C is a good language.
>Well, C has 32 commands. That twice too many, I'd say.
>

Why are you so ignorant ? Off course it's better to have many commands. You 
don't have to use them if you think you could write better routines 
yourself, but it's very, very nice to have them. And what you say about C is 
not true in practice. Every single C-compiler comes with a large set of 
include-routines, but let me guess, you never use them. 




>Seems like you didn't get it. LoadIFF is probably bug free, but there are
>commands in AMOS that are not. Suppose LoadIFF had a bug, like thrashing the
>picture, if it was size 319x76. Now, you command syntax is correct, where the
>hell is the bug?

Suppose this, suppose that. It's working, so where the hell is your problem ?


>On your assembly (I think that was what you meant) program the bug would be
>spotted automatically by the compiler. There is no instruction "Move A.x".

Wich compiler would spot a missing 'Move' ? FutureSofts compiler with 
artificial intelligence.

>BTW: It is obvious you don't even know what you're exactly loading. IFF picture
>is NOT loaded with 11 assembly instructions, or even 20. It can be read from
>disk in that, if you count dos.library calls as one instruction, but after
>that it has to be converted into a bitmap. You can not just show IFF format.
>IFF is interleaved, possible packed, and has a lot more information than just
>the bitmap.
>If you want to do it easily, there is the iff.library. If you want do to it
>more efficiently, retaining simplicity, update iff.lib. In AMOS, you'd have
>to re-compile your program, provided there even is a updated, more efficient
>version available.

And why couldn't you use iff.lib from AMOS ? Or why couldn't you write your 
own LoadIFF in Amos ?

>You, on the other hand, seem to have VERY little experience, period. Your
>concepts of programming are exactly the things I want to avoid by not using
>AMOS programs.
>

You should be careful of judging other peoples capabilities. Especially when 
you don't know them. You sure don't sound to experienced to me. You sound 
exactly like a guy who think he's something special, since he know something 
about coding. Everybody else are lamers, right ? But, I really shouldn't 
write that. For all I know, you could be the one behind Real-3d.


>All languages have advantage over other, just as you quoted. What do you want
>to do? If you just want a general, all-purpose language, I'd choose C, not
>because it's powerful, but because it's pretty easy, well supported, and is 
>found on several platforms.

C is not easy. C is easy for you and me, because we have gotten the hang of 
it. Other languages, such as Amos, HyperCard etc. are easy. But they are not 
as powerfull and flexible. But I would prefer to write a game in Amos. You 
would get away with it in C if you included some assembly routines. With 
Amos that is not needed.
 

>>animation capability with the same ease.  To play a MOD file in amos,
>>you type Music "<music name>".  Can they have more sprites on the screen
>

>And if you want to play a MED file?
>
Then you play a MED-file. AmosPro supports just that. I'm getting tired of 
this. You don't obviouly know as much about Amos as you belive you do.


Njaal E.