ewhac@well.UUCP (07/10/87)
[ Note this this is not necessarily restricted to EA ]
This is *not* a CP flame, but a flame on other aspects of EA
business practices and the quality of their published products.
I bought DPaint ][ (unprotected). I got it home, and loaded it.
Now, I have the noisy flavor of drive, so I can hear everything that's going
on. I thought the disk was thrashing an awful lot for an unprotected
program.
So I pulled out my sooper-dooper nifty disk utility, 'fm' (it's on
Fish Disk #36), and looked at the sector allocation. The disk was
*horribly* fragmented, and the DPaint executable occupied sectors all over
the surface of the disk.
"This won't do at all," I said, and formatted a new disk. I then
entered a CLI and said, "copy df0: df1: all". My working copy of DPaint now
has a *much* cleaner organization, and the head thrashes minimally when
loading.
This point of all this is that it is *no trouble at all* to have
someone in EA's production department perform this maneuver before
submitting a disk to the duplicators. I personally take some degree of
pride in my work, and if I had a major commercial product on the shelves, I
would see to it that this was done. Otherwise, I would whine about it to my
publisher until they A) did something about it, or B) felt guilty.
More DPaint bashing: The copy of the DPaint art disk I received had
a brush file on it called "building". I loaded it, and on the screen
appeared an image that looked nothing like a building. "Oh well," I
thought, "what they call it is their own business I guess." Then one day, I
was using a friend's copy of DPaint, and just for ducks, decided to load the
"building" brush to see if it was the same. I got a different image from
mine, and this one looked like a building. Doesn't someone at EA check
these things?
DVideo Bashing: I don't own this, but I've seen it in operation. I
know, for example, that the thing is *permanently* fixed in dual-playfield
mode, and you can only get eight colors per playfield. One day, EA shows up
at a FAUG meeting, hawking its new, upgraded-for-1.2 wares. The were
showing off DVideo. I asked, "Is it still restricted to eight colors?" And
the marketroid responded, "Well, because you have two 8-color playfields on
the screen at once, you actually can have up to 16 colors." That's funny; I
only use *four* bitplanes when I write a program needing sixteen colors....
SkyFox Bashing: Boot up SkyFox. Listen to the coverpage music.
All of it. About two-thirds of the way through the music, one of the music
voices runs away from the others and gets about four beats ahead, making it
sound terrible. Again, this is something that could *easily* have been
detected if EA had a respectable Quality Assurance department. The music
bug still exists in SkyFox to this day.
Archon Bashing: Why do I have to unplug my mouse to play Archon by
myself? Surely, Jon Freeman could have used the mouse to move pieces
around. But he chose instead to force the use of a joystick on port one.
Someone in EA should have mentioned this to him.
Marble Madness Bashing (probably beaten to death, but...): Why
is the screen left-justified? Why isn't it centered? Why wasn't the font
from the coin-op version used? Since the game boots by double-clicking on a
WorkBench icon, it seems logical that it should be possible to return to the
WorkBench, but that's not the case. Why isn't there a high-score screen?
Why doesn't my final score from a given game stay on the screen longer?
General EA Bashing: EA claims to offer to its artists a state-of-
the-art program development system. This means an Amiga with a CSA Turbo
rack with the Manx compiler, right? *Wrong!* It means an IBM-AT with the
Lattice cross-compiler.
Without getting into compiler wars, I do not consider this to
be a state-of-the-art development system. First, you're not developing
native, so you have very little feeling for the machine you're writing
code for. By using the machine all the time for everything, you get
up-close-and-personal knowledge of what will guru the machine, and what
won't. You get to know how the machine behaves, and how to write a
product that will obey all the rules. By developing on the AT, you're
divorced from the Amiga, and just think of it as "The Target Machine."
This is not a good mindset to have when writing commercial
applications.
Second, debugging is not as thorough as it should be. Suppose I
write an application native. I run it. It seems to work okay. I exit. It
seems to exit cleanly. "Great," thinks I, and I start up some other
program. The machine crashes. Obviously I mashed something, and start
looking for the problem. Now, suppose I cross-develop an application. I
download (or, in the case from an IBM to an Amiga, upload) the program to the
Amiga. I run it. I seems to work okay. I exit. It seems to exit cleanly.
"Fine," says I, and I move to another task on the IBM. Meanwhile, my
application has mashed something in the Amiga, but *because I don't use it
for everything, I'LL NEVER KNOW ABOUT IT.*
Needless to say, any bug which makes the machine guru will, if
developing native, make that bug get squashed that much faster.
EA should seriously examine these issues. It could well be the root
cause of a lot of the, shall we say, "fluff" in their products.
I could think of other things, but it's getting late. If anyone
sees any blatant flaws in my logic, corrections would be appreciated.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac
O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorhadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) (07/10/87)
In article <3526@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > General EA Bashing: EA claims to offer to its artists a state-of- >the-art program development system. This means an Amiga with a CSA Turbo >rack with the Manx compiler, right? *Wrong!* It means an IBM-AT with the >Lattice cross-compiler. Well, not completely true. I agree that native development is superior to cross-development, although both is even better (having an AT to run the remote debugger is great.) I personally have always done native development, and I think you are right, it has contributed to the general reliability of the stuff I've done on the Amiga. EA, however, developed the AT cross-development workstations because they were committed to Amiga development long before prototype machines were available. I should note that they put a large fraction of their development staff on the Amiga out of pure faith in the machine and a desire to work in a state-of-the-art environment, despite the fact that it was very iffy at the time whether the Amiga would even get to market at all. I should note that this was a great risk taken by EA, and it was not at all a money-driven decision (they had most of their top developers working on the Amiga way back before it was even a news item to most people). The AT stations were necessary because there was nothing else to develop on; they were running a simulation of an Amiga on an AT. Later they turned it into a cross system, which many people there still use, but not all. They have long known of the advantages of the Manx compiler, and many (I'm not sure how many) of them have switched (including Dan Silva, for DPaint II). > EA should seriously examine these issues. It could well be the root >cause of a lot of the, shall we say, "fluff" in their products. I agree. There is a good argument for native; I prefer native---but note that EA had put in a lot of effort getting tools for people to use on the cross systems, and it was some time before alternative native environments were available. (Also, many of them *bought* their ATs, and in the middle of projects to switch to native would have been a pain.) As I say, people like Dan Silva have switched to Manx, so others may have too (I haven't been around there recently.) -Mitsu
jmpiazza@sunybcs.uucp (Joseph M. Piazza) (07/11/87)
In article <2507@husc6.UUCP> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >In article <3526@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> General EA Bashing: ... > >... I should note that [EA] put a large fraction of their >development staff on the Amiga out of pure faith in the machine and >a desire to work in a state-of-the-art environment, despite the >fact that it was very iffy at the time whether the Amiga would even >get to market at all. I should note that this was a great risk >taken by EA, and it was not at all a money-driven decision ... Though EA's early commitment to the Amiga is admirable, ultimately, it IS a money decision. Sure, there's a risk but don't forget the pay-off if they're successful. Right, Perry? Mitsu, I'm curious as to why you are so staunchly supportive of EA especialy in the face of the sheer volume of boo-boos EA has made on so many labeled programs. The only EA program I ever intended to buy was Marble Madness, which I did. I'm quite satisfied with the game, but I hate the copy protection that kept me from making a backup copy, prevents me from copying it to my 1.5 Meg of RAM; making me twiddle my thumbs while it grinds away the disk loading each level, and doesn't even help me keep track of steadily improving scores over time. I don't plan to buy another program from EA since they all seem to have similar or worse shortcomings. And from what I gather, I'm not missing much aside from frustration and aggravation. I was truly amazed and ironically amused when I received a flyer in the mail from EA advertising a copy protected upgrade to DP II and V something-or-other for $20 and an unprotected upgrade for $50! It appears that EA is offering to share some risk for a $30 discount. (Keep up the good work, Leo). Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@cs.buffalo.edu BI: jmpiazza@sunybcs
tenney@well.UUCP (Glenn S. Tenney) (07/15/87)
Disclaimer: I'm not now doing a project for EA, but I did an
Amiga project that shipped over a year ago for EA...
It is easy to "bash" people at this time. When I started my project,
we were working with black boxes at V21 or so, and no DOS, Intuition,
etc. What do you do at that time: You use a Sun or develop your own
development system. I think we can all understand how expensive a
single user Sun system was 2-3 years ago, compared to a PC-XT, so when
you have 10-20 people EACH needing a development system, the answer is
obvious.
Yes, if you USE your target machine alot you get a better feeling for
the environment. Because of what I mentioned above, there was nothing
I could do with my black box effectively, so... Now, it's a different
story.
I don't know what Dan Silva is using now for development, but a couple of
months ago he was using an AT with a cross development Manx system. The
native Manx system is great, but there are times you need a logic analyzer and
a cross development system is a good middle ground.
Then, there is the point of utilities and peripherals. I can outfit a PC
clone with 20 meg hard disk for less than the cost of a hard drive
alone for the Amiga. I'm using an A2000 with hard disk right now and
let me tell you what it's like NOT having an effective backup capability
as I do on my PC based systems.
All in all, there are reasons for both methods of development and I
don't think your (Leo) bashing reflects a mature analysis of the data.
This is NOT to say that I agree with everything that EA does, quite the
contrary! I personally hate copy protection and tried to get my
project out without it, to no avail. The pipeline is long, and some of
the problems you experienced were found and corrected quickly, but the
effect takes time. It is quite different to correct an error in a
shipment of 500 or a 1000 versus 20,000 or 50,000 units! Leo also
mentioned some comments about disk fragmentation. Ok, even the best of
us are human and might forget to rebuild the entire disk from scratch; or
maybe not everyone has the tools to see what's going on, but ...
Whew, much longer than I figured or expected. Sorry, but...
-- Glenn Tenney
UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney
ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY
As Alphonso Bodoya would say... (tnx boulton)
Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!kinner@wsucshp.UUCP (Bill Kinnersley ) (07/16/87)
In <3526@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > First, you're not developing > native, so you have very little feeling for the machine you're writing > code for. By using the machine all the time for everything, you get > up-close-and-personal knowledge of what will guru the machine, and what > won't. You get to know how the machine behaves, and how to write a > product that will obey all the rules. By developing on the AT, you're > divorced from the Amiga, and just think of it as "The Target Machine." > This is not a good mindset to have when writing commercial > applications. By the same token, I would like to encourage us "natives" to experience the real flavor of the machine, and use the Workbench once in a while. It's great that we have both line-oriented and visual interfaces available, but I think that many programmer-types who sit and use the CLI all day eventually come to think of the Workbench interface as being solely for little kids and computerphobes. Instead of a "Target Machine", you're writing for a "Target User." I think many of the programs out there would have been much easier to use if the author had been forced to become a user himself for a while. > Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ > \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac > O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") > "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor ----------- O <- If .signature is too large, click here to iconify "Nesting is for the birds" --Bill Kinnersley USENET: ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!kinner INTERNET: kinner%wsu@RELAY.CS.NET CSNET: kinner@cs1.wsu.edu MAIL: CS Dept, Washington State Univ, Pullman WA 99164-1210 PHONE: (509)332-4008