home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.amiga.programmer:17357 comp.sys.amiga.hardware:21490
- Path: sparky!uunet!mcsun!uknet!edcastle!dcs.ed.ac.uk!jxp
- From: jxp@dcs.ed.ac.uk (Joe Potter)
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
- Subject: Re: Attn Commodore: You are making a Big Mistake (Hardware
- Message-ID: <Bz9qq6.5L6@dcs.ed.ac.uk>
- Date: 14 Dec 92 21:37:17 GMT
- References: <1992Nov12.000037.27562@wuecl.wustl.edu><1992Nov13.221116.15921 <70436@cup.portal.com> <amipb.04wr@amipb.gna.org>
- Sender: cnews@dcs.ed.ac.uk (UseNet News Admin)
- Organization: Department of Computer Science, University of Edinburgh
- Lines: 50
-
-
- Well, I've spent half an hour catching up on this (and associated)
- threads, and all I can see is people saying the same old things again and
- again. I must admit it is a knotty problem, as I hope I'll illustrate, but I
- am tending towards the OS side of things.
-
- The major point on the side of the OS people is that of compatibility.
- It is, right enough, a very important issue, perhaps the most serious one being
- debated. Truly, the Amiga cannot advance until there is a software base that
- can run on the advanced machine. This is obvious: we've already heard people
- saying "who's going to buy an A1200?" and this is going to be a valid question
- for some time now.
- So (we?) developers should be very concerned with making things work.
- fair enough. This leads to problem number 1.
-
- I write Product X, a great ECS-compatible game, runs just great, even
- on my A1500 w/33MHz 040 + ECS. I must admit, at this point, this is a
- speculative example. Product X will sell well over the existing architecture,
- i.e. 16bit ECS Chip architecture and whocares Fast architecture. I'll make
- money, but I must be concerned with the Amiga's future: the consoles are
- catching up.
- Now comes the difficulty. I've been good so far: I'm a clean coder and
- all my program is modular, the graphics sections are easily isolated, and
- recoded for OS compliance, and I can return the product to AmigaDOS compliance.
- This is no problem, a matter of a few days work. Great. I have two versions
- of Product X. How do I market them? Do I include both copies in the same
- package? Quite a loss, I should imagine. Do I combine them, and have the
- Product detect which machine is in use and select the appropriate executable?
- Still requires extra space - will it still fit on a (two?) disks, without
- compromising depth of gameplay, or will it spill onto an extra disk? Or should
- I market two versions, with big labels declaring which system they are valid
- for? Would the resulting consumer confusion damage my sales?
- Remember, I can't use OS compliant software in the base machine case -
- it would be too slow, because I can't guarantee the presence of WB2.1 or better.
- I'd have to have *very* intricate code that figured out what calls were
- floating around that I could still use, all-or-nothing library coding seems to
- still be quite popular. I suspect the answer to my quandary is the second
- option above, but this does lengthen development time and cost, and can raise
- production cost, especially in the manual ("If you're the proud owner of a
- machine with the AGA graphics hardware, you can select >KAPOW< from the title
- screen and run OS compliant! ...")
-
- I might also take this point to slap a few OS enthusiasts' wrists for
- doggedly attacking the demo-coders whilst also saying that the demo scene
- doesn't affect Amiga sales. You can't have your cake and eat it! If they
- don't matter, why should they comply?
-
- Joe.
-
- "How many times must the cannon balls fly?"
-