Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!unido!fauern!fauern!csbrod
From: csbrod@medusainformatik.uni-erlangen.de (Claus Brod )
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Closing AES boxes interfering with VDI drawing
Message-ID: <3391@medusainformatik.uni-erlangen.de>
Date: 18 Dec 90 11:57:24 GMT
References: <9267@ncar.ucar.edu> <1990Nov29.145734.1059@chinet.chi.il.us> <27569349.8114@maccs.dcss.mcmaster.ca> <111330@convex.convex.com> <GLAZOU.90Dec17101227@mowitz.pdc.kth.se> <111628@convex.convex.com>
Organization: CSD, University of Erlangen, W-Germany
Lines: 50

rosenkra@convex.com (William Rosencranz) writes:
>>
>>>   there is a better way, at least i use it:
>>>
>>>   1) as above
>>>   2) save ALL the screen to a 32000 byte buffer
>>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>   3) objc_draw anywhere u like
>>>   4) form_do as above, in a loop while (!exit_condition)
>>>   5) on exit, restore the entire screen from the buffer
>>
>>
>>	THIS IS DEFINITELY NOT A GOOD WAY OF PROGRAMMING GRAPHICS !

>aw, c'mon, dan. it is not THAT bad. lighten up!
Sorry, Bill, Dan is right. It _is_ that bad, and there are easy ways to
do it better.

>and it is the only way i know of to use dialogs larger than 25% of the
>screen. unless u can suggest a better approach? i'd gladly change my
>evil ways :-).

Get the size and position of the dialog displayed. Find out the number
of bitplanes used by calling vq_extnd() and looking at work_out[4]
(I think it is 4, but there I might be wrong.). Malloc sufficient space
for your dialog and vro_cpyfm the background to the allocated memory area.
You don't need any video buffer addresses to do that. Just fill in 0L
as the start address in the screen MFDB; VDI will automatically fill
in all the required MFDB parameters for the screen.

Then objc_draw() your dialog and do any form_do thingies you'd like.
Afterwards, vro_cpyfm() the background to the screen again.

This way, you can have _fast_ dialogs in a GEM-compatible way, and
you won't ever have to bother with new screen resolutions or graphic
cards with video RAM that is not visible in the processor's address
space.

>i really do not think this affects most *current* ST owners. and i use line A,
>too, so u can get on my case there, too, since i don't think the TT supports
>it, though this has been a sanctioned as OK by atari up to now, i believe
>(since i got a nice laser-printed S.A.L.A.D. from atari maybe 1.5 yr ago).

Right, you shouldn't use Line A anymore.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, West Germany		(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
----------------------------------------------------------------------