urlichs@smurf.ira.uka.de (02/08/90)
In comp.sys.mac.programmer gillies@p.cs.uiuc.edu writes:
< >Good idea -- sort of a "Stepping In".
<
< Actually, if I ever had some time, I was going to try and write one of
< these. It would make a 5-star MacTutor article.
<
Let's do it!
Quick and dirty approach:
- Make your own gDevice. Write a driver which manages a fake color table.
- Allocate the storage for your pseudo-screen somewhere convenient.
- Set its coordinates correctly, and update grayRegion and similar data
structures. (You'll have to do that at INIT time or something.)
- Make a window to show your non-screen. Create a palette from the color table
(see step one), and attach it to that window.
- At convenient times, copy your buffer to your window, using CopyBits or
similar. (Convenient: not at VBL time because you have to draw things!
Probably patch _Button or something else which is called periodically
when dragging regions and pulling on menus.)
Or patch the QD bottlenecks to draw twice (once into your window, once into
your gDevice). Timbuktu does something like this, except that the second
draw command is translated to AppleTalk. (NB: You still need the offscreen
buffer. You're going to have to update the window occasionally...)
Somewhat more difficult agenda item: copying the pointer bits and making
sure that nothing is left lying around.
- How to keep said window alive under MultiFinder is left as an exercise to
the reader. ;-)
< The main thing to do is to simulate 2 different screens on the same
< color screen. The "Monitors" control panel device would allow you to
< drag the second screen around, relative to the first screen, and
< change the color depth on different screens (probably impossible,
< unless you use some offscreen bitmap trickiness). You might have to
< allocate 128 color table entries per subscreen.
<
Color table entries? The thing is going to have the same or fewer colors than
the screen it apears on anyway, so let CopyBits worry about that. ;-)
(Actually, see step three. We'll just let the ROM worry about colors and
stuff. No need to reinvent the wheel.)
< This would be a great boon to people developing software for multiple
< monitors, who can't afford (or don't want to bother) buying a second monitor.
Besides, it would be great fun to actually move a window into another window!
Disclaimer: I am sure that people with more QuickDraw experience can and
no doubt will find lots of problems with this approach.
Claimer: If I had any spare time in the next few months, I'd write this
myself, just for the fun of it. Fat chance, however. :-(
--
Matthias Urlichsts@cup.portal.com (Tim W Smith) (02/10/90)
Speaking of faking various environments, how about an INIT version of non-32-bit Quickdraw. This would be for people whose machines have 32-bit Quickdraw in ROM, and want to run applications that are not compatible... Tim Smith
paul@taniwha.UUCP (Paul Campbell) (02/14/90)
In article <26793@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Speaking of faking various environments, how about an INIT version >of non-32-bit Quickdraw. This would be for people whose machines >have 32-bit Quickdraw in ROM, and want to run applications that >are not compatible... I'm sure all those people who want to do Mac clones would like this too :-) Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P You know there's something wrong when 100,000 people marching in Moscow makes page 1 and 400,000 in Washington doesn't .....