America Online APPLE II DEVELOPMENT FORUM AFTER-CHAT CONFERENCE LOG Tuesday, December 28, 1993 10:00 p.m. Eastern Time Topic: An after-chat technical discussion on the creation of a new movie animation format for the IIGS. Primary participants in the discussion were MikeW50 (Mike Westerfield from the Byte Works), and SoftDiskGS (Greg Templeman). SoftdiskGS Sure, we can talk publically (although I'm naturally a secretive person... ;) DanP18 (you can keep your secretions to yourself. SoftdiskGS No sweat, Dan. :) DanP18 (didn't we used to get free time for the worst joke of the night? I think DanP18 that was a winner) AFL GaryJ Sure Dan, it's all yours :) AFL GaryJ (That was the worst :) MikeW50 Greg, what's the goal of your movie format? SoftdiskGS OK, I assume you're basing your format loosely upon QuickTime. MikeW50 Mine is to extend movies to allow compaction, resyncing of frames to stay in step with timed MikeW50 events (like sound), and the ability to add sound tracks (digital recordings and instrument files). SoftdiskGS My format is based around Paintworks animations, with the following additional goals: MikeW50 The format itself is very close to QuickTime. The major differences: SoftdiskGS 1) A compressed format needs to be used. MikeW50 1. No real-time scaling. Heck, most of the Macs can't keep up with it. James S WI To get Greg's name in lights. (Or on a file type note.) SoftdiskGS 2) Sequencing (such as repetitions) needs to be available. MikeW50 2. No coordinat transformations at run-time. MikeW50 3. Many 4-byte fields become 2 byte. AFC DYAJim :) James SoftdiskGS 3) Frames may be any size smaller than the screen, instead of always being full-screen. DanP18 (you know what's funny? How Apple puts "quick" in the name of things that DanP18 aren't) BCS Frank Like "plus," too. :) SoftdiskGS 4) Additional effects should be able to be associated with movies, and time between frames should be MikeW50 Dan: QuickDraw, according to some sources at Apple, didn't stand for quick-running. It stood SoftdiskGS allowed to vary (i.e. pauses are allowed, etc.) James S WI Like "Quick Responce"? MikeW50 for quick-to-implement. :) AFC DYAJim (yeah, Dan, Frank!! :) DanP18 (I KNOW, I KNOW! sheesh.) SoftdiskGS Just like the S in GS didn't originally stand for Sound, but rather for Speed (!) (Try to swallow THAT SoftdiskGS one!) DanP18 (note: mail mike a sense of humor). AFC DYAJim it's ResponSe :) AFC DYAJim it's quicker, but it slows your system down more :) AFC DYAJim no way, Greg! James S WI It slows your system down quicker? SoftdiskGS It looks like our general models are somewhat different. I believe your animation model will MikeW50 Sounds like our goals are similar, Greg. What time frame are you looking at? I'm looking at creating SoftdiskGS be based on independent frames, instead of SoftdiskGS change-list frames? MikeW50 a tool and/or library for some of the basic functions, and putting it out with a free license MikeW50 and some sort of a developer pack. Does that fit in with your goals/needs? In other words, maybe we AFC DYAJim Well, I've got to go. I'm going skiing tomorrow and have to get up at 4:30AM :) 'night all!! MikeW50 won't need two different packages at all. I'd be willing to come up with a common format, and SoftdiskGS Well, I hope to be putting some of this technology into the new Shell RSN. (Jan.?) James S WI Have fun Jim! MikeW50 if it fits your plans, work out some sort of arrangement to share my work. I'll need access to MikeW50 it for my own uses, though. BCS Frank I love this cross talk... kinda like holographic thinking. :) AFC DYAJim (I love AOL ski reports :) AFC DYAJim thanks James SoftdiskGS But as far as stand-alone file-formats, that is indefinite, goes with the ebb and flow of issue mater- SoftdiskGS ial. DanP18 (single-tasking, multi-threaded) MikeW50 Greg, the basic format is flexible enough to allow for both frame-based and delta-based animations. I MikeW50 plan to support both. SoftdiskGS Because of my loose organization around PaintWorks layout, my plan was to have a series of objects. SoftdiskGS Each one could call other objects, or touch-off sounds, or initiate other special effects, or (the SoftdiskGS main thing) play change-list frame(s). SoftdiskGS Because frames can be any size, a frame could conceivably be "called" repeatedly in different spots on MikeW50 That's sort of what QuickTime does, and what I was planning. The main difference is that everything SoftdiskGS screen for efficient animation. In that case, the change-list would include everything, but it would MikeW50 is based on times, rather than being linked together. That has a distinct advantage: if the SoftdiskGS still be a change-list (I've got a very fast way to do change-lists, though). MikeW50 player doesn't know how to handle something (say, it knows how to play a movie, but not a midiSYNTH MikeW50 song) it can skip the records it can't handle, and still do a passable job. SoftdiskGS Well, mine is based on minimum times also, but not maximum ones. In my model, any action not SoftdiskGS understood would be skipped, but time-actions would be recognized by all players, so they have a AFC DYAJim hi carol :) AFC DYAJim I wish I could stay to hear the cool discussion (sounds like we're gonna get at least one new SoftdiskGS synchonizing effect. Of course, they only specify minimum times: on a very slow machine, you won't AFC DYAJim cool anim format! :) but I've gotta get some sleep. 'night all! happy new year!!!!!!!!!!!!!! CarolO7680 Hi, is the discussion still on HyperLogo or have you moved on? SoftdiskGS skip any actions to re-sync with the times in the movie (I don't know whether QuickTime does that). MikeW50 We've moved on, but I'd be happy to field any questions you have, Carol. DanP18 I'm sure they could be persuaded to move back. AFL GaryJ Mike Westerfield is still here, Carol. The main topic tonight AFL GaryJ was HyperLogo, and Mike can still answer your questions on it (as he AFL GaryJ has just said :) SoftdiskGS (Does anybody know what QuickTime does on really slow machines?) MikeW50 QuickTime (and TwoTime) can skip frames to resync. That's very important when you have both a sound MikeW50 and a movie. They need to stay in tune. MikeW50 TwoTime allows for delta-frame, but with two twists: First, you would not use it when you need AFL GaryJ We talked about HyperLogo for the first 1.4 hours of this conference, and now SoftdiskGS How much have you done with actual animation format, Mike? In other words, can you make this stuff SoftdiskGS happen fast enough? That's one of the reasons I've gone with the change-list frames. MikeW50 to syncronize with a timed event like a sound. Second, it's a mixed format: you can have more than MikeW50 one key frame, which works like a starting frame. AFL GaryJ we're on a tangent. DanP18 (This all sounds a lot like Frame-Up) MikeW50 Greg, I have change lists, too. :) For the frame animation, the critical thing is the timing, though AFL GaryJ (Carol, if you have a question on HyperLogo, feel free to ask away) SoftdiskGS Contrariwise, my format allows normal frames (non-change-list type), that are just blocks; it uses MikeW50 In Logo (which loads & saves Paintworks, but really uses frame animation internally), I have no SoftdiskGS these for any starting frame (much like PaintWorks starts out with an SHR screen), but they could be MikeW50 trouble with full-screen 10 fps, and for "normal" size movies, 30fps is possible on an anaccelerate MikeW50 machine. SoftdiskGS embedded anywhere, which would technically allow for regular, independent frames. However, I SoftdiskGS concentrate on the change-list stuff, because that is the fastest stuff to do in most cases (without DanP18 (I had a quick vision of my IIgs moving at 30 feet per second through DanP18 my office :)) MikeW50 Right. We agree. I just said the same thing using different words. :) SoftdiskGS using non-GS/OS-friendly memory-switching techniques). MikeW50 That's ferlongs per sneeze, Dan. Get with the program. BCS Frank (This is gonna be a classic log edit.) :) DanP18 I don't have any allergies, so of course I wouldn't know that unit of MikeW50 Greg: I stick with GS/OS. Period. I want 100% compatibility with everything except, possibly, DanP18 measurement AFL GaryJ You've got that right :) MikeW50 CloseView, and even that is not precluded by the format, only the player. SoftdiskGS Mike: From my animation background, changing 32000 bytes of data in slow memory, I don't think 10 fps DanP18 Amen! Say on, Brother Mike! SoftdiskGS is feasible without using shadow/bank-switch tricks... SoftdiskGS (Or perhaps an unrolled loop... actually, correction, I can do it faster than that with a big unrolled James S WI What is not GS/OS friendly about shadow/bank-switching? MikeW50 I dunno. It seems to work for me. It's possible I'm skipping a frame now and then -- I usually run SoftdiskGS loop...; I have general block-move type code that does that now in... er... Great Project... :) MikeW50 with an accelerator, and certainly don't then, but with the accelerator off, I didn;t _notice_ any MikeW50 skips. I even had an alarm for them at one time, and it didn't kick in at that speed. SoftdiskGS I didn't say I intend to do any non-GS/OS friendly stuff... that's why I picked change-list frames. MikeW50 Greg: With full frame animation (which is what Logo does) you just zap the memory in one big MikeW50 chunk (after appropriate opening checks, of course). It's pretty fast that way. James S WI Mike, are you animationg the whole screen or just a window at 10 FPS? MikeW50 Greg: Sorry I misunderstood. I thought that's what you said a few pages -- er, 2 minutes -- ago. :) SoftdiskGS What technique do you use to move your memory, Mike? I have general-purpose code that takes, I believ MikeW50 James: The whole screen at 10fps; about 1/4 at 30 fps. SoftdiskGS e, about 2.5K, which is up to about 57% faster than block-move instructions when the destination is a SoftdiskGS large chunk of slow RAM. MikeW50 Greg: I'm just moving 32000 bytes with a quick block move. (I hope I really did this. I think MikeW50 I did. All of these questions are making me want to go back and check that I wasn't at 7.5fps, or SoftdiskGS (Which could probably do full-screen animation fairly well...) MikeW50 that I didn;t forget to turn off the accelerator. :) SoftdiskGS So, it sounds like your format is pretty well along, then, Mike? Because on a low-level, it sounds SoftdiskGS like the actual arrangement of data between our methods is very different... MikeW50 Greg: I was talking about two different things. TwoTime will be very different from Logo. Logo is MikeW50 _fast_, and I like that -- but TwoTime will sacrafice some of that speed to pick up some space MikeW50 savings. At least, that will be one option. The player can expand things internally like Logo MikeW50 does, and that may be an option. Depends on time, etc. SoftdiskGS Ahhh... you intend to decompress on the fly, then? SoftdiskGS I was going to decompress to memory when I loaded... SoftdiskGS (and my compression scheme relies on knowing about the internal characteristics of the basic datatypes James S WI Greg, I would like to know more about this routine you have that moves memory faster than... James S WI BlockMove. MikeW50 Greg: I planned to leave that option up to the Player, and write players with options to handle SoftdiskGS Well, the 57% is only when the destination is slow RAM (not when it is fast RAM shadowed to slow RAM, MikeW50 whatever made sense for the program at hand. At first, I figured on expanding comressed frames like MikeW50 you do, but Logo expands delta frames to full frames, too. That is fast, but wasts a lot of MikeW50 space. That's the big difference I was talking about. SoftdiskGS for instance). The savings increases for the amount of memory being copied; also, for regular fast-RAM SoftdiskGS moves, I think it is about 16%-20% faster than a block move... MikeW50 James, Block Move's overhead is painful. All tool calls are. Our 2-byte multiply outruns Apple's by SoftdiskGS (on average) MikeW50 a factor of 2, even though they used the same algorithm and run in ROM, which is faster -- the MikeW50 difference is the overhead for a tool call. SoftdiskGS Well, I'm not comparing to the _BlockMove tool call, Mike; I'm comparing against MVN/MVP opcodes... James S WI But when you are moving a lot of data (especialy to slow RAM), that inital overhead hardly James S WI campairs at all to the time it takes to do the move. MikeW50 Greg: BlockMove doesn't use MVN and MVP. They're too slow. It uses a loop over Y & X regs, like the MikeW50 moves in our libraries. MikeW50 (At least, that's what my friends at DTS told me when I posed the same question to them. I think SoftdiskGS Actually, Mike, MVN/MVP instructions tend to be pretty comparable to regular loops most of the time MikeW50 an early version really did use MVN and MVP, but it was caught and fixed.) SoftdiskGS (except when you add bank-crossing handlers). SoftdiskGS I stepped through the BlockMove using MVN/MVP's, BTW, and I'm not sure it's as ancient as you think... James S WI Mike, are you saying that calling memcpy() would be faster than doing an MVN? MikeW50 May be. I was called to task for accusing them of using MVN and MVP. Maybe Dave didn't know what SoftdiskGS Typically, in a regular loop, your load/store/increment/branch can get down to 13 cycles for every MikeW50 he was talking about, but Dave Lyons isn't wrong often enough to get excited about. I'll have to SoftdiskGS word (if memory serves), so you save one cycle per word over an MVN/MVP, which uses 7 cycles/byte. MikeW50 look for myself in 6.0.1 now, though. SoftdiskGS Well, I've stepped through the GS/OS move vector, and I know the overhead on that ALONE is more than SoftdiskGS anything one is likely to move... MikeW50 I sure agree with the overhead issue. See the log, about 8 pages back. ;) SoftdiskGS In an unrolled loop, you can get slightly better timing, until you get up to what I consider the DanP18 (*This* is why I still come here. I *love* this technical stuff!) SoftdiskGS ultimate unrolled loop, which is used by my special memory mover (quoted earlier at up to 57% faster). MikeW50 It's a geometric trade-off, though. Once you go over the elbow in that curve, using twice as much MikeW50 memory may only gain a couple of percent of speed. Not worth it, to me, anyway. CarolO7680 Did you talk about memory 8 pages back too? Where are you getting the memory for any good tools? SoftdiskGS OK, I was right! I just stepped through the BlockMove tool call (which is in ROM, BTW), and it uses SoftdiskGS MVP/MVN. They're not very inefficient for most purposes, except when the destination is slow RAM. MikeW50 I'll have to talk to Dave about that. :O This will be fun. James S WI How is one rooutine better with slow RAM than the next? MikeW50 Carol, I'm not sure I understood the question. SoftdiskGS Exactly, Mike. Which is why, with my 2.5K memory-mover, the ideal trade-off is reached. It isn't SoftdiskGS too big to include in a program if you need high-speed moves (of ANY kind, not just graphics), but SoftdiskGS it eliminates the loop-overhead of your move to the negligible point... you can't save much more than MikeW50 Actually, I didn't unroll my loop much at all in Logo. In worked great. I did use self-modifying MikeW50 code, though. ;) SoftdiskGS what I get... basically, I believe my routine is the optimal unrolled loop (of course, the fastest DanP18 So, this fantastic move routine is in the developers library, right? James S WI Greg, can't you type any faster? ;-) SoftdiskGS memory moves is a straight load/store sequence without indexing, but as that takes up 225K of memory, SoftdiskGS it isn't very efficient.) SoftdiskGS Sorry, I'm "multi-tasking" here with two computers... :) MikeW50 Dan, you can write one yourself, optimized for your needs. The idea is simple: instead of writing a SoftdiskGS It's not in any libraries, Dan, because it is (right now) a part of "Great Project". MikeW50 loop that has a single LDA-STA (or whatever you are using), write it with LDA-STA-LDA-STA, so the DanP18 Mike, I understand the principles. I was just making a pint that while MikeW50 overhaed of the loop end is cut in half. Keep doing that until the code gets big enough to DanP18 it's nice to hear about it, we developers should be sharing nifty code and DanP18 supporting one another. MikeW50 be painful. Because of the 8/16 bit nature of the 65816, 256 bytes per "line" is a convinient way MikeW50 to break up the move. McKinsey I would suggest using the memory managers move routine for everything except McKinsey graphics. MikeW50 Dan, the exact code you use for a trick like this generally has to be taylored to the specific SoftdiskGS Well, I usually use block moves, which is the same technique (we just ascertained :), but I think the MikeW50 situation. What works great for 32000 bytes would fall apart for 12659 bytes. DanP18 The descriptions I've been reading make the "perfect move" routine sound SoftdiskGS that any fast-graphic program could benefit from a general-purpose unrolled loop. DanP18 pretty generic. Is that true, Greg? McKinsey Your talking about graphics, huh. McKinsey Well, if your talking graphics, then your way off. MikeW50 Yep. Animation, to be precise. SoftdiskGS In what sense, Dan? If you mean, can it move any block of memory to any other block of memory, yes. DanP18 I mean, is it only good for 32000 byte moves, or is it 57% faster for all SoftdiskGS For this discussion, we're eliminating memory switching/shadowing techniques which interfere with MikeW50 McKinsey: Depends on what you're doing. For a game, you bet. We're talking about full-frame DanP18 moves? MikeW50 movies, though. SoftdiskGS the built-in interrupt manager, McKinsey. SoftdiskGS Dan: The 57% was for 32K moves to banks $E0/$E1. I forget the precise figures for moves to fast RAM MikeW50 Greg, meandering back to the point of all of this... :) McKinsey There are other techniques. MikeW50 It sounds like we're working toward similar, but not identical goals, and with time lines and SoftdiskGS (even fast RAM shadowed to slow RAM), but I believe they were in the 16% to 25% range (possibly slower MikeW50 copyright issues that may make it impossible for us to share formats or routines. Is that the way you MikeW50 read all of this, or do you think we might be able to develop at least a common file format? SoftdiskGS for small moves). I believe anything less than 3 or maybe 5 pages was more efficient with regular MVNs McKinsey For full from animations use delta modulation or compiled shapes. MikeW50 McKinsey: Yep. Most of the time. But we were discussing specific issues surrounding the use SoftdiskGS I use a delta technique as the heart of my new animation format (see earlier discussion if Gary MikeW50 of full-frame animation, which we both intend to use imbeded in delat-frame animations to allow a SoftdiskGS posts it all). AFL GaryJ No "shape" in this situation. Just the whole screen :) MikeW50 movie to resyncronize with a stable time base. That lets us keep the picture in sync with, say, a SoftdiskGS Mike: Yes, it seems like we've already cemented the little details differently, even though the over- MikeW50 digital sound. We're both shooting for something like QuickTime, but on the GS. AFL GaryJ I'll post it in a separate log file, as long as you guys don't care if your conversation is posted :) SoftdiskGS all effect will probably be very similar (although, of course, I personally think my will be faster, MikeW50 Gary, go for it. McKinsey It's already been done. SoftdiskGS but there are other considerations in what we're trying to do). SoftdiskGS GA, Gary. SoftdiskGS We could come up with a common file format, similar to APF's, or we could even merge aspects of our MikeW50 McKinsey: By several people. But we're both trying to do more. Faster. In particular, I'm SoftdiskGS material (with more specific info on exact format, of course), but it comes down to an issue of how MikeW50 trying to make a single format work with at least 3, and probably more, programs, and make the format MikeW50 and routines widely available and well documented. That hasn't been done on the GS. SoftdiskGS useful that would be; i.e., would any program be able to handle both my type and your type? We'd have SoftdiskGS to talk specifics before we could really decide that. MikeW50 Greg, the TwoTime file format is basically a GS-ed version of QuickTime. That format is flexible MikeW50 enough to handle multiple animation formats internally, and you can leave it up to the SoftdiskGS I'm trying to replace PaintWorks animations, but in a flexible format with QuickTime-type capabilities MikeW50 player whether it wants to support some or all of them. All that's really needed is at least one SoftdiskGS The question is how much redundancy you want. Because if you're not personally committed to the MikeW50 commaonly available program (hopefully freeware) that can load and save any of the formats. In that SoftdiskGS low level format of the actual interpretation of frames, then perhaps we could merge. MikeW50 case, many applications may only support a single format, or just a couple. SoftdiskGS Also, Softdisk's policy is not to make source code available, but to release pseudo-"Toolbox" SoftdiskGS libraries (GSLib) which contain all the necessary routines that can be linked into anybody's code, and MikeW50 I'm more commited to the overall layout. I want to have time-based records. I need at least one SoftdiskGS used similarly to the ORCA stuff (people just have to post a notice in the program). MikeW50 delta-frame record that can support scattered full frames for syncronization. I need at least one MikeW50 compression format that expands quickly. I need at least one digitized sound record, and at least one MikeW50 instrument sound record. I plan to have a couple of most of these. McKinsey I suggest LZSS for compression. MikeW50 I tend to think that particular policy, well, stinks. But then, we don;t really case about that, SoftdiskGS My graphics compression right now is limited to PackBytes for regular images, with my own special MikeW50 do we? If we have a common file format, all is well. We can each write separate players. Seems MikeW50 like a waste, but I don't see any real way around that. SoftdiskGS optimizer for reorganizing the image before compression for better compression, and my own SoftdiskGS special compression for delta information (basically separating data from indexing). SoftdiskGS Which policy were you "stink"ing, Gary? SoftdiskGS Oops, Mike... :) SoftdiskGS (Sorry Gary) MikeW50 Cool. Another thing that can speed things up is a variable delta format. In other words, have not MikeW50 only individual delat words, like Paintworks, but also sequences of words that get moved in. McKinsey Sorta like delta packbytes? MikeW50 Policy: No source code. Ick. People shouldn't have to _trust_ a library, they should be able MikeW50 to check for themselves. IMHO, anyway. Which is why all of the ORCA run-time libraries are MikeW50 available as source. SoftdiskGS Well, it's kind of like the GS tools: the code shouldn't have any problems, and the programmer should MikeW50 McKinsey: Or more like run-length encoded deltas. McKinsey Hehe.. the same. SoftdiskGS be insulated from it (of course, you're speaking to a guy who's stepped through more toolbox/OS code MikeW50 "The code shouldn;t have any problems..." Right. We all know how well that works. I still feel the SoftdiskGS than anybody I know of). SoftdiskGS (so I can see both sides) McKinsey How would you quickly check for moving in more than 1 word sequences? McKinsey All the checking might slow things down. MikeW50 GS would be a better place to live (and the Mac, too) if the source were available to developers. MikeW50 Debugging would be a lot easier, and Apple would get a lot of bug fixes, rather than just bug reports. SoftdiskGS Well, I'm just dealing with company policy as it stands (it may change in the future). We're not in SoftdiskGS the business of giving away source code, you know, Mike. In your case, since you wrote the programs MikeW50 McKinsey: Have super-records. One kind would _be_ a Paintworks equivalent. For some frames, that's DanP18 Mike, I applaud your sentiments. If you would like to lead the charge SoftdiskGS to COMPILE that source code, it is to your benefit. However, I think it's a pretty generous policy to MikeW50 the whole story. That requeres just two extra checks: one at the beginning and one at the end. If DanP18 to open software on the GS, I would love a copy of the Orca compilers. MikeW50 you need to change a lot of stuff in a row, though, or even a whole frame (which happens with SoftdiskGS give away these HUGE libraries of routines as Freeware, with no distribution or sales restrictions MikeW50 movies that have been digitized) you have that option. SoftdiskGS on them (except a public notice that they use our routines). DanP18 Got to run. Best Tuesday in months! See you next week. MikeW50 Dan: I give you the code that ends up in your program. That's what I'm talking about here, McKinsey I really think that would slow things down -- unacceptably. MikeW50 and what I have always done, and what I wish Apple had done. McKinsey For instance, my own paintworks viewer is 45% faster than the one in PaintWorks MikeW50 Greg: You sell magazines. I sell compilers. I respect your need to make a living. My own needs MikeW50 are admitedly different. McKinsey , and I adding checks would just slow the thing down bigtime. SoftdiskGS Also, Mike, in this case the file format would be publically available, which means anybody COULD BCS Frank <"See you next week?" It -is- next week! What a great chat!> SoftdiskGS write a player for ANY of it, but we'd provide a library routine that would play stuff, if anybody SoftdiskGS didn't want to reinvent the wheel. MikeW50 McKinsey: In the worst case, you would add two LDA-BNE sequences per frame. I don't think that is MikeW50 unacceptable when you expect some of the frames to have very large fifferences, like, for example, MikeW50 the two most popular QuickTime movies: The Saturn stage separation and the NASA flyby of Saturn. In McKinsey Not per frame -- but per continues stream. Which could be several per line. MikeW50 movies like that -- not in hand-created animations like Paintworks was generally used to create -- MikeW50 being able to move large chunks of data is a big time saver. It all comes down to what you expect MikeW50 the input to be, of course, and in this case, the typical input is a little different from what you MikeW50 generally saw with Paintworks. MikeW50 Greg: Right. So, can we share a common file format and write our own players? Or do we feel the MikeW50 need for separate file formats, too? I'm willing to spend the time to create a shared file format MikeW50 if you are. McKinsey A digitized graphic/animatin would definitely recquire more changes. And with SoftdiskGS As far as I can tell, it all comes down to how the flow-of-control is processed. I had envisioned all McKinsey more changes comes increased overhead because of trying to figure out what McKinsey record your processing and such. SoftdiskGS effects being special embedded "opcodes" within the change data, which would make other things happen. MikeW50 McKinsey: Yep. Agreed. It's a trade off, all right. SoftdiskGS Following the QuickTime format, you would have a supervisory level which would "call" the various James S WI A digitized graphic would probably have move changing bytes but less "records". Probably on SoftdiskGS tracks (such as mine) and expect to handle that itself. How would you handle parallel processes if James S WI big record for the whole screen because everything changes. SoftdiskGS something like my scheme was playing? Background tasks? MikeW50 Fortunately, parallel processing won't be needed very often. I frankly expected to side-step that SoftdiskGS Yes, I'm willing to make a shared format, if we can make it practical. McKinsey If your going to change huge rows, you need a counter. This counter adds big McKinsey cycles onto your speed. MikeW50 issue in the original player with a careful use of preprocessing of frames so there were never two McKinsey Just using a brut force method like paintworks seems far better. MikeW50 animation players going at once. With the GS's setup, the digitized sound and music tracks are MikeW50 handled mostly by the sound chip anyway, so you truly have parallel processing, not multi-tasking. MikeW50 The format might allow more options, but as a practical matter, the player I envision won't. McKinsey Mike, not entirely true. MikeW50 McMinsey: Depends on how much you are changing, of course. Paintwords has a loop, too: one cycle McKinsey The Ensoniq is not a processor. SoftdiskGS (and not a very efficient one at that... -ed) :) MikeW50 per word. I know there are shortcuts, but there is a point where moving a stream of bytes is faster MikeW50 with a block move. The recorder has to pick the tradeoff point, and be in sync with the player. McKinsey SoftdiskGS: You might be surprised how fast the paintworks format is. McKinsey My viewer is very fast. SoftdiskGS McKinsey: I KNOW how fast the PaintWorks viewer is, which is why my technique is BASED on PaintWorks MikeW50 McKinsey: I've written a Paintworks player, too. It's a good basic format, but it does assume a MikeW50 _relatively_ small number of changes per frame. That's almost always true in computer generated or SoftdiskGS animations. But what program have you written? I've stepped through all the ones I've got, and I have MikeW50 hand drawn graphics, which is why Paintworks is so good. But it is not true as often with digitized SoftdiskGS code that is more efficient (faster) than all of them. MikeW50 movies. Which is why we _sometimes_ need alternatives. McKinsey SoftdiskGS: Are you asking me what programs I've written? SoftdiskGS No, I was just wondering what your viewer is... I've seen how fast some of these viewers are (really) MikeW50 McKinsey: If nothing else, surely you'll agree that a key frame (which is required for what we SoftdiskGS and then when I saw what there display loop was, I realized I could easily go faster, which is why I'm McKinsey My viewer is SuperView GS. Also "Eye" the finder extension. SoftdiskGS leaning very heavily toward the Paintworks format. MikeW50 intend to do) is a place where an unrolled block move is far, far faster than a PaintWorks format MikeW50 (which actually would not work at all, unless you coded a change for each word). SoftdiskGS It can be faster, Mike, which is where we get down into file formats: my compression scheme actually SoftdiskGS leaves it up to the player as to how it wants to organize the uncompressed data (it would be very easy McKinsey Mike: I agree with that. SoftdiskGS to take runs of words and make them into a solid block without all the indices with it. SoftdiskGS ) MikeW50 I'm not sure McKinsey agrees with us even now. But whatever. Either I'm right or wrong: the nice MikeW50 thing about code is the claims can be proven or disproven. :) AFL GaryJ :) SoftdiskGS Anyway, Mike, I think a file-format hinges on how you intend to handle the supervisory level of things AFL GaryJ (When the software is done :) MikeW50 OK, Greg. How would you suggest we move on from here? We could start a topic in the Byte Works MikeW50 area, which I check almost daily. Or in ADV, which I could check. Are you basically OK with a MikeW50 superstructure for the file format based on QuickTime, with compressed delta frames and MikeW50 periodic key full frames as the principal (i.e. first) animation cell format? SoftdiskGS Yes, as long as we can agree on the formats of these things so that they don't get in the way of SoftdiskGS the high-speed routines I've got. MikeW50 I suspect we can, since the overhead of the file format is something that really only has to be delt MikeW50 with once, when you load and initialize the animation player. McKinsey Have any of you looked at FLI and other similiar formats? MikeW50 I don't feel, as the QuickTime autors did, that every frame has to be in a separate record. SoftdiskGS Good. MikeW50 McKinsey, I don't recall that name. But I did look at the ones I found documented here and on SoftdiskGS What about my concept of "opcodes" in the change-list flagging other operations? Is that at MikeW50 GEnie. None of them supported all of the features I need and still run quickly enough on the GS. In SoftdiskGS odds with the flow-of-control you've got in mind (i.e. it should happen at a higher level)? McKinsey FLI = Auto Desk Animator (IBM) MikeW50 fact, QuickTime was the only one I found that was robust enough, but it would be a pig on the GS. If MikeW50 you have documentation for an alternative format that you would like to propose, I'd be thrilled to MikeW50 look it over. MikeW50 I did see some infor on Auto Desk Animator, but I did not have the complete documentation. If you MikeW50 have it, I'd like to see it. Can you post it in the library? McKinsey I would suspect any format specifically made for the GS would tend to suit McKinsey the GS better. McKinsey In space saving, efficiency, and speed. SoftdiskGS Which is why we're making a new format. MikeW50 Greg: I don't think the opcode idea meshes with time-control very well, but I might be wrong. If you MikeW50 have an idea to mesh the two, let's hear it. I might think of something once we start talking and MikeW50 have more time to think than to type. :) THX1672 Hi, all. AFL GaryJ Hi THX SoftdiskGS I was thinking of having an "object" list (up to 65535 objects, any of which could be called from any McKinsey Ill check for the FLI format dox on my hd, and post them if I find them. SoftdiskGS other), each of which could contain any number of frames, or could have alternative formats (like SoftdiskGS sound). MikeW50 Geat. If we can use it, it saves a lot of work. If we can't use it, we're still bound to learn MikeW50 something new. McKinsey I think I have the GLE format specs too. SoftdiskGS So if you have a draft of the supervisory level of your format, send it and I'll see how it meshes. MikeW50 Greg, but how do you know when to start a sound or video track? AFL GaryJ Hi Tang MikeW50 Greg: Unfortunately, I wrote it out by hand. It will take some time to get it in a machine- Tang IIGS Hello All MikeW50 readable state. :( SoftdiskGS I have a time-stamp opcode that is followed by a time-stamp value, and I check against the tick count. SoftdiskGS You can FAX it here, Mike... let me see if I've got the FAX number... Tang IIGS Has anything happened for the IIGS world this month? Tang IIGS Ive been out of the Net MikeW50 I don't have a fax. I don't want one. A fax is an evil extension of that evil device: The telephone. Tang IIGS hahahahahahahha AFL GaryJ Yes, the Byte Works released Modula 2, and HyperLogo GS. AFL GaryJ (This month) McKinsey I totally agree. Phones stink. Tang IIGS but with out phones, no phone lines, no Modem AFL GaryJ So is a modem, Mike :) SoftdiskGS Oh, well, I don't have a FAX _personally_, but Softdisk does... but I don't know the number, and MikeW50 And Programmer's Reference for System 6.0.1. And ORCA/Debugger 1.1.1. And 3D Logo 1.0.1. :) SoftdiskGS I couldn't find it around here... AFL GaryJ So, lots of new things for the IIGS world this month, Tang :) Tang IIGS SoftDiskGS.. I placed an order months ago to start, but nothing ever came McKinsey Hehe... Tang IIGS thanks all Ill have to spend some time in the LIBs MikeW50 AOL is a place where I can post and read questions at _my_ convinience, without interrupting or being SoftdiskGS E-mail me your name, address, phone-number, etc., and I can take have a customer service person MikeW50 interrupted. For me, anyway, that takes out the evil. :) SoftdiskGS call you back this week. MikeW50 Why, Greg. I really don't have a fax. No kidding on that issue. McKinsey Is that Mike Westerfield?? Hehe. McKinsey I had no idea. :) SoftdiskGS Anyway, I can send you a basic overview of my file format, Mike, and if can send me how it differs MikeW50 The hand-written notes make sense to me, but I still need to write up something before they would MikeW50 be useful to someone else. Might as well write it on the computer so I can upload it and everyone MikeW50 can see. SoftdiskGS (on the flow-of-control level, at least) from the QuickTime, I can dig up Chapter 4 of the QuickTime SoftdiskGS Ref. (I only have the first two chapters in my office). SoftdiskGS (Ch. 4 = File format) MikeW50 Greg, it's on the developer CD. I'm sure that's somewhere around your office. SoftdiskGS Ah. I'll commandeer Bryan's machine and use his CD-ROM player then. MikeW50 My first cut was essentially QuickTime with some 2-byte fields, some fields removed, and a new frame Tang IIGS Has anyone here tried Modem Wars? MikeW50 format for GS delta aminations. SoftdiskGS What about your change from separate records for each frame? That is an important consideration in SoftdiskGS light of my concept. MikeW50 Well, tell you what: I'll try to whip the format into shape next week. I have some articles I MikeW50 have to finish this week. I'll start a topic in the ByteWorks area if you don't beat me to it. We SoftdiskGS WHAT?!? I have to wait until NEXT YEAR?!? :) AFL GaryJ (I haven't Tang, at least I don't think I have) MikeW50 can post our own starting points there, and start discussing them. Sound OK? Tang IIGS Mike....Do you also do stuff for the Mac? MikeW50 Tang: Yes, a little. I did HyperLogo Mac, and will be doing 3D Logo Mac very soon. SoftdiskGS Yes. I may not have time to type out a draft until the weekend anyway, so that will work out fine for SoftdiskGS me. Tang IIGS I have 2 IIGS's and 3 old macs sitting here, I want to Net them MikeW50 OK. I better go now, then. It's been sort of a long night. Enjoyable, but long. :) Tang IIGS Well the SE isnt That old Tang IIGS thanks Alot Tang IIGS take care SoftdiskGS Chris (it is Chris, right?): I'm looking for the Paintworks viewer I have here at work... SoftdiskGS OK, goodnight Mike. McKinsey Bye Mike AFL GaryJ Goodnight, Mike MikeW50 Tang: That's possible -- I use my GSs and Macs on the same network. I use LocalTalk and AppleTalk. BCS Frank Night, Mike, and thanks :) AFL GaryJ Thank you for coming! MikeW50 Works great. AFL GaryJ It's been fun. AFL GaryJ (And you're right, it has been long :) Tang IIGS yes thats what im doing now, but I want to MikeW50 SO long all. Thanks for having me as the guest tonight. See 'ya!