cthulhu@athena.MIT.EDU@caip.RUTGERS.EDU (02/21/86)
From: cthulhu@athena.MIT.EDU
Tim-
Firstly, I think it's great to actually find someone who can do something
about CP instead of just a bunch of hackers complaining to each other...
However... there is no excuse for not making applications runnable under
the workbench. None. On the Mac, it might be necessary to actually
write to the screen memory, to take co ntrol of all the sound channels (all
one of them) or to make unmovable windows, but intuition takes this problem
into account. That's why the Amiga has screens. That's why the Amiga has
exec. I don't know about you, but it detracts a lot from the usefulness of
a game that I can't multitask it with something else (OK, Textcraft, you go
print my document, and I'll play a game... BUT NOT ARCHON OR ANY OTHER EA
GAME, SINCE THEY DON'T MULTITASK) The only real reason I could think of is
that of copy protection ("archon minidos?") I wouldn't mind an occasional
pause for another programs I/O during a game. Please, please set an example
and put evil copy protections like this to rest before they become common
practice!
- Jim Reich
cthulhu@athena.mit.edulbg@gitpyr.UUCP (Lee B Grey) (02/22/86)
In article <1323@caip.RUTGERS.EDU>, cthulhu@athena.MIT.EDU@caip.RUTGERS.EDU writes: > However... there is no excuse for not making applications runnable under > the workbench. None.... > .... That's why the Amiga has screens. That's why the Amiga has > exec. I don't know about you, but it detracts a lot from the usefulness of > a game that I can't multitask it with something else (OK, Textcraft, you go > print my document, and I'll play a game... BUT NOT ARCHON OR ANY OTHER EA > GAME, SINCE THEY DON'T MULTITASK) .... On page 2-10 of the V. 1.1 ROM Kernal Manual, there is a CAUTION: Section 1.2 describes the lowest level graphics interface to the system hardware. If you use any of the routines and the data structures described in these sections, your program will essentially take over the entire display. It will not, therefore, be compatible with the multi-window operating environment, known as Intuition, which is used by AmigaDOS. End-quote. As you can see, the routines used by EA games are not compatible with multi-tasking capabilities. Your Amiga can be a great multi-tasking workstation, or it can be an awesome game machine -- just not at the same time. Lee
dale@amiga.UUCP (Dale Luck) (02/22/86)
In article <1450@gitpyr.UUCP> lbg@gitpyr.UUCP (Lee B Grey) writes: >On page 2-10 of the V. 1.1 ROM Kernal Manual, there is a CAUTION: > >Section 1.2 describes the lowest level graphics interface to the system >hardware. If you use any of the routines and the data structures described >in these sections, your program will essentially take over the entire display. >It will not, therefore, be compatible with the multi-window operating >environment, known as Intuition, which is used by AmigaDOS. > >End-quote. I think I need to clarify this: The section that this caution appears in is the display/viewport area of the manual. The data structures in question are: View,ViewPort,RasInfo. 95% percent of the programmers out there never even bother with this since intuition manages them for you. The routines in question are InitView,InitVPort,MakeVport,MrgCop. Intuition provides these capabilities with its Screens. By using the intuition functions you can get nearly the same results. The low level routines were designed for a single program to manage since they do not suffer the overhead of multitasking protection. That is exactly what intuition does. For example: MakeScreen is a multitasking/protected for of MakeVPort. MakeScreen manages multiple tasks requiring MakeVPorts and preventing them from tromping on each other. When an application needs to double buffer it calles MakeScreen/RethinkDisplay. When the user is moving Screens up and down intuition is also calling MakeScreen/RethinkDisplay. These operations must be done in a safe interleaved manner since these operations recreate lists, allocate memory etc. Thats what intuition provides. The caution does not apply to any of the rendering routines. AreaFill Linedraw,etc. are all the exact same graphics calls. EA could have designed there programs to make use of intuition. But because intuition provides a protective coating around display operations, they are slower. EA must have felt that the slow down was too much. So they had to write there own user interface, and not use intuition. Again I repeat, those graphics routines cautioned against use with Intuition running are only the display routines that it uses directly. And it provided safe interfaces to those routines. Dale Luck Amiga
lbg@gitpyr.UUCP (Lee B Grey) (02/23/86)
In article <732@amiga.amiga.UUCP>, dale@amiga.UUCP (Dale Luck) writes: > In article <1450@gitpyr.UUCP> lbg@gitpyr.UUCP (Lee B Grey) writes: > >On page 2-10 of the V. 1.1 ROM Kernal Manual, there is a CAUTION: > > ... > >It will not, therefore, be compatible with the multi-window operating > >environment, known as Intuition, which is used by AmigaDOS. > > . . . > Again I repeat, those graphics routines cautioned against use with > Intuition running are only the display routines that it uses directly. > And it provided safe interfaces to those routines. I apologize for posting misleading information and making it sound like I knew what I was talking about. I don't. :-) Thanks for setting me straight, Dale. Lee
tenney@well.UUCP (Glenn S. Tenney) (02/24/86)
In article <1323@caip.RUTGERS.EDU> cthulhu@athena.MIT.EDU@caip.RUTGERS.EDU writes: >... >However... there is no excuse for not making applications runnable under >the workbench. None. On the Mac, it might be necessary to actually >write to the screen memory, to take co ntrol of all the sound channels (all >one of them) or to make unmovable windows, but intuition takes this problem >into account. That's why the Amiga has screens. That's why the Amiga has >exec. I don't know about you, but it detracts a lot from the usefulness of >a game that I can't multitask it with something else (OK, Textcraft, you go >print my document, and I'll play a game... BUT NOT ARCHON OR ANY OTHER EA >GAME, SINCE THEY DON'T MULTITASK) The only real reason I could think of is >that of copy protection ("archon minidos?") I wouldn't mind an occasional >pause for another programs I/O during a game. Please, please set an example >and put evil copy protections like this to rest before they become common > practice! > - Jim Reich > cthulhu@athena.mit.edu I've gotten a couple of responses similar to the above. I'd like to respond personally. These are my own opinions and do not necessarily reflect those of EA (I am not an employee of EA btw). Since I've been writing for the Amiga for almost a year now, believe me that it has been difficult. For me, C-A couldn't provide enough info to even use Intuition until almost V1.0, so months of work had to be done with NO planned Intuition support. As to resources, Forbid and OwnBlit are a step in the right direction, but it takes tons of code to stomp on Intuition (and its tasks like Input.Device) and get it out of the way. As to RAW:, well obviously you haven't done much work on the Amiga: it isn't raw enough in a way usable quickly enough (i.e. getting a stream of IDCMP-like characters just to see a key up/down is too slow for a fast moving game). A major point is that games often need to get to the nitty gritty and Intuition et. al. is often simply in your way. If you even get around all of the hurdles put in your way, Intuition, Workbench, their screens and windows and Dos take up a lot of ram. Then there is the question of performance! By doing things through rom calls, it is sometimes MUCH slower than you can do it yourself. Remember the rom must support everyone and you know the one way you want to do it, so you can optimize it. To my knowledge, not using Intuition etc. has nothing to do with copy protection! Don't misinterpret any of this, I think Amiga has done a fantastic job with the software, but it can't be all things to all people both in capabilities and performance. Please note that my personal views here always mentioned games. I think "productivity" software is a completely different situation. (I am an Amiga developer and co-host of the Amiga conference on the Well) -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
rb@ccivax.UUCP (rex ballard) (03/01/86)
I don't know what the situation was a year ago, but it seems hard to believe that your graphics routines are that much different from what is provided. If your graphics routines are that much faster and re-entrant, then make your own Intuition compatible driver and sell it as a separate product. Intuition, and friends have provided a nice, clean, easy to use VDI interface that let's you do practically anything currently popular (including Bit-Blts) and "prima-donna programmers" throw it in the trash!! This is like buying a hamburger and throwing away the meat!!! The old IBM-PC mentality of "Stomp on everything and take over" is not appropriate on a multi-tasking machine. Lotus wrote high speed drivers because there was no efficient default built into the machine. Many PC hackers jumped directly into the BASIC rom because they didn't understand vectoring. DRI, Microsoft, and IBM have all finally come out with their own (different) graphics vector "drivers", but too late for existing applications. Of course, EGA, PGA, and CAD graphics cards are unusable with these older programs. True, it takes a little studying to learn about VDI devices, but that's what software engineering is all about. It took time to learn about symbolic debuggers and full screen editors (if you started with 'ed' and "front panel switches"), but not using them make one less productive than someone who uses them. Even if an "industry standard VDI" is several years away, as it appears to be, the principles are not that much different, and many times the implementations aren't either. How many different ways can you draw a line? Even if there are 5, it's still just <routine name>(<start point>, <end point>). Would you write new code in 8085 assembler and run it through a translator to get 68K code!! :-) The early releases can be excused grounds of incomplete information, but new products should fall in line. To decide at this point that you are going to continue to stomp the operating system to gain 3-5 microseconds over a VDI call is not wise. Run a historgram on a logic analyser and scope the actual overhead of a "Vectored OS call"! It just isn't worth it! Note: I haven't scoped an Amiga so I don't know what it's overhead is, but in the worst OS I've ever seen, the "transition time" for "well behaved" vs. "Disruptive" programs has never been the "hot spot" of the histogram. Either a better, "well behaved driver" (if the hot spot was the driver), or a half-dozen lines of assembler in the application has easily solved the speed problem. If EA has a better device driver, sell it as the "EA Super Whiz-Bang Graphics driver" and give users the benefit of using it in All of their applications. I guess it's not too late to do your own different VDI if you want to, so long as it doesn't stomp on the applications that use the old one (Uses a different vector). It's been said that most applications writers are frustrated OS writers, I know it was true for me (Now I get the "whole box" OS, Drivers, Apps...), and it's really tempting to "play games" with the drivers, but all it does is prevent access to other markets, or raise the stakes to enter them. We all want to run the whole show, but sometimes its better to be a good actor and let the director be the director.