Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!mvb.saic.com!dayton.saic.com!hopperj From: hopperj@dayton.saic.com Newsgroups: comp.sys.mac.programmer Subject: Message-ID: <1991Apr18.051748.1572@dayton.saic.com> Date: 18 Apr 91 09:17:47 GMT References: <9822@etsu.CMI.COM> Organization: Science Applications Intl. Corp., Dayton, Ohio Lines: 74 In article <9822@etsu.CMI.COM>, davet@cmi.com (David Temkin) writes: > I'm developing an animated game for for the Mac which, because of > performance requirements, doesn't use QuickDraw. It works in 1-bit (black > and white) mode, as well as 2-bit mode. In black and white everything is > pretty much fine. But in 2-bit mode things sometimes get a bit flaky, and > I've been having problems with a variety of obscure (read non-sanctioned) > Mac graphics techniques. Would some kind (and knowledgeable) souls in > netland please read on and pass on any info they might have? > I wrote also wrote a replacement for quickdraw graphics routines for a special purpose (simulation of a graphics box) which has similar limitatioins as yours I found that the best way to maintaine compatability was to draw into an offscreen bitmap and blit to mac screen. I originally wrote to the video buffer as well, but i found same thing that you did, there was no real standard way to do this that worked well. > 1. The most serious problem I have manifests itself in 2-bit mode on some > machines, but not on others. The problem seems to be that my program > writes directly into the video buffer. This only works properly on SOME > configurations. > > On the Mac IIsi and the IIci and some fx configurations, there is no > apparent problem writing directly to video memory. But on other machines, > notably the vanilla Mac II, IIx, IIcx (each with the standard video cards) > and the LC, my program produces a distorted image (multiply overlaid > copies of the image, separated horizontally) on the top two-thirds of the > screen, and nothing below it. I'm using 24-bit addressing, but even if I > use 32-bit addressing (with SwapMMUMode) the result is the same. > (Incidentally, the new calls provided with 32-bit QuickDraw -- > GetPixBaseAddr and PixMap32Bit -- do not help. The addresses in question > are unchanged and apparently do not need to be addressed in 32 bit mode). > I considered the possibility that the problem may have something to do > with 32-bit clean ROMs, but (1) I have seen it work on a IIcx with a > different video card, and (2) there are no ROM calls involved -- all of > the graphics code is mine. > I had no trouble making this work with mac II, IIx, and IIcx using original toby frame buffer card. Things got more complicated when new graphics cards came out, and as i had moved on to offscreen bitmaps by this time i did not have to wory about this problem. I can look up my code and get back to you in email if you wish. the problem you discuss about the multiple images is because you are assuming an incorrect rowbytes i belive. in 2 bit mode rowbytes no longer equals pixels/8. > 2. For some reason, I have been unable to communicate with the video > drivers as specified in Designing Cards and Drivers. I'm interested in > using > the second video page in Macs that have them (apparently Mac IIs and > SE/30s may have them as well as the originals), and to determine whether > such a beast exists, I need to query the video driver using a Status call. > But it comes up nonsense. Here's the code in question (Think C): when i first did my code to talk directly to the mac video buffer (to get multi screen buffering) i had some problems due to a bug in the video driver (this was when the mac II first cam out) but i have had no problem since. like i said before email me if you want me to look into this further (code is at home right now). > > There are a number of problems with this method. First, relaunching in > this manner does not seem to be supported in System 7 or under > Multifinder. Second, I can't figure out from inside the program whether or > not the program has already been launched. The problem here is that if I'm > running under Multifinder or whatever and I cannot get possession of the > second screen, the program continues to launch itself, over and over, > without notifying the user (or itself) that there has been a problem. I'd > like to be able to take some intelligent action if I cannot gain > possession of the second screen. Ideas? > the way i have seen other programs solve this is with an init which alocates the alternate buffer at boot time before multifinder loads. Jim Hopper Hopperj@Dayton.SAIC.Com Applelink JimH