moses@hao.ucar.edu (Julie Moses) (11/25/90)
I have an annoying problem in a program I am writing. I open a
dialogue box then close the box and immediately afterwards do some
VDI drawing (automatically not by hand) onto screen. The problem is
that the closing of the AES dialogue box does not finish before the VDI
drawing begins and therefore the VDI drawing is also erased.
I have tried putting a delay by evnt_timer and by a long for()
loop between closing the box and the VDI drawing. In each case the
closing of the AES dialogue box is also delayed and it still erases
the VDI drawing. Then I thought it might be my wind_updates but after
changing them it did not solve the problem either.
Julie Mosesandrew@cs.utk.edu (Andrew Krzywdzinski) (11/25/90)
In article <9267@ncar.ucar.edu> moses@hao.ucar.edu (Julie Moses) writes: > > > I have an annoying problem in a program I am writing. I open a >dialogue box then close the box and immediately afterwards do some >VDI drawing (automatically not by hand) onto screen. The problem is >that the closing of the AES dialogue box does not finish before the VDI >drawing begins and therefore the VDI drawing is also erased. > I have tried putting a delay by evnt_timer and by a long for() >loop between closing the box and the VDI drawing. In each case the >closing of the AES dialogue box is also delayed and it still erases >the VDI drawing. Then I thought it might be my wind_updates but after >changing them it did not solve the problem either. > > >Julie Moses I also had a similar problem, and would be interested in the replies. Thanks. -andrew krzywdzinski (andrew@cs.utk.edu)
saj@chinet.chi.il.us (Stephen Jacobs) (11/29/90)
In article <9267@ncar.ucar.edu> moses@hao.ucar.edu (Julie Moses) writes: > > > I have an annoying problem in a program I am writing. I open a >dialogue box then close the box and immediately afterwards do some >VDI drawing (automatically not by hand) onto screen. The problem is >that the closing of the AES dialogue box does not finish before the VDI >drawing begins and therefore the VDI drawing is also erased. > I have tried putting a delay by evnt_timer and by a long for() >loop between closing the box and the VDI drawing. In each case the >closing of the AES dialogue box is also delayed and it still erases >the VDI drawing. Then I thought it might be my wind_updates but after >changing them it did not solve the problem either. > I don't quite understand this. If I take the phrase "immediately afterwards" literally, it could mean that the screen isn't being redrawn before the VDI drawing is done. When I started with GEM, I was confused between alert boxes (which are erased by having GEM save a copy of what used to be on that part of the screen, and slap it back in when the alert is closed) and dialog boxes (which have to be redrawn by the application). Could that be the problem? The working difference is in one case, there's an evnt_multi(), in which some event causes the dialog to be used, and when the dialog ends, it falls through to the VDI stuff (WRONG). In the other (RIGHT) case, when the dialog ends, it sets a flag and recycles through the evnt_multi()-controlled loop. Next time through, the flag causes the VDI drawing to happen. Of course, the pending message that a redraw is needed must be handled first. Am I too far off on what's going on here? If the code already takes the correct approach, maybe an evnt_timer(0L) is needed to resynchronize the event handler before the VDI stuff. Or maybe there's a need to wait for a VBL before drawing. What to try next depends on what's been tried already. Steve J.
johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) (12/01/90)
In article <1990Nov29.145734.1059@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >In article <9267@ncar.ucar.edu> moses@hao.ucar.edu (Julie Moses) writes: >> >>[ has a problem with dialog boxes ] >> >[ replies mentioning evnt_multi() and evnt_timer() and even VBL ] From my experience, the sequence goes like this. 1. Build the dialog box via a RCS-like prog or by hand 2. Center it on the screen with form_center() [ or if you want to, fill in the x,y,w,h fields in the structure manually ] 3. Call form_dial( FMD_START, ... ) to reserve some screen space 4. Call form_dial( FMD_GROW, ... ) to draw a growing box [ optional ] 5. Call objc_draw( ) to actually draw it on the screen 6. Call form_do( ) to let the AES handle the dialog. 7. When you get control back again, call form_dial( FMD_SHRINK, ... ) 8. Call form_dial( FMD_FINISH, ... ) to free up screen space This last step sends a WM_REDRAW message to the application that owns the screen space where the dialog box was drawn before. If it is the desktop, then it just gets paster over with green (or whatever colour). If it is your application, then it is up to you to react on on the redraw message to redraw your screen space (window etc) before you do other stuff. This is more work than I was expecting before I learned a little of GEM, but I find it inuitive now, and I like programming this way. If what I do is in any way incorrect, I'd love to hear about it. I don't mind learning at all. BTW, isn't Lattice C 5 a pretty good development environment? What do you use instead of make? -- John Schmitt johns@maccs.dcss.mcmaster.ca ...!unet!utai!utgpu!maccs!johns
rosenkra@convex.com (William Rosencranz) (12/15/90)
In article <27569349.8114@maccs.dcss.mcmaster.ca> johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) writes: >>>[ has a problem with dialog boxes ] > > From my experience, the sequence goes like this. > >1. Build the dialog box via a RCS-like prog or by hand >2. Center it on the screen with form_center() [ or if you want to, fill in > the x,y,w,h fields in the structure manually ] >3. Call form_dial( FMD_START, ... ) to reserve some screen space >4. Call form_dial( FMD_GROW, ... ) to draw a growing box [ optional ] >5. Call objc_draw( ) to actually draw it on the screen >6. Call form_do( ) to let the AES handle the dialog. >7. When you get control back again, call form_dial( FMD_SHRINK, ... ) >8. Call form_dial( FMD_FINISH, ... ) to free up screen space this is the "normal" way of doing it, but it does have limitations. i think the max dialog size is 1/4 the screen as that is all the memory form_dial deals with. i may be wrong here, though... 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 you don't get the (silly?) growbox/shrink box (my beta testers told me to ax them on some code i produced a while back). this allows you to draw dialogs as big as the screen. the screen save/redraw is virtually instantaneous. users have the need for speed. u can also draw the dialog anywhere (on the screen makes most sense, though i think it is possible to draw it off screen and clip to the screen - i actually think i needed to do this once, but don't quote me). u get the screen location from Physbase or Logbase calls (forget which). i think vro_cpyfm is what i use to copy the screen, though tight loop copying longs should work, too. jeez, it's been a while... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
glazou@mowitz.pdc.kth.se (Daniel Glazman) (12/17/90)
In article <111330@convex.convex.com> 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 AAAARRRRGGGGGLLLLL !!!! Never do that !!!! NOW, the screen buffer is 32000 bytes long, but if you uses a greater scrn, your routine will only save a small part of it... Same thing if you use Protos or any other screen soft- enhancer... THIS IS DEFINITELY NOT A GOOD WAY OF PROGRAMMING GRAPHICS ! With such hints, when the resolution or the hardware changes, the program does not work any more ! A good development muST work on all ST-models with any hardware you want... I know this not easy to realize, but it's the price you have to pay if you want to see the ST as a professional computer ! Daniel. -- +---------------------------------------+-------------------------------------+ | Daniel Glazman , TDS | glazou@mowitz.pdc.kth.se | | The Royal Institute of Technology | | | S-100 44 STOCKHOLM, SWEDEN | glazman@inf.enst.fr | +---------------------------------------+-------------------------------------+ | "Ca fait 25 ans que je me demande pourquoi je suis encore la a me demander | | ce que je fais ici..." Anonyme | | | | "Gardez votre ville propre : mangez un pigeon !" Gary Gregory. | +-----------------------------------------------------------------------------+
rosenkra@convex.com (William Rosencranz) (12/18/90)
In article <GLAZOU.90Dec17101227@mowitz.pdc.kth.se> glazou@mowitz.pdc.kth.se (Daniel Glazman) writes: > >In article <111330@convex.convex.com> 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 > > > AAAARRRRGGGGGLLLLL !!!! Never do that !!!! NOW, the screen buffer is >32000 bytes long, but if you uses a greater scrn, your routine will only save a >small part of it... Same thing if you use Protos or any other screen soft- >enhancer... good point, though i plead pressed for time :-) actually, if u look at all the examples of "good" programming atari put out "in the beginning", this was often used. the "correct" way is to first ascertain the size of the screen (one of the open workstation workout[] entries, as i recall) then malloc/Malloc the space. maybe i SHOULD have said "allocate enuf space for the screen and save it to this buffer" rather than 32k. picky, picky... > THIS IS DEFINITELY NOT A GOOD WAY OF PROGRAMMING GRAPHICS ! aw, c'mon, dan. it is not THAT bad. lighten up! 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 :-). > With such hints, when the resolution or the hardware changes, the >program does not work any more ! A good development muST work on all ST-models >with any hardware you want... I know this not easy to realize, but it's the >price you have to pay if you want to see the ST as a professional computer ! 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). -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (12/18/90)
In article <111628@convex.convex.com> rosenkra@convex.com (William Rosencranz) writes: >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 :-). You can certainly save everything on the screen without knowing that it's 32k bytes long. Try finding out how big it is and then blit it into a buffer and back.
don@milton.u.washington.edu (Don Clifton) (12/18/90)
In article <111628@convex.convex.com> rosenkra@convex.com (William Rosencranz) writes: >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 :-). There is no limit to the size of a dialog. A dialog can fill the entire screen. This is because the area covered by the dialog is not saved in bitmap form, but instead is redrawn by GEM and the application that owns the window(s) it covers. Only the size of alerts is limited. Don Clifton
jeroen@ruuinf.cs.ruu.nl (Jeroen Fokker) (12/18/90)
In article <111330@convex.convex.com> rosenkra@convex.com (William Rosencranz) writes: > [ to draw a dialog ] > > 1. Build the dialog box via a RCS-like prog or by hand > 2. Center it on the screen with form_center() [ or if you want to, fill in > the x,y,w,h fields in the structure manually ] > 3. Call form_dial( FMD_START, ... ) to reserve some screen space > 4. Call form_dial( FMD_GROW, ... ) to draw a growing box [ optional ] > 5. Call objc_draw( ) to actually draw it on the screen > 6. Call form_do( ) to let the AES handle the dialog. > 7. When you get control back again, call form_dial( FMD_SHRINK, ... ) > 8. Call form_dial( FMD_FINISH, ... ) to free up screen space > this is the "normal" way of doing it, but it does have limitations. i think > the max dialog size is 1/4 the screen as that is all the memory form_dial > deals with. i may be wrong here, though... The call to form_dial(FMD_START...) does not reserve ANY memory. It just remembers the coordinates of the rectangle that will be disturbed. The final call to form_dial(FMD_FINISH...) likewise doesn't restore the screen. Rather, it generates an "event". This event must be picked up by the program by a call to evnt_multi. The infamous coordinates are supplied to you by the event, and it is the responsibility of the program to redraw the affected screen. The limitation of 1/4 the screen size applies only to form_alert dialogues. The background of form_alert dialogues is saved by the operating system, and therefore no events are generated by this call. > 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 I prefer this solution, too. You can even have sub-dialogues by allocationg a second buffer. >you don't get the (silly?) growbox/shrink box (my beta testers told me to >ax them on some code i produced a while back). The choice to grow/shrink box is independent of the way you save the background. This feature is achieved by the form_dial(FMD_GROW/SHRINK) calls, which can be included or not, regardless of the way you subsequently restore the screen. Ideally, the grow/shrink is executed conditionally depending on a switch that can be set by some preferences-dialogue. -- Jeroen Fokker | jeroen@cs.ruu.nl dept.of Computer Science, Utrecht University | tel.+31-30-534129 PObox 80089, 3508TB Utrecht, the Netherlands | fax.+31-30-513791
csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) (12/18/90)
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 ----------------------------------------------------------------------
glazou@mowitz.pdc.kth.se (Daniel Glazman) (12/18/90)
in article from csbrod@medusainformatik.uni-erlangen.de (Claus Brod ) Date: 18 Dec 90 11:57:24 GMT, you write: > [deleted lines] > > >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. > > [deleted lines] Waouuuuuuu... a REAL programmer... Thanks God, it still exists. You are perfectly right, this is a complete GEM-routine. BUT, i am not so happy to see work_out[4]... This last sentence is not written for you but for Atari. A parameter MUST NEVER BE OBTAINED by looking in a set of system variables but using inquire's functions like vdi_what_is_current_resolution(x,y,w,h,planes) And it is possible to compare the use of Line-A stuff to the old Peek & Poke. I hope we will see someday a *nice* Gem... /Daniel/ -- +---------------------------------------+-------------------------------------+ | Daniel Glazman , TDS | glazou@mowitz.pdc.kth.se | | The Royal Institute of Technology | | | S-100 44 STOCKHOLM, SWEDEN | glazman@inf.enst.fr | +---------------------------------------+-------------------------------------+ | "Ca fait 25 ans que je me demande pourquoi je suis encore la a me demander | | ce que je fais ici..." Anonyme | | | | "Gardez votre ville propre : mangez un pigeon !" Gary Gregory. | +-----------------------------------------------------------------------------+
mintha@unixg.ubc.ca (Jim Mintha) (12/19/90)
I'm writing a program that uses only AES, and not VDI. When I put up a dialog box, I save the portion of the screen used with my own copy routines, and when the dialog finishes, I copy the region back. Everything works fine except when the user moves the mouse at a later time, a small square the size of the mouse appears with the standard desktop background pattern. Is there anyway to avoid this, can I change the buffer used to hold what is underneath the mouse pointer background? -- ------------------------------------------------------------------------------- Jim Mintha University of British Columbia Programming Assistant Geography Department e-mail: mintha@geog.ubc.ca Vancouver, B.C.
rosenkra@convex.com (William Rosencranz) (12/19/90)
In article <1990Dec18.161238.24031@unixg.ubc.ca> mintha@unixg.ubc.ca (Jim Mintha) writes: > > I'm writing a program that uses only AES, and not VDI. When I put up >a dialog box, I save the portion of the screen used with my own copy routines, >and when the dialog finishes, I copy the region back. Everything works fine >except when the user moves the mouse at a later time, a small square the size >of the mouse appears with the standard desktop background pattern. Is there >anyway to avoid this, can I change the buffer used to hold what is underneath >the mouse pointer background? hide the mouse before u copy the screen (before and after)... and for the rest of u, quit beating me up about 32k. i don't do this myself (i even checked my last GEM program). i DO do it correctly. my post was done in haste, admitedly. ALL code i write that absolutely is not tied to some OS or other dependency IS portable, or at least i strive for it consciously. sometimes i hack, but believe me, anything i write which i have the slightest inkling of selling at some point is done to maximize the potential user base. things i do on usenet generally do not fall into this category. yes, yes, by all means write your code to be hardware independent. though i still believe 99% of STs use 32k screen buffers and i suspect this will be the case for some time. if u want, we can argue that point, though i think that is a waste of time. later... -bill rosenkra@convex.com (real programmers use emacs :-) -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
jansteen@cwi.nl (Jan van der Steen) (12/19/90)
mintha@unixg.ubc.ca (Jim Mintha) writes: > I'm writing a program that uses only AES, and not VDI. When I put up >a dialog box, I save the portion of the screen used with my own copy routines, >and when the dialog finishes, I copy the region back. Everything works fine >except when the user moves the mouse at a later time, a small square the size >of the mouse appears with the standard desktop background pattern. Is there >anyway to avoid this, can I change the buffer used to hold what is underneath >the mouse pointer background? [mail bounced...] Did you hide the mouse while redrawing? Jan van der Steen -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jan van der Steen jansteen@cwi.nl Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jan van der Steen jansteen@cwi.nl Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
jeroen@ruuinf.cs.ruu.nl (Jeroen Fokker) (12/19/90)
In article <1990Dec18.161238.24031@unixg.ubc.ca> mintha@unixg.ubc.ca (Jim Mintha) writes: > I'm writing a program that uses only AES, and not VDI. When I put up >a dialog box, I save the portion of the screen used with my own copy routines, >and when the dialog finishes, I copy the region back. Everything works fine >except when the user moves the mouse at a later time, a small square the size >of the mouse appears with the standard desktop background pattern. Is there >anyway to avoid this, can I change the buffer used to hold what is underneath >the mouse pointer background? While copying the screen, you must temporarily switch the mouse off, like in: copyscreen(from,to) long from,to; { register long *x; register long *y; register int i; x = (long*) to; y = (long*) from; i = 8000; graf_mouse(M_OFF,0L);; do{ *x = *y; x++; y++; } while (--i); graf_mouse(M_ON,0L); } Note for Swedish flamers: no, I do NOT intend to port my programs to later versions of the Atari. It is my decision to sacrifice portability later for efficiency now. I am aware of the fact that it is harmful. -- Jeroen Fokker | jeroen@cs.ruu.nl dept.of Computer Science, Utrecht University | tel.+31-30-534129 PObox 80089, 3508TB Utrecht, the Netherlands | fax.+31-30-513791
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (12/19/90)
In article <4545@ruuinf.cs.ruu.nl> jeroen@ruuinf.cs.ruu.nl (Jeroen Fokker) writes: >It is my decision to sacrifice portability later >for efficiency now. I am aware of the fact that it >is harmful. The question is, of course, is how much faster is your hard-wired routine than using a software-blitter? It's better to fix the slow ROM code in one place than fix it in all your programs.
mintha@unixg.ubc.ca (Jim Mintha) (12/20/90)
On a related topic, does anyone who is using gcc know how the asm
command works? I can't seem to find any information on in it in the
info system in emacs. I want to do a loop to move the screen up one
line in assembly, but I can't seem to get it to use labels.
I want to do something like this: (somewhat simplified)
asm ("movel %0,a0" :: "a" (scrbase)) /* load a0 screen adr */
asm ("movel %0,a0" :: "a" (scrbase2)) /* destination (1 line down) */
asm ("movew %0,d0" :: "d" (size)) /* number of long words */
asm ("loop: movel (a1)+,(a0)+") /* copy the memory */
asm ("dbf d0,loop") /* --1 and branch */
My assembly is a little shakey, but I was able to get it to work with
megamax C, but the above GCC version won't work.
Jim (email mintha@geog.ubc.ca)
--
-------------------------------------------------------------------------------
Jim Mintha University of British Columbia
Programming Assistant Geography Department
e-mail: mintha@geog.ubc.ca Vancouver, B.C.rehrauer@apollo.HP.COM (Steve Rehrauer) (12/20/90)
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: >In article <4545@ruuinf.cs.ruu.nl> jeroen@ruuinf.cs.ruu.nl (Jeroen Fokker) writes: >>It is my decision to sacrifice portability later >>for efficiency now. I am aware of the fact that it >>is harmful. > >The question is, of course, is how much faster is your hard-wired >routine than using a software-blitter? It's better to fix the slow ROM >code in one place than fix it in all your programs. Which (code in TOS ROMs) is out of Jeroen's control. And, this assumes that Atari *will* optimize the ROMs in our lifetimes. (*Have* they significantly sped-up AES or VDI since v1.0 of the ROMs? I'm genuinely curious, not flaming. Were the 1.4 ROMs, or the 1.6 ROMs in STes, tuned in any way for graphics performance? My impression from reading this group was not...) -- "The goons are riding motorcycles, but WE'VE | (Steve) rehrauer@apollo.hp.com got a whole big metal car! This will be like | The Apollo Systems Division of stepping on ants..." -- Freelance Police | Hewlett-Packard
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (12/20/90)
In article <4eb2849b.20b6d@apollo.HP.COM> rehrauer@apollo.HP.COM (Steve Rehrauer) writes: >>The question is, of course, is how much faster is your hard-wired >>routine than using a software-blitter? It's better to fix the slow ROM >>code in one place than fix it in all your programs. > >Which (code in TOS ROMs) is out of Jeroen's control. And, this assumes >that Atari *will* optimize the ROMs in our lifetimes. No, I was talking about commercial programs like TurboST and QuickST, that replace the ROM routines. They are sometimes not completely compatible, but it seems that if you're doing "ordinary" GEM programs, they do pretty well. And you can just program in GEM and not have to drop into assembler all the time. >(*Have* they significantly sped-up AES or VDI since v1.0 of the ROMs? Well, from what people said, removing the line-F traps and putting in subroutine calls made things faster. But they certainly didn't go in and rewrite the VDI routines in assembler :-( Fortunately, there are at least 2 companies happy to exchange your cash for their solution. Are QuickST and TurboST available in Europe?
harryk@bucsf.bu.edu (Harry Karayiannis) (12/23/90)
In article <1990Dec18.161238.24031@unixg.ubc.ca> mintha@unixg.ubc.ca (Jim Mintha) writes: > > I'm writing a program that uses only AES, and not VDI. When I put up >a dialog box, I save the portion of the screen used with my own copy routines, >and when the dialog finishes, I copy the region back. Everything works fine >except when the user moves the mouse at a later time, a small square the size >of the mouse appears with the standard desktop background pattern. Is there >anyway to avoid this, can I change the buffer used to hold what is underneath >the mouse pointer background? > >-- >------------------------------------------------------------------------------- >Jim Mintha University of British Columbia >Programming Assistant Geography Department >e-mail: mintha@geog.ubc.ca Vancouver, B.C. The problem should be that you don't hide the mouse before you make any changes to the screen. A procedure that should work is the following: 1. hide the mouse ( AES: graf_mouse(M_OFF, 0L), or VDI: v_hide_c(vdi_handle) ) 2. save the screen-area that the dialog box will cover 3. show the mouse ( AES: graf_mouse(M_ON, 0L), or VDI: v_show_c(vdi_handle, 0) ) 4. display & manipulate the dialog box ( objc_draw(...) and form_do(..) or evnt_multi(...)) 5. same as 1 6. restore the screen-area saved in step 2. 7. same as 3 Hope we helped....... Alex Volanis, Harry Karayiannis