Author Topic: .ANI's and .GIF's  (Read 4222 times)

0 Members and 1 Guest are viewing this topic.

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Can the code be easily expanded to use something different, like...not JPEG?


Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
Originally posted by WMCoolmon
Can the code be easily expanded to use something different, like...not JPEG?

It includes an image type specifier in the header.  That's in addition to the file format part of the header.  It's not really needed but there anyway.  This is also based on the all-in-one EFF idea that was under consideration but I stopped working on.  That's why it's there, I just haven't removed it.  The individual frames are complete files, not just the data part.  That's done so that individual compression and palette settings can be used.  The frame data follows a uint with the size of data in that frame.  That much data is read into memory and sent off to be decoded by a the jpeg reader that reads from memory rather than disk (already done when I did the new jpeg decoder).

Other than the fact that it's only ever sent off to a jpeg decoder there is nothing that prevents us from using multiple data formats (providing it's always the same for that animation).  And other than the decoder part everything else is in animplay.cpp.  The only exception is that it can't use DDS since it has the power-of-2 restriction.  JPEG is good to go now but that still leaves PCX and TGA as something that could be used.  Using either of those does nothing for disk space though which was one of the requests for any new format.

Uhh, really long way of saying "Yes, other formats could be used."  I should really figure out how to say things in a more efficient way. :rolleyes:


Offline Grug

  • 211
  • From the ashes...

What's everybody's problem with jpeg's?
Really, there is only minor picture glitches. Unless you use MSPaint to save your jpeg's they are fine for quality on the max setting.

Stop your complaining wmcoolman. :p