ewhac@well.UUCP (09/13/87)
In article <1263@dasys1.UUCP> cheeser@dasys1.UUCP (Les Kay) writes: > >If YOU had to write a massive game program for the Amiga and later port >it to the Atari ST and Apple //gs (forget about the gs, that'll be in assembly) >what would you pick as a 'c' development system? I wouldn't. >And why? > Depending on the kind of game you're writing, C may not be fast enough for you, even with a ~8MHz 68K to back you up. You'll probably have to go directly to assembly if you want any kind of respectable speed. Also, machine architectures are fundamentally different. Whereas on the Amiga you have the call BltBitMap(), on the Atari you have the call vfocpyfm() (or some such), both of which take entirely different parameters. A significant fraction of your program's critical path will change dramatically when moving from one machine to another, so you won't really gain much portability by writing it in C. To be fair, if I were writing it, I'd first model all the algorithms in C to make sure I had a working model, then I'd go through the critical path and turn it into handcrafted assembly. Oh, yes. I'd select the Manx package. No reason; just personal bias. Note: The foregoing applies *only* to writing games. A point: Given the (deleted) first paragraph in your posting, I assume that you have never programmed the Amiga in-depth before. If this is indeed the case, I would highly recommend one of two things: 1. Be prepared to set aside *AT LEAST* two months for general hacking time to familiarize yourself with the machine and the full ramifications of the system software. If you think this is an unreasonable learning curve, then, 2. Don't do the project. There's *MUCH* more to the Amiga than you may initially think, and it'll take a long time before you get a handle on The Big Picture. A lot of the good PD programs for the Amiga are the result of many people ascending that learning curvr through long and persistent hacking. It's not a machine you can just walk up to and expect to do a respectable job on the first time. Of course, if you *have* programmed the Amiga in-depth before, you can ignore the previous two paragraphs, since you probably know it already. >Probably reply in mail, unless others here are interested....but as this is >sort of a religous question, we could end up with all sorts of flaming.... > Gosh, I hope I haven't started anything.... _-_-_ Old .signature included to make Andy Finkel and his drill happy. _-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
keithd@cadovax.UUCP (09/17/87)
In article <3941@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
. Also, machine architectures are fundamentally different. Whereas on
.the Amiga you have the call BltBitMap(), on the Atari you have the call
.vfocpyfm() (or some such), both of which take entirely different parameters.
.A significant fraction of your program's critical path will change
.dramatically when moving from one machine to another, so you won't really
.gain much portability by writing it in C.
This will probably be less true as soon as the Amiga port of GEM is
available.
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170peter@sugar.UUCP (Peter da Silva) (09/23/87)
In article <1751@cadovax.UUCP>, keithd@cadovax.UUCP (Keith Doyle) writes: > This will probably be less true as soon as the Amiga port of GEM is > available. Excuse me, but isn't this like porting RSTS to a Sun/3? Why would you want to port something that's so iconsistent with the Amiga user interface? I could go for a GEM-lookalike software interface that lets the program make GEM calls but runs Intuition, but porting GEM over is just going to screw the users by forcing them to learn yet another way of doing things. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
peter@sugar.UUCP (Peter da Silva) (09/23/87)
> 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? 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. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
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
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/29/87)
>... >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. This isn't much of a surprise considering that GEM was originally based on the same principles as PC/MSDOS. PC/MSDOS is so notoriously slow that most good programs for the IBM use custom code for everything but keyboard and disk IO... Most of the disk backup programs use custom code for the disk IO. So while GEM and MSDOS might be 'portable', it turns out you need to duplicate or simulate the underlying hardware anyway to get things to work. Warning to C-A: Unless you fix AmigaDOG, this is what is going to eventually happen on the Amiga as well. (Side Note: It happens on all computers, including the Amiga; I am refering to large scale customization). > 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. Second that. With most programs taking over the Atari's screen anyway, completely integrated multitasking is out. -Matt
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*.
toebes@sas.UUCP (John Toebes) (09/09/88)
|_o_o|\\ |. o.| || Copyright (c) 1988 The Software Distillery. | . | || All Rights Reserved. | o | || | . |// ====== As coordinator of the Software Distillery, purveyors of the finest in Amiga freely redistributable software, I would like to announce the completion of a new project. Two of the Distillery's members, my wife Mary Ellen and myself, have been working on the project since last January (Mary Ellen did most of the actual development, and I supported her efforts). The project came in a little under two weeks late, which is not bad in the world of software development, and seems to be completely bug-free at this point. Unfortunately, this project will not be available for distribution, but you can send a self-addressed stamped mailer and a blank diskette for instructions on reproducing our results on your own. In short, then, this is to announce the newest addition to the Software Distillery lineup: Ann Marie Toebes Born September 8, 1988, 8:16 pm 8 lb, 2 oz 20.5 inches ---- John A. Toebes, VIII usenet:..mcnc!rti!sas!toebes The Software Distillery USnail: 235 Trillingham Ln, Cary NC 27513
richard@gryphon.CTS.COM (Richard Sexton) (09/10/88)
Congrats John, welcome to the sleeplessness club.
Golly, what WAS it about last xmas/newyears ?
And have you noticed that none of those ``other'' micro people don't
seem to, uh, reproduce.
``Only Amiga makes it possible ?''
:-)
--
``Beam THAT between your pointy ears''
richard@gryphon.CTS.COM {backbone}!gryphon!richard