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...