[Scummvm-devel] DXA file format for videos
max at quendi.de
Fri May 5 03:30:00 CEST 2006
Am 05.05.2006 um 10:21 schrieb Travis Howell:
> From: "Max Horn" <max at quendi.de>
>> Well, we still are talking a 5x increase compared to our current
>> BS2 video pack, and a 2x increase for the BS1. Granted, the
>> quality is probably better (maybe even a lot -- I never had a
>> chance to see the uncompressed versions of the videos). Still, if
>> we switch the format and at the same time ditch support for the
>> MPEG2 variants, we are "forcing" a lot of people to re-download
>> those cutscene packs.
>> From the coders point of view, of course the nicest and cleanest
>> solution would be to just ditch MPEG2 support completely in favor
>> of using DXA exclusively. From the point of view of a
>> "customer", though, having both supported in parallel (at least
>> in the next release) definitely would be preferable...
> If we plan to ditch MPEG2 support eventually, we might as well do
> it in the next release.
I disagree, see below.
> A good idea would be to post an announcement of change of formats,
> several weeks before the next release (Maybe around testing time?).
> We could provide a detailed guide for converting smacker files to
> DXA file format on wiki or web site, snapshots of updated tools
> package, and the updated cutscenes packs at that time. The advanced
> notice would give users enough warning, and choice of converting
> files or downloading updated cutscenes packs. Users can always use
> previous versions of ScummVM, if they prefer to stick with MPEG2
> support too.
I wasn't thinking about users who want to stick with MPEG2. The real
problem I see with the "ditch MPEG2 immediately" is the total lack of
a transition period. People download the new ScummVM, and *wham*,
their cutscenes stop work. This *will* happen to many people, no
matter how many warning we post in advance, simply because many
people don't read our news etc., but rather only notice when we make
a new release and grab that.
Again, for the coder, the easiest "solution" usually is to make a
hard transition. Nice clean code, no worries about update strategies,
etc.. For the enduser, thought, priorities are a bit different..
Coding with backward compatibility isn't easy, I know, but that's no
excuse. My I remind everybody of the SCUMM savegame system? There was
a point where it was very hard for us to make any changes to it,
because whenever we made such a change, *all* old savegames were
rendered unusable. That wasn't very nice.
This situation now of course is a bit different. We are talking about
a one-time transition. So if we say we want to make a hard cut, we
can do that. However, I want to make it absolutely clear what we are
talking about. To me, it *does* make quite a difference whether we
ditch MPEG2 support *now*, or whether we ditch it in the release-
after-the-next-release. Esp. when in the meantime, we add a warning
dialog to ScummVM that shows up whenever a game with "old" cutscenes
is started and asks the user to update to the new cutscenes (with an
option to turn off that nag screen).
More information about the Scummvm-devel