jdow@gryphon.CTS.COM (Joanne Dow) (09/23/87)
In article <1758@crash.CTS.COM> amiguy@pnet01.CTS.COM (Sean Wolfe) writes: >I've got a small problem with my sprites, and maybe someone knows the cause. >When I run programs like Sproing! or PacMan87 instead of just the normal >sprites, tall verticle lines attatched to the sprite appear along with some >garbage that move along with the sprites. I bet you are using morerows or otherwise setup overscan on your workbench screen. Overscan eats into sprite time. If you overscan enough you can even eat into the mouse sprite's time and even IT becomes a verticle bar. Run these programs from a workbench that has not been set into an overscan mode and they should work perfectly for you. -- <@_@> 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.
bryce@zen.UUCP (09/24/87)
>I've got a small problem with my sprites, and maybe someone knows the cause. >When I run programs like Sproing! or PacMan87 instead of just the normal >sprites, tall verticle lines attatched to the sprite appear along with some >garbage that move along with the sprites. They are just "flaked out." >[why?] Two possibilites: 1> You have an overscan Workbench, created with morerows or ScnSizer. 2> The screen centering gadget in preferences is set too far to the left. 3> Your hardware is indeed defective. Bitplane DMA has a higher priority than sprite DMA. In either case the Bitplane hardware is fetching data during the sprite time. Case #1 is a problem only for programs that open a window on the Workbench. Case #2 can affect almost any program. The system's GetSprite() call does not know how to check to see if it is returning usable sprites. |\ /| . Ack! (NAK, ENQ, SYN) {o O} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U How can you go back if you have not yet gone forth?
netoprhm@ncsuvm.bitnet.UUCP (09/24/87)
I have witnessed the same problem. This is on a A500 with 501 upgrade,
booted with a vanilla workbench disk (a straight copy of the original).
It happens on PacMan87 and Missle Command. No overscan, nothing else.
Works fine with everything else (except stuff that normally blows up
under Workbench /Kickstart 1.2). RoboCity runs, but displays trash.
I am also interested in some ideas of what it may be.
Hal
hsgj@batcomputer.tn.cornell.edu (Dan Green) (09/25/87)
In article <3933@zen.berkeley.edu> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >>I've got a small problem with my sprites, and maybe someone knows the cause. >>When I run programs like Sproing! or PacMan87 instead of just the normal >>sprites, tall verticle lines attatched to the sprite appear along with some >>garbage that move along with the sprites. They are just "flaked out." >>[why?] > >1> You have an overscan Workbench, created with morerows or ScnSizer. >2> The screen centering gadget in preferences is set too far to the left. >3> Your hardware is indeed defective. > (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce I have experienced "problems" with my Sprites, too. In the shareware PacMan87 game, one sprite (the pacman mouth guy) has the vertical bar about 16 pixels wide and the height of the whole screen; the bar is centered in the pacman. When the pacman moves, the bar moves, so it is "stuck" inside the sprite (Mr. Technical Terms here...). My workbench is the old standard, so problem (1) does not apply. I have my centering gadget exactly in the center of the box in preferences, so problem (2) does not apply. So I figured that problem (3) eg bad hardware must be the case. But - I went to my dealer's and took the PacMan87 program. The dealer ran the program on his brand new Amiga 500 with 512K only. Guess what -- the same vertical line was in the pacman sprite. Now either this town has high cosmic rays that damage only 1 sprite out of 8 on every Amiga, or there is a bug in the program. I would be curious to know whether someone got PacMan87 to work without this bug. PS: While I was at the dealer's, several people called asking him for Amiga 500's. Guess what -- in under one week he had sold his entire allotment of Amiga 500's, except the one that he was using for his own entertainment. I have no idea how big an "allotment" is, but the store was doing considerably more business then it was last semester. Praise the 500! -- Dan Green -- ARPA: hsgj@tcgould.tn.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/25/87)
In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >Overscan eats into sprite time. If you overscan enough you can even >eat into the mouse sprite's time and even IT becomes a verticle bar. [...] More egg, Joanne.... :-) :-) There is a hardware stop for display DMA at data fetch cycle $18. Display DMA cannot occur before this cycle. This cycle, oddly enough, is *just* after the data fetch for sprite 0. So you'll never stomp the Intuition pointer. Which is what I think they had in mind. Footnote: A little experiment you might try is to 'run' Oing, then start up Preferences, and slowly drag the screen to the left. As you do so, you will slowly stomp over the sprite DMA slots, and Oing will start to fall apart. Sorta neat to watch. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jesup@mizar.steinmetz (Randell Jesup) (09/26/87)
In article <2450@batcomputer.tn.cornell.edu> hsgj@tcgould.tn.cornell.edu (Dan Green) writes: >>2> The screen centering gadget in preferences is set too far to the left. ... >My workbench is the old standard, so problem (1) does not apply. >I have my centering gadget exactly in the center of the box in >preferences, so problem (2) does not apply. So I figured that problem >(3) eg bad hardware must be the case. > >But - I went to my dealer's and took the PacMan87 program. The dealer >ran the program on his brand new Amiga 500 with 512K only. Guess what -- >the same vertical line was in the pacman sprite. Unfortunately, 'too far to the left' means anything except almost touching the right edge (Note where resetting to the defaults leaves the screen-dragger). When you took your disk with you, if it is a WB disk, it took it's settings, so you'd get the same problem. Move the centering gadget to the extreme right and try again. Commodore should note this in the manual, and warn people of the signs of having it too far left. Randell Jesup (Please use one of these paths for mail) sungod!jesup@steinmetz.UUCP (uunet!steinmetz!{sungod|crd}!jesup) jesup@ge-crd.ARPA
scott@applix.UUCP (Scott Evernden) (09/27/87)
In article <2450@batcomputer.tn.cornell.edu> hsgj@tcgould.tn.cornell.edu (Dan Green) writes: >I have my centering gadget exactly in the center of the box in >preferences, so problem (2) does not apply. The center is the wrong place; it needs to be very much to the right, close to the right edge. -scott
blgardne@esunix.UUCP (09/28/87)
in article <176NETOPRHM@NCSUVM>, NETOPRHM@NCSUVM.BITNET (Hal Meeks) says: > > I have witnessed the same problem. This is on a A500 with 501 upgrade, > booted with a vanilla workbench disk (a straight copy of the original). > It happens on PacMan87 and Missle Command. No overscan, nothing else. ^^^^^^^^^^^^^^ I've seen this problem with the PD Missile Command game, the satellite sprite would break up on me. > Works fine with everything else (except stuff that normally blows up > under Workbench /Kickstart 1.2). RoboCity runs, but displays trash. ^^^^^^^^ I fixed RoboCity by running it through FixHunk, no more problems. While we're discussing sprite problems, how about Mindwalker? This is one of the few well behaved games I've seen (multitasking, pause, front-back gadgets, and a clean exit), but the sprite for the player dissapears during the "in the brain" sequence, unless Mindwalker is run from it's own disk. Has anyone else experienced this, or am I simply a victim of a shifted screen? -- Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 UUCP Address: {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!blgardne Alternates: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne seismo!usna!esunix!blgardne
keithd@cadovax.UUCP (Keith Doyle) (09/28/87)
In article <2450@batcomputer.tn.cornell.edu> hsgj@tcgould.tn.cornell.edu (Dan Green) writes: >In article <3933@zen.berkeley.edu> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >>>I've got a small problem with my sprites, and maybe someone knows the cause. >>>When I run programs like Sproing! or PacMan87 instead of just the normal >>>sprites, tall verticle lines attatched to the sprite appear along with some >>>garbage that move along with the sprites. They are just "flaked out." >>>[why?] Before you decide your machines are broke, first go into preferences and adjust the screen centering to be as far to the right as you can, and see if the problem goes away. My favorite example, is if you run Leo's 'oing' to get the bouncing ball sprites, and while it's running go into preferences, you can make one of the balls break up if you move the screen to the left a bit. I found this somewhat of a pain, as when I adjust preferences to be 'centered' with regards to any of the video gear I have, some sprites break up. I found it interesting that the default preferences setting seems to be a bit too much to the right when you look at it with standard video (i.e. your T.V.). Could be that is the only way they could make enough room for the sprite DMA. Oh well, not that much good stuff actually makes much use of sprites anyway. (ever since I got my Amiga, I stopped playing games, as the rest of the stuff is so much more fun!) Certainly any Video-oriented utilities ought to stay away from them if they expect to do useful stuff either in overscan or even just when correctly centered. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jdow@gryphon.CTS.COM (Joanne Dow) (09/29/87)
In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >>Overscan eats into sprite time. If you overscan enough you can even >>eat into the mouse sprite's time and even IT becomes a verticle bar. [...] > > More egg, Joanne.... :-) :-) > > There is a hardware stop for display DMA at data fetch cycle $18. >Display DMA cannot occur before this cycle. This cycle, oddly enough, is >*just* after the data fetch for sprite 0. So you'll never stomp the >Intuition pointer. > > Which is what I think they had in mind. Your turn for something akin to egg. There may be such a stop; but, I have a program that stomps the mouse cursor. The latest Showanim (4.0) is the guilty party. The mouse turns into the cannonical vertical bar exactly the same way any other sprite might. Showanim uses a LOT of overscan. And I can demung the mouse by eating off about 10 dots on the right of the screen. See - I'm always right --- except when I'm wrong. <@_-> -- <@_@> 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.
higgin@cbmvax.UUCP (09/29/87)
in article <1770@cadovax.UUCP>, keithd@cadovax.UUCP (Keith Doyle) says: > Oh well, not that much good stuff actually makes much use of sprites > anyway. (ever since I got my Amiga, I stopped playing games, as the > rest of the stuff is so much more fun!) Obviously you haven't played any of the latest mountain of games from Europe. I personally like Garrison. Paul.
ewhac@well.UUCP (09/30/87)
In article <1770@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >Oh well, not that much good stuff actually makes much use of sprites >anyway. [ ... ] Oh! I see! I get it. "Oing" isn't good stuff then, huh? Well excuuuuuuuuuuuuse me! (-: :-) (-: :-) _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
ewhac@well.UUCP (09/30/87)
In article <1686@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >>>Overscan eats into sprite time. If you overscan enough you can even >>>eat into the mouse sprite's time and even IT becomes a verticle bar. [...] >> >> More egg, Joanne.... :-) :-) >> >> There is a hardware stop for display DMA at data fetch cycle $18. > >Your turn for something akin to egg. There may be such a stop; but, I have a >program that stomps the mouse cursor. The latest Showanim (4.0) is the guilty >party. [ ... ] Sigh. My information came from the mystic DMA timing chart that everyone says isn't in the A/W Hardware manual but really is. There's a notation saying that a hardware stop is at cycle $18. Well that's what it said..... Regarding your screwed up mouse cursor: what do you want to bet that they are SetPointer()ing to a blank sprite image that isn't in CHIP RAM? _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
bryce@hoser.berkeley.edu.UUCP (10/01/87)
In article <4094@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1686@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >>In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>>In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >>> >>> More egg, Joanne.... :-) :-) >>> There is a hardware stop for display DMA at data fetch cycle $18. >> >>Your turn for something akin to egg. There may be such a stop; but, I have a >>program that stomps the mouse cursor. The latest Showanim (4.0) is the guilty >>party. [ ... ] > > Sigh. My information came from the mystic DMA timing chart that >everyone says isn't in the A/W Hardware manual but really is. There's a >notation saying that a hardware stop is at cycle $18. The DMA timing chart came to me as a separate ~40 page stapled addendum. It is also in the A500/A2000 technical reference manual. It clearly implies that DMA can't overrun Sprite zero: "Hardware stop installed here. Default cannot begin any sooner than cycle $18. This allows the user to wipe out most of the sprites if desired...." The problem is that sprite zero gets nuked when DIWSTRT is $1c!! This may be partially due to other effects, but the $18 is not hard and fast. In fact, it does not seem to be a stop at all. Just as well. It would be circutry that has no actual system value. (Unlike CDANG which has a possible use in a protected mode Operating System so the custom chips don't need to run though the MMU 1/2 :-) [The Copper ought to be able to write to the lower $40 registers when dangerous, though]) It seems a bit strange that the positioning is locked to Agnus DMA offsets, rather than starting the entire DMA locking "DMASTRT" cycles after one of the syncs. That would allow arbitary screen positioning with no undue sprite loss, since the bitpane DMA would always be backed up against the last cycle before the next line (and memory refresh). Even without that mythical register, you can get lots of sprites even with lots of overscan. (Register sure would help for high overscan applications that must be centered, however.) Working backwards on the "kill list": Sprite 7 Sprite 6 Sprite 5 Sprite 4 Sprite 3 Sprite 2 Sprite 1 Sprite 0 ;Manual implies this is preserved. Test says no. Audio 3-0 ;Could this be killed also? Disk 2-0 ; " Refresh 3-0 ;Or how about these!!! :-) GetSprite() ought to be able look DIWSTRT up on a table to determine what sprites are unusable. But what about an already allocated sprite? YankBackSprite() ?? :-) :-) :-) With 704*464 overscan I still can get all 8 sprites as long as the screen is shifted a bit too far to the right. Now the burning question is:: Is it possible to set up a screen such that not enough refresh DMA happens? Probably not. |\ /| . Ack! (NAK, ENQ, SYN) {o O} . (") bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce U How can you go back if you have not yet gone forth?
grr@cbmvax.UUCP (10/01/87)
In article <4094@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > In article <1686@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: > >In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > >>In article <1659@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: > >>>Overscan eats into sprite time. If you overscan enough you can even > >>>eat into the mouse sprite's time and even IT becomes a verticle bar. [...] > >> > >> There is a hardware stop for display DMA at data fetch cycle $18. > > > >Your turn for something akin to egg. There may be such a stop; but, I have a > >program that stomps the mouse cursor. The latest Showanim (4.0) is the guilty > >party. [ ... ] > > Sigh. My information came from the mystic DMA timing chart that > everyone says isn't in the A/W Hardware manual but really is. There's a > notation saying that a hardware stop is at cycle $18. > > Well that's what it said..... > > Regarding your screwed up mouse cursor: what do you want to bet that > they are SetPointer()ing to a blank sprite image that isn't in CHIP RAM? The "hard stop" aka "hardward start default" is intended to protect the guaranteed memory cycles i.e. refresh, floppy, audio. Sprite 0 may well be at the tender mercy of the display programmer. -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jimm@mitsumi.UUCP (10/02/87)
In article <4094@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
)
) Sigh. My information came from the mystic DMA timing chart that
)everyone says isn't in the A/W Hardware manual but really is. There's a
)notation saying that a hardware stop is at cycle $18.
)
) Well that's what it said.....
)Leo L. Schwab -- The Guy in The Cape
Perhaps there is not enough time for system horizontal blank processing
to run on the right; that is, perhaps the problem wraps around from the
right somehow.
Or, perhaps the timing spec (my personal favorite diagram) is wrong, or
the chip is broken.
Eat your eggs, Leo.
jimm
--
Jim Mackraz
Mitsumi Technology, Inc. 408/980-5422
{amiga,pyramid}!mitsumi!jimmkeithd@cadovax.UUCP (10/02/87)
In article <4093@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1770@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>Oh well, not that much good stuff actually makes much use of sprites >>anyway. [ ... ] > > Oh! I see! I get it. "Oing" isn't good stuff then, huh? Well >excuuuuuuuuuuuuse me! > (-: :-) (-: :-) Well, it was entertaining, but not for quite as long as robotroff (which uses sprites too). But I've just found that creating my own stuff (videos, music, display hacks) is so much more fun than playing any of the games, that the games just don't hold my interest. Now that I have a computer that has enough room for the artist in me to get interested, the game- player moves to the back of the bus. Might end up creating some games myself though. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
jdow@gryphon.CTS.COM (Joanne Dow) (10/03/87)
In article <4094@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1686@gryphon.CTS.COM> jdow@gryphon.CTS.COM (Joanne Dow) writes: >>In article <4034@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > Sigh. My information came from the mystic DMA timing chart that >everyone says isn't in the A/W Hardware manual but really is. There's a >notation saying that a hardware stop is at cycle $18. > > Well that's what it said..... > > Regarding your screwed up mouse cursor: what do you want to bet that >they are SetPointer()ing to a blank sprite image that isn't in CHIP RAM? > Don't wanna bet; but, note that the ouse mung is dependant on the preferences screen position. If I move the screen edge off to the side enough things suddenly come back to normal. This is standard sprite mung performance. -- <@_@> 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.
blgardne@esunix.UUCP (Blaine Gardner) (10/05/87)
Well as a couple of people suggested, it was the screen centering that
was trashing the sprites in Mindwalker. Thanks!
Someone mentioned that Mindwalker won't run under 1.2 and fast ram. Mine
does run without any problems at all. (It's possible that I ran MW
through FixHunk long ago and forgot about it, but I don't think I had to
modify it.)
On the subject of brain damaged programs (EA in particular) only Marble
Madness worked with 1.2 and fast ram, of all the EA programs I own.
Deluxe Video and Deluxe Print were fixed by decoding them with Marauder
II, then FixHunking them. Due to the bizzare copy-protection on Archon,
One on One, and Skyfox I have been unable to fix them.
I've heard a rumor that EA has a policy of upgrading their braindamaged
games for $7.50 and the original disk, can anyone confirm?
There was some talk of compiling a list of ill behaved Amiga software a
while back, if this has been done, I would appreciate a copy. Several
new A500 owners in my user's group are rather upset that their new games
won't run on their new computer. They don't make the distinction between
a software vendor's mistake, and an "incompatible" computer.
--
Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108
UUCP Address: {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!blgardne
{ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne
"I don't see no points on your ears boy, but you sound like a Vulcan!"king@dciem.UUCP (Stephen King) (10/05/87)
In article <499@esunix.UUCP> blgardne@esunix.UUCP writes: >While we're discussing sprite problems, how about Mindwalker? >This is one of the few well behaved games I've seen (multitasking, >pause, front-back gadgets, and a clean exit), but the sprite for the >player dissapears during the "in the brain" sequence, unless Mindwalker >is run from it's own disk. > >Has anyone else experienced this, or am I simply a victim of a shifted >screen? >-- Yup. As I already posted, MW has mental problems w/1.2 and SOME versions of WB1.1 I have kicking around. Maybe due to that screen centering gadget in 1.1, but what of 1.2 problems? Are we going to get an upgrade of this game from C-A? Hopefully one that runs from RAMdisk. ...sjk -- * Defence & Civil Institute * ...!utzoo!dciem!king * of Environmental Medicine * Stephen J King - Simulation & Training Group - (416) 635-2149
adh@well.UUCP (Allen D. Hastings) (10/08/87)
The reason that the new ShowANIM blanks the mouse cursor is not overscan
or any DMA issue but simply to allow video recording of the animation being
played. Old versions of ShowANIM required one to use preferences to change
the pointer into something that can be hidden in the corner if you wanted
to properly record the animation (it wouldn't do to have an arrow obscuring
your unicycles), so Gary Bonham (the author of ShowANIM) changed it to
automatically blank the pointer while playing. This shouldn't cause too
many problems since the program is written for speed and is not intended to
multitask...
- Allen Hastingsblgardne@esunix.UUCP (Blaine Gardner) (10/11/87)
in article <2464@dciem.UUCP>, king@dciem.UUCP (Stephen King) says: > In article <499@esunix.UUCP> blgardne@esunix.UUCP writes: >>While we're discussing sprite problems, how about Mindwalker? > Yup. As I already posted, MW has mental problems w/1.2 and SOME versions > of WB1.1 I have kicking around. Maybe due to that screen centering gadget > in 1.1, but what of 1.2 problems? Are we going to get an upgrade of this > game from C-A? Hopefully one that runs from RAMdisk. ...sjk Nope. After checking my screen centering, Mindwalker works perfectly on my 2.5 Meg Amiga with 1.2. It runs from VD0:, and runs fine with any other program except VT100. It chokes there since it won't run unless it has all 4 audio channels. I think this could be worked around by running Mindwalker before VT100, but I haven't tried it yet. Just a minute, let's check this idea out.......... I just tried it, and it works fine if you run Mindwalker before you run VT100. The sound on both programs is working just fine. I can't imagine what your problem with Mindwalker is, but it works just fine on my system (2 drives and 2 meg of ASDG ram). -- Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 UUCP Address: {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!blgardne {ihnp4,seismo}!utah-cs!esunix!blgardne "I don't see no points on your ears boy, but you sound like a Vulcan!"