Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!wrdis01!gatech!bloom-beacon!eru!hagbard!sunic!sics.se!fuug!funic!santra!hila.hut.fi!jmunkki From: jmunkki@hila.hut.fi (Juri Munkki) Newsgroups: comp.sys.mac.programmer Subject: Re: Graphics/Animation Problems (long) Summary: An even longer solution... Keywords: video, game, color Message-ID: <1991Apr14.011556.23504@santra.uucp> Date: 14 Apr 91 01:15:56 GMT References: <9822@etsu.CMI.COM> Sender: news@santra.uucp (Cnews - USENET news system) Reply-To: jmunkki@hila.hut.fi (Juri Munkki) Organization: Helsinki University of Technology, FINLAND Lines: 170 In article <9822@etsu.CMI.COM> davet@cmi.com (David Temkin) writes: >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. You are probably assuming that rowBytes is related to the width of the screen. This isn't so. A 640 pixel screen actually has a rowBytes that accomodates 1024 on most Macintosh video cards. 640/1024 probably looks like two thirds of the screen and results in overlaid graphics. > I'm using 24-bit addressing, but even if I >use 32-bit addressing (with SwapMMUMode) the result is the same. You should be using 32-bit addressing no matter what machine you are using. It never hurts and if you fail to use it in the right place, you'll just a crash or something even worse. >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? As I said above, this is not true. Never assume anything. Dig it out from Inside Macintosh. Inside Macintosh says that each row is rowBytes wide, so that's how you have to write software. >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. I just wrote something that seems to work quite well. I was thinking about doing this with the Sega 3D glasses, so this seemed like a good time to try it out. Project STORM uses a different approach (it plays with color tables). You have to have a valid mode in the mode parameter, so I first get the current mode. You then find out how many pages there are. With MaxAppleZoom, the 16 color mode doesn't allow two pages. This was a surprise, but it also explains why the Oids demo behaves the way it does. You have to remember that video cards are not required to support multiple pages. Most of them just happen to have that capability. Palette animation is a more reliable method of obtaining double buffering. Here's some Think C code that works: #include GDHandle Device; CntrlParam VideoParam; VDPageInfo ModeRecord; int NumPages=1; /* At least one page, I assume */ void GetMainInfo() { Device=GetMainDevice(); VideoParam.ioCompletion = 0; VideoParam.ioRefNum = (*Device)->gdRefNum; } int ReadCurrentMode() { int theErr; VDPageInfo ThisModeRecord; *(void **)(&VideoParam.csParam) = &ThisModeRecord; VideoParam.csCode = cscGetMode; theErr = PBStatus(&VideoParam,0); if(theErr) return theErr; ModeRecord = ThisModeRecord; VideoParam.csCode = cscGetPageCnt; theErr = PBStatus(&VideoParam,0); NumPages = ThisModeRecord.csPage; return theErr; } int SetCurrentPage(n) int n; { int theErr; VDPageInfo NewModeRecord; NewModeRecord = ModeRecord; NewModeRecord.csPage = n; *(void **)(&VideoParam.csParam) = &NewModeRecord; VideoParam.csCode = cscSetMode; theErr = PBControl(&VideoParam,0); return theErr; } void main() { int i; long j; GetMainInfo(); ReadCurrentMode(); for(i=0;iThere 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? Leave yourself an event that identifies your application. You can put an application specific event in the event queue and look for it at startup. I don't know how well this is supported with System 7.0, but at least I think it should work on anything newer than that. Another way is to use a file to mark your startup. Of course the system folder might be locked... >(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.) As far as I know it isn't supported. Just write your program so that it can do without the alternate buffer if it has to and notify the user that there will be a 20% improvement if the game is booted from a disk containing an older system. A boot time init that reserves this RAM area might work. I remember seeing something like this posted on the net a few years ago... >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? Try it, now that you have working code. It might work. Let us know if it does. I don't have a machine to try it on. >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). I assume that you are using SetEntries to restore the screen contents. A Develop magazine issue specifically warns about this (it was an article about the palette manager). I haven't had any problems with a pair of SaveEntries and RestoreEntries. Just remember that the color count is not the actual count but the count-1 (I was bitten by that feature). ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~