[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).


Bye,
Max





More information about the Scummvm-devel mailing list