[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#689824: RFP: yquake2 -- Yamagi Quake II - Enhanced client for Quake II



Diverting this to debian-devel-games for somewhat wider feedback; see
#689824 for older context. I'd particularly appreciate any feedback from
Jon on g-d-p, and from Fabian on Quake II.

On 26/09/13 11:59, Simon McVittie wrote:
> * The dlopen() stuff for OpenGL/OpenAL seems bad: we don't benefit from
>   Debian's extensive library dependency checking. I think we should
>   patch the client to link those libraries in at compile time in the
>   normal way (like I did for darkplaces) and hard-depend on them.
>   Their size is insignificant when compared with the Quake II data.

I did that: wip/qgl branch in yquake2 git.

While doing so I realised that if we want a split package, the client
part will have to depend on the server part, because they both want
game.so. I renamed yamagi-quake2-server to yamagi-quake2-core and made
yamagi-quake2 depend on it - it contains the server binary, but no init
script or adduser invocation or anything (those are in quake2-server).

>>> I'd like to have a quake2/experimental package (probably as part of
>>> src:quake to reduce duplication) ready for the NEW queue at the same
>>> time, so the Description in yamagi-quake2 can say "this is just the
>>> engine, install quake2 to have a fully-working Quake II installation".
> 
> src:quake git branch wip/quake2
> 
> Completely untested, but it compiles.

After some adjustment, it even works. Review welcome. I think it's
basically good for upload, but perhaps to experimental.

>>> Similarly, I'd like to have quake2 support in at least
>>> game-data-packager/experimental before this hits NEW
> 
> src:game-data-packager branch wip/quake2
> 
> Somewhat untested, and only tested via "./game-data-packager" so far.
> 
> Things still to be done:
> 
> * Jon, does it look OK to you?
> * maybe give gdp_unzip support for the equivalent of "unzip -d"/"7z -o",
>   and decide whether it's doing "7z e"/"unzip -j" or "7z x"/"unzip"
>   (at the moment it depends on the tool used) - I'm not comfortable with
>   just changing it immediately, because I don't have any of the games
>   it's currently used for, so I don't know which behaviour was intended

Still pending; someone (probably me!) needs to test this in more situations.

Regards,
    S


Reply to: