FlicRaster -> WinBitmap?
17 messages in this thread
Hello,
I just received the Animation Support Libraries with the expectations
of being able to read a frame of a FLC or FLI file into a Window
Bitmap structure. I'm afraid I still don't have what I need. What
do I need to do with the Raster formats to convert to a Windows DIB
or BITMAP?
Help,
Andy
P.S. I'm developing in Visual C++ 1.5, MFC 2.5, Windows 3.1
<<I just received the Animation Support Libraries with the expectations of
being able to read a frame of a FLC or FLI file into a Window Bitmap structure.
I'm afraid I still don't have what I need. What do I need to do with the
Raster formats to convert to a Windows DIB or BITMAP? >>
What you need to get the single image of RGB information is found in the FLCLIB
(Animator Pro File Formats) section of the ASL. You can use this to generate
the picture file containing the still image in an uncompressed format. (.PIC
files)
The .BMP format is documented by Microsoft. You can find it in a number of
reference books, (i.e. the Windows Programmers reference) or call Microsoft at
206-882-8080 or the Microsoft Information Center at 800-426-9400.
-Brian
Hi Brian,
Thanks for the response. I guess I'm surprised that the ASL has no functions
to convert the FlicRaster (I think this is the RGB information you spoke of)
into the Windows BMP structure. The Autodesk Animation Player for Windows has
obviously done this in order to play animations in Windows. Is this technique
or code completely unavailable to Windows programmers?
Andy Pettigrew
<<I guess I'm surprised that the ASL has no functions to convert the FlicRaster
(I think this is the RGB information you spoke of) into the Windows BMP
structure.>>
There are no functions to do any conversion. That is not the real function of
the library. The library will give you the RGB data in a structured format that
will allow you to organize it however you want. To do the conversion you
already have the data structure of the FIL/PIC files, and Microsoft will
provide you with the data structure for the .BMP file.
<< The Autodesk Animation Player for Windows has obviously done this in order
to play animations in Windows.>>
Actualy, no. The Windows player can read an FLC file, and read a BMP file, but
it can not convert between the two.
<< Is this technique or code completely unavailable to Windows programmers?>>
The FLCLIB is not designed to be a graphics engine, but rather an entry point
into the Autodesk patented file formats. I think you are misunderstanding the
function of this library. It is not designed to give you specific functions,
but instead give you access into the file structure. It is possible that there
are libraries out there that have the functionality you are looking for, but
Autodesk does not provide a graphics conversion engine.
One company you might contact is:
Alchemy Mindworks Inc.
P.O. Box 500
Beeton, Ontario
L0G 1A0
Canada
1-800-263-1138 is an order line for their software, but they may be able to
point you to a technical person. Alchemy wrote software which converts FLC
files to BMP files, they may be willing to license their code to you. I don't
know.
-Brian
Hi Brian,
Thanks for the referral to Alchemy Mindworks Inc. Unfortunately, they do not
license the code.
Any other suggestions?
andy
<<Any other suggestions?>>
Not for a pre-packaged solution.
Unless you can find some other developer who would licence some existing code
for you, it looks like you will have to program the functionality. You have
access to both the begining and ending file formats, it shouldn't be an
impossible task. Just takes the time to actually do it.
-Brian
Hi Brian,
I've been working on several different problems so it's been a few days since I
checked here. After reading one of your previous replies, I wanted to clarify
something I said.
<<
Andy: The Autodesk Animation Player for Windows has obviously done this in
order to play animations in Windows.
Brian: Actualy, no. The Windows player can read an FLC file, and read a BMP
file, but it can not convert between the two.
>>
In my statement, I claim that the Animation Player AAWIN.EXE, must be able to
convert each frame of the FLI/FLC files into the Window Device Independent
Bitmap (DIB), or maybe even a Device Dependent Bitmap (DDB, aka HBITMAP), in
order to display them in Windows. At some point in the AAWin player, the frame
is read, converted to the appropriate Windows format, then the Windows API
function BitBlt() is called to display the frame.
If this is indeed true, then the code has been written that makes Windows
bitmaps. If at all possible, I'd prefer not to have to write this code myself.
If I'm beating a dead horse, I apologize.
Thanks again,
Andy
<<In my statement, I claim that the Animation Player AAWIN.EXE, must be able to
convert each frame of the FLI/FLC files into the Window Device Independent
Bitmap (DIB), or maybe even a Device Dependent Bitmap (DDB, aka HBITMAP), in
order to display them in Windows. At some point in the AAWin player, the frame
is read, converted to the appropriate Windows format, then the Windows API
function BitBlt() is called to display the frame.>>
I understand what you are saying. I am not sure if this is how the Windows
player reads the FLC files or not. If this is the way that it is accomplished,
then the code would be within the AAPLAY.DLL file.
However, in reviewing the C programmers reference manual for the .DLL, I see no
reference on how to obtain that DIB information. If this information actually
exists, there was no entry point into the .DLL programmed to access the data.
I will forward your post to one of the programers and see if he can clarify the
manner in which a FLC file is read and displayed in Windows. Hopefully this
will give us the information we are looking for.
-Brian
Andy,
Here is the reply from the programmer:
"Yes, in the internals of player it does create a DIB to blit to the
screen, but there isn't a function that converts a specific frame into
a DIB, its more like we paint the flic deltas into the same DIB over
and over and then blit that to the screen. "
So it sounds like if you could grab that intermediary DIB frame, after the
delta had been painted, you could get your BMP file. However there are no
program hooks already built in to do this. Can you reverse engineer that from
the .DLL?
-Brian
Hi Brian,
>>
"Yes, in the internals of player it does create a DIB to blit to the
screen, but there isn't a function that converts a specific frame into
a DIB, its more like we paint the flic deltas into the same DIB over
and over and then blit that to the screen. "
So it sounds like if you could grab that intermediary DIB frame, after the
delta had been painted, you could get your BMP file. However there are no
program hooks already built in to do this. Can you reverse engineer that from
the .DLL?
<<
Thanks for following up on this issue for me.
The quote from your programmer friend is encouraging. I don't think I can
"reverse engineer" the DLL though.
The FLICLIB documentation is a little vague in the format of the data in the
FlicRaster data structure. Specifically, on page 27 of the "File Formats and
FlicLib Reference", the "hw field" says "a RAM raster stores pointers to the
pixel memory buffer, and so on."
I'm stuck at this point because I don't have clue how to move the data in the
"pointers" into the DIB data structure.
I would be very grateful if your programmer friend could give some "pointers"
(pun intended) on the steps they use in the AAPLAY.DLL that moves data from the
raster data into the appropriate places in the DIB structure. If possible,
just that portion of source code would be very, very nice.
Thanks again for your help in this.
Andy Pettigrew
<<I would be very grateful if your programmer friend could give some "pointers"
(pun intended) on the steps they use in the AAPLAY.DLL that moves data from the
raster data into the appropriate places in the DIB structure. If possible,
just that portion of source code would be very, very nice.>>
I will forward this e-mail to him. Of course, if you can ask very specific
questions, I can get specific answers. The programers don't have a lot of time
to spend answering questions, so they may not respond request for a general
explanation. Let's see.
-Brian
Brian,
I noted in your message your reference to "Autodesk patented file formats". Can
you say specifically what file formats have been patented by Autodesk? Having
viewed the .GIF nightmare where UNISYS came back 10 years after the fact
demanding royalties from anyone using the patented encoding schemes for .GIF,
our attorneys our asking us to be very wary of patent/royalty issues for the
future.
Also, is there a license or royalty fee required for using FLCLIB in a
commercial application product? If so, can you say how much?
Thanks, Jack
<< Can you say specifically what file formats have been patented by Autodesk?>>
Anything in the FLCLIB would count, including FLC, FLI, CEL, PIC, etc….
<<Having viewed the .GIF nightmare where UNISYS came back 10 years after the
fact demanding royalties from anyone using the patented encoding schemes for
.GIF, our attorneys our asking us to be very wary of patent/royalty issues for
the future.>>
Yes, that was a nightmare, and not my intent in mentioning that we own the file
formats. My intent with that phrase was to clarify that we were the creator of
the file format, and thus are the company that distributes the file format to
the public.
<<Also, is there a license or royalty fee required for using FLCLIB in a
commercial application product? If so, can you say how much?>>
At minimum, you might need a licence agreement. It depends on what you use, and
how you distribute it. The person to talk to is Mark Gerhard. He is the product
manager for the ASL. He can be reached at 415-507-5000 or markg@autodesk.com
-brian
>> Anything in the FLCLIB would count, including FLC, FLI, CEL, PIC, etc…. <<
PIC? careful! Lotus (.PIC) and Storyboard (.PIC) to mention a few… <g> -dave
<<PIC? careful! Lotus (.PIC) and Storyboard (.PIC) to mention a few… <g>
-dave>>
I refrain from answering on the grounds that I may say something "snippy".
-b
>> I refrain from answering on the grounds that I may say something "snippy".
<<
such control! <ggg> -dave