Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!indetech!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.tech Subject: Re: asd Message-ID: <1990Dec22.143657.21505@zorch.SF-Bay.ORG> Date: 22 Dec 90 14:36:57 GMT References: <925@boing.UUCP> <7335@sugar.hackercorp.com> <6301@amiga.UUCP> Organization: SF-Bay Public-Access Unix Lines: 49 [In response to jimm's article] The standards out of ISO & ANSI X3X3 (GKS, GKS3D, PHIGS, PHIGS+,...) address the full range of issues you mention, specifically for instance the full range of multiple display devices, each having it's own private input devices, each with its own set of forward and inverse transformations for both input and output, each with its own resolution and color capabilities, etc. As the Amiga moves more and more into the high end graphics for which these standards were designed, less and less of the functionality in the standards would be unusable on the Amiga. The ones with which I am familiar also have a way of asking the display driver "can you do/can you emulate/must I do" questions, that would cover the cases of sprites/copper lists and so on that exist on one display but not another, as well as "standard escapes" for getting at hardware capabilities not a part of the standard. Rather than go with an "industry 'standard'", I'd guess Commodore would be well advised to have one of the real graphics heavies take a break from development, sit down for some number of months with these international standards, and try to identify parts that the Amiga would _not_ find useful. I suspect it would be a small list indeed. To the other question of pokey performance on the A500, it is long ago time for Commodore to stop selling a configuration so minimal that every attempt to do software improvements is blocked by hardware limitations. It is plain dumb in today's market to sell a machine with under 2Mbytes of memory, for example, when the A500's limited memory is harming not only Commodore but also 3rd party software development. Developers must design to the base model, since so many machines stay at that base "forever"; setting the base too low is the virtual equivalent of grinding one's heel into the back of the prone developer's neck; s/he finds it hard to work in that position. Putting this kind of a limitation on the software that can be written for the base machine eventually puts a limit on the market to which all your machines can aspire; limited software availability == limited hardware sales, and the first "limited" doesn't only mean "few in number" but also "lesser in capability". We've been running into this time and again in comp.sys.amiga.games in the last couple of weeks; some of the best development discussions alive go on the what was meant to be a noise group, though they sure are noisy enough! I hope someone from C= has been listening and passing on the lessons there. Kent, the man from xanth.