[Scummvm-devel] DXA file format for videos

Max Horn 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 mailing list