Re: [Warzone-dev] 2.1 beta3 again

[Per Inge Mathisen]

On Fri, Jun 13, 2008 at 8:31 AM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
> PS That someone is me. I changed several parsers (.y files) to use the
> %destructor feature, which is only available without being seriously
> broken in Bison > 2.1.

Could we revert those changes and go back to relying on an older
version of bison? I do not really care much if we leak a bit of memory
- in the long run (hopefully sooner rather than later) I think we all
agree that we are converting to lua for the scripts anyway.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Per Inge Mathisen]

On Fri, Jun 13, 2008 at 6:00 AM, bugs buggy <[EMAIL PROTECTED]> wrote:
> I'll get back to the other parts, but I would like to know why the
> extremely short gestation period for the new contract/readme ?
>
> You blink,  and you miss everything.
>
> I left the issues about this on the forums, but I rather like to know
> why it wasn't made public before hand, and only after the fact it was
> revealed.
>
> I for one was quite shocked at the exception part.

I worked on getting the FMVs and soundtracks released as GPL through
Pivotal. The new README with the exception was pushed by the wz2200
people who were talking directly with the EIDOS person who showed up
on the forum. We managed to get some input on the README that made it
better than what we had (confirmed GPL v2 *or later*, as well as a
more official confirmation of the GPL release of all the data), so on
the whole I am happy with it, although I am less than enthusiastic
about the exception itself. Note that our code and our version does
not contain the exception, so this means that wz2200 cannot use any of
our code now - but I told them of this consequence and they were happy
with it.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Per Inge Mathisen]

On Fri, Jun 13, 2008 at 1:35 AM, Christian Ohm <[EMAIL PROTECTED]> wrote:
> For playback I'd prefer using FFMPEG to the OGG libraries directly,
> since this will make it easier for others to make movies for mods
> without lossy reencoding into obscure formats.

Note that ffmpeg is not distributed by most linux distributions,
because of many murky patent issues, and usually has to be separately
installed by the end user. For this reason I would prefer to use the
ogg libraries.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta3 again

[Giel van Schijndel]

Ari Johnson schreef:
> On Thu, Jun 12, 2008 at 11:58 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
>> You wouldn't happen to know what causes (or caused)  this would you:
>> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.h\ \"${INPUT_FILE_PATH}\"\
>> ||\ exit\ 1
>> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.c\ \"${INPUT_FILE_PATH}\"\
>> ||\ exit\ 1
>> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
>> unrecognized: %name_prefix
>> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
>> Skipping to next %
>> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
>> unrecognized: %destructor
>> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
>> Skipping to next %
>> ** BUILD FAILED **
>>
>> Or is that now fixed?
>> It seems weird it sees %name_prefix, and not %name-prefix.
> 
> That was caused by someone changing our .y files to require a version
> of Bison newer than the one included with OS X.

Those changes could explain the error on line 61 (%destructor), but they
don't explain the error on line 51. Line 51 holds the %name-prefix
directive, which we've used since the dawn of days...

PS That someone is me. I changed several parsers (.y files) to use the
%destructor feature, which is only available without being seriously
broken in Bison > 2.1.

-- 
Giel



signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta3 again

[Ari Johnson]

On Thu, Jun 12, 2008 at 11:58 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
> On 6/13/08, Ari Johnson <[EMAIL PROTECTED]> wrote:
>> On Thu, Jun 12, 2008 at 10:55 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
>>  > Ari, when you get the time, is it possible to write down someplace
>>  > what all is involved in building the mac builds the way you want it to
>>  > be done?
>>  > In the forums, ( http://forums.wz2100.net/viewtopic.php?f=19&t=1747 ),
>>  > people have issues, but I don't know what the 'correct' fix is, or how
>>  > to explain the process to them.
>>
>>
>> That documentation is cleverly hidden in macosx/README.BUILD.txt where
>>  it has been located since I first created the Mac port. :)
>>
> LOL :o ... guess you can tell I never even bothered to look.
>
>>  >
>>  > That way, it would be easier to know what breaks, (and how NOT to
>>  > break) mac builds.
>>
>>
>> That's one thing I try to keep consistent and which has not been
>>  maintained as faithfully by other developers: A simple build process
>>  that has as its only prerequisites Mac OS X 10.4 or higher, Xcode, and
>>  the Warzone sources.  Given those things, it has (ever since I
>>  converted the port to an Xcode project) been a single command in the
>>  terminal that generates the .app.
>
> I wonder if it could be possible for you (or someone you trust) to
> allow remote logins into your machine, and then see if it still builds
> ok or not?  Or can't you build something that way?
> Or, perhaps you can have a script that autobuilds the source code, and
> if it fails, you send a automated e-mail to the ML, saying that r
> broke mac builds. (or something like that.)
> That way, we know there is a problem that needs fixing ASAP.
>
>
> You wouldn't happen to know what causes (or caused)  this would you:
> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.h\ \"${INPUT_FILE_PATH}\"\
> ||\ exit\ 1
> bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.c\ \"${INPUT_FILE_PATH}\"\
> ||\ exit\ 1
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
> unrecognized: %name_prefix
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
> Skipping to next %
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
> unrecognized: %destructor
> /Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
> Skipping to next %
> ** BUILD FAILED **
>
> Or is that now fixed?
> It seems weird it sees %name_prefix, and not %name-prefix.

That was caused by someone changing our .y files to require a version
of Bison newer than the one included with OS X.  The problem is that I
now have to get the Xcode project to build and use a newer version of
Bison automatically to counter that, because I don't want to rely on
ANYTHING that I didn't list above.  And I don't have time to finish
that process.  Freddie, on the other hand, didn't bother to do that
with Bison and just used DarwinPorts or Fink to install a newer
version of Bison and rely on that (also for time constraint reasons on
his part)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[bugs buggy]

On 6/12/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
>  Here are my very preliminary thoughts:
>   * we ship beta3 once we have run some quick network tests on it,
>  tomorrow or Saturday, with an announcement of the above good news,
>  adding that we will attempt to integrate as much as possible of it
>  into the final 2.1 release.
>   * we put the original soundtracks in a mod to be distributed along with 
> beta3

I agree that beta3 should be shipped ASAP.  We need to test the
netcode with all platforms!
Finding Mac people with free time is a huge problem though.  There
must be someplace where we can get some mac people to test out the
builds with us?
Anyone know a good place to post the 'Help wanted' sign?  Forums seem
to be a very low traffic area for Mac people.

I know that debian needs to have something in unstable for at least 10
days, before it can get into lenny, and the freeze date for that is
July.
We can also assume that when that is done, Ubuntu (and the others?)
will finally update their (ancient) version of warzone that they have.

>   * we create a new branch based on trunk to attempt to quickly produce
>  working FMV code for 2.1 beta4

Off trunk?  I am not sure that is the best bet, unless we do some reverting?
(yeah, I know the patch I did is off trunk., but I am having 2nd
thoughts about that.)

>   * we put the converted FMVs in a tarball on gna.org, but not in the
>  svn repository (too big, 300mb+)

I dunno where you come up with 300MB, since originals are around 700MB
or so, and the converted videos are more or less 1:1 in size, but are
a larger resolution. (320x240 vs 640x480) (well, with the bitrate I
talk about before)

>   * for 2.1 we allow the user to play without FMVs, as before, and only
>  optionally play them if present

That  IS what it does now.  If file not found, then it don't play.  If
found, then it plays.
(speaking about patch #885)


>   * for 2.2 we try to isolate all of the campaign into a mod, so that
>  you can pull down a single mod to enable the campaign with FMVs, and
>  find a way for mods to 'register' their presence into the main menu,
>  etc.
Not sure that is needed.
For windows, the installer can query the enduser what they want, and
download from where-ever.  For the other platforms, I have no idea.

I don't like any binary data in svn, it just doesn't do a good job with it.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta3 again

[bugs buggy]

On 6/13/08, Ari Johnson <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 10:55 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
>  > Ari, when you get the time, is it possible to write down someplace
>  > what all is involved in building the mac builds the way you want it to
>  > be done?
>  > In the forums, ( http://forums.wz2100.net/viewtopic.php?f=19&t=1747 ),
>  > people have issues, but I don't know what the 'correct' fix is, or how
>  > to explain the process to them.
>
>
> That documentation is cleverly hidden in macosx/README.BUILD.txt where
>  it has been located since I first created the Mac port. :)
>
LOL :o ... guess you can tell I never even bothered to look.

>  >
>  > That way, it would be easier to know what breaks, (and how NOT to
>  > break) mac builds.
>
>
> That's one thing I try to keep consistent and which has not been
>  maintained as faithfully by other developers: A simple build process
>  that has as its only prerequisites Mac OS X 10.4 or higher, Xcode, and
>  the Warzone sources.  Given those things, it has (ever since I
>  converted the port to an Xcode project) been a single command in the
>  terminal that generates the .app.

I wonder if it could be possible for you (or someone you trust) to
allow remote logins into your machine, and then see if it still builds
ok or not?  Or can't you build something that way?
Or, perhaps you can have a script that autobuilds the source code, and
if it fails, you send a automated e-mail to the ML, saying that r
broke mac builds. (or something like that.)
That way, we know there is a problem that needs fixing ASAP.


You wouldn't happen to know what causes (or caused)  this would you:
bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.h\ \"${INPUT_FILE_PATH}\"\
||\ exit\ 1
bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.c\ \"${INPUT_FILE_PATH}\"\
||\ exit\ 1
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
unrecognized: %name_prefix
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:
Skipping to next %
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
unrecognized: %destructor
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:
Skipping to next %
** BUILD FAILED **

Or is that now fixed?
It seems weird it sees %name_prefix, and not %name-prefix.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[bugs buggy]

On 6/12/08, Christian Ohm <[EMAIL PROTECTED]> wrote:
> On Thursday, 12 June 2008 at 23:54, Angus Lees wrote:
>  > My intention with the fmvs originally was to provide a separate 'fmv.wz'
>  > which could just be dropped into the right directory - as other's have
>  > suggested.  Look for the movie and fall back to current behaviour if not
>  > found (and when the movie ends).  Distros-and-whatever would presumably
>  > package it separately, and (when the legal situation was murky) users could
>  > choose to download/distribute it themselves.
>  >
>  > The patch I sent some time ago supported both .ogg and .rpl formats, again
>  > my intention being allowing those few people with the original game to use
>  > their .rpls (or something) and the rest of us can use .oggs.  And the code
>  > is structured to allow other formats if something better turns up.
>
>
> Since the reencoded movies are quite a bit smaller and can now
>  definitely be redistributed, the RPL code isn't really needed anymore, I
>  think.
>
>  For playback I'd prefer using FFMPEG to the OGG libraries directly,
>  since this will make it easier for others to make movies for mods
>  without lossy reencoding into obscure formats.

You mean launch a external program to handle this?
I am not sure this is the best way to go on all platforms, you would
also need some way to make sure each platform has ffmpeg available.

Right now, I am playing around with ogg libraries...

>
>
>  > For reference, a no-fancy-options recompression of the rpl files into ogg
>  > ends up at about this resulting size:
>  >
>  >  187Msequences_ogg.zip
>  >  777Msequences_rpl.zip
>  >
>  > So .ogg theora/vorbis is a pretty big saving in size.  sequences_ogg.zip 
> was
>  > generated via my rpl2avi wine program with the original eidos dlls and then
>  > reencoded using ffmpeg2theora - if you're interested in the resulting file
>  > or any of the pipeline just ask.
>
>
> What codec was the intermediate AVI? If it was lossy, the double
>  reencoding degraded the quality/size more than necessary (i.e. with
>  direct encoding to the target format the files could be smaller or
>  of better quality (or even both)).

For my experiment into this, I just dumped out each frame, and the
sound, and then used ffmpeg to make that into a ogg/theora video.
I used a bitrate of 2400K (unsure what I should use), and the results
are pretty much what the originals look like.  The only other thing I
was trying to figure out is, that the original videos are all 320x240
or less.  The 'full screen' option renders the video every other
scanline.  If you know a good way to upscale from 320x240 without big
ugly pixelazation, I am all ears. :)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[bugs buggy]

On 6/12/08, Angus Lees <[EMAIL PROTECTED]> wrote:
> The patch I sent some time ago supported both .ogg and .rpl formats, again
> my intention being allowing those few people with the original game to use
> their .rpls (or something) and the rest of us can use .oggs.  And the code
> is structured to allow other formats if something better turns up.

I didn't see your patch on the tracker @ GNA, or maybe I am blind?
The current ones are from Gerard, and one supports lua which is
https://gna.org/patch/?908 and the other one is patch #885.

I currently updated #885 for trunk, but it still has some issues.
I would like to check out your ogg playback code, and see if it works better.

>
> For reference, a no-fancy-options recompression of the rpl files into ogg
> ends up at about this resulting size:
>
>  187Msequences_ogg.zip
>  777Msequences_rpl.zip
>
> So .ogg theora/vorbis is a pretty big saving in size.  sequences_ogg.zip was
> generated via my rpl2avi wine program with the original eidos dlls and then
> reencoded using ffmpeg2theora - if you're interested in the resulting file
> or any of the pipeline just ask.

I haven't done much with video stuff, but I used ffmpeg with a bitrate
of 2400K, and used the 'double sized' video (as in, it skips ever
other scanline to make the FMV appear bigger than it is), so while the
original FMVs are 320x240 (and some are less than this), the one I
converted is 640x480.   The issue with the 320x240 is that if we
stretch that out to fill the screen, then we get really ugly
pixelization.  Is there any filter or some other program that we can
use to fix this?
The original vid I converted from is 30,996,655 bytes (320x240), and
the new one is  32,095,488 bytes (640x480).


> As for the original patch, it was deliberately against 2.0, since I figured
> that was where the unmodified game was (this may not be the intention
> anymore however).  I tried briefly to port it to svn head, but I don't think
> I finished the job.
>
> I can easily throw what I've got into an svn branch and everyone can hack on
> it, although there seemed little interest from other developers last time..
> My code always had a strange opengl bug I could never track down: after
> playing an fmv, the closest LOD textures were corrupted. As far as I could
> work out I was correctly resetting the texture page and other obvious things
> - I figure I wasn't cleaning up sufficiently after the various YUV opengl
> shenanigans and I expect someone who actually understands GL would be able
> to spot it fairly easily.  The RPL dec130 decoder also always had some
> output corruption I could never work out.  The ogg/theora decoder works fine
> though.  Oh and I hadn't reverted enough of our hacks to be able to show the
> windowed research videos again, but that should be quite possible.
>
> --
>  - Gus

I rather we just skip the RPL headaches, and just convert them to
ogg/theora.  Would seem to be the best bet, and less code maintenance.

I dunno about our mac friends, and if the RPL playback code is endian
safe or not.  Actually, I don't even know if the ogg playback code we
have on the tracker is endian safe either.   Sorry Ari. :(

Maybe Jobs will give the devs a few macs so we can test? ;)

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta3 again

[Ari Johnson]

On Thu, Jun 12, 2008 at 10:55 PM, bugs buggy <[EMAIL PROTECTED]> wrote:
> On 6/8/08, Ari Johnson <[EMAIL PROTECTED]> wrote:
>> On Sun, Jun 8, 2008 at 9:36 AM, Per Inge Mathisen
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> > We found and fixed a serious endianness problem in the network code
>>  > (packet size was not byte swapped), which means we will have to
>>  > recreate the binaries again. Sorry.
>>  >
>>  > Let me know when you are ready.
>>
>>
>> Given that my binaries are subject to deletion anyhow, I'll let
>>  Freddie do it.  Have fun.
>>
> I am unsure I understand what you mean, all the binaries are now here:
> http://download.gna.org/warzone/releases/2.1/hold_back/
>
> So I don't see anything that was deleted?

I meant that my build was going to be deleted because it was larger in
size and a debug build.

>
> For the other things, I think there should be 2 binaries available for
> each platform, a release build and a debug build.
> I agree that debug builds are *far* better for finding bugs, and all
> betas *should* be debug builds.
> Then when we go into release mode, have a release & a debug build
> available that people can use to see if they can replicate the problem
> with both builds.

I agree.

>
> Ari, when you get the time, is it possible to write down someplace
> what all is involved in building the mac builds the way you want it to
> be done?
> In the forums, ( http://forums.wz2100.net/viewtopic.php?f=19&t=1747 ),
> people have issues, but I don't know what the 'correct' fix is, or how
> to explain the process to them.

That documentation is cleverly hidden in macosx/README.BUILD.txt where
it has been located since I first created the Mac port. :)

>
> That way, it would be easier to know what breaks, (and how NOT to
> break) mac builds.

That's one thing I try to keep consistent and which has not been
maintained as faithfully by other developers: A simple build process
that has as its only prerequisites Mac OS X 10.4 or higher, Xcode, and
the Warzone sources.  Given those things, it has (ever since I
converted the port to an Xcode project) been a single command in the
terminal that generates the .app.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[bugs buggy]

On 6/12/08, Per Inge Mathisen <[EMAIL PROTECTED]> wrote:
> For those of you who have not followed the latest events on the forum
>  and/or IRC, EIDOS have now granted us permission to distribute both
>  the FMVs and the soundtracks from the original game under the GPL.
>  This bodes well for the future.
>
>  Opinions?
>
>  Yours
>  Per
I'll get back to the other parts, but I would like to know why the
extremely short gestation period for the new contract/readme ?

You blink,  and you miss everything.

I left the issues about this on the forums, but I rather like to know
why it wasn't made public before hand, and only after the fact it was
revealed.

I for one was quite shocked at the exception part.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] 2.1 beta3 again

[bugs buggy]

On 6/8/08, Ari Johnson <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 8, 2008 at 9:36 AM, Per Inge Mathisen
>
> <[EMAIL PROTECTED]> wrote:
>
> > We found and fixed a serious endianness problem in the network code
>  > (packet size was not byte swapped), which means we will have to
>  > recreate the binaries again. Sorry.
>  >
>  > Let me know when you are ready.
>
>
> Given that my binaries are subject to deletion anyhow, I'll let
>  Freddie do it.  Have fun.
>
I am unsure I understand what you mean, all the binaries are now here:
http://download.gna.org/warzone/releases/2.1/hold_back/

So I don't see anything that was deleted?

For the other things, I think there should be 2 binaries available for
each platform, a release build and a debug build.
I agree that debug builds are *far* better for finding bugs, and all
betas *should* be debug builds.
Then when we go into release mode, have a release & a debug build
available that people can use to see if they can replicate the problem
with both builds.

Ari, when you get the time, is it possible to write down someplace
what all is involved in building the mac builds the way you want it to
be done?
In the forums, ( http://forums.wz2100.net/viewtopic.php?f=19&t=1747 ),
people have issues, but I don't know what the 'correct' fix is, or how
to explain the process to them.

That way, it would be easier to know what breaks, (and how NOT to
break) mac builds.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Dennis Schridde]

Am Freitag, 13. Juni 2008 01:13:39 schrieb Christian Ohm:
> For the Windows world, rather a zip than a tarball. And a torrent would
> be nice as well, to spare GNA's bandwidth a bit.
Last time I talked to Gna about this, they said that bandwith is not remotely 
an issue for them.

--Dennis


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Christian Ohm]

On Thursday, 12 June 2008 at 23:54, Angus Lees wrote:
> My intention with the fmvs originally was to provide a separate 'fmv.wz'
> which could just be dropped into the right directory - as other's have
> suggested.  Look for the movie and fall back to current behaviour if not
> found (and when the movie ends).  Distros-and-whatever would presumably
> package it separately, and (when the legal situation was murky) users could
> choose to download/distribute it themselves.
> 
> The patch I sent some time ago supported both .ogg and .rpl formats, again
> my intention being allowing those few people with the original game to use
> their .rpls (or something) and the rest of us can use .oggs.  And the code
> is structured to allow other formats if something better turns up.

Since the reencoded movies are quite a bit smaller and can now
definitely be redistributed, the RPL code isn't really needed anymore, I
think.

For playback I'd prefer using FFMPEG to the OGG libraries directly,
since this will make it easier for others to make movies for mods
without lossy reencoding into obscure formats.

> For reference, a no-fancy-options recompression of the rpl files into ogg
> ends up at about this resulting size:
> 
>  187Msequences_ogg.zip
>  777Msequences_rpl.zip
> 
> So .ogg theora/vorbis is a pretty big saving in size.  sequences_ogg.zip was
> generated via my rpl2avi wine program with the original eidos dlls and then
> reencoded using ffmpeg2theora - if you're interested in the resulting file
> or any of the pipeline just ask.

What codec was the intermediate AVI? If it was lossy, the double
reencoding degraded the quality/size more than necessary (i.e. with
direct encoding to the target format the files could be smaller or
of better quality (or even both)).

> As for the original patch, it was deliberately against 2.0, since I figured
> that was where the unmodified game was (this may not be the intention
> anymore however).  I tried briefly to port it to svn head, but I don't think
> I finished the job.
> 
> I can easily throw what I've got into an svn branch and everyone can hack on
> it, although there seemed little interest from other developers last time..

I guess because of the uncertainty regarding the movies it never made it
into SVN and thus fell by the wayside.

> My code always had a strange opengl bug I could never track down: after
> playing an fmv, the closest LOD textures were corrupted. As far as I could
> work out I was correctly resetting the texture page and other obvious things
> - I figure I wasn't cleaning up sufficiently after the various YUV opengl
> shenanigans and I expect someone who actually understands GL would be able
> to spot it fairly easily.  The RPL dec130 decoder also always had some
> output corruption I could never work out.  The ogg/theora decoder works fine
> though.  Oh and I hadn't reverted enough of our hacks to be able to show the
> windowed research videos again, but that should be quite possible.

Is the YUV stuff really necessary? I don't really know the OGG libs, but
FFMPEG includes yuv2rgb conversion that could be used as a baseline, and
the OpenGL YUV converters as optional optimizations. That also has the
advantage of working always (if not that fast, but for the low-res FMVs
that shouldn't matter much) - IIRC none of the mplayer OpenGL YUV
variants works correctly on my system.

-- 
* dark has changed the topic on channel #debian to: Later tonight: After
  months of careful refrigeration, Debian 2.0 is finally cool enough to
  release.

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Christian Ohm]

On Thursday, 12 June 2008 at 16:11, Giel van Schijndel wrote:
> Dennis Schridde schreef:
>> Am Donnerstag, 12. Juni 2008 13:13:49 schrieb Per Inge Mathisen:
>>> I believe there is some expectation that our next release
>>> will include the missing data now, and we should discuss if this is a
>>> good idea.
>
> I'd say we don't include the FMVs for beta3, it'll only delay beta3  
> further. As for the final 2.1 I'd really love to have the FMVs in them.  
> Though I think we shouldn't delay too long for that, as we can always  
> release a 2.1.1 or whatever for that purpose.

Agree.

>>> I would like some input from the people who worked with the
>>> FMVs on how much work remains to integrate them properly (gerard,
>>> angus...), and I would also like to hear people's opinions on how they
>>> should be distributed.
>
> As for distribution I suggest we use a non-RPL based format. Ogg/Theora  
> comes to mind, though I don't really mind other formats either. (As long  
> as it's a free & open format).

I prefer MKV to OGM as a movie container, though for a game it doesn't
really matter. Codec-wise Theora/Vorbis seems a good choice.

>>>  * we create a new branch based on trunk to attempt to quickly produce
>>> working FMV code for 2.1 beta4

Why a branch? The movie code shouldn't be that difficult to reactivate
(unless someone ripped it totally apart in the last months), so just
doing it in the trunk seems easier to me.

>>>  * we put the converted FMVs in a tarball on gna.org, but not in the
>>> svn repository (too big, 300mb+)
>
> I suggest we stuff all FMVs in a .wz modpack instead of a tarball. This  
> way no further processing will be required by those wish to download and  
> use it (aside from dumping it in the correct directory). I suggest that  
> we put all non-FMV data (i.e. meta data) that will have to reside in the  
> same .wz zip file in our svn repository though.

For the Windows world, rather a zip than a tarball. And a torrent would
be nice as well, to spare GNA's bandwidth a bit. 

>>>  * for 2.1 we allow the user to play without FMVs, as before, and only
>>> optionally play them if present
>
> It's probably best to somehow register the FMVs with warzone through the  
> WRF resource system. Then we just attempt to always play these videos and 
> do nothing when they're not loaded through the WRF system.

The infrastructure for that should still be in place, we just need code
to decode and show the videos.

>>>  * for 2.2 we try to isolate all of the campaign into a mod, so that
>>> you can pull down a single mod to enable the campaign with FMVs, and
>>> find a way for mods to 'register' their presence into the main menu,
>>> etc.
>> Sounds good. For modem people we could also provide a cam-novid.wz download.
>
> How about splitting up the campaign in two parts? An "all except for  
> videos and other huge media" part (packed in a single .wz) and a "videos  
> and huge media" part (in another .wz). That way we don't have to provide  
> a cam-novid.wz download. Instead we can just neglect to download the  
> cam-optional-media.wz pack.

What he said.

>> Apropos soundtracks. There is still MichaelB et al.'s soundtracks 
>> dangling somewhere. Maybe we could add them to beta4 as well?
> I've already added them to a mod pack [1] and solved out the licensing  
> issues for those. I've also set up the NSIS installer to automatically  
> download that mod-pack at the user's request (i.e. they just have to  
> enable it in the "components" section).
>
> [1] http://download.gna.org/warzone/releases/mods/music_1.0.wz

Are those all the contributed tracks, or just a selection?


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Angus Lees]

On Thu, Jun 12, 2008 at 12:13 PM, Per Inge Mathisen <[EMAIL PROTECTED]>
wrote:

> For those of you who have not followed the latest events on the forum
> and/or IRC, EIDOS have now granted us permission to distribute both
> the FMVs and the soundtracks from the original game under the GPL.
> This bodes well for the future.
>

Hurray!  \o/

My intention with the fmvs originally was to provide a separate 'fmv.wz'
which could just be dropped into the right directory - as other's have
suggested.  Look for the movie and fall back to current behaviour if not
found (and when the movie ends).  Distros-and-whatever would presumably
package it separately, and (when the legal situation was murky) users could
choose to download/distribute it themselves.

The patch I sent some time ago supported both .ogg and .rpl formats, again
my intention being allowing those few people with the original game to use
their .rpls (or something) and the rest of us can use .oggs.  And the code
is structured to allow other formats if something better turns up.

For reference, a no-fancy-options recompression of the rpl files into ogg
ends up at about this resulting size:

 187Msequences_ogg.zip
 777Msequences_rpl.zip

So .ogg theora/vorbis is a pretty big saving in size.  sequences_ogg.zip was
generated via my rpl2avi wine program with the original eidos dlls and then
reencoded using ffmpeg2theora - if you're interested in the resulting file
or any of the pipeline just ask.


As for the original patch, it was deliberately against 2.0, since I figured
that was where the unmodified game was (this may not be the intention
anymore however).  I tried briefly to port it to svn head, but I don't think
I finished the job.

I can easily throw what I've got into an svn branch and everyone can hack on
it, although there seemed little interest from other developers last time..
My code always had a strange opengl bug I could never track down: after
playing an fmv, the closest LOD textures were corrupted. As far as I could
work out I was correctly resetting the texture page and other obvious things
- I figure I wasn't cleaning up sufficiently after the various YUV opengl
shenanigans and I expect someone who actually understands GL would be able
to spot it fairly easily.  The RPL dec130 decoder also always had some
output corruption I could never work out.  The ogg/theora decoder works fine
though.  Oh and I hadn't reverted enough of our hacks to be able to show the
windowed research videos again, but that should be quite possible.

-- 
- Gus
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #11820] Crash on attempt to save game

[Max]

URL:
  

 Summary: Crash on attempt to save game
 Project: Warzone Resurrection Project
Submitted by: the_source_him
Submitted on: Четверг 12.06.2008 at 18:55
Category: None
Severity: 5 - Blocker
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.1_beta2
Operating System: GNU/Linux
 Planned Release: None

___

Details:

System: Fedora 9 x86_64, Intel Core 2 Duo E6600, GeForce 8800GTX
Game version:
warzone2100-2.1.0-0.5.beta2.fc9.x86_64


Happens on any attempt to save game. Attaching warzone output on crash.



___

File Attachments:


---
Date: Четверг 12.06.2008 at 18:55  Name: warzone.log  Size: 8kB   By:
the_source_him
warzone crash report


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Giel van Schijndel]

Dennis Schridde schreef:

Am Donnerstag, 12. Juni 2008 13:13:49 schrieb Per Inge Mathisen:

I believe there is some expectation that our next release
will include the missing data now, and we should discuss if this is a
good idea.


I'd say we don't include the FMVs for beta3, it'll only delay beta3 
further. As for the final 2.1 I'd really love to have the FMVs in them. 
Though I think we shouldn't delay too long for that, as we can always 
release a 2.1.1 or whatever for that purpose.



I would like some input from the people who worked with the
FMVs on how much work remains to integrate them properly (gerard,
angus...), and I would also like to hear people's opinions on how they
should be distributed.


As for distribution I suggest we use a non-RPL based format. Ogg/Theora 
comes to mind, though I don't really mind other formats either. (As long 
as it's a free & open format).



Here are my very preliminary thoughts:
 * we ship beta3 once we have run some quick network tests on it,
tomorrow or Saturday, with an announcement of the above good news,
adding that we will attempt to integrate as much as possible of it
into the final 2.1 release.


Sounds good.


 * we put the original soundtracks in a mod to be distributed along with
beta3


Could be done with a similar approach to the music mod pack I've done 
[1] (see below).



 * we create a new branch based on trunk to attempt to quickly produce
working FMV code for 2.1 beta4


With emphasis on *attempt*, I would prefer not to delay 2.1 much longer. 
As I suggested above, 2.1.1 is another option.



 * we put the converted FMVs in a tarball on gna.org, but not in the
svn repository (too big, 300mb+)


I suggest we stuff all FMVs in a .wz modpack instead of a tarball. This 
way no further processing will be required by those wish to download and 
use it (aside from dumping it in the correct directory). I suggest that 
we put all non-FMV data (i.e. meta data) that will have to reside in the 
same .wz zip file in our svn repository though.



 * for 2.1 we allow the user to play without FMVs, as before, and only
optionally play them if present


It's probably best to somehow register the FMVs with warzone through the 
WRF resource system. Then we just attempt to always play these videos 
and do nothing when they're not loaded through the WRF system.



 * for 2.2 we try to isolate all of the campaign into a mod, so that
you can pull down a single mod to enable the campaign with FMVs, and
find a way for mods to 'register' their presence into the main menu,
etc.

Sounds good. For modem people we could also provide a cam-novid.wz download.


How about splitting up the campaign in two parts? An "all except for 
videos and other huge media" part (packed in a single .wz) and a "videos 
and huge media" part (in another .wz). That way we don't have to provide 
a cam-novid.wz download. Instead we can just neglect to download the 
cam-optional-media.wz pack.


Apropos soundtracks. There is still MichaelB et al.'s soundtracks dangling 
somewhere. Maybe we could add them to beta4 as well?
I've already added them to a mod pack [1] and solved out the licensing 
issues for those. I've also set up the NSIS installer to automatically 
download that mod-pack at the user's request (i.e. they just have to 
enable it in the "components" section).


[1] http://download.gna.org/warzone/releases/mods/music_1.0.wz

--
Giel



signature.asc
Description: OpenPGP digital signature
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] FMVs released as GPL, and the 2.1 release

[Dennis Schridde]

Am Donnerstag, 12. Juni 2008 13:13:49 schrieb Per Inge Mathisen:
> For those of you who have not followed the latest events on the forum
> and/or IRC, EIDOS have now granted us permission to distribute both
> the FMVs and the soundtracks from the original game under the GPL.
> This bodes well for the future.
>
> It does, however, give us somewhat of a challenge for 2.1, which is
> way overdue. I believe there is some expectation that our next release
> will include the missing data now, and we should discuss if this is a
> good idea. I would like some input from the people who worked with the
> FMVs on how much work remains to integrate them properly (gerard,
> angus...), and I would also like to hear people's opinions on how they
> should be distributed.
>
> Here are my very preliminary thoughts:
>  * we ship beta3 once we have run some quick network tests on it,
> tomorrow or Saturday, with an announcement of the above good news,
> adding that we will attempt to integrate as much as possible of it
> into the final 2.1 release.
>  * we put the original soundtracks in a mod to be distributed along with
> beta3 * we create a new branch based on trunk to attempt to quickly produce
> working FMV code for 2.1 beta4
>  * we put the converted FMVs in a tarball on gna.org, but not in the
> svn repository (too big, 300mb+)
>  * for 2.1 we allow the user to play without FMVs, as before, and only
> optionally play them if present
>  * for 2.2 we try to isolate all of the campaign into a mod, so that
> you can pull down a single mod to enable the campaign with FMVs, and
> find a way for mods to 'register' their presence into the main menu,
> etc.
Sounds good. For modem people we could also provide a cam-novid.wz download.

Apropos soundtracks. There is still MichaelB et al.'s soundtracks dangling 
somewhere. Maybe we could add them to beta4 as well?

--Dennis


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] FMVs released as GPL, and the 2.1 release

[Per Inge Mathisen]

For those of you who have not followed the latest events on the forum
and/or IRC, EIDOS have now granted us permission to distribute both
the FMVs and the soundtracks from the original game under the GPL.
This bodes well for the future.

It does, however, give us somewhat of a challenge for 2.1, which is
way overdue. I believe there is some expectation that our next release
will include the missing data now, and we should discuss if this is a
good idea. I would like some input from the people who worked with the
FMVs on how much work remains to integrate them properly (gerard,
angus...), and I would also like to hear people's opinions on how they
should be distributed.

Here are my very preliminary thoughts:
 * we ship beta3 once we have run some quick network tests on it,
tomorrow or Saturday, with an announcement of the above good news,
adding that we will attempt to integrate as much as possible of it
into the final 2.1 release.
 * we put the original soundtracks in a mod to be distributed along with beta3
 * we create a new branch based on trunk to attempt to quickly produce
working FMV code for 2.1 beta4
 * we put the converted FMVs in a tarball on gna.org, but not in the
svn repository (too big, 300mb+)
 * for 2.1 we allow the user to play without FMVs, as before, and only
optionally play them if present
 * for 2.2 we try to isolate all of the campaign into a mod, so that
you can pull down a single mod to enable the campaign with FMVs, and
find a way for mods to 'register' their presence into the main menu,
etc.

Opinions?

Yours
Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev