fdfishman@watcgl.UUCP (04/18/87)
Hi,
It is me again. I am still doing some work creating psychology experiments
for the university, as part of the experiments I have several questions.
1)In most of the experiments we want to be able to display multiple stimulus
"instantly" (by instantly I mean that the image is presented in one screen
refresh, 16 milliseconds). We were originally drawing the stimulus on
different screens (the stimulus is generally 4 bits) and then doing a
ScreenToFront() and this appears to work fine, however, we did some timing
experiments and noticed that of we started a timer, did a ScreenToFront(Scr),
and then recorded the time we got variable times.
i.e.
for (loop = 0; loop < 100; loop++)
{
Start8520Timer();
ScreenToFront(Scr);
Time[loop] = Get8520Time();
Stop8520Timer();
}
The times were something like 0, 16 (acceptable), 21, 42, and sometimes
really large numbers. On further testing we noticed that if we replace the
ScreenToFront() with WaitTOF() we get the same results (makes sense since
ScreenToFront() calls WaitTOF() ) but we noticed that if we did a
WaitBOVP(Scr) we got a nice constant 0 or 16 ms (which is good). Further we
tried using both the 8520A and the 8520B chips to do the timing (we
require a ms grain). Now my question is, what is not working, the timer
routine or WaitTOF() and can either be fixed.
2)We also tried to use the WindowToFront(), but this does not appear to be
"Instant", since we could see each plane get copied, and we get a fade in
effect (I actually like the effect but for an experiment it does not work), I
figured that I could solve this problem by defining the windows as
SuperBitMap windows, but alas, it works for small windows, but for larger
windows we still see see the fade in (It might be noted that I still have
free chipmemory after opening all the windows). So my question is, is it
possible to make a Window raise "instantly"? Also on this note I noticed
that when you do a WindowToFront it returns within a ms, is this because a
WindowToFront is done in the background?
3)Something else we played with was to exchange pointers, so we tried
exchanging, bitmaps, rasterports, viewports, of screens and windows, but
could not seem to get the displayed data to change, is it possible to do a
screen to front in this manner? And if so how?
As a note: we tried putting Forbids() and Disables() all through the code with
not changed results.
-The timer is the same one I posted to the net half a year ago.
-----------------------------------------------------------------------------
Now on a personal note, Leo posted a program called ing to the net awhile ago
which required a program heapmem.o to compile, what is heapmem and where could
I find a copy of it.
And since I am here anyways, I would like to thank everyone on the net for the
information and the toys that have been posted on the net.
--
FDFISHMAN (Flynn D. Fishman) @ WATCGL (but you can call me Flynn)
UUCP : ...!{decvax|ihnp4|clyde|allegra|utzoo}!watmath!watcgl!fdfishman
ARPA : fdfishman%watcgl%waterloo.csnet@csnet-relay.arpa2
CSNET : fdfishman%watcgl@waterloo.csnetali@rocky.STANFORD.EDU (Ali Ozer) (04/20/87)
In article <912@watcgl.UUCP> fdfishman@watcgl.UUCP writes: >Hi, > It is me again. I am still doing some work creating psychology experiments > for the university, as part of the experiments I have several questions. > [Question about how to get an image displayed for 16 ms and have it go > away rather quickly...] Hmm, will changing the color registers work? You can change all the color registers to the same color. I have no idea if it will (it might end up being slower than any other method, who knows), but it is one method you apparently have not tried... Ali Ozer, ali@rocky.stanford.edu
scott@applix.UUCP (Scott Evernden) (04/23/87)
In article <912@watcgl.UUCP> fdfishman@watcgl.UUCP writes: > 1)In most of the experiments we want to be able to display multiple stimulus > "instantly" (by instantly I mean that the image is presented in one screen > refresh, 16 milliseconds). We were originally drawing the stimulus on... In addition to Matt's color-map tricks, you may want to try some "double-buffering" techniques. The idea is to create a new View (InitView), and then swap in the new View (LoadView) between frames. Max. delay would be also be until the next video frame is scanned (1/60 sec). Examples of this code can be found in the Rom Kernel Manual, else I can post a fragment. And, while I'm here, some more terminology: > video gate array Or, VGA, is the name of the "graphics processor" found on the new IBM PS/2 series pcs. The VGA provides several display modes for these pcs, but doesn't include a blitter or other high speed rendering hardware. > blitter A device which can perform a "bitblt" (bit-blit) operation. The classic bitblt (or "rasterop") merges a source rectangle of graphics memory, to a destination area of graphics memory, with control of boolean operations, and possible including a "halftone" bitmap for shading, etc. The Amiga's blitter generalizes this and provides a 3 source bitblt operation. I believe the Amiga's blitter is called a "bimmer" by Jay Miner (designer of chips in Amiga), meaning "bit image mover" (?) > copper In addition to WAIT, and MOVE, the Amiga copper can SKIP - making it a 3 instruction processor. A qualifier on these instructions allow the copper to note if the blitter is busy while WAITing. Also the copper can wait for a beam position ANDed with a mask, allowing it to WAIT for a combination of scan positions. The Amiga's copper makes possible the Amiga's: 1) sliding multi-screen capability 2) color map changes in mid screen 3) animation system's control of Vsprites No one has yet fully exploited the power of this simple yet versatile device.
gary@eddie.MIT.EDU (Gary Samad) (04/29/87)
In article <912@watcgl.UUCP> fdfishman@watcgl.UUCP writes: > > 2)We also tried to use the WindowToFront(), but this does not appear to be > "Instant", since we could see each plane get copied, and we get a fade in > effect (I actually like the effect but for an experiment it does not work), I > figured that I could solve this problem by defining the windows as > SuperBitMap windows, but alas, it works for small windows, but for larger > windows we still see see the fade in (It might be noted that I still have > free chipmemory after opening all the windows). So my question is, is it > possible to make a Window raise "instantly"? Also on this note I noticed > that when you do a WindowToFront it returns within a ms, is this because a > WindowToFront is done in the background? > Unfortunately, you're right about this one. WindowToFront and WindowToBack and a few others actually only REQUEST that the window be moved to the front (or whatever) and return immediately. Eventually, when Intuition gets around to it, the window is finally moved. Ah, yes, another call that works this way is ActivateWindow which, unfortunately, can cause some not-so-funny problems with window activation. Anyone have a solution (even just some way to wait until the requested action has really been performed)? Gary
mcinerny@rochester.ARPA (Michael McInerny) (04/30/87)
[I'm sorry if someone's suggested this already...] Why don't you use screens and not windows for your applications? You should be able to do a Screen-To-Front/Back very quickly--it's just chaning a few bits, rather than blitting planes. Also, if you're really crazy (:-) you could use a Dual Playfield--use one playfield for your instructions, etc. (stuff you want to stick around), and cut a "hole" in it, for presenting the stimuli. Then, on the second plane, you render the stimuli and shift the second plane (again easy--there's a demo for all this) so that the appropriate stimulus is under the "hole". If you're clever, you can divy up the space on the second plan for several stimuli plus a blank. Render 'em once and then move the plane. The demo is a Dual Playfield from C/A Los Gatos a long time ago, but I could probably dredge it up if you _really_ wanted it. You could even build the screen without depth arrangers so that inquisitive subjects can't rearrange your work. -Michael
cmcmanis@sun.UUCP (04/30/87)
In article <5645@eddie.MIT.EDU>, gary@eddie.MIT.EDU (Gary Samad) writes: > In article <912@watcgl.UUCP> fdfishman@watcgl.UUCP writes: >> >> 2)We also tried to use the WindowToFront(), but this does not appear to be >> "Instant", since we could see each plane get copied, and we get a fade in >> effect ... > Unfortunately, you're right about this one. WindowToFront and WindowToBack > and a few others actually only REQUEST that the window be moved to the front > (or whatever) and return immediately... > ...Anyone have a solution (even just some > way to wait until the requested action has really been performed)? > Gary The simplest way to do this is to wait for the IDCMP message ACTIVEWINDOW for activating the window. So your code goes (Note this is psuedo code I don't have the manuals in front of me, check calling arguments against the Rom Kernel Manual) ... ModifyIDCMP(MyWindow,ACTIVEWINDOW); WindowToFront(MyWindow); WaitPort(MyWindow->UserPort); msg = (struct IntuiMessage *)GetMsg(MyWindow->UserPort); /* Should be an ACTIVEWINDOW message */ --- Check for it here --- ReplyMsg(msg); /* Reply to it! */ ModifyIDCMP(MyWindow,NOACTIVEWINDOW); I don't know if there are IDCMP messages for your window coming to the front but I thing there are. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These views are my own and no one elses. They could be yours too, just call MrgCop() and then ReThinkDisplay()!
gary@eddie.MIT.EDU (Gary Samad) (05/07/87)
In article <17730@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: -In article <5645@eddie.MIT.EDU>, gary@eddie.MIT.EDU (Gary Samad) writes: -> Unfortunately, you're right about this one. WindowToFront and WindowToBack -> and a few others actually only REQUEST that the window be moved to the front -> (or whatever) and return immediately... -> ...Anyone have a solution (even just some -> way to wait until the requested action has really been performed)? -> Gary - -The simplest way to do this is to wait for the IDCMP message ACTIVEWINDOW -for activating the window. So your code goes (Note this is psuedo code - - ModifyIDCMP(MyWindow,ACTIVEWINDOW); - WindowToFront(MyWindow); ^^^^^^^^^^^^^ etc. - ModifyIDCMP(MyWindow,NOACTIVEWINDOW); - -I don't know if there are IDCMP messages for your window coming to the front -but I thing there are. ---Chuck McManis Good idea! However, this would only work for ActivateWindow. Anyone have any ideas about WindowToFront and WindowToBack? Gary
dale@amiga.UUCP (Dale Luck) (05/12/87)
You might try ScrollVP. This call mucks with the copper list directly. It would be a good idea to use LockIBase/UnlockIBase around this call. Dale
mikeb@pnet02.UUCP (05/20/87)
You can tell Intuition to let you know when your window needs refreshing. When you WindowToFront, Wait() for the refresh message. ---Mike