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

Re: Quake packaging

Replies inline, but first a brief top-posted summary:

I think quakespasm and darkplaces are about ready for upload, once I've
fixed the quakespasm-dbg package.

quake is about ready for a first upload too, but it'll need a second trip
through the NEW queue for missionpack support (once my copies arrive from
eBay), or I might hold off on uploading anything until I've done the
mission packs if that goes as quickly as I hope. I'll probably add a
quake-server binary package at the same time.

Feel free to commit stuff to darkplaces.git (and in particular add yourself
to the Uploaders), if you're interested - I suspect you know Quake better
than I do!

To complete the set, I've vaguely started work on a quake2 package based on
quake and quake3 (see quake2.git in the usual place) but I haven't yet
researched which engine fork(s) we should be using or which files
game-data-packager will need. If you like Quake II, you're welcome to
help out - APRQ2, Quetoo or R1Q2 look like possibilities?

On Sat, 09 Jul 2011 at 20:38:28 +0100, David Banks wrote:
> > In my branches I changed the target distribution to UNRELEASED, because if
> > I'm going to sponsor this, I'll upload directly from pkg-games git, and only
> > push the change from UNRELEASED to unstable when I have actually uploaded.
> Hmm, I don't really understand what it means to upload directly from
> pkg-games git, but if it works it's no problem for me.

For your reference: sponsoring normally starts from a downloaded source
package, but since I'm in pkg-games too, instead of getting your .dsc from
mentors.d.n, I generally prefer to update my git checkout and build from
there. In the historical (non-VCS) Debian workflow there's a big difference
between a sponsored upload and an upload by a co-maintainer, but collaborative
maintenance in a VCS blurs the distinction.

> Just out of interest, what's the benefit to shipping the multiple sizes
> of icon?  I figured that most environments would just scale down the
> large one.

The Tango icon style guide recommends 1px outlines at all sizes <= 48px
(so the icons don't just scale down proportionally - the outline gets,
proportionally, thicker as you reduce the size). This makes the outlines
nice and clear.

(You can also do tricks analogous to font hinting - simplifying shapes
at smaller sizes, and aligning lines to pixel boundaries to avoid blurring -
but the Quake logo doesn't really need the former, and is too curved for the
latter to be very useful.)

> > If you launch a game of vanilla Quake, can you "upgrade" to a
> > mission pack through the GUI
> Definitely in the original engine and also in Quakespasm you have to
> re-run the engine and change it on the command line.

OK, so we probably want a separate .desktop for each mission pack. I have
both mission packs on the way from eBay, so I'll try this out soon!

> > If you need a command-line option, the packages produced by g-d-p should
> > probably be called quake-armagon-data and quake-dissolution-data, and the
> > quake source package should produce quake-armagon and quake-dissolution
> > binary packages (similar to quake) with a .desktop and .menu that use
> > the appropriate option.
> This would make it more consistent, although I think anyone who has the
> mission packs likely knows about -rogue, -hipnotic and such.

I was hoping we could have nice menu entries for the mission packs,
for non-command-line users :-)

(Hmm, I'll have to work out some sort of identifiable icon, though...)

> I can
> definitely put the appropriate packages in 'quake' package, but I guess
> the binaries and menus would always end up installed, even if the user
> did not have those data packages installed?

Unless we do a separate binary package per mission pack, or (as a compromise)
one for the base game, and one for users with either or both of the mission

> > I notice that quakespasm uses ~/.quakespasm, not ~/.quake. This means that
> > if we ever decide to make quake use a different engine, everyone doing an
> > upgrade will "lose" their settings and savegames, which would be
> > unfortunate.
> Yeah, that's a good point.  I'm not sure if savegames would generally be
> cross engine compatible.  (/me looks at the format)  Actually since it's
> all text it might be OK.

When I tried it, DarkPlaces loaded a QuakeSpasm savegame, but QuakeSpasm
couldn't load a DarkPlaces savegame:

    % quake --engine=darkplaces
    (start single-player, don't bother choosing a skill level)
    ] save darkplaces
    ] quit
    % mv ~/.darkplaces/id1/darkplaces.sav ~/.quakespasm/id1/
    % quake --engine=quakespasm
    ] load darkplaces

    Loading game from /home/smcv/.quakespasm/id1/darkplaces.sav...


    Shutting down SDL sound

    QUAKE ERROR: First token isn't a brace

There's some extra cruft at the end of the save which is probably the reason:

    +// DarkPlaces extended savegame
    +sv.lightstyles 0 m

> It's likely that config.cfg files would be mostly cross engine
> compatible

Having thought about this some more I think the key word there is
"mostly", unfortunately.

If we make sure all alternatives are priority=0 like I said in the
mini-policy, then we shouldn't "lose" any savegames, because automatic mode
for update-alternatives will never replace quakespasm with darkplaces or
vice versa. If someone uses manual mode, or installs a new engine and
uninstalls the old one, then "you asked for it, you got it".

To avoid collisions I'll add a note to the mini-policy that specifically
says to use a dot-directory per engine.

> I saw you added quakespasm-dbg package [...]
> it produces an empty binary package.

Sorry, I got halfway through implementing that. I'll finish it.


Reply to: