home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / sys / amiga / demos / 1699 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  6.9 KB
  1. Xref: sparky alt.sys.amiga.demos:1699 comp.sys.amiga.advocacy:29350
  2. Newsgroups: alt.sys.amiga.demos,comp.sys.amiga.advocacy
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!news.funet.fi!funic!news.cs.hut.fi!news.cs.hut.fi!oahvenla
  4. From: oahvenla@snakemail.hut.fi (Osma Ahvenlampi)
  5. Subject: Re: Programming
  6. In-Reply-To: njale@dhhalden.no's message of Tue, 17 Nov 1992 10:23:26 GMT
  7. Message-ID: <OAHVENLA.92Nov17195727@lk-hp-4.hut.fi>
  8. Sender: usenet@cs.hut.fi (Uutis Ankka)
  9. Organization: Helsinki University of Technology, Finland
  10. References: <mwm.2n4z@contessa.palo-alto.ca.us> <1e43mkINNler@ub.d.umn.edu>
  11.     <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi>
  12.     <njale.32.721995806@dhhalden.no>
  13. Date: Tue, 17 Nov 1992 17:57:26 GMT
  14. Lines: 118
  15.  
  16. (I'm doing this AGAIN! Why?)
  17.  
  18. In article <njale.32.721995806@dhhalden.no> njale@dhhalden.no (NJAL EIDE) writes:
  19.  
  20. (this is from my earlier post)
  21. >>it, but that's because there are already some very powerful spreadsheets out
  22. >>there. Show me an AMOS spreadsheet.. I have seen HyperCard based games that
  23. >>beat AMOS games easily.
  24.  
  25. >No, you have NOT. Maybe you have seen some intricate puzzle-games, but 
  26. >anything wich incorporate moving graphics is dead slow with Hypercard (I'm 
  27. >not meaning flip-frame animations). In fact, anything is dead slow with 
  28. >Hypercard. I've been using it with a 20 mhz Mac IIsi and I would say that a 
  29. >humble A500 with Amos blows it miles away (Hypercard, not the Mac). F.ex. 
  30. >recently I wrote a little program that should simulate the trajectory of an 
  31. >arrow. It took into consideration gravity and the angle and power at wich 
  32. >the arrow was shot. The arrow was a simple polygon of two - 2 - points, but 
  33. >still, when I was moving it above a muliti-colored bit-map, it used nearly 
  34. >two seconds a frame. I could go on-and-on telling how dreadfully slow 
  35. >Hypercard is. I'm not an expert at it. A more experienced Hypercard-user 
  36. >could probably speed up things a little bit, but then again I'm not an 
  37. >expert at Amos either, and here animating objects is quite fast. I'm sure I'
  38. >m not taking my mouth to full when I say about 50, yes fifty, times faster 
  39. >at moving objects. It probably is even more.
  40.  
  41. Anyone who knows HyperCard wouldn't try animations with it. It's not created
  42. for that. There are lots of games that don't need animation, and I'd take
  43. one of them any day over an AMOS shoot'em or whatever. In fact, over just
  44. about any shoot'em.
  45.  
  46. >>Oh, well that tells something about you. If you think lots of commands make
  47. >>a language powerful, boy, are you lost... You said that C is a good language.
  48. >>Well, C has 32 commands. That twice too many, I'd say.
  49.  
  50. >Why are you so ignorant ? Off course it's better to have many commands. You 
  51. >don't have to use them if you think you could write better routines 
  52. >yourself, but it's very, very nice to have them. And what you say about C is 
  53. >not true in practice. Every single C-compiler comes with a large set of 
  54. >include-routines, but let me guess, you never use them. 
  55.  
  56. The more instructions, the more there is to remember, and the more restrictive
  57. the use of any single instruction is. A large base instruction set is not a
  58. strenght. Subroutine librarys is not the same thing. You can choose what
  59. library, if any, you want to use, or write a better one if you can.
  60. There is not a one routine in C includes. Only descriptions about the basic
  61. C routines found in the linkable libraries, and in the case of Amiga,
  62. extensively about the system calls.
  63.  
  64. >>Seems like you didn't get it. LoadIFF is probably bug free, but there are
  65. >>commands in AMOS that are not. Suppose LoadIFF had a bug, like thrashing the
  66. >>picture, if it was size 319x76. Now, you command syntax is correct, where the
  67. >>hell is the bug?
  68.  
  69. >Suppose this, suppose that. It's working, so where the hell is your problem ?
  70.  
  71. No, it isn't. If it is, you could do a OS 2.0 Commodity with AMOS. Do it, and
  72. I'll take my every word against AMOS back.
  73.  
  74. >>On your assembly (I think that was what you meant) program the bug would be
  75. >>spotted automatically by the compiler. There is no instruction "Move A.x".
  76.  
  77. >Wich compiler would spot a missing 'Move' ? FutureSofts compiler with 
  78. >artificial intelligence.
  79.  
  80. No compiler would spot a missing Move. Nor would AMOS spot a missing LoadIFF
  81. for that matter.
  82.  
  83. >And why couldn't you use iff.lib from AMOS ? Or why couldn't you write your 
  84. >own LoadIFF in Amos ?
  85.  
  86. You could use any library from AMOS, yes. Forgetting for a moment that you'd
  87. have to either use the offsets or write your own defines (AMOS doesn't have
  88. #DEFINE (meaning a constant), does it?), even if you did use libraries for
  89. everything (which would make using AMOS harder than using assembler, not to
  90. mention C), you couldn't get rid of the AMOS run-time library, which is the
  91. thing that makes all serious AMOS use an impossibility.
  92.  
  93. >You should be careful of judging other peoples capabilities. Especially when 
  94. >you don't know them. You sure don't sound to experienced to me. You sound 
  95. >exactly like a guy who think he's something special, since he know something 
  96. >about coding. Everybody else are lamers, right ? But, I really shouldn't 
  97. >write that. For all I know, you could be the one behind Real-3d.
  98.  
  99. Well, I'm not. Does that make you feel better? I don't care what you say about
  100. my abilities, they don't change from that.
  101.  
  102. >C is not easy. C is easy for you and me, because we have gotten the hang of 
  103. >it. Other languages, such as Amos, HyperCard etc. are easy. But they are not 
  104. >as powerfull and flexible. But I would prefer to write a game in Amos. You 
  105. >would get away with it in C if you included some assembly routines. With 
  106. >Amos that is not needed.
  107.  
  108. All really powerful languages are easy, because that makes them powerfu|.
  109. Unfortunately, easy languages don't compile well on Von Neumann machines..
  110. C isn't hard. 
  111.  
  112. >>And if you want to play a MED file?
  113.  
  114. >Then you play a MED-file. AmosPro supports just that. I'm getting tired of 
  115. >this. You don't obviouly know as much about Amos as you belive you do.
  116.  
  117. Great. AMOS Pro supports MED files. What about FutureComposer. If I release
  118. tomorrow THE music editor, which unfortunately must have a TOTALLY different
  119. module format to get rid of the limitations of other formats (not that I am,
  120. ever, as I don't know a shit about music), AMOS Pro definitely won't support
  121. it. Every assembler or C compiler or whatever good language that supports
  122. linking subroutines would. AMOS might support it two years from now, when
  123. they get around to add it to their run-time library, which, by that point,
  124. is over 300KB long.
  125.  
  126. This will definitely be the last post by me to this thread. I'll put it in
  127. my kill file right now to avoid temptation.
  128.  
  129. alt.sys.amiga.demos is in the newsgroups, because I think that's where this
  130. thread started from... .advocacy I don't read.
  131. --
  132. Osma Ahvenlampi  -  oahvenla@snakemail.hut.fi   * Workstation power for micro-
  133. All my opinions are not necessarily really mine * computer price: Amiga := FUN
  134.