Fast Graphic Movement on 68k

[Brüggi]

Hi there,

I am the new one here I hope, my english is good enough. If there any mistakes, sorry, please.

On my old Amiga, i've developed a Scmumm-Like Adventure-Engine. Since I moved to Mac (LC !, LC III), I want to develop a similar Engine on System 7.x. Actual I prefer FutureBASIC and already wrote a Sokoban-Like Game. My intention for the Adventure-Engine is to "build" the current Screen inside a RAM-Area and move it to screen. Here are my problems

I. Is there a (fast!) System-Call I can use? or

II. How can I get the Pointer to the Screen-Memory (so I can move the data via asm) ?

III. And is there a Way to wait on a Retrace / Frame Fly Back to avoid flickering?

My Goal is to let the Engine run on a Mac LC as an absolute minimum Config.

Thanks 

Brüggi

 

[techknight]

If anything, you're going to want an LCIII. anything less is bottlenecked enough that itll be slow no matter what you do. At least with an LCIII the bus transfers are 32-bit all the way across. 

the VRAM is external so you would need to make calls to it via the toolbox. You may be able to do direct-addressing with the VRAM, but I would look up Inside Macintosh for that era of machines and use that as a guide. 

There was a guy here somewhere that started a thread for bare-metal work on the compact macs. That sounds like what your attempting to achieve in a way, using calls outside of the normal Mac ones. I Will see if I can dig up that thread and the information in there will probably help you immensely. 

 

[techknight]

Here: 

https://68kmla.org/forums/index.php?/topic/28362-bare-metal-mac-project/&tab=comments#comment-303082

Anyways, I could be mis-speaking but if I am not mistaken, QuickDraw is what handles all the calls to framebuffer, and you call the graphics tools in QuickDraw. Its a rendering engine in of itself, and thats how everything gets painted on the screen. 

If your creating your own engine, you may need to bypass QuickDraw and go around it, writing to framebuffer directly as a replacement "driver" for quickdraw. 

 

[Crutch]

You don’t really need the “bare metal” (avoiding ROM/Toolbox entirely) idea to do this. There are pretty standard ways to do this inside a regular classic Mac application, with the best approach depending on the era. In the pre-System 7 days or with a slower machine, you can write directly to the screen buffer (QuickDraw global screenBits.baseAddr tells you where it is). (Of course all the black&white toaster Macs through the SE/30 were 1 bit deep and 512x342 so a lot of people just assumed that which broke compatibility on any other display and resulted in sad little blocks of dancing pixels at the top of the screen when trying to launch classic games on a Mac II.) You can use a Vertical Retrace Manager OS call VInstall() to ensure this gets done at VBL interrupt time if you really want to.  http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/Processes/Processes-77.html

In the System 7 world there are “official” Toolbox calls to set up an offscreen GWorld, then you can use CopyBits (which can be slow because as I recall it respects clipping regions, etc.). The functions you’d need are in QDOffscreen.h, see for example https://github.com/phracker/MacOSX-SDKs/blob/master/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/Headers/QDOffscreen.h

Of course you can still write directly to screenBits but need to respect color depth, monitor size, possibility of multiple installed monitors, etc. A common practice was to check for 256 colors on load and, if the color depth was set to something else, ask the user to change to 8 bit depth in the Control Panel and exit. 

Happy to try to answer questions if I can, but it’s been a while obviously!

 

[Crutch]

... Oh, and all the QDOffscreen stuff is documented in Inside Macintosh Volume VI. 

 

[AbelVincze]

Hi, if you're still need some info, just let me know. I'm working with LC series, and Mac Classic II. The VideoRAM address can be retrieved very easy, using some system calls. I have C sources, and also complete ASM sources to start an app, initialize and access the screen, (change screen depth/ restore at exit). For the vertical retrace, use the SlotVBL interrupt (my sources also contains SlotVBL solution).

Here are some examples:

https://www.youtube.com/watch?v=THLHg4X96Ok

https://www.youtube.com/watch?v=-vomXNL2rGA

https://www.youtube.com/watch?v=hRgW_U2wFi0