Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part IV Message-ID: Date: 29 Mar 91 18:28:10 GMT References: <23787@well.sf.ca.us> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 115 In-Reply-To: mykes@amiga0.SF-Bay.ORG's message of 28 Mar 91 15:20:13 PST In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >The point I am trying to make is that game machines are game machines >and workstations are workstations. The Genesis and Nintendo are game >machines. Shutting them down to run a game is acceptable; that's all >they do. The Amiga is a workstation. Shutting it down means saving the >state of and haltingany running servers, ditto for any ongoing >computations, disabling UUCP dialins, and the like. Shutting it down >to play a game isn't acceptable. > The Amiga 500 is not a workstation. It is a game machine just like the Nintendo or the Genesis. 90% of people who have Amiga 500's just stick floppies in and reboot. The Nintendo and Genesis allow expansion to things like hard drives, TOY clocks, and more memory? Available software includes UUCP, image processing, accounting, spreadsheets, and compilers? They come with keyboards? Sorry, the Amiga 500 is as much a workstation as the Amiga 2000. The only difference between the two is that extra 512K and the built-in expandability on the 2000. I know people who develop productivity software on A500s with two floppy drives. It's a workstation. > The Amiga operating system is not a high performance video game > operating system. BOBs are slower than what I use. Intuition takes > 30% of the CPU time when you just move the mouse around > >You've said this a number of times. I'm curious - why are you letting >intuition see mouse moves when your game is running? > Intuition never runs when my game is running. Neither does the rest of the OS (thank GOD). The example I give is just one of a zillion gotchas that the OS has for you. Sounds like Mike Farren's charge of laziness may be correct. > ******************************************************* > * Assembler Language separates the men from the boys. * > ******************************************************* > >Yeah - the men realize that choosing the right tool for the job makes >them more productive; the boys don't realize that doing everything in >assembler does little more than make them overworked. > 'C' is hardly ever the right tool for games. I use it a lot when I use my Amiga as a workstation, but if it weren't for the fact that I have a 68030, the performance would suck. C is hardly ever the right tool for anything. It's just blasted popular. Jim Goodnow used 'C' to write his assembler (as), and HiSoft used Assembler language. AS is > 50K and is a slow pig. Devpac is 27K on disk and is blindingly fast. Which is the right tool? Devpac is clearly the right tool for you to us. If I remember correctly, AS was designed as a back end for his C compiler, so speed/size were probably swamped by the front end, and just aren't important for his purpose. Time spent developing and supporting it are. Do you happen to have those figures for the two projects? If JG spent less time on AS than was spent on Devpac, then he probably made the right choice. This, of course, has nothing to do with whether C or assembler is a better choice for either purpose; to many other variables involved. The same applies to the examples I know of where switching to an HLL led to smaller, faster code. Further afield, I once did an assembler as a class assignment. Speed, size and maintainability don't matter at all - just development time. I wrote it in Snogol (snobol with my custom algoloid extensions added); it was 300 lines of code and 2 days of work. The best straight HLL implementation was five times the length, and five times the time. That my version was huge but blindingly fast compared to the algol versions was immaterial - I won by a factor of 5 on the only important criteria. I don't care how hard YOU think it is for HiSoft to maintain the source to their assembler, but ME the consumer cares how it performs. All reasonable. And you the consumer should also care whether they stay in business, and how quickly they put out updates. Both of these are affected by maintainability. Of course, how maintainable I think the code is doesn't change either of those things; how maintainable it actually is is what's important. Genim2 is the ONLY assembler on the market that performs as it is documented, and it has NO bugs. I have bought every other assembler and they all are deficient and larger. This probably has more to do with the skill of the programmers and Q/A people than the language choice. The speed/maintainability issue _isn't_ one of "C is slow and maintainable; asm is fast and a nightmare". I can write maintainable assembler as well as HLL. I can trade away maintainability to create those tightly-crafted, basically unchangeable jewels in either flavor. ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ******************************************************** Gee, they managed to put complete documentation on the spiffy Amiga microkernel in 10 pages, and still had room for the custom hardware? That's pretty good!