🚀 go-pugleaf

In article <1992Aug20.133400.21569@ppgfr.uucp> wolpert@mars (Florian Wolpert)  
writes:
> rabjab@golem.ucsd.edu (Jeff Bytof) writes:
> : I wrote a short program to send image files to the
> : screen in real time for animation purposes.  It works great except
> : there is some flickering of the image.  Perhaps not being synched with
> : the natural refresh rate of the screen is causing the flickering.
> : Is there a register I should poll for the event of screen refresh?
> 
> Yes, this would be of interest for me too. Is there something like
> a vsync-call (or is this a general problem of no-realtime-
> no-singletask-unix) ?

This discussion belongs in comp.sys.next.programmer.
It has NOTHING to do with low-level hardware issues---you just
need to use the software capabilities NeXT has provided, such as
NXImage compositing and flushWindow control.

Here are some articles on this forwarded from c.s.n.p (please direct
all further discussion there.

PB

-------------------------------------------------------------------
From: sam_s@NeXT.com (Sam Streeper)
Subject: Re: Animating lots of small bitmaps
Date: 13 Aug 92 01:20:02 GMT
Sender: news@NeXT.COM
Reply-To: sam_s@NeXT.com

In article <22171@venera.isi.edu> dstrout@isi.edu (David Strout) writes:
> I need to animate many (up to 40) small (48>x>20) bitmaps in a view
> under 3.0.  (Think what the X game netrek looks like)  

Use NXImages to store your sprites, and then lockFocus on the appropriate
View or NXImage to composite them in.  Also note whether your window
is retained or buffered; if it's buffered you may need to flush frequently
to prevent the dirty rect from getting too big; when this happens, flushing
will become slower than necessary.  If it's retained you may need to pull
some tricks so that the display doesn't flicker.

For an interesting experiment, run BoinkOut from the command line like this:

BoinkOut -NXShowAllWindows

This unsupported feature will show you what how the window server is cacheing
all the images an app uses, and can be very edifying.  In the case
of BoinkOut, I use a retained window and buffer everything myself in an
NXImage.  Once the buffer is fully constructed, I can output the changed
pieces of it without worrying about accumulating a large dirty rect.
(This probably won't make any sense until you program something like it)
You can get BoinkOut via ftp from (nova.cc.purdue.edu) or on the 3.0
NeXTSTEP release.

> I tried doing
> it with a subview per bitmap, but that flashed badly.

No doubt.  Not a good approach for fast animation.

> I tried putting
> them all in the drawSelf:: of the main view, but that makes the whole
> view flash.  

I recommend using your own optimized animation display methods that
draw as little as possible.

> Current idea is to define a Type 3 font with my bitmaps,
> then use xyshow to draw them.  This seems really gross.  If I wanted
> to do graphics with fonts, I'd program (pick one: X, TI99/4a, IBM PCs)

This is fast, but is a big pain, and you can only output 1 color at a time.
NXImage is much more appropriate.

-sam

---------------------------------------------------------------------------
From: andrew@cubetech.com (Andrew Loewenstern)
Subject: Re: Animating lots of small bitmaps
Organization: Cube Technologies, Inc.
Date: Wed, 12 Aug 1992 04:09:12 GMT

In article <22171@venera.isi.edu> dstrout@darpa.mil (David Strout) writes:
>I need to animate many (up to 40) small (48>x>20) bitmaps in a view
>under 3.0.  (Think what the X game netrek looks like)  I tried doing
>it with a subview per bitmap, but that flashed badly.  I tried putting
>them all in the drawSelf:: of the main view, but that makes the whole
>view flash.  Current idea is to define a Type 3 font with my bitmaps,
>then use xyshow to draw them.  This seems really gross.  If I wanted
>to do graphics with fonts, I'd program (pick one: X, TI99/4a, IBM PCs)
>etc.  Does anyone have a better method?  Ideas welcome, example code 
>even better.

turning flushWindow off before drawing will hide the flashing, but
compositing may be too slow...  Fonts are really fast though.


andrew