home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / sys / amiga / demos / 1692 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  6.5 KB
  1. Xref: sparky alt.sys.amiga.demos:1692 comp.sys.amiga.applications:8744 comp.sys.amiga.introduction:1555 comp.sys.amiga.marketplace:8975 comp.sys.amiga.misc:16983 comp.sys.amiga.advocacy:29312
  2. Newsgroups: alt.sys.amiga.demos,comp.sys.amiga.applications,comp.sys.amiga.introduction,comp.sys.amiga.marketplace,comp.sys.amiga.misc,comp.sys.amiga.advocacy
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!aun.uninett.no!nuug!dhhalden.no!pc116.dhhalden.no!njale
  4. From: njale@dhhalden.no (NJAL EIDE)
  5. Subject: Re: Programming
  6. Message-ID: <njale.32.721995806@dhhalden.no>
  7. Lines: 118
  8. Sender: news@dhhalden.no (Network News User)
  9. Nntp-Posting-Host: pc116
  10. Organization: Ostfold College
  11. References: <mwm.2n4z@contessa.palo-alto.ca.us> <1e43mkINNler@ub.d.umn.edu> <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi>
  12. Date: Tue, 17 Nov 1992 10:23:26 GMT
  13.  
  14. In article <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi> oahvenla@snakemail.hut.fi (Osma Ahvenlampi) writes:
  15. >From: oahvenla@snakemail.hut.fi (Osma Ahvenlampi)
  16. >Subject: Re: Programming
  17. >Date: Sun, 15 Nov 1992 11:58:40 GMT
  18. >In article <1e4r1uINN2jt@ub.d.umn.edu> rfentima@ub.d.umn.edu (Robert Fentiman) writes:
  19. >
  20.  
  21. >I haven't even seen AmigaVision, so I can't speak for it, but I have done some
  22. >pretty extensive work with HyperCard (a Mac program). It is a multimedia
  23. >program, one of the first. It is also a database, and in fact is to some extent
  24. >marketed as a database. I have done a 1500 card application using sounds,
  25. >text, animation and so on with it, and it wasn't very difficult. In fact, it is
  26. >VERY easy. It has a HIGH object orientation, which makes it very simple to add
  27. >new elements to your programs. True, I haven't seen a spreadsheet made with
  28. >it, but that's because there are already some very powerful spreadsheets out
  29. >there. Show me an AMOS spreadsheet.. I have seen HyperCard based games that
  30. >beat AMOS games easily.
  31.  
  32.  
  33. No, you have NOT. Maybe you have seen some intricate puzzle-games, but 
  34. anything wich incorporate moving graphics is dead slow with Hypercard (I'm 
  35. not meaning flip-frame animations). In fact, anything is dead slow with 
  36. Hypercard. I've been using it with a 20 mhz Mac IIsi and I would say that a 
  37. humble A500 with Amos blows it miles away (Hypercard, not the Mac). F.ex. 
  38. recently I wrote a little program that should simulate the trajectory of an 
  39. arrow. It took into consideration gravity and the angle and power at wich 
  40. the arrow was shot. The arrow was a simple polygon of two - 2 - points, but 
  41. still, when I was moving it above a muliti-colored bit-map, it used nearly 
  42. two seconds a frame. I could go on-and-on telling how dreadfully slow 
  43. Hypercard is. I'm not an expert at it. A more experienced Hypercard-user 
  44. could probably speed up things a little bit, but then again I'm not an 
  45. expert at Amos either, and here animating objects is quite fast. I'm sure I'
  46. m not taking my mouth to full when I say about 50, yes fifty, times faster 
  47. at moving objects. It probably is even more.
  48.  
  49. >
  50. >>look at the AMOS manual.  Also consider getting the AMOS demos (like the
  51. >>demo of AmosPro, available at many FTP sites).  AMOS has over 500
  52. >>commands (in addition to those from the 3D support module), and AMOS Pro
  53. >>has over 700.
  54. >
  55. >Oh, well that tells something about you. If you think lots of commands make
  56. >a language powerful, boy, are you lost... You said that C is a good language.
  57. >Well, C has 32 commands. That twice too many, I'd say.
  58. >
  59.  
  60. Why are you so ignorant ? Off course it's better to have many commands. You 
  61. don't have to use them if you think you could write better routines 
  62. yourself, but it's very, very nice to have them. And what you say about C is 
  63. not true in practice. Every single C-compiler comes with a large set of 
  64. include-routines, but let me guess, you never use them. 
  65.  
  66.  
  67.  
  68.  
  69. >Seems like you didn't get it. LoadIFF is probably bug free, but there are
  70. >commands in AMOS that are not. Suppose LoadIFF had a bug, like thrashing the
  71. >picture, if it was size 319x76. Now, you command syntax is correct, where the
  72. >hell is the bug?
  73.  
  74. Suppose this, suppose that. It's working, so where the hell is your problem ?
  75.  
  76.  
  77. >On your assembly (I think that was what you meant) program the bug would be
  78. >spotted automatically by the compiler. There is no instruction "Move A.x".
  79.  
  80. Wich compiler would spot a missing 'Move' ? FutureSofts compiler with 
  81. artificial intelligence.
  82.  
  83. >BTW: It is obvious you don't even know what you're exactly loading. IFF picture
  84. >is NOT loaded with 11 assembly instructions, or even 20. It can be read from
  85. >disk in that, if you count dos.library calls as one instruction, but after
  86. >that it has to be converted into a bitmap. You can not just show IFF format.
  87. >IFF is interleaved, possible packed, and has a lot more information than just
  88. >the bitmap.
  89. >If you want to do it easily, there is the iff.library. If you want do to it
  90. >more efficiently, retaining simplicity, update iff.lib. In AMOS, you'd have
  91. >to re-compile your program, provided there even is a updated, more efficient
  92. >version available.
  93.  
  94. And why couldn't you use iff.lib from AMOS ? Or why couldn't you write your 
  95. own LoadIFF in Amos ?
  96.  
  97. >You, on the other hand, seem to have VERY little experience, period. Your
  98. >concepts of programming are exactly the things I want to avoid by not using
  99. >AMOS programs.
  100. >
  101.  
  102. You should be careful of judging other peoples capabilities. Especially when 
  103. you don't know them. You sure don't sound to experienced to me. You sound 
  104. exactly like a guy who think he's something special, since he know something 
  105. about coding. Everybody else are lamers, right ? But, I really shouldn't 
  106. write that. For all I know, you could be the one behind Real-3d.
  107.  
  108.  
  109. >All languages have advantage over other, just as you quoted. What do you want
  110. >to do? If you just want a general, all-purpose language, I'd choose C, not
  111. >because it's powerful, but because it's pretty easy, well supported, and is 
  112. >found on several platforms.
  113.  
  114. C is not easy. C is easy for you and me, because we have gotten the hang of 
  115. it. Other languages, such as Amos, HyperCard etc. are easy. But they are not 
  116. as powerfull and flexible. But I would prefer to write a game in Amos. You 
  117. would get away with it in C if you included some assembly routines. With 
  118. Amos that is not needed.
  119.  
  120.  
  121. >>animation capability with the same ease.  To play a MOD file in amos,
  122. >>you type Music "<music name>".  Can they have more sprites on the screen
  123. >
  124.  
  125. >And if you want to play a MED file?
  126. >
  127. Then you play a MED-file. AmosPro supports just that. I'm getting tired of 
  128. this. You don't obviouly know as much about Amos as you belive you do.
  129.  
  130.  
  131. Njaal E. 
  132.