bart@amiga.UUCP (Barry A. Whitebook) (10/24/87)
[eat this line -- please!] this is amiga!bart in article <1793@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) states: > According to Carolyn at CBM, this has been a problem > because the MaxXMouse etc. values are in 'don't mess with it' space in > IntuitionBase. Carolyn indicated they may be coerced into not moving this > stuff because there is presently no alternative but to modify these values > and we need the functionality. it is NOT only a matter of not moving the information... when intuition says DO NOT MODIFY there is good reason for it... even intuition must follow a locking protocol whenever it messes with internal variables to prevent unpleasant side effect... so: "don't mess with these" really means: "DON'T MESS WITH THESE" (of course, we *may* be induced into providing system-approved means to modify the information in a future/near-future rom release) thank you for your continued support... -- //----------------------------------------------------- ----------\\ //| Bart Whitebook, Manager of Amiga ROM Software | {|V|))) |\\ | Commodore-Amiga, Inc. | ()^()-)))| | 16795 Lark Avenue, Suite #106, Los Gatos, CA 95030 | /_ ?))| | UUCP: pyramid!oliveb!amiga!bart | { _ } )\ | | BIX: amiga_bart | \ // | \\|_____________________________________________________|__\//____ |// \\ //
keithd@cadovax.UUCP (Keith Doyle) (10/26/87)
In article <1961@amiga.amiga.UUCP> bart@amiga.UUCP (Barry A. Whitebook) writes:
.this is amiga!bart
.> According to Carolyn at CBM, this has been a problem
.> because the MaxXMouse etc. values are in 'don't mess with it' space in
.> IntuitionBase. Carolyn indicated they may be coerced into not moving this
.> stuff because there is presently no alternative but to modify these values
.> and we need the functionality.
.
.it is NOT only a matter of not moving the information... when intuition
.says DO NOT MODIFY there is good reason for it... even intuition must follow
.a locking protocol whenever it messes with internal variables to prevent
.unpleasant side effect... so:
.
. "don't mess with these"
.
.really means:
.
. "DON'T MESS WITH THESE"
.
.(of course, we *may* be induced into providing system-approved means to modify
. the information in a future/near-future rom release)
That still doesn't address the immediate problem, which is we need the
functionality, and IMMEDIATELY as our program is going out in 2 weeks.
Right now it patches MaxXMouse and MaxYMouse to adjust the centering for
overscan screens. It works fine, but isn't approved. It's going to hit
the streets that way if you can't tell us how it should be done better,
and within the next 2 weeks.
If you can tell me *how* I can use a locking protocol to prevent 'unpleasant
side-effects' then great. Otherwise, save it, as you're not addressing the
problem. If DPaint had waited until version 1.3 comes out, we'd all have
machines running lo-res paint programs right now. Now you're going to
stick it to me just like you stuck it to Dan Silva by making us have
to re-release our software the 'correct' way when it breaks after the
new release comes out. Well, I think this SUCKS!!!! No wonder the Amiga
has such a lousy rep for buggy packages.
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170bryce@hoser.berkeley.edu (Bryce Nesbitt) (10/27/87)
In article <1825@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <1961@amiga.amiga.UUCP> bart@amiga.UUCP (Barry A. Whitebook) writes: >. >. "DON'T MESS WITH THESE" >. >That still doesn't address the immediate problem, which is we need the >functionality, and IMMEDIATELY as our program is going out in 2 weeks. >Right now it patches MaxXMouse and MaxYMouse to adjust the centering for >overscan screens. It works fine, but isn't approved. It's going to hit >the streets that way if you can't tell us how it should be done better, >and within the next 2 weeks. Nobody is going to like this solution much, but you will have to admit it should work: Check the version of Intuition (IntuitionBase->LibNode.lib_Version): If less than 33, post a requester saying "Requires at least Kickstart V1.2". If it is 33 or 34 then do the above kludge. If it is *above* 34, then assume that the bug has been fixed, or at least the IntuitionBase *has* changed, and thus cannot be messed with. (I call it a bug because I highly suspect a change to the OS will render your problem null and void) For Your Information, here are the Version numbers as I understand them: 30 ;V1.0 31 ;V1.1 32 ;V1.1 (with PAL video support) 33 ;V1.2 34 ;V1.21 (Adds hard disk boot support to V1.2.. NOT AVAILABLE YET. I KNOW NOTHING ELSE ABOUT IT. PATIENCE IS A VIRTUE. DON'T WORRY ABOUT WHEN IT MIGHT BE RELEASED. DON'T FLOOD THE NET WITH QUESTIONS!) This solution is *slightly* better than just mashing Intuition's private data structure. BTW: The "LockIBase(0L)" call can be used to disable Intuition temporarily while doing wild things. Again it is not good to do such things, but at least try to protect yourself. Example: long key; key=LockIBase(0L); /* Do funny stuff here... but not much of it... be QUICK! */ UnlockIBase(key); Flakey software comes about in part because people break rules like the above mouse fields. I can sympathize with your need to release a product. On the other hand I once did an Operating System upgrade project where everyone had been playing with reserved bits, undefined entry points, undocumented features etc. It's hell to work on a system like that. I'd like to see the Amiga grow and improve... it can't if people insist on breaking the rules too often. All I'm saying is take care and tread lightly... >Keith Doyle ># {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170 |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U "Fanitic: One who can't change his mind, and won't change the subject."
andy@cbmvax.UUCP (Andy Finkel) (10/27/87)
In article <1825@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <1961@amiga.amiga.UUCP> bart@amiga.UUCP (Barry A. Whitebook) writes: >.this is amiga!bart >.> According to Carolyn at CBM, this has been a problem >.> because the MaxXMouse etc. values are in 'don't mess with it' space in >That still doesn't address the immediate problem, which is we need the >functionality, and IMMEDIATELY as our program is going out in 2 weeks. I think the important point here is that you've been warned. Using these fields will result in broken software in a future revision. When it breaks, it shouldn't be a surprise to you. >Right now it patches MaxXMouse and MaxYMouse to adjust the centering for >overscan screens. It works fine, but isn't approved. It's going to hit >the streets that way if you can't tell us how it should be done better, >and within the next 2 weeks. A threat ? Oh well. While that logic forced us to freeze the C64 roms much too early, it doesn't cut much ice these days. We've warned you what not to do. If you do it anyway, there's not much that I can do about it. Your software will break in a future release, and I'm sorry about that, both from your point of view, and from the point of view of the Amiga itself. But the alternative, freezing random kluges into the OS forever and ever is worse. >If you can tell me *how* I can use a locking protocol to prevent 'unpleasant >side-effects' then great. Otherwise, save it, as you're not addressing the >problem. >If DPaint had waited until version 1.3 comes out, we'd all have >machines running lo-res paint programs right now. Now you're going to >stick it to me just like you stuck it to Dan Silva by making us have >to re-release our software the 'correct' way when it breaks after the >new release comes out. I think that Dan had other improvements in mind when he released DPII. (because DPIseems to run on V1.2, if you remove its copy protection) > Well, I think this SUCKS!!!! No wonder the Amiga >has such a lousy rep for buggy packages. Actually, its people who expect kluges to hang around forever that give a computer a rep. for buggy packages. You see, freezing an OS (until its perfect) hurts you more. Jim and I talked about releasing the extended IntuitionBase information before he did it. He felt it would be valuable for people debugging their programs. I warned him that people would use it in the programs themselves, and complain bitterly if it ever changed. (Kind of like people making direct calls into the C64 ROM...which prevented us from improving them!) (See, Jim, I was right :-) ) Well, it still isn't going to happen on this machine. We're *not* going to freeze the OS. If you do the things we've asked you not to do, then you'll have to release a new version next OS release. >Keith Doyle BTW, can I interest you in a MiniDos ? :-) * andy (* EA hackers will know of what I speak) -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
keithd@cadovax.UUCP (10/28/87)
In article <21469@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >Nobody is going to like this solution much, You got that right. >but you will have to admit it should work: Well, it won't BREAK anything once 1.3 is out, but that is because it is designed to STOP WORKING then. >Check the version of Intuition (IntuitionBase->LibNode.lib_Version): >If it is *above* 34, then assume that the bug has been fixed, or at >least the IntuitionBase *has* changed, and thus cannot be messed with. >(I call it a bug because I highly suspect a change to the OS will render >your problem null and void) You're implying that in 1.3, if you do an OpenScreen() of an overscan screen, that MaxXMouse and MaxYMouse will automatically be adjusted appropriately. If that is true, then yes, your fix should do the trick. I tend to doubt that C= is willing to guarantee this. (and at *exactly* what version number?) >This solution is *slightly* better than just mashing Intuition's private >data structure. Assuming the "bug" is fixed in Intuition version 35. (or some known version) >BTW: The "LockIBase(0L)" call can be used to disable Intuition temporarily >while doing wild things. Again it is not good to do such things, but at >least try to protect yourself. Example: >long key; > > key=LockIBase(0L); > /* Do funny stuff here... but not much of it... be QUICK! */ > UnlockIBase(key); Sounds reasonable. Is this any better/worse/different than doing a Forbid()/Permit() or an Enable()/Disable() ? >I'd like to see the Amiga grow and improve... it can't if people insist >on breaking the rules too often. Or if Commodore insists on a "I'm sorry, we don't support that feature" response to stuff like this. > All I'm saying is take care and tread lightly... And carry a big stick. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (10/28/87)
In article <2631@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Actually, its people who expect kluges to hang around forever that >give a computer a rep. for buggy packages. I don't expect kludges to hang around forever, but you are telling me "we don't support overscan, so do so at your own risk" when at the same time, all the customers are saying "do you support overscan? we need overscan! Package X and package Y support overscan, so what's the problem?" And the problem is, we support some features the other packages don't, that if you do in overscan I have to monkey around to make work, because C= doesn't support overscan. If as Bryce postulates, the fact that MaxXMouse and MaxYMouse aren't automatically updated when you OpenScreen() an overscan screen is considered a BUG, and is to be fixed in a future OS release, that's a different story, and Bryce had a reasonable and helpful idea of a work around. All I am hearing from C= right now is "tough!" effectively. >You see, freezing an OS (until its perfect) hurts you more. I agree. I wasn't assuming that was the only alternative. >If you do the things we've asked you not to do, then you'll have >to release a new version next OS release. All I'm saying is "ok, I don't want to do what I'm not supposed to do, but HOW DO I DO WHAT I NEED TO DO?". So far, the C= answer has been "you can't". I'm sorry, but that's the WRONG ANSWER. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
andy@cbmvax.UUCP (10/29/87)
In article <1831@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>In article <2631@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >I don't expect kludges to hang around forever, but you are telling me >"we don't support overscan, so do so at your own risk" when at the >same time, all the customers are saying "do you support overscan? we >need overscan! Package X and package Y support overscan, so what's >the problem?" If Johnny's mother let him jump out the window, I suppose you'd want to, also. >And the problem is, we support some features the other >packages don't, that if you do in overscan I have to monkey around >to make work, because C= doesn't support overscan. We're being fair about this; if they do it, they might break. If you do it, you might break. >and Bryce had a reasonable and helpful idea of a work around. All I >am hearing from C= right now is "tough!" effectively. Nope, we say "You've been warned" >All I'm saying is "ok, I don't want to do what I'm not supposed to do, >but HOW DO I DO WHAT I NEED TO DO?". So far, the C= answer has been >"you can't". I'm sorry, but that's the WRONG ANSWER. The answer isn't "you can't". The answer was, if you do this, a future Intuition release might break your software, because private Intuition things may have to change, things unrelated to overscan. It is the right answer. If the OS can't do what you need it to do, but you can kluge your way around it, its *your* choice to do it. Demanding that Intuition magically start supporting overscan in a nice manner is singularly non-productive. Everyone who is kluging in overscan support via manipulation of private intuition data structures evaulated the risks, and made their decision. But don't ask us to support it forever. In a perfect world we would have got it right the first time. >Keith Doyle ># {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170 -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
andy@cbmvax.UUCP (Andy Finkel) (10/29/87)
In article <2658@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >In article <1831@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>>In article <2631@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >>All I'm saying is "ok, I don't want to do what I'm not supposed to do, >>but HOW DO I DO WHAT I NEED TO DO?". So far, the C= answer has been >>"you can't". I'm sorry, but that's the WRONG ANSWER. You might try the morerows trick. It may or may nor do what you want...(yell at me later, Dale :-) ) andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jimm@mitsumi.UUCP (Jim Mackraz) (10/30/87)
In article <1831@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <2631@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >>If you do the things we've asked you not to do, then you'll have >>to release a new version next OS release. >All I'm saying is "ok, I don't want to do what I'm not supposed to do, >but HOW DO I DO WHAT I NEED TO DO?". So far, the C= answer has been >"you can't". I'm sorry, but that's the WRONG ANSWER. This is not all you have been saying. You have been implying that CBM is thwarting your attempts to develop software, and that the position that CBM takes leads to buggy applications. You have been taking a position that if your program breaks on v1.3 CBM will have noone to thank but themselves. Unfortunately, the correct answer *should have been*, "You Can't, PERIOD," rather than to support people who were trying to figure out a way to make it work with 1.2, because there are people out there (you, Keith) who think that any hack they see in some product is all at once supported for all time. You seem to miss the point that this is simply not so. There are lots of things that are not supported, such as font control for string gadgets. There are worse things than overscan, such as booting from hard disks. It becomes increasingly hard to support things in the future if every side effect of use of non-public data structures is going to be supported. It wasn't any mystery to us that 1.2 does not adequately support overscan. Unfortunately, as I said, the fact that some people found a way to make it work with 1.2 (the officially suggested way was to use one's own personal View for *displaying* large pictures, but not to try to get Intuition to support them as screens), seems to mean to some people (you, Keith) that Commodore is being difficult. You really piss me off Keith. It is people like you, Keith, that make it impossible to distribute source to Intuition and the like. If the private fields of IntuitionBase were not made available for your reference, you would never have figured this hack out and been such a jerk, right? Right, Keith, huh? Your crack that CBM not pledging to support the overscan hacks is one reason that the Amiga has a reputation for buggy applications ranks as one of the most bass-ackward comments I have heard from anyone not Jerry Pournelle (who thought that all processor exceptions were caused by the OS because they result in an alert). I think you lose a lot of currency with people closely involved with the system when you pull that sh*t. If I knew how to do overscan using supported data structures (I have some ideas) I wouldn't be too inclined to share them with you. >Keith Doyle ># {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170 jimm -- Jim Mackraz Mitsumi Technology, Inc. 408/980-5422 {amiga,pyramid}!mitsumi!jimm
bryce@hoser.berkeley.edu.UUCP (10/30/87)
In article <1830@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <21469@> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > >>BTW: The "LockIBase(0L)" call can be used to disable Intuition temporarily >>while doing wild things. Again it is not good to do such things, but at >>least try to protect yourself. Example: ^^^^^ >>long key; >> key=LockIBase(0L); >> /* Do funny stuff here... but not much of it... be QUICK! */ >> UnlockIBase(key); > >Sounds reasonable. Is this any better/worse/different than doing a >Forbid()/Permit() or an Enable()/Disable() ? It is much better. LockIBase(0L); will force your task to wait until Intuition is done doing things like, say, dragging a screen. If you just Forbid() or Disable() you might catch Intuition in the middle. You are going to get a lot of hostility from Amiga programmers if you release a product that mucks with the Intuition private data structure. I speak for many of them when I say that *WE* want Commodore to release an updated private data structure next release. If *you* screw with this, *WE* are going to be upset. In fact, I rather hope Commodore scrambles that structure in the next release... just so programs that break the rules get broken. (That would be as of Intuition version 35). It is far better to clean up the software base now than be crippled in the future. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U "I never said you _could_, I merely said you _should_." -Humpty Dumpty
shs@ji.Berkeley.EDU.UUCP (10/30/87)
In article <1830@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >> key=LockIBase(0L); >> /* Do funny stuff here... but not much of it... be QUICK! */ >> UnlockIBase(key); > >Sounds reasonable. Is this any better/worse/different than doing a >Forbid()/Permit() or an Enable()/Disable() ? YES!!! The main difference is that LockIBase allows other tasks to run (except ones that want to LockIBase also). Forbid() prevents other tasks from running. This may be necessary for some programs, but should be used as little as possible. In all cases if LockIBase() is sufficient, use it over Forbid (it should be sufficient for any Intuition meddling). Disable() is the worst of the three and prevents other interrupts from occurring. This means trackdisk, video, timers, etc. For passing data (semaphores) between user processes, Forbid() is sufficient, unless you think some interrupt handler is going to mess with your data. *** I cannot stress enough a frugal use of Forbid()/Permit(). Many programmers don't think too hard about this and just stick it in for safety. If you are running a multiple processor configuration, this means that all processors must stop. I'm not kidding here. Think about tasks on a stock Amiga that you will be halting. Then think ahead some more. In the not too far future, there will be multiple processors running in Amiga cards, and the only way to deal with a Forbid() on one is to stop them all. Although necessary for some applications, this is very painful. Please be a good citizen and limit Forbid and Disable as much as possible. Steve Schoettler
peter@sugar.UUCP (10/30/87)
Is it considered kosher to play with the copper lists the way, for example, Marauder // does (for its rainbow background)? I hope not... 'cos that will hurt you should you ever support Intuition on other display cards. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
jimm@mitsumi.UUCP (Jim Mackraz) (10/31/87)
In article <21519@ucbvax.BERKELEY.EDU> shs@ji.Berkeley.EDU.UUCP (Steve Schoettler) writes: )In article <1830@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: )>> key=LockIBase(0L); )>> [ do protected processing ] )>> UnlockIBase(key); )> )>Sounds reasonable. Is this any better/worse/different than doing a )>Forbid()/Permit() or an Enable()/Disable() ? ) ) YES!!! ) ) The main difference is that LockIBase allows other tasks to run )(except ones that want to LockIBase also). ) [ other valuable comments ] )Steve Schoettler This misses a key point which Bryce's posting got right, but deserves further emphasis. Before I go on, let me say that using semaphores rather than Forbid/Permit is important, and Steve's comments are 100% correct about that, I think. Whether Forbid/Permit or ObtainSemaphore/ReleaseSemaphore (which is LockIBase() amounts to) are used to arbitrate shared data between multiple tasks, it is generally necessary that all tasks use the same arbitration method. In this case, if Intuition says LockIBase() and starts walking down the list, if you come with a Forbid(), this keeps intuition locked out, but either a) IntuitionBase may not be in a stable state: linked lists may be in the process of corruption or b) Intuition will crash when it regains control because you have invalidated an assumption about IntuitionBase that is has temporarily made (e.g. removed the node in a list that Intuition was working on when interrupted). Now it turns out that most of the time, there won't be a problem, because Intuition runs at a higher priority than your tasks (normally), so it tends to run to completion (i.e., past UnlockIBase()) before you can get in with your Forbid(). But if Intuition waits for the Blitter or other resource (or for a lock held by yet a third task), Intuition gets blocked, your task might run, and POOF! Note that I don't recommend using priority as an arbitration technique in any case. Note also that using Forbid/Permit as the arbitration mechanism is what made Intuitions prior to 1.2 highly unstable. This is because waiting for a signal or the blitter (ie calling Wait()) RELEASES the hold of Forbid(), so a competing task can get in and run. Lessons: Forbid/Permit simply do not arbitrate operations on data if the function Wait() may be (even indirectly) called. Note that LOTS of system functions call Wait() one way or another. Forbid/Permit don't arbitrate data operations where they might (like walking linked lists) unless ALL USERS of the data use Forbid/Permit which Intuition does not do. Semaphores work good, if everyone uses them. LockIBase() uses the Signal Semaphores, functions including ObtainSemaphore() and ReleaseSemaphore(). And as Steve stressed, semaphores lock just the data they are supposed to, without shutting out other tasks needlessly. Learn 'em, use 'em, love 'em. That lock-a-billy guy, jimm -- Jim Mackraz Mitsumi Technology, Inc. 408/980-5422 {amiga,pyramid}!mitsumi!jimm
peter@sugar.UUCP (Peter da Silva) (11/02/87)
Here are some things I want to mess with. The mouse port. I want to put a joystick in it. How can I do this without blowing away intuition? If I do blow it away, what part of it do I blow away? Can I keep using some of it? What happens if I do blow it away and I get a disk error? The device list. I want to get a list of devices on the system. In fact, I do get a list of devices on the system... see "VolList.c" in my programs "Instant Application" and "Standard File". Is this kosher? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
john13@garfield.UUCP (11/03/87)
-- If, as was said before, the Intuition fields are automatically set correctly if the Workbench screen is in overscan, why not ship your program on an overscan Workbench disk of the correct screen size? John -- "...and intuition, in a case such as this, is of crucial importance." -- William Gibson, _Count_Zero_
keithd@cadovax.UUCP (Keith Doyle) (11/06/87)
In article <2659@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >You might try the morerows trick. It may or may nor do what you >want...(yell at me later, Dale :-) ) Ok, what is the morerows trick? I thought it just modifies the system-configuration, and then Intuition sets up the MaxXMouse/MaxYMouse. Unfortunately, I need to do it without requiring a reboot. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (Keith Doyle) (11/06/87)
In article <663@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes: >In article <1831@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>All I'm saying is "ok, I don't want to do what I'm not supposed to do, >>but HOW DO I DO WHAT I NEED TO DO?". So far, the C= answer has been >>"you can't". I'm sorry, but that's the WRONG ANSWER. > >This is not all you have been saying. You have been implying that >CBM is thwarting your attempts to develop software, and that the >position that CBM takes leads to buggy applications. You have been >taking a position that if your program breaks on v1.3 CBM will >have noone to thank but themselves. Alright, so my first message may have been a little high in the flamage department. I wouldn't say CBM is "thwarting" here, but I wouldn't say they were "supportive" either. If developers have to resort to unauthorized hacks because of deaf ears at CBM, I would say that CBM *can* thank itself to some degree. Look at the PC. Everyone bypassed the BIOS to do screen I/O because as soon as one developer did it, everyone expected all the packages to have faster screen I/O. Was it WordStar's fault (or whoever started perpetuating it)? Or might IBM have nipped it in the bud by proposing some way to do screen I/O that wouldn't box them all in (including IBM) to the same hardware. But I guess they would have had to think a little bit on their feet, and IBM doesn't move very fast. >Unfortunately, the correct answer *should have been*, "You Can't, PERIOD," >rather than to support people who were trying to figure out a way to make >it work with 1.2, Try telling that to someone in marketing. >because there are people out there (you, Keith) who >think that any hack they see in some product is all at once supported for >all time. You seem to miss the point that this is simply not so. Why do you think I tried to bounce it off of you guys? So you could protect yourself against unauthorized hacks by suggesting a way that might not screw up on future OS versions. Instead, you apparently would rather protect yourselves by reserving the right to say "I told you so" if customers complain. Once a product exists that supports a feature that was produced by a hack, it becomes the status-quo, as the competition and any compatible programs then MUST support these same features to survive. This is expected by the CUSTOMERs, and we all know "The customer is always right". We have such a situation right now: 1. DeluxePaint II and VideoScape 3D both support overscan screens. 2. There is no Commodore-Approved mechanism for moving the mouse over the full surface area of overscan screens, when the boot disk itself does not boot up overscan (if it is even then). 3. A program that propends full DPaint II and VideoScape 3D compatibility, and provides mouse interaction, is about to be released. 4. Most end-user customers have no understanding of any technical difficulties caused by any of these issues (which are all self- imposed software limitations) and will expect such features. >Unfortunately, as I said, the fact that some people found a way to make >it work with 1.2 (the officially suggested way was to use one's own personal >View for *displaying* large pictures, but not to try to >get Intuition to support them as screens), seems to mean to some people >(you, Keith) that Commodore is being difficult. >You really piss me off Keith. It is people like you, Keith, that >make it impossible to distribute source to Intuition and the like. >If the private fields of IntuitionBase were not made available for your >reference, you would never have figured this hack out and been such a >jerk, right? Right, Keith, huh? Well, I suppose I could just have told everyone that it's an Intuition "bug" that when you go to 364x220 (or whatever) that you're still stuck with a 320x200 mouse area. But that wouldn't be very supportive of my customer, me passing the buck like that now would it? >Your crack that CBM not pledging to support the overscan hacks >is one reason that the Amiga has a reputation for buggy applications >ranks as one of the most bass-ackward comments I have heard from >anyone not Jerry Pournelle (who thought that all processor exceptions >were caused by the OS because they result in an alert). I think you >lose a lot of currency with people closely involved with the system >when you pull that sh*t. When CBM is not responsive to the demands of the customer, they lose a lot of currency with the customers. Personally, I think it's more important to keep currency with customers than anyone else. I could have just kept my mouth shut, but I had the mistaken idea that you guys might be helpful with a situation which I have no control (ok, I guess I have the "control" to decide to give up and go home, or to strip my package of significant features, or blame limitations on Intuition "bugs" or see if I can move to the MAC II or something, but that's not quite what I had in mind). >If I knew how to do overscan using supported data structures (I have >some ideas) I wouldn't be too inclined to share them with you. See above. I am responding to customer demands, and I have no choice but to do whatever it takes. I think your attitude is *exactly* why developers have been boxed into producing applications which break under new OS releases and has given the Amiga a reputation for buggy software. It has nothing to do with whether overscan hacks are supported or not, but everything to do with whether or not CBM is helpful and supportive to developers who are trying to meet customers needs and expectations. What say the rest of you, gang? Should I be postponing the release of such a product till 1.3? Till I can port to the Mac II? Should I just tell everyone "Hey, I had a great idea for this fantastic product on the Amiga, was 2 weeks to release on the product, but then I found out it can't be done on that machine" ? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
cmcmanis%pepper@Sun.COM (Chuck McManis) (11/06/87)
In article <1845@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <2659@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >>You might try the morerows trick. It may or may nor do what you >>want...(yell at me later, Dale :-) ) > >Ok, what is the morerows trick? I thought it just modifies the >system-configuration, and then Intuition sets up the MaxXMouse/MaxYMouse. >Unfortunately, I need to do it without requiring a reboot. Keith, and others in this bind. Consider the following ... One of the problems with 'overscan' is that not all monitors can handle it. That means that if you put the screen into what you think is a reasonable overscan mode, the image may very well be off the edges of the screen of some users. So how can you know ahead of time that what the users screen can handle ? You CANT! However, when the *user* resizes his screen intuition picks this up and you don't have to do anything different in your program, just open a screen to the smaller of your maximum desired screen/window size -or- the maximum intuition screen/window size. The mouse will always travel to *all* parts of this screen! When looking at it this way, the answer becomes obvious (to me at least). For pre-1.2+ systems you supply morerows ( which last time I checked was freely redistributable) and explain to the user how to set up the maximum screen size that they are comfortable with on their monitor. Then your application is 'well behaved' and doesn't open a window or screen bigger than ( GfxBase->NormalDisplayColumns, GfxBase->NormalDisplayRows ). It's supported, and will work in this and all future releases because you have only used *public* variables in the GfxBase structure and when overscan is officially blessed and supported Commodore will undoubtedly provide a means for the user to set up the maximum sized screen their display can handle. As a suggestion to Commodore, why not provide a 'sizing' gadget on the screen positioning box in preferences ? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
keithd@cadovax.UUCP (Keith Doyle) (11/06/87)
In article <4112@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >-- >If, as was said before, the Intuition fields are automatically set correctly >if the Workbench screen is in overscan, why not ship your program on an >overscan Workbench disk of the correct screen size? Except that only the end user knows what the "correct" screen size is, and it may be different from invocation to invocation. What my program does, is set up the screen based on an IFF file it is given, which can vary from one invocation of the program to the next. There is no "correct" screen size in the case like this because it is 100% dynamic. In fact, it can even vary during a single invocation. With my program you can preload IFF files of varying sizes (resolutions) and switch between them, thereby allowing a mix of overscan and non-overscan images if desired. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
farren@gethen.UUCP (Michael J. Farren) (11/07/87)
In article <1846@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >Once a product exists that supports a feature that was produced by a hack, >it becomes the status-quo, as the competition and any compatible programs >then MUST support these same features to survive. This is expected by >the CUSTOMERs, and we all know "The customer is always right". Wrong. Once a program exists that supports a feature produced by a hack, that program is in deadly danger of breaking at the next OS release, as had been found out, sadly, by many vendors of Apple ][ software, Mac software, Atari software, IBM software, and endlessly on. The culprits include some of the biggest names around, not just hackers. > 4. Most end-user customers have no understanding of any technical > difficulties caused by any of these issues (which are all self- > imposed software limitations) and will expect such features. Wrong. End users do not understand these limitations, and quickly learn to adapt to the limitations as they use the software. >Well, I suppose I could just have told everyone that it's an Intuition >"bug" that when you go to 364x220 (or whatever) that you're still stuck >with a 320x200 mouse area. But that wouldn't be very supportive of my >customer, me passing the buck like that now would it? No, but it would be a lot more honest. Better yet, don't talk in terms of Intuition "bugs" to the customer at all. Just tell her that the mouse is limited to the 320x200 area, and provide other means of doing what you mean to do. Use your imagination, rather than deriding CA simply because they don't agree with YOUR vision. >When CBM is not responsive to the demands of the customer, they lose a >lot of currency with the customers. And when Keith Doyle is not responsive to the demands of the customer, by providing software which will break as soon as a new OS release comes out, he loses even more. They won't think it's Commodore's fault, they'll think it's YOUR'S. >What say the rest of you, gang? Should I be postponing the release of >such a product till 1.3? Till I can port to the Mac II? Should I just >tell everyone "Hey, I had a great idea for this fantastic product on the >Amiga, was 2 weeks to release on the product, but then I found out it >can't be done on that machine" ? How about figuring a way to do whatever it is that you want to do within the limitations of the system as it really is, rather than as you want it to be? Sure, that might not be as slick as you originally thought, but it will have the advantage of working, now and forever. -- ---------------- Michael J. Farren "... if the church put in half the time on covetousness unisoft!gethen!farren that it does on lust, this would be a better world ..." gethen!farren@lll-winken.arpa Garrison Keillor, "Lake Wobegon Days"
carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) (11/09/87)
In article <1846@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > > 1. DeluxePaint II and VideoScape 3D both support overscan screens. ^^^^^^^^^^^^^^ Someone (you?) said this previously and it slipped by me. DeluxePaint II does not use overscan screens. ^^^^^^^ DeluxePaint II only displays the entire Full-video image in a ViewPort. It therefore does not have to muck with private IntuitionBase variables. When using screens (in drawing mode) it treats it as a scrollable SuperBitMap window. So, "But Maaa, Dan Silva did it" is not a valid argument. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
keithd@cadovax.UUCP (11/09/87)
In article <33210@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >One of the problems with 'overscan' is that not all monitors can handle >it. That means that if you put the screen into what you think is a >reasonable overscan mode, the image may very well be off the edges of >the screen of some users. So how can you know ahead of time that what >the users screen can handle ? You CANT! However, when the *user* resizes >his screen intuition picks this up and you don't have to do anything >different in your program, just open a screen to the smaller of >your maximum desired screen/window size -or- the maximum intuition >screen/window size. Except when I'm playing back IFF ShowANIM files, the overscan mode is explicitly defined. I open up a screen of whatever size is specified in the IFF file. If the users monitor can't handle it, he'd better get a new monitor or throw away his copy of Videoscape 3D. I do not hard-code screen sizes anywhere in my application, they are defined by the IFF picture and ANIM files specified by the user. >For pre-1.2+ systems you supply morerows ( which last time I checked was >freely redistributable) and explain to the user how to set up the maximum >screen size that they are comfortable with on their monitor. Assuming he only wants to work in one resolution, which is not a very good assumption. >screen positioning box in preferences ? > Even this wouldn't help with my application. You can mix resolutions as you please, including overscan with non-overscan images. 100% dynamic. Should I force you to convert your overscan workbench to non-overscan while you run certain animations, but not when you run others? Doesn't sound very user-friendly to me. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (11/09/87)
In article <305@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >Wrong. Once a program exists that supports a feature produced by a hack, >that program is in deadly danger of breaking at the next OS release, as >had been found out, sadly, by many vendors of Apple ][ software, Mac >software, Atari software, IBM software, and endlessly on. The culprits >include some of the biggest names around, not just hackers. Yes, and why? Because IBM, Apple, Atari, etc. couldn't give them the kind of support they needed to produce their package. They had to resort to hacks to remain competitive. >> 4. Most end-user customers have no understanding of any technical >> difficulties caused by any of these issues (which are all self- >> imposed software limitations) and will expect such features. > >Wrong. End users do not understand these limitations, and quickly learn >to adapt to the limitations as they use the software. Yes, and they blame the individual software package for limiitations that were actually imposed by the underlying support system. You find that acceptable? I don't. I think they'd like me better if I sent them a new version at 1.3, just like most of the rest of their packages. *I'm* the one that want's to avoid that, because it costs me money. >>When CBM is not responsive to the demands of the customer, they lose a >>lot of currency with the customers. > >And when Keith Doyle is not responsive to the demands of the customer, >by providing software which will break as soon as a new OS release comes >out, he loses even more. They won't think it's Commodore's fault, they'll >think it's YOUR'S. Either now or later. If I don't provide the capability, they'll blame me now for having limitations they don't understand, or later if it breaks under a new release. At least later, I will no doubt be in company with a lot of other developers, and aren't opening myself up to the competition now. >How about figuring a way to do whatever it is that you want to do within >the limitations of the system as it really is, rather than as you want >it to be? Sure, that might not be as slick as you originally thought, >but it will have the advantage of working, now and forever. Well, I suppose I could create a mouse pointer image where the "hot" point is actually a hundred or so pixels above where it seems to be, so that the visible pointer will extend as far as I need, and then compensate the coordinates. Then I can detect the middle of the screen and readjust it when I am in the upper portion of the screen so I can also move all the way to the top and left as well. While such a scheme could be made to work, it is darn messy, prone to bugs, probably causes some kind of a crazy glitch in the middle of the screen, won't multitask well, and it probably will end up having to do something that isn't guaranteed to work in 1.3 either. In fact, I doubt that much is "guaranteed" to work in 1.3 anyway. I can think of a few other ways to kludge a mouse that will cover an overscan screen, but we're all subject to something breaking at 1.3 anyway. I figure the best way to avoid that is to open a discussion with Commodore on the subject ahead of time. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
john13@garfield.UUCP (11/10/87)
In article <305@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >In article <1846@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >>Well, I suppose I could just have told everyone that it's an Intuition >>"bug" that when you go to 364x220 (or whatever) that you're still stuck >>with a 320x200 mouse area. But that wouldn't be very supportive of my >>customer, me passing the buck like that now would it? > >No, but it would be a lot more honest. Better yet, don't talk in terms >of Intuition "bugs" to the customer at all. Just tell her that the >mouse is limited to the 320x200 area, and provide other means of doing >what you mean to do. If you can do it in this release (which all theorizing aside will probably be the Intuition/Graphics standard release for a _long_ time to come), and it doesn't break 1.2 software, and we assume that version X.Y will make the problem a non-issue by making the mouse movable anywhere within the screen limits, why not limit the "hack" portion by putting in a switch which would either test the Rev # or be settable by the user, as to whether they wanted you to mess with the fields? Phrased something like "this feature of my program is not directly supported by Intuition V1.2. Disable/enable mouse movement beyond normal screen dimensions?". So the situations go like: - this issue never gets addressed, your program works forever - this issue is resolved in 2.1 or whatever, and you stop messing with the fields - 2.1 still doesn't support it, and your hack breaks, so the user has the choice of using 1.2 or disabling the feature. The program may be 5 or 10% less useful, but so will everyone else's overscan programs and yours is the most flexible (so everyone buys it) I appreciate the concerns about future compatibility, but providing non- standard features as a (well-explained) option doesn't decrease it, and it is a major change from the bull-in-a-china-shop methods of many past software manufacturers. The best of both worlds, you might say. John, who still remembers when they changed the damn system load address from the PET to the 64 which broke EVERYTHING, even some Basic! -- "The day-to-day travails of the IBM programmer are so amusing to those of us who are fortunate enough never to have been one -- sort of like watching Charlie Chaplin trying to cook a shoe." -- the new and improved Fortune database
keithd@cadovax.UUCP (Keith Doyle) (11/10/87)
In article <2704@cbmvax.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes: >In article <1846@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >> >> 1. DeluxePaint II and VideoScape 3D both support overscan screens. > ^^^^^^^^^^^^^^ > > Someone (you?) said this previously and it slipped by me. DeluxePaint II >does not use overscan screens. > ^^^^^^^ > > DeluxePaint II only displays the entire Full-video image in a ViewPort. >It therefore does not have to muck with private IntuitionBase variables. >When using screens (in drawing mode) it treats it as a scrollable SuperBitMap >window. But then what do you do with a full-video image after that? Do we expect that a completely static "here it is guys, look but don't touch" is all we can do with it? The point is that DPaint II has a full-video mode, and users then want to make use of these full-video images in a real full-video mode, not just as a scrollable bitmap. You don't need a full video mode to scroll a bitmap. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
keithd@cadovax.UUCP (Keith Doyle) (11/10/87)
[from jimm...] >I agree that there are two sides to these issues, and as a major flame >contributor on this topic, I acknowledge the problems that the facts >give to all concerned. The issue that gathered so much heat from >former and current C-A employees regards the causes of "buggy programs" >and a "threatening tone." I'm sorry if you took it that way. What I was trying to do (and obviously failed) was to impart a sense of urgency to the problem, as the disks go to the duplicator *very soon*. At this point, what I have decided to do is this: 1. Await any further input from Amiga on the subject in the hopes that someone figures out an "approved" workaround, until the disks have to go to the duplicator (approx 11/18). 2. In the meantime, I am going to add an "opt" parameter that disables my "feature", along with a README note on the disk (the manuals have already gone to press), explaining that if something breaks under 1.3 this option can be used to disable a known non-approved feature which *might* be the cause. I feel that checking Intuition rev level to be undesirable, as that approach *assumes* that things will break which at this point is unknown, and even if known there's no telling at exactly which rev. 3. Hope that things don't break and use of the option is unecessary. Not an elegant solution, but with the lack of better information, I feel the optimistic approach of "maybe it won't break" preferable to the alternatives. Now. This is NOT an ultimatum, nor were previous messages. This is our schedule, and it is imperative that we meet it. If you found my tone threatening, it was not intended, rather a desperate cry for "help! how do I fix it so it's right, so I don't have to send out free upgrades to a darn inexpensive (read: I can't afford it) package when 1.3 comes out!". What came back seemed like "how long can you tread water?" from my perspective. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
cmcmanis%pepper@Sun.COM (Chuck McManis) (11/10/87)
[ I'll try and edit it alot, for more context track down the references ] Keith = > My original comments = >> >>One of the problems with 'overscan' is that not all monitors can handle >>it. >Except when I'm playing back IFF ShowANIM files, the overscan mode is >explicitly defined. I open up a screen of whatever size is specified >in the IFF file. If the users monitor can't handle it, he'd better get >a new monitor or throw away his copy of Videoscape 3D. I do not hard-code >screen sizes anywhere in my application, they are defined by the IFF picture >and ANIM files specified by the user. And at least one user I know of has 'thrown away' (actually taken it back) his copy of V3D because the pictures went off the edges of his TV (he doesn't have a monitor yet and he was quite irritated that Aegis expected him to buy one.) You should not hard code the maximum screen size in your code, you should simply check GfxBase -> NormalDisplay[Rows|Columns] before you open a screen. If it won't fit, then warn the user that it won't fit and explain in the manual how morerows can increase that limit on 1.2 systems. >>For pre-1.2+ systems you supply morerows ( which last time I checked was >>freely redistributable) and explain to the user how to set up the maximum >>screen size that they are comfortable with on their monitor. >Assuming he only wants to work in one resolution, which is not a very >good assumption. No, the Assumption is you can always safely open a screen that is smaller than the workbench. You cannot always open one that is larger and expect it to work. All the user has done with morerows is told you "I can't see pictures that are bigger than my workbench". If you have one that is larger than that you *know* it won't be displayable on the system. >Even this wouldn't help with my application. You can mix resolutions as >you please, including overscan with non-overscan images. 100% dynamic. >Should I force you to convert your overscan workbench to non-overscan >while you run certain animations, but not when you run others? Doesn't >sound very user-friendly to me. No, No, and again No. If the image is overscan and larger than the screen size the User has defined, then you should warn him that this image cannot be displayed on his monitor. That is much friendlier than having him get pissed off because *your* program chops off the bottom/side of the images. The guy I mentioned above has lost mucho respect for Aegis because they *assumed* he had a monitor, and that it handled overscan. If the Animation doesn't run in overscan mode then just open a non-overscan screen and run it, or run it in an overscan screen and leave the borders alone. In either case you win, your compatible, the user likes it, and your code still works under 1.3. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
bryce@hoser.berkeley.edu (Bryce Nesbitt) (11/12/87)
In article <1860@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >I'm sorry if you took it that way. What I was trying to do (and obviously >failed) was to impart a sense of urgency to the problem... Urgency we all got. It came with some other stuff, however :-). Some people have made comments about overscan, usually to the effect of "how big the workbench is". There is something very wrong with at least two of those postings... There are *two* types of overscan. ------------------------------------ Type 1, "The Size of the Workbench": This is the available space for computer type stuff. It will have a border (presumably). Since the user has set this size him/her self it is safe to assume that all this space is available. The minimum this will ever be is 640*200. The vertical size will be much larger for PAL machines (256 or more). The numbers may be doubled for lace. My workbench runs morerows to 704*464 pixels. This is the size you should open screens and windows to! Note that there is no (reasonable) upper bound to this, so if you can only handle displays of, say, 32768 pixels wide clip the number above to that maximum. ------------------------ Type 2, "Real Overscan": Watch some TV. Notice there is no "border" imposed on the picture. It disapears into the set. Anyone doing animations or pictures intended for brodcast or video tape will want to draw into the overscan area. Just like TV produceers must do, the action is >At this point, what I have decided to do is this: > >1. Await any further input... > >2. In the meantime, I am going to add an "opt" parameter that disables > my "feature", along with a README note on the disk... > ... I feel that checking Intuition rev level to > be undesirable, as that approach *assumes* that things will break which > at this point is unknown, and even if known there's no telling at exactly > which rev. Make that opt parameter the rev level at which to disable the "feature" and I, for one, will be happy with you. Set this to "35" for now and make the readme say "try bumping this higher if you get a new version of the operating system and the mouse ends up restricted". This has a *good* chance of never needing adjustmemt, or action on the user's part when 1.3 comes out. As Jim Mackraz pointed out, why all the concern about breaking under 1.3? That would seem the perfect opourtinity to show your users what a great company you are by providing a timely upgrade at a reasonable price. It would also blow away any pirates. Add 1/2 :-) to this and think about it. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U "We want to fashon puppets that pull their own strings." -Ann Marion
peter@sugar.UUCP (Peter da Silva) (11/12/87)
What you say is: Overscan Work Screens: "This feature is not currently supported by Intuition, and any software that uses it will probably break when the next release of Intuition comes out. Therefore this package will check the version it is running under and will not support this feature if it does not match. An upgrade will be forthcoming that will fix the problem when Intuition support is provided. "Be aware that any competing product that uses this feature will likely break." Here's an alternative: Do what MacPaint does, and allow the user to grab and drag the overscan screen around. Then you can support MORE than overscan (for printing only, of course). How about a paint program that allows the use of full 8.5" by 11" paintings at the resolution of the printer? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
richc@vaxwaller.UUCP (Rich Commins) (11/12/87)
In article <1860@cadovax.UUCP>, keithd@cadovax.UUCP (Keith Doyle) writes: > I'm sorry if you took it that way. What I was trying to do (and obviously > failed) was to impart a sense of urgency to the problem, as the disks > go to the duplicator *very soon*. I think we all could learn to be better diplomats, but its very hard after spending many hours tracing down the bug in the system (Sometimes it *is* cockpit error) 8^) . The intent is **constructive** comments and critisism and not **destructive** remarks. If we all try harder we'll all win big my making the AMIGA the best it can be. > > schedule, and it is imperative that we meet it. If you found my tone > threatening, it was not intended, rather a desperate cry for "help! how > do I fix it so it's right, so I don't have to send out free upgrades to a ^^^^^^^^^^^^^ > darn inexpensive (read: I can't afford it) package when 1.3 comes out!". > What came back seemed like "how long can you tread water?" from my perspective. Why free upgrades? Why not just charge enough to cover costs, say around $8.00. This would reduce the urgency of the problem, and not make you go broke in the process. I personally find this approach reasonable compared to not offering a fixed disk until a major upgrade is made available, then force the user to buy the upgrade just to fix the bug (ala EA). -- -- Rich Commins (415)939-2400 \ /\ Varian Instruments, 2700 Mitchell Drive, Walnut Creek, CA 94598 \/--\ {ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}varian!richc
keithd@cadovax.UUCP (Keith Doyle) (11/13/87)
In article <33492@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >And at least one user I know of has 'thrown away' (actually taken it back) >his copy of V3D because the pictures went off the edges of his TV (he doesn't >have a monitor yet and he was quite irritated that Aegis expected him to buy >one.) Wait a minute! The're SUPPOSED to go off the edge of your TV. That's the whole point of OVERSCAN. Why do you think they call it OVERscan? Only if his monitor loses sync because of it could it ever be an issue. And in fact, you stress my point. If the user want's to produce full overscan for his videotapes, but his monitor cuts off much of it in that mode, I for SURE don't want to force him to have to put his workbench in that mode where he won't be able to find his menu bar, just so his videotapes will come out right. If the images go off screen in VideoScape, then why doesn't he just zoom back the camera position a bit making the whole image a little smaller? I mean, what's the problem? The VideoScape option screen is 640x200 normal screen just like it should be. >You should not hard code the maximum screen size in your code, you >should simply check GfxBase -> NormalDisplay[Rows|Columns] before you open >a screen. If it won't fit, then warn the user that it won't fit and explain >in the manual how morerows can increase that limit on 1.2 systems. Except that if a user want's to do 704x464 full video in the application, requiring him to set his workbench to that mode could get pretty unwieldly, not to mention he's likely to eat up much of his valuable chip ram as well. >No, the Assumption is you can always safely open a screen that is smaller >than the workbench. You cannot always open one that is larger and expect >it to work. Why should I make that assumption? The *user* decides where he should set his workbench, and what kind of images he wishes to display. Why should I make him work with a 704x464 workbench (where he might not even be able to see his menu bar) when he wants to run an application that does an image for video where the 704x464 is important? >All the user has done with morerows is told you "I can't see >pictures that are bigger than my workbench". If you have one that is larger >than that you *know* it won't be displayable on the system. But if the result is to be videotaped, even if you can't see it all on the monitor you have, you may still want to be sure that the video is coming out full screen. >No, No, and again No. If the image is overscan and larger than the >screen size the User has defined, then you should warn him that this >image cannot be displayed on his monitor. That is much friendlier than >having him get pissed off because *your* program chops off the bottom/side >of the images. If he doesn't want to see images that get chopped of because they are too big, he can decide not to create such images with DPaint. You're suggesting I pop up a requester that says "warning: use morerows to make your workbench too big to be used" when a user tries to playback a VideoScape ANIM, when he's got a normal workbench, and a small monitor? Or I suppose I could do some kind of dynamic re-sizing of the image to force it to workbench size? If you think writing a ShowANIM player is messy when they're changing the specs once a week, see how you like it when you try to readjust the screen resolution on the fly to boot. (can you say S L O W ?) >The guy I mentioned above has lost mucho respect for >Aegis because they *assumed* he had a monitor, and that it handled overscan. Well I don't assume that. But I don't assume he doesn't either. This is the first I've heard of such problems, even my home TV can handle it as can my VCR. I'd be inclined to think his monitor's broke if it loses sync, and if he's just complaining about the size of his TV, well, the normal workbench won't fit its 80 columns on one old TV I have, but did I blame Amiga? Nope, I resized my workbench window. If doesn't work for him, all he has to do is create images as big as he CAN work with in DPaint (or wherever), it's totally up to him. And I won't make him size his workbench to that if it's OVERSCAN which is *supposed* to extend beyond the edges of the viewable screen. >If the Animation doesn't run in overscan mode then just open a non-overscan >screen and run it, Doing this on the fly with IFF ANIM's would slow down a process everyone is counting CPU cycles trying to find ways to speed up. And actually, with my package you CAN do that if you really want. You can triple (or is it quadruple?) buffer a ShowANIM and cut a smaller screen out of it that fits on what you have. Not terribly elegant, not at all automatic, but it can be done for that 1% of the market out there who couldn't afford a decent monitor. I mean, jeez, C= was giving the monitors away free in the early days (package deals), and I've got one of those and it works just fine. Tell your buddy to get a job! Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jdow@gryphon.CTS.COM (Joanne Dow) (11/13/87)
Sorry, Chuck, I have to disagree with you strongly regarding what "morerows"
"tells" a program. It does NOT tell the program the size of the largest screen
that the monitor can support. Do not forget that horizontal overscan starts
killing off the sprites one by one. A particular user may well wish to have
those sprites available so that he can run oing! in the background or some
such insanity. Hence examining the appropriate preferences records to check
for the maximum allowed screen size is phoney if your program will be opening
its own screen and does not need the sprites.
Further your friend who returned VideoScape is within his rights I suppose. He
is also sadly misinformed regarding what the authors of VideoScape intended.
I'll ask him (indirectly) whether he'd like his normal TV pictures to have a
black boarder around them of wasted pixels or not? VideoScape is designed to
produce a TV-like picture. Hence it uses maximum overscan. True this cuts
off some of the picture. But it really looks a lot nicer than having any silly
frame around the picture.
--
<@_@>
BIX:jdow
INTERNET:jdow@gryphon.CTS.COM
UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow
Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was
better you left it in the bush with the other one.cmcmanis%pepper@Sun.COM (Chuck McManis) (11/17/87)
[Has anyone *not* commented on this subject?] In article <2272@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >Sorry, Chuck, I have to disagree with you strongly regarding what "morerows" >"tells" a program. The point I tried to make was that you can open a screen of size [NDC,NDR] because that is what size the workbench is. Opening a screen larger than this *may* be a useless gesture if there is someone like myself who has made their workbench extend right to all four edges of the screen. Enhancement Request for Dale : If you open a screen that is smaller than the maximum size that NormalDisplay variables indicate it could be, would it be possible to build the copper list such that the smaller screen opens 'centered' in this larger area? >Further your friend who returned VideoScape is within his rights I suppose. He >is also sadly misinformed regarding what the authors of VideoScape intended. >I'll ask him (indirectly) whether he'd like his normal TV pictures to have a >black boarder around them of wasted pixels or not? VideoScape is designed to >produce a TV-like picture. Hence it uses maximum overscan. True this cuts >off some of the picture. But it really looks a lot nicer than having any silly >frame around the picture. What he was complaining about were some canned demos that put interesting things into the overscan area (like titles) and looked really poorly framed on his TV. Joanne's and Keith's comments earlier were certainly valid w.r.t. eliminating the border, and overscan viewports can do this nicely. If you put things that need to be reached interactively with the mouse in the 'overscan' area you will have problems on cheap monitors because now your mouse pointer may disappear off the edge of the world. So to summarize my opinion on these matters, use overscan all you want to eliminate borders, please restrict where you put things the mouse needs to get to within the [0,0 ... NDC,NDR] boundaries. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
peter@sugar.UUCP (Peter da Silva) (11/22/87)
> But then what do you do with a full-video image after that? Do we expect > that a completely static "here it is guys, look but don't touch" is all > we can do with it? You can display it. You can display it through a genlock. You can print it. You can use it as the background for a game. You can do anything else you want with it. You just can't move the mouse outside the NormalDisplayRows and NormalDisplayColumns. I don't see why you're making a big deal about this. Presumably you want to do this for video applications anyway, so you don't want to have a mouse dorking around in your screen anyway. > The point is that DPaint II has a full-video mode, and users then want to > make use of these full-video images in a real full-video mode, not just > as a scrollable bitmap. You don't need a full video mode to scroll a > bitmap. You don't need the full video to edit a bitmap, just to display it. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.