#New FLIC Compressor
34 messages in this thread
To all:
We have developed a FLIC compression system that has real time play back. It
will compress flics a minimum of 4 to 1 up to as high as 10 to 1. The player
supports all 8 bit VESA modes, and can interleave sound with the data. On a 66
Mhz 486, it can decompress 105 frames per second into the video buffer (640×480
full deltas – if there are fewer deltas, the speed will improve dramatically).
While the lossy portion of the system creates almost perfrect images, the
system also allows for the interleaving of the original data over the top of
the compressed data. That way, important objects can be retouched to appear
perfect.
The system was specifically designed for large delta flics – walk-throughs, 3D
Studio renderings, etc. It makes these types of flics viewable off CD-ROMs
again.
We designed the system for Access Software's new virtual reality game, and are
now considering marketing the system separately.
What we're wondering is, what's the level of interest in this area? Would
there be more interest in a developer's package, or an end-user's toolkit (or
both?) Is it a problem for many, some, or any of you?
Thanks for your help,
->Jeff
P.S. If there is a test flic that many of you are familiar with, I could
compress and reupload it, if the interest is there. Let me know.
Jeff- What you've developed sounds very interesting. I would be interested in
it from the standpoint of someone who developes multimedia projects (IE
Educational, Training, etc.) I'm not sure whether you would classify that as
developer or end user, but I would be interested none the less. How well does
it work on slower machines….286,386? Thanks,
-Mark
Mark:
It can playback 30 frames/sec on an 386sx, but it is 386 code (it could be
ported to 286 code, with a bit of a slowdown).
->Jeff
Jeff,
As an end user, I have been searching for something that would allow
realtime playback of flics (640×480), with full delta changes. I was hoping the
VL-bus would do it,
but I still wound up with the restriction of limiting camera movement (as in no
movement at all!) if I wanted full speed playback.
Is the interest there? YES!!! Could you briefly describe what the "end
user toolkit"
would include, an executable? a set of programs? What would be involved in
compressing a flic? A simple command, filename, and parameters? Any info you
could give would be helpful.
Thanks,
David
Your situation is the exact problem Access Software was trying to solve (full
deltas). What I was figuring would make up the end user kit would be: a
command line compressor, a utitility to merge back an original detail flic back
into the compressed file, and finally the player.
->Jeff
Jeff – This kit would include ability to interleave audio, too, right?!?!?!
David Taffet
Yes, audio (or any other data) can be interleaved, but the playback system
doesn't currently contain sound drivers, a programmer would have to add that.
Is there a need for sound drivers to be built-in? Opinions?
->Jeff
Yeah – built in sound support. Definitely.
Dave
Depends who you want to ultimately be your customers. If it will be
for commercial release, yes, you'll need sound drivers. It would need
to be a no-brainer. I would think that it would be helpful, at least,
for anyone, if you put hooks in your software to call sound drivers
and have them happily coexist with your software in RAM. FWIW
Yeah, the hooks are already there for other people's sound drivers. I
was just curious if the included player should supply sound drivers.
Big level of interest, Jeff. I know people (especially game developers) who
could use code like this instead of writing their own, as long as it is
completely authorable. This is real important when you are trying to play a
640-line high-delta file off a CD-ROM at a frame rate that's acceptable. I'd
love to hear more about it. It seems that GD at Trilobyte has decided not to go
ahead and commercially market his commpression/authoring scheme so it makes
this all the more interesting.
-Alan Iglesias
Alan —
The 7th Guest from Trilobyte has had all sorts of compatibility problems.
Over on GAMxPUB where I am a SysOp, there are constantly patches being uploaded
and tons of complaints.My feeling about GD's method is that it is too CD-ROM
based, and the majority of games are still disk-based.
My understanding of this particular game is that it is more a set of
un-related puzzles for each room, rather than a connected set of puzzles,
actions etc. for a united, connected game. The majority of games are still
disk-based and it would be nice to have FLICs which could still be used for a
disk-based game ( and not just for the intro).
Judy
Umm…Whatever, Judy.
Alan,
uh-oh!
Yeah, the code was written specifically for games – Access's new one. The
compression quality and speed is much, much beyond what's in 7th Guest.
->Jeff
Sounds great, Jeff. I'd appreciate any information on this code becoming
commercially available.
Thanks,
-Alan Iglesias
>We have developed a FLIC compression system that has real time play back.
I know that many here should be interested in that software. I am doing a lot
of company and product presentation with FLC's now and have some problem
fitting it in on diskett's <g>. If your player could compress and still wont
lose to mush in imagequality I will be VERY interested !
This could be used when wanting to make previous of frame-by-frame renderings
to !
Regards, Martin
I would be interested in something like that. Although I would use it for
diskette based game. Just now a Flic played as a game intro takes up way too
much room to use for anything else in the game other than the intro. I
certainly can see a real use for someting like this, but not just for CD-ROM –
but for disk based games. The CD-Rom market still has a lot of "shovelware" and
the percentage of gamers who have a CD-ROM driver is still under 50% of the
market. Also many games that CD-ROM only cause a lot of install problems either
due to the Video, AUdio etc. or both. Many gamers do complain at the slowness
of CD-ROM for any sort of action type game.
But I am working on a game now, and would like to use quite a few Flic, but
hesitate because of the size of them. So I would be very interested in hearing
more about what you are doing.
Judy
Our method has no specific ties to the CD-ROM format – it's just much faster
when played from the hard drive. You can also preload if you've got the
memeory.
->Jeff
The point I am making is that most FLICS take up so much room that if you plan
more than just the intro in a FLIC you must use CD-ROM unless you want to ship
the game on 20+ diskettes.
I am very interested in what you are talking about — especially if the
compression rate is high enough to allow the use of more FLICS on diskette
shipped games.
Also would your FLIC program allow the user to make directional changes:
turn around, go left/right, back up etc.
Judy
Gotcha. I agree that most games are too slow when run off the CD-ROM. I do,
however, like when they just ship the software on CD-ROM, so I can start the
installation and walk away.
I believe the compression rate is good enough for diskette based products. And
no, the playback system just plays back a predone flic.
->Jeff
Jeff – Very interesting! The real-time part *and* the sound interleave. I think
I constitute an end user, but might bleed over into the multimedia development
catagory a bit. I'm certainly interested in more info… Can you provide that?
David Taffet
Sure (on the more info). Where we're at now is that we have a command line
comrpessor that does the initial lossy swishing, a command line utility that
will merge detail back into the flic, another command line utility to merge in
any other kind of data (sound, another flics, etc), a utility that then takes
all of the lossy, detail, and extra data and compresses it lossless. And of
course the real time player.
Are there other utilities that would be useful?
->Jeff
This sounds great, Jeff! As to other utilities, see my other note. I
guess I think drivers for the 4-6 most common sound cards would be
pretty nifty in there, too. Where can I get this beast? <g>
Jeff:
End-User! End-User! End-User!
Have I put this plainly enough?<g>
How 'bout taking a flic off the 3DS (r2 or r3) CD-ROM and compressing it, or,
render the CHAPEL.3DS (r3 CD-ROM) animation and compress that! That would make
a really cool test! Can't wait to see something.
Dave
PS When is this new Access game coming out?
I'll do the Chapel.3ds and upload it with the player.
->Jeff
What would be very helpful is to have the player be able to use the mci
commands, like the current adesk.dll uses. This would make it possoble to have
some control over playback. I think the player overall would be very helpful
especially if incorporated into some of the authoring systems. If you would
like to get an idea go to the multimedia vendor forum(go multiven). there is
always alot of interest in getting animations to play and if compression is
available it makes it much more attractive.
Sam
Oh, BTW the Access game comes out sometime in spring.
->Jeff
Jeff
An flc compressor would be the answer to many peoples nightmares. I've been
trying to record small animations to video using a vga to ntsc converter and
its extremeley difficult to get what you want becouse of restrictions in memory
and video frame rates. When would this compression\player package become
available and do you have a cost for it yet?
Vern Shurtz
Graphic
Sight & p.s. Need anymore Beta testers? :>
Sounds
I make small animations for local businesses and to keep the cost
down I use real-time flic playback to tape. A utility(s) like this
would be a real godsend so I, for one, am VERY interested. Can you
supply more details? Availability? Cost?
I do a lot of flics, too. Often 320x200x256 colours. Once you get good
at making the most of the availabe res and pallette, then they can
look darned good. In fact, they have been more lucrative for me than
high-end video projects this year. Mainly because of the ease of
working with such small files and lack of frame-by-frame to video
pitfalls.
The utilities sound mighty interesting. I can't help but wondering why
Autodesk hasn't come up with an update/replacement for the .flc
format….
Martin,
320×200 wow! I didn't think that resolution would be acceptable to
anyone and I've never offered anything less than 640×480. Now I may have to
reconsider. It would certainly be more cost-effective for the client.
>> I can't help but wonder why Autodesk hasn't come up with an
>> update/replacement for the .flc format….
I don't know, perhaps from their lofty offices in Sausalito they just assume
everyone is going to invest $50,000 on equipment.<G>
Gregory,
320×200 you bet! Lots of work is still done at that res at 256 colours and
other vga resolutions like 640x480x16 colours (although I haven't done any 16
colour stuff). Many games and vga graphics/animations. The Video for Windows
crowd is all excited about 320×240 resolution now.
I know that when I started with r1 I hated 320×200 and yearned for higher. Then
I did 640×480 flics and I yearned for more colours so I started doing 3/4"SP
and then BetaSP work and now I realise frame-by-frame work is full of pitfalls
and doesn't really pay well enough to compensate for the aggrevation and the
equipment required to pump out the high resolution required. Now, I'm happy to
do low-res work and I can make decent money doing it. I tend to steer clear of
video work now unless it can be recorded in realtime.
Jeff,
I sure could use a flc system that has audio interleaved. After trying
to find a good dos based video system for a month I wrote my own interleaved
fli maker and playback. Sure it's cool but no real compression. How much and
when will it be ready?
ken/deep river publishing