rcook@eagle.wesleyan.edu (ME:MINT.INIT) (02/12/91)
In article <1961.27B4BFB4@stjhmc.fidonet.org>, Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: > Baudoin Raoult writes in a message to All > > BR> The simplest way is to use TickCount, as the tick counter is > BR> updated every 60th of second, each time the video spot starts > BR> to update new screen. So just write: > BR> tmp := TickCount; while tmp=Tickcount do { nothing } ; CopyBits(.....) > > To make sure that you get the most accurate reading (and the longest time in > which to do your drawing) use GetTrapAddress to bypass the Trap Dispatcher and > jump directly to TickCount. Otherwise, you have 100+ CPU cycles of overhead > that you are wasting. This might not be much, but it could change the flicker > if your drawing is small enough. um, couldn't you just read the global variable ticks (or whatever it is called)? If you did it inline, it might take 12 or 16 CPU cycles or so. BUT, what does all this talk of synchronization to the screen refresh mean if CopyBits takes more than one video frame to put the image on the screen? And even if it takes less than one video frame, what happens if the "video spot" passes over the point in the screen buffer CopyBits it currently writing to? This could easily occur if your object is to be drawn near the top of the screen. In addition, how would your program deal with the unpredicatble VBL tasks which eat up time potentially every video frame? For example, suppose you are playing a sound on a Mac with no sound chip, so the 68000 must send the sound bytes to the speaker. This can take up lots of CPU time; so much so that it could seriously impinge on any graphics you might be doing concurrently. I realize that I'm raising a lot of questions and giving no answers, but I hope I have made the point that good animation comes as a result of a very efficient erase/redraw algorithm and not from fancy synchronization schemes. Perhaps the best way is to do what games programmers were doing on Apple ][s 12 years ago*: page flipping, where you have two screen buffers and you alternate between them. *I'm sure page flipping has been around a lot longer than the Apple ][, I just want to keep everything in the same company :-) If only the Mac had sprites like a Nintendo... ------------------------ Randall Cook rcook@eagle.wesleyan.edu ------------------------
pkraus@bonnie.ics.uci.edu (Pamela Joy Kraus) (02/12/91)
In article <1991Feb11.142307.38779@eagle.wesleyan.edu> rcook@eagle.wesleyan.edu (ME:MINT.INIT) writes: > >If only the Mac had sprites like a Nintendo... > Better: sprites like a Lynx (no 8x8 size limit, no 8-per-scanline limit) Nintendo-style sprites would be cool for reducing basic mouse cursor overhead, though. I doubt you'll ever see a game like Colony or Falcon on Nintendo.
rcook@eagle.wesleyan.edu (ME:MINT.INIT) (02/12/91)
In article <27B6FAE5.14450@ics.uci.edu>, pkraus@bonnie.ics.uci.edu (Pamela Joy Kraus) writes: > In article <1991Feb11.142307.38779@eagle.wesleyan.edu> rcook@eagle.wesleyan.edu (ME:MINT.INIT) writes: > >> >>If only the Mac had sprites like a Nintendo... >> > Better: sprites like a Lynx (no 8x8 size limit, no 8-per-scanline limit) > Nintendo-style sprites would be cool for reducing basic mouse cursor overhead, > though. > > I doubt you'll ever see a game like Colony or Falcon on Nintendo. Indeed. I am well aware of the limitations of my little Japanese wonder that lives under the TV. I was just making the point that you don't need to be too much of a computer to do sprites. -- ------------------------ Randall Cook rcook@eagle.wesleyan.edu ------------------------
bruner@sp15.csrd.uiuc.edu (John Bruner) (02/12/91)
Just for curiosity's sake, is there an alternate screen buffer on the Classic? I don't believe that an 8MHz 68000 can redraw the entire Mac screen in less than 1/60 second. Considering memory traffic alone (ignoring any other instruction execution overheads), there aren't enough bus cycles to fetch the instructions and move the data around. [1/60 second at 8MHz is 133,333 cycles. At four cycles per bus transaction, that's 33,333 word reads or writes. A 512*342 1-bit image has 21,888 bytes, so updating it requires 10,944 reads and 10,944 writes. That leaves only 33333-21888 = 11445 bus transactions for instruction fetches, and this simple analysis doesn't consider the other factors that will slow you down.] Of course, most animation sequences don't involve changing all of the pixels at once. Thus, a CopyBits of a large image from an offscreen bitmap may not be the best way to update an animated image. -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
kg1a+@andrew.cmu.edu (Kevin Michael Goldsmith) (02/14/91)
> Excerpts from netnews.comp.sys.mac.programmer: 11-Feb-91 Re: Who cares > about sync? (.. John Bruner@sp15.csrd.ui (1030) > I don't believe that an 8MHz 68000 can redraw the entire Mac screen in > less than 1/60 second. Considering memory traffic alone (ignoring any > other instruction execution overheads), there aren't enough bus cycles > to fetch the instructions and move the data around. Of course that is true, but you only need 30 frames/second to produce video quality animation or 24 frames/second to produce film quality animation, although 8MHz is too slow for this too. Kevin kg1a+@andrew.cmu.edu kmg@isl1.ri.cmu.edu Disclaimer: Disclaimer, I don't need no stinkin disclaimer.
costin@cogsci.ucsd.edu (Dan Costin) (02/14/91)
In article <0biMyLy00UgKA__1sc@andrew.cmu.edu>, kg1a+@andrew.cmu.edu (Kevin Michael Goldsmith) writes: |>> Excerpts from netnews.comp.sys.mac.programmer: 11-Feb-91 Re: Who cares |>> about sync? (.. John Bruner@sp15.csrd.ui (1030) |> |>> I don't believe that an 8MHz 68000 can redraw the entire Mac screen in |>> less than 1/60 second. Considering memory traffic alone (ignoring any |>> other instruction execution overheads), there aren't enough bus cycles |>> to fetch the instructions and move the data around. |> |> |>Of course that is true, but you only need 30 frames/second to produce |>video quality animation or 24 frames/second to produce film quality |>animation, although 8MHz is too slow for this too. |> |>Kevin |>kg1a+@andrew.cmu.edu |>kmg@isl1.ri.cmu.edu |> |>Disclaimer: Disclaimer, I don't need no stinkin disclaimer. Well, believe or not, you CAN do 30 frames/second on a Mac Plus, redrawing the entire screen. The screen can be drawn in a little bit more than a screen refresh. Of course, CopyBits does it from the bottom up, so you need to write your own routine to do it from the top down. I might have one around for those interested. -dan
oster@well.sf.ca.us (David Phillip Oster) (02/15/91)
There is far too much worrying about Synch in the this newsgroup.
The basic problem is flicker. The root cause of flicker hjas nothing to do
with synching to the video. The root cause is not doing enough double
buffering.
Suppose you want to move an object over a background. the object starts at
0,0, and the next frame shows it at 1,1. The worst way to do it is:
1.) erase the object at 0,0 (either by xor drawing or restoring the background)
2.) draw the object at the new position
A bad way to do it is:
1.) draw the object at the new position
2.) erase the object at 0,0.
Both of these have a transient state, BETWEEN steps 1 and 2 where the
display is "messed up". In method 1, the object is missing. This is
percieved as flicker. in methos 2, the object is present more than once.
If you are lucky, this will be percieved as motion blur. (Which will
actually make the motion more realistic, since we are used to motion
blur from movies and TV) More likely, it will be percieved as flicker.
The best way to do the job is:
1.) Do either of the above algorithms to an offscreen bitmap/pixmap
2.) CopyBits the smallest area you can to simultaneously replace the
old posiition by background, and draw the new.
This way, there is no transient improper state, hence no flicker.
When Bill Atkinson was writing the lasso in MacPaint, which allows you
to drag around a quite large irregularly shaped object, he discovered that
although the animation frame rrate decreased when he installed off-screen
buffering, the user's perception was that it was FASTER, because it stopped
flickering.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- oster@well.sf.ca.us = {backbone}!well!osterrcook@eagle.wesleyan.edu (ME:MINT.INIT) (02/16/91)
article <293@cogsci.ucsd.EDU>, costin@cogsci.ucsd.edu (Dan Costin) writes: > Well, believe or not, you CAN do 30 frames/second on a Mac Plus, redrawing the > entire screen. The screen can be drawn in a little bit more than a screen > refresh. Of course, CopyBits does it from the bottom up, so you need to > write your own routine to do it from the top down. I might have one > around for those interested. > > -dan Of course, this leaves you with less than a video frame to prepare the next image to be shown. The way I see it, unless you have _all_ your images precomputed, a Mac Plus just isn't fast enough for real time, TV quality animation. What a shame :-) Come to think of it, what Mac short of an FX is fast enough to put up 30 512x384 pictures a second? If you have a II series machine in 8-bit mode, what it can accomplish in 8 byte moves a 1-bit Mac can accomplish in one move. So if you're using color, graphics operations aren't necessarily in step performancewise with what you might expect from your processor speed. In other words when it comes to scrolling a window, a 20 MHz IIsi in 256 color mode isn't necessarily faster than a 16 MHz SE/30. I realize most people who read this newsgroup know this, but it just underscores the performance boost a graphics coprocessor can provide. I suppose you just get what you pay for... To think that the original Mac had the main processor handle the video too! -- ------------------------ Randall Cook rcook@eagle.wesleyan.edu ------------------------