keithd@cadovax.UUCP (Keith Doyle) (09/25/87)
In article <800@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> This will probably be less true as soon as the Amiga port of GEM is >> available. >Isn't this rather like porting curses to the Mac? Yeah, I'd say so. >I mean, Intuition >is the standard user interface on the Amiga... and it's important to >stick to it. Now, a subroutine library that allows you to make GEM >calls but uses Intuition... that I could see. But sticking the GEM >user interface on the users is going to (1) hurt sales to non-naive >users, and (2) hurt the naive users who buy the package anyway. Sure, sure, but when faced with the prospect of porting a GEM application to Intuition, (I've looked at it, and we're talking some major rewrite here) many developers will decide it's too much work and just stick to the Atari. GEM on the Amiga, silly as it sounds at first, provides an almost immediate new market for Atari developers with little effort expended on their part. And GEM is a completely portable windowing system, DESIGNED to be ported around. TOS weirdnesses and ill-behaved talk-directly-to-hardware applications present some interesting challenges, but allowing Atari developers to spend a little time hacking 5% of the code is a lot more palatable than spending a lot of time hacking 70% of the code. It could make the difference between a lot of applications migrating, and almost none migrating at all. And hell, it just opens up it's own screen so you can still multitask at the same time. Not 'sticking' the GEM interface on the users is only going to 1) hurt the Amiga sales of Atari developers, and 2) hurt Amiga users who would like to have Atari packages. Cad-3D anyone? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jimomura@lsuc.UUCP (Jim Omura) (09/28/87)
In article <1769@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <800@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: ... > >Sure, sure, but when faced with the prospect of porting a GEM application >to Intuition, (I've looked at it, and we're talking some major rewrite here) >many developers will decide it's too much work and just stick to the Atari. Difficulty of porting hasn't been that much of an issue from what I've seen. It's more a matter of some programmers simply wanting to support one computer or the other. Where the programmer has *wanted* to support both, the programs have become available on both. >GEM on the Amiga, silly as it sounds at first, provides an almost >immediate new market for Atari developers with little effort expended on >their part. And GEM is a completely portable windowing system, DESIGNED >to be ported around. TOS weirdnesses and ill-behaved talk-directly-to-hardware >applications present some interesting challenges, but allowing Atari >developers to spend a little time hacking 5% of the code is a lot more >palatable than spending a lot of time hacking 70% of the code. It could >make the difference between a lot of applications migrating, and almost >none migrating at all. The reason TOS was created, as I understand it, was due to the difficulty getting reasonable speed out of GEM under CP/M.\ But CP/M is a very straight forward, *fast* OS. In fact, most of the better ST programs have substituted their own low level routines to get around the slowness of GEM. Flash! has custom RS-232 drivers. Jim Kent's Cyberpaint is almost all custom code. There are others as well. GEM's portability seems to have resulted in slowness. What's more, that problem has create a reality where simply running GEM on the Amiga in itself won't help that much to port the software running under it. > >And hell, it just opens up it's own screen so you can still multitask at >the same time. Not 'sticking' the GEM interface on the users is I've heard knowledgable programs say that you can't multi-task with GEM. I have heard others say you can. I'm tired of hearing speculation. I'll believe it when I see it. >only going to 1) hurt the Amiga sales of Atari developers, and 2) hurt >Amiga users who would like to have Atari packages. Cad-3D anyone? I have CAD-3D. It's nice, but not wonderful. I've seen Sculpt 3D and it also is nice, but not wonderful. Coin toss really. Still, I can't say that Amiga users are desparate to get ahold of CAD-3D. Each has its own strong points, but just for example, Sculpt 3D addresses on of my "holy grail" features -- you can move an individual point! Anybody who has tried to do serious work on CAD-3D knows how important this can be. I would have expected it to be one of the most important things that TH would try to add to CAD-3D version 2, but he didn't do it. I have no idea why. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
peter@sugar.UUCP (Peter da Silva) (10/06/87)
> > Now, a subroutine library that allows you to make GEM > >calls but uses Intuition... that I could see. Did you miss this line? > And hell, it just opens up it's own screen so you can still multitask at > the same time. Not 'sticking' the GEM interface on the users is > only going to 1) hurt the Amiga sales of Atari developers, and 2) hurt > Amiga users who would like to have Atari packages. Cad-3D anyone? You're confusing the users with the developers. The developers can be kept happy with a GEM compatibility library that runs under Intuition. The users need to be presented with as few divergent working environments as possible. For the Amiga, for better or for worse, that means Intuition. I have experience with one ST port already. Music Studio uses a GEM-like interface (touchy menus, one-button-mouse, the whole nine yards), and it's a pain to use. GEM.library would give you all the GEM junk, *and* save memory. How many copies of different menu-handling code do you want, anyway? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.