Re: Apple II Music Video - Welcome to the Jungle!!

["Michael J. Mahon" <mjmahon@aol.com>]

BLuRry wrote:
> Frank M. wrote:
>
> > Continuing my previous experiments with rasterizing video on an //e,
> > I've finished rendering all 6,462 frames for the music video to Guns N
> > Roses "Welcome to the Jungle". Each frame is a single lo-res GR screen
> > dump. Obviously this only will work on a machine with a CompactFlash
> > drive or in an emulator.
>
>
> Very cool -- and something I never would have expected out of a //e.
> But here's some suggestions that can speed it up.
>
> 1) Don't use + in the print statements, use the ; operator

Better, don't use *any* operator--concatenation is assumed if
you juxtapose quoted strings and variables.

> 2) Don't convert the loop variable to a string or use an if statement
> to zero-pad it.  Just split that part off to a couple of extra loops
> 3) Break each directory into a separate loop and change the prefix
> in-between the loops.  You're causing a lot of extra conditional logic
> to be processed.  If you never noticed, applesoft basic is slow. ;-)

But the overhead is the only time that a whole loaded frame is actually
displayed, as opposed to being read in.

Double buffering and using byte offsets into a *single* file will
drastically reduce the overhead, smooth the animation, and reduce
the program to a 3-line loop.

> If you follow these three recommendations, you'll see it run really
> fast for the first few frames and then slow down after about 50 or so
> frames.  Ultimately, you'll need to break up the directory structure a
> lot more -- or figure out some other way to reduce the number of
> entries in the directory (is it slower to read from a non-zero location
> starting point of a file?  if so, how much slower?)  Another
> possibility is to pre-cache frames into a ram card and use the mem copy
> to move over pages as needed during the VBL.  Using this you could load
> chunks of frames at a go (probably a lot faster) and avoid having to
> hit the filesystem as much.

Byte offsets into a single file solve all these problems quite easily.

How about something like this:

 80 d$=chr$(4)
 90 bx=3072 : REM $400 + $800
100 gs=49235 : REM Graphics softswitch base address
110 fs=1024 : REM frame size
120 mv$="moviename" : REM (Or use dialog to select movie.)
130 fr=numframes : REM (Or first two bytes could be number of frames.)
140 GR : REM Set Graphics page 1 and clear
150 poke gs,0 : REM Select nomix
160 by=0 : REM Initial byte offset
170 bf=2048 : gp=2 : REM $800 for first frame
180:
200 for i = 1 to fr : REM Loop over all frames
210 print d$"BLOAD "mv$",b"by",l$400,a"bf
220 poke gs+gp : REM Select loaded page
230 by=by+fs : REM Advance to next page offset
240 bf=bx-bf : REM Toggle GR pages ($800/$400)
250 gp=2-gp : REM Toggle GR page numbers (2/1)
260 next

Of course, the FOR loop could easily be a short M/L program on
page 3, which would simply do a ProDOS MLI "read" of successive
1024-byte (not 2048-byte as I suggested earlier) frames.  This
would bypass all the file open overhead of BLOAD for higher
frame rates.

> Apart from that, because you're using a very palette-reduced rendition
> of a live motion video it gets very grainy because it's downright
> impossible to find good approximate color matches.  If you convert
> something that uses a simpler color palette and line art like a cartoon
> it will be easier to make things out.  If you wanted a real statement
> of irony, I'd recommend "futurama" -- especially the episode where they
> reveal Bender's brain is a 6502.  ;-)  But that's just my personal
> taste.

With a sufficient frame rate, it should be possible to "dither" colors
in the time domain from frame to frame...

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."