Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!etsu!cmi.com!davet
From: davet@cmi.com (David Temkin)
Newsgroups: comp.sys.mac.programmer
Subject: Graphics/Animation Problems (long)
Message-ID: <9822@etsu.CMI.COM>
Date: 10 Apr 91 22:03:05 GMT
Sender: news@etsu.CMI.COM
Organization: Center for Machine Intelligence, EDS Corp.
Lines: 118

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?

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.

What is going on? Is the memory mapping following a non-linear or 
discontinuous model with the 2-bit video screen? Does anybody out there 
have any experience with this? I assume that the 2-bit screen is mapped 
essentially like the black and white screen, except that each pixel takes 
two bits. Is this not universally true? Or am I simply missing some 
initialization procedure?

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):

void
this()
{
	GDHandle gdev;
	short refNum;
	OSErr err;
	VDPageInfo csParam;
	
	InitToolbox();
	gdev = GetMainDevice();
	refNum = (**gdev).gdRefNum;
	err = Status(refNum, cscGetMode, &csParam);
}

Following the status call, err is 0 (noErr) but csParam contains garbage. 
What am I missing? One odd aspect of this problem is that on the machine 
I'm currently using (IIci w/built-in video), the device refNum is -49, 
even though IM says reference numbers range from -1 to -32. Is this 
significant?

Along these lines, I am currently using the alternate screen buffers on 
the old (compact) macs using the old segment loader techniques (relaunch 
if I don't have the alternate screen allocated):

if (CurPageOption != -1) { 
	GetAppParms(ApplName, &ref, &aHandle);
	Launch(-1, ApplName); 
	}

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?

(In fact, I'd really like to know a way to get at the old Mac alternate 
screen under Multifinder and System 7. What exactly is preventing it from 
being used under these systems? Is there a workaround? It would improve 
the performance of my program by about 20 percent if I could reliably 
access the alternate screen buffer. And on 68000-based systems, that 20 
percent is significant.)

Also -- on the SE/30, one does not flip video pages in the same way as it 
is done on older compact Macs (using the VIA register A, bit 6). Is it 
done using the video driver SetMode control call? A tech note said in 
plain English that the SE/30 has two video buffers, but I haven't been 
able to get at the alternate screen. How is this done? And how is it done 
on the Classic? Is it the same as the Plus/SE?

3. How do you invalidate the whole screen? Because my program takes over 
an entire monitor, and because the pallete manager "hard-wires" black and 
white into the color table (I don't use white), I've resorted to the color 
manager to set the colors directly for the given device, and after 
running, I restore the colors which were present prior to running my 
program. This works fine, but sometimes when the program exits, the text 
in underlying windows is drawn improperly (white on black -- it seems that 
something happens to the QuickDraw background/foreground colors). However, 
if the screen is then blanked using a screen saver and then restored, 
everything comes back to normal. So, the question is: what can I do to 
correct this? How does one invalidate the whole screen in the same manner 
as the screen saver?

Anyway, thanks for reading this far. I would truly appreciate some answers 
to these questions; I've been dealing with these problems for some time 
now. If there's anyone out there who's knowledgeable about low-level Mac 
graphics, I'd appreaciate it if they could give me some pointers.


David Temkin
Center for Machine Intelligence, EDS Corp.
davet@cmi.com