[Scummvm-devel] ScummVM 0.14.0

Travis Howell kirben at optusnet.com.au
Sun Jul 5 02:23:37 CEST 2009


Max Horn wrote:
> Am 04.07.2009 um 14:09 schrieb Travis Howell:
> 
>> Max Horn wrote:
>>> Am 04.07.2009 um 12:10 schrieb Travis Howell:
>>>> Could the planned release cycle for ScummVM 0.14.0 be delayed a few
>>>> weeks longer, in order to wait for merger of 16bit color support?
>>>>
>>>> 16bit color support will add a few more games (Freddi Fish 5, Pajama
>>>> Sam: Games to Play on Any Day, Spy Fox 3), and is planned to be  
>>>> merged
>>>> into trunk in the near future.
>>> It is ???
>>> I would have thought that it won't be merged before the end of  
>>> GSoC,  i.e. *soonest*till August 10, probably later. At that point  
>>> we'll have  very little testing.
>>> So, if we wait for that, we need to delay by at least 2 months.
>> A release cycle is due to start soon, with the branch added not long  
>> (1 week) after the release cycle starts.
>>
>> It was mentioned on IRC, to merge 16bit color support, as soon as  
>> ScummVM was branched for the next release.
> 
> I think I made my stance on the value of decisions about major API  
> changes on IRC clear enough in the past, so I won't repeat it.
> 
> Anyway, if Eugene and Jody are confident about it, we can discuss  
> *here* about merging the 16 bit API now. But I think it's better to  
> first develop it some further in its branch, and finalize 16bit  
> support in at least 2-3 engines in the branch, to make sure the API is  
> at least in principle usable. I'd also like to know how well 16bit  
> support interacts with the GUI, etc.

Those requirements for a future merge are too strict, especially with
quite a lot of game engine development in the gsoc2009-16bit branch of
ScummVM already (which can get out of sync with trunk too easily).

Three game engines (Groovie, SCUMM, SCI) are currently making use of
16bit color support in the gsoc2009-16bit branch of ScummVM. With 16bit
color support only finalized in the SCUMM game engine so far.

It could be a long time before 16bit color support is finalized in other
games engines, since support for the games requiring 16bit color support
  isn't complete (outside of 16bit color support).

So it would still be quite useful to have 16bit color support merged
into trunk, shortly after ScummVM 0.14.0 branch, if it isn't included in
the next release.

Your point about GUI interaction isn't clear, but sounds like another
case of more testing required.

Willem Jan Palenstijn wrote:
> I think it would be better to have more time between merging the 16bit
> branch back into trunk and a release. The larger number of developers
> (on a larger number of platforms) looking at the code when it hits trunk
> might well trigger some more minor API changes/discussion, and it would
> be bad to do that in the middle of the release process.

Any platform based off the SDL backend would immediately benefit from
initial 16bit color support, with the addition of several HE games.

It still isn't clear which other platforms (non-SDL) will even be able
to handle the higher resolution (640 x 480), color depth (16bit/24bit) 
and memory requirements (x1.5/2) of games using higher color depth either.




More information about the Scummvm-devel mailing list