[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple II Music Video - Welcome to the Jungle!!
Michael J. Mahon wrote:
> Michael J. Mahon wrote:
> > 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...
>
> There is much to be said for testing a program before posting it! ;-)
>
> My modified player above has a couple of problems--two trivial and
> one a bit of a puzzler.
>
> The two easy ones are that "nomix" is selected by "150 POKE gs-1,0", and
> line 220 should POKE a "0" instead of nothing. ;-)
>
> The troublesome one, which Frank already knows about, is that ProDOS
> is reluctant to trample on the primary text page, so double buffering
> awaits a fix for that problem...
>
> In any case, the following program works well to play single-file
> movies:
>
> 10 REM **********************
> 20 REM * *
> 30 REM * Move Movie Frames *
> 40 REM * by Frank Milliron *
> 50 REM * (modified by MJM) *
> 60 REM **********************
> 70 REM
> 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$ = "movie": REM (Or use dialog to select movie.)
> 130 FR = 6826: REM (Or first two bytes could be number of frames.)
> 140 GR : REM Set Graphics page 1 and clear
> 150 POKE GS - 1,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,0: REM Select loaded page
> 230 BY = BY + FS: REM Advance to next page offset
> 260 NEXT
> 270 TEXT : HOME : END
>
> And the multi-file movies may be made into single files by adding
> the lines:
>
> 210 PRINT CHR$ (4) + "BLOAD FRAME." + N$ + ",A$1000"
> 212 PRINT CHR$ (4)"bsave /hd/movie,b"BY",a$1000,l$400"
> 213 BY = BY + 1024
> 215 VTAB 23: PRINT N" "
>
> to Frank's player program. This program simply creates the
> file "movie" in the root directory. The current frame number
> is printed out as a progress indicator.
>
>
> -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."
Using Michael's modifications and running in AppleWin with the
emulation speed set to 2Mhz, the animation looks almost "normal time" -
ie. not running too slow or too fast.
Without Michael's mod, I had to run it at maximum-full-tilt-speed to
get something watchable.
This is a pretty kewl little project, and I'm keen to see what else you
can manage to convert. It would probably look pretty good on an
animation (ie. cartoon) where there aren't as many colours to dither...
great stuff!
cheers,
-p