Re: [Warzone-dev] [Warzone 2100 Trac] #64: FMV playback code --Testing needed, especially on MACS!

[bugs buggy]

On 9/23/08, Tim Baumgartner <[EMAIL PROTECTED]> wrote:
>
> bugs buggy wrote:
> > On 9/14/08, Tim Baumgartner <[EMAIL PROTECTED]> wrote:
> >> Nice work :)
> >>
> >> I tested on Linux (if you can wait about a week I can test it out on OS
> X)
> >> and
> >> only had a problem with the directory names in the extracted sequences
> >> directory. I had to lowercase the first letters in the directories
> >> data/base/sequences/Cam1, Cam2, and Cam3 so that they are 'cam1',
> 'cam2',
> >> 'cam3'
> >> in order for my machine to find and load the mission videos.
> >>
> >> Other than that, my only complaint is that the video quality is pretty
> low.
> >>
> >>
> >> Tim
> >>
> >
> > Not to sound too pushy, but is it possible to explain to others how to
> add
> > the Theora dependency ?
> >
> > We got some more mac people wanting to test things out, but nobody has a
> > clue how to fix the xcode stuff to make this patch work correctly.
> >
> > For the low video quality, I added a menu option of 'native', so it will
> > display it centered on your screen in its native resolution, which makes
> it
> > look better.
> > Other than redoing all the videos from scratch, we have to live with the
> > 320x240 & 192x168 videos we got now.
>
>
> I'll try to get the patch (is it still a patch or had it made it to the
> trunk
> yet?) working on OS X in the next few days and post the patch of the Xcode
> project. I meant to test it over the weekend but I've been busy with other
> obligations...
>
>
> Tim
>

At this time, it still is a patch, it still needs some cleanup before it
goes into trunk.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone 2100 Trac] #64: FMV playback code --Testing needed, especially on MACS!

[Tim Baumgartner]

bugs buggy wrote:
> On 9/14/08, Tim Baumgartner <[EMAIL PROTECTED]> wrote:
>> Nice work :)
>>
>> I tested on Linux (if you can wait about a week I can test it out on OS X)
>> and
>> only had a problem with the directory names in the extracted sequences
>> directory. I had to lowercase the first letters in the directories
>> data/base/sequences/Cam1, Cam2, and Cam3 so that they are 'cam1', 'cam2',
>> 'cam3'
>> in order for my machine to find and load the mission videos.
>>
>> Other than that, my only complaint is that the video quality is pretty low.
>>
>>
>> Tim
>>
> 
> Not to sound too pushy, but is it possible to explain to others how to add
> the Theora dependency ?
> 
> We got some more mac people wanting to test things out, but nobody has a
> clue how to fix the xcode stuff to make this patch work correctly.
> 
> For the low video quality, I added a menu option of 'native', so it will
> display it centered on your screen in its native resolution, which makes it
> look better.
> Other than redoing all the videos from scratch, we have to live with the
> 320x240 & 192x168 videos we got now.

I'll try to get the patch (is it still a patch or had it made it to the trunk 
yet?) working on OS X in the next few days and post the patch of the Xcode 
project. I meant to test it over the weekend but I've been busy with other 
obligations...

Tim

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

[Warzone-dev] Splitting the repository into source & data sections?

[bugs buggy]

I was thinking it might be a good time to either split the repository into
dedicated sections, or have multiple repositories.
One should be only used for source, and the other only for data.

The question remains, do we stick with GNA, even though they still are
having some issue?  Is having multiple repositories allowed on GNA?

Should we take the data to a new host to test the waters?  Or is having data
not allowed as a 'project' on like source forge, or whatever?
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Vote for what you think is best.

[bugs buggy]

On 9/22/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>
> Am Montag, 22. September 2008 18:41:04 schrieb bugs buggy:
>
> > On 9/22/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > > Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
>
> > > We cannot release 2.2 just now. You are giving a wrong impression to
> the
> > > community...
> > > I *will* be full of bugs, several things may need to be removed if you
> > > want to
> > > start releasing it within the next one or two months, several things
> will
> > > not
> > > be finished till then, etc...
> > > So you need at least till December for a release, imo.
> > > Obviously not telling the community these things (in the question
> > > already, people are likely to click before they have read everything),
> > > and making them
> > > think "2.1 is crap, but we could get 2.2 just now" resulted in those
> > > wrong votes.
> >
> > I didn't say 2.1 is crap, I said it breaks savegames, and is lacking
> other
> > features.  I see there was a slight miswording though--I will redo it,
> and
> > start poll over.
>
> Don't forget to state that 2.2 aka trunk will not be affected by the
> savegame
> change of 2.1_beta5... ;)


Ok, everything should be correctly worded now, and the poll has been reset.
http://forums.wz2100.net/viewtopic.php?f=6&t=2188
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] [Warzone 2100 Trac] #64: FMV playback code --Testing needed, especially on MACS!

[bugs buggy]

On 9/14/08, Tim Baumgartner <[EMAIL PROTECTED]> wrote:
>
> Nice work :)
>
> I tested on Linux (if you can wait about a week I can test it out on OS X)
> and
> only had a problem with the directory names in the extracted sequences
> directory. I had to lowercase the first letters in the directories
> data/base/sequences/Cam1, Cam2, and Cam3 so that they are 'cam1', 'cam2',
> 'cam3'
> in order for my machine to find and load the mission videos.
>
> Other than that, my only complaint is that the video quality is pretty low.
>
>
> Tim
>

Not to sound too pushy, but is it possible to explain to others how to add
the Theora dependency ?

We got some more mac people wanting to test things out, but nobody has a
clue how to fix the xcode stuff to make this patch work correctly.

For the low video quality, I added a menu option of 'native', so it will
display it centered on your screen in its native resolution, which makes it
look better.
Other than redoing all the videos from scratch, we have to live with the
320x240 & 192x168 videos we got now.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

[Warzone-dev] [bug #12345] The 3D perspective increases too much on big screens

[Markus]

URL:
  

 Summary: The 3D perspective increases too much on big
screens
 Project: Warzone Resurrection Project
Submitted by: omikronman
Submitted on: Montag 22.09.2008 um 22:18
Category: Engine: Graphics
Severity: Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 2.1_beta4
Operating System: All
 Planned Release: None

___

Details:

I use a 1920 x 1200 screen. The 3D perspective distortes near polygones far
too much. This effect increases the more the higher the screen mode is. 




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


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

Re: [Warzone-dev] Vote for what you think is best.

[Dennis Schridde]

Am Montag, 22. September 2008 18:41:04 schrieb bugs buggy:
> On 9/22/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
> > We cannot release 2.2 just now. You are giving a wrong impression to the
> > community...
> > I *will* be full of bugs, several things may need to be removed if you
> > want to
> > start releasing it within the next one or two months, several things will
> > not
> > be finished till then, etc...
> > So you need at least till December for a release, imo.
> > Obviously not telling the community these things (in the question
> > already, people are likely to click before they have read everything),
> > and making them
> > think "2.1 is crap, but we could get 2.2 just now" resulted in those
> > wrong votes.
>
> I didn't say 2.1 is crap, I said it breaks savegames, and is lacking other
> features.  I see there was a slight miswording though--I will redo it, and
> start poll over.
Don't forget to state that 2.2 aka trunk will not be affected by the savegame 
change of 2.1_beta5... ;)

> However, I didn't state a 'release', I said 2.1 beta 5 or 2.2 beta 1.
> Either way, we are going to have another beta, it just depends on which
> version we do the beta from.
You indeed said "Release 2.2" in the poll item...

--Devu


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] Vote for what you think is best.

[Dennis Schridde]

Am Montag, 22. September 2008 18:40:02 schrieb Per Inge Mathisen:
> On Mon, Sep 22, 2008 at 6:08 PM, Freddie Witherden
>
> <[EMAIL PROTECTED]> wrote:
> > I still think that SQLite is the way to go, so far as future proofing
> > goes. Going straight to tagfile makes it a lot harder to go to SQLite
> > later on (two converters needed etc.). The advantages of a database
> > are also numerous, firstly data abstraction and secondly in viewing/
> > using the data outside of Warzone (e.g for debugging purposes, as any
> > SQLite viewer could be used).
>
> Perfection or progress - pick one.
The second. If it includes the first, ok, but it does not have to necessarily.

--Devu


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] Vote for what you think is best.

[bugs buggy]

On 9/22/08, Freddie Witherden <[EMAIL PROTECTED]> wrote:
>
> Hey Dennis,
>
>
> On 22 Sep 2008, at 16:24, Dennis Schridde wrote:
>
> > Am Montag, 22. September 2008 15:29:09 schrieb Freddie Witherden:
> >>> Speaking of conversion: The only thing that makes =2.1_beta4 games
> >>> not load in
> >>>
>  2.1_beta4 is that the static gateway and zone information is
>  missing? Can't
> >>>
> >>> we just copy that from the original map again? (In a conversion
> >>> step, maybe as
> >>> an external tool if necessary.)
> >>
> >> It would be a lot of effort that would only be useful/used in beta5.
> >> Furthermore it would need a lot of bug-checking, perhaps more so than
> >> getting trunk 100% stable.
> > Better than leaving a out a release and letting the ship sink in the
> > dream
> > that the next release would come anywhere "soon".
>
>
> To support save games with and without zones would be a massive
> undertaking. It would be paramount to adding a large amount of
> relatively untested code to a beta release, written under a tight time
> constraint, that would only ever be used in 2.1. Writing code for a
> single, already outdated release is foolhardy.
>
> This is not a good use of developer time -- which could be better
> spent on 2.2 -- ensuring that we never get into this situation again.


This about sums it up.
Developer time is short, so we need to do what will be best for developers.

The whole predicament of not having a release for such a long period of time
*IS* the problem.

The two different versions, trunk & branch, are getting *very* different.
The longer we wait, the differences keep growing, and the harder it is
getting to backport the needed patches.

If everyone wants a 2.1 release, fine, do it now.
Then 2.2 will make a appearance (aka beta 1) soon after the release of 2.1
anyway.

They we can do releases much quicker from then on, and never have this
problem come up again.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Vote for what you think is best.

[bugs buggy]

On 9/22/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>
> Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
>
> > While this has been discussed before, I feel that we need more input from
> > everyone, so I created a poll to see what the community thinks is the
> best
> > course of action.
> >
> > This concerns if we should do a 2.1 beta 5, or skip 2.1 beta 5, and do a
> > 2.2 beta 1.
> > In either case, there must be another beta.
>
> I vote for 2.1_beta5 for the reasons stated earlier.
>
> We cannot release 2.2 just now. You are giving a wrong impression to the
> community...
> I *will* be full of bugs, several things may need to be removed if you want
> to
> start releasing it within the next one or two months, several things will
> not
> be finished till then, etc...
> So you need at least till December for a release, imo.
> Obviously not telling the community these things (in the question already,
> people are likely to click before they have read everything), and making
> them
> think "2.1 is crap, but we could get 2.2 just now" resulted in those wrong
> votes.


I didn't say 2.1 is crap, I said it breaks savegames, and is lacking other
features.  I see there was a slight miswording though--I will redo it, and
start poll over.

However, I didn't state a 'release', I said 2.1 beta 5 or 2.2 beta 1.
Either way, we are going to have another beta, it just depends on which
version we do the beta from.

I have been playing 2.2 (trunk+ FMVpatch) SP game, and as I encounter
bugs/issues, that is what I work on.
For 2.1 (branch), IMO, it is *not* worth even playing the SP game.
 You can't even compare them, the difference the FMVs bring is simply huge.

That is mainly why I do not think 2.1 is worth it to continue to work on/be
released

On the MP front, since 2.2 & 2.1 are pretty much the same codewise, there is
no real difference here.




> http://forums.wz2100.net/viewtopic.php?f=6&t=2188
> >
> > The reasons have (more or less) already been discussed on this list
> > already.
> >
> > But let me add that savegames are a very good debugging tool, and *if* we
> > release a 2.1 beta 5 that will break savegames since beta 4, and trunk as
> > well, there will be no easy way to load those games up, and see if the
> same
> > issue is present in trunk or not.
>
> 2.1_beta5 would add the gateway section back to savegames, right?
> And that would make them unable to load in trunk?


And this is that miswording.


> And in my latest rounds of debugging things, this would not be something I
> > would like that much, in fact, I would hate it.
> >
> > With such a small, active, development crew working on this project, I
> > rather we all concentrate our efforts on trunk, and rebase from that.
>
> You mean "rebranch"?


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

Re: [Warzone-dev] Vote for what you think is best.

[Per Inge Mathisen]

On Mon, Sep 22, 2008 at 6:08 PM, Freddie Witherden
<[EMAIL PROTECTED]> wrote:
> I still think that SQLite is the way to go, so far as future proofing
> goes. Going straight to tagfile makes it a lot harder to go to SQLite
> later on (two converters needed etc.). The advantages of a database
> are also numerous, firstly data abstraction and secondly in viewing/
> using the data outside of Warzone (e.g for debugging purposes, as any
> SQLite viewer could be used).

Perfection or progress - pick one.

I don't even see anyone working on the stats sqlite stuff for a long
while. We can use the stats sqlite code to save stuff that would be
duplicated, such as droid templates. But I do not want the savegame
cruft to hold us back much longer, so unless someone has a plan to get
the code to ported to sqlite, I will complete what I know how to do
once I get the time.

  - Per

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

Re: [Warzone-dev] Vote for what you think is best.

[Freddie Witherden]

Hi Per,

On 22 Sep 2008, at 16:38, Per Inge Mathisen wrote:
> On Mon, Sep 22, 2008 at 5:24 PM, Dennis Schridde  
> <[EMAIL PROTECTED]> wrote:
>> How far are the tagfile and database ideas? Any progress there? I  
>> know the
>> tagfiles basically seem got stuck after the early phase of  
>> implementing the
>> framework functions...
>
> There is a separate tagfile branch, which is very close to being able
> to load savegames from the new format. There is a crash I need to sort
> out, and the scripting stuff is not saved yet, which is the hardest
> part. This work got much lower priority after several people agreed
> that we should go with the sqlite idea instead. However, that idea has
> no code going for it yet, while tagfile is nearly there, so maybe I
> should reprioritize.

I still think that SQLite is the way to go, so far as future proofing  
goes. Going straight to tagfile makes it a lot harder to go to SQLite  
later on (two converters needed etc.). The advantages of a database  
are also numerous, firstly data abstraction and secondly in viewing/ 
using the data outside of Warzone (e.g for debugging purposes, as any  
SQLite viewer could be used).

Regards, Freddie.

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

Re: [Warzone-dev] Vote for what you think is best.

[Freddie Witherden]

Hey Dennis,

On 22 Sep 2008, at 16:24, Dennis Schridde wrote:

> Am Montag, 22. September 2008 15:29:09 schrieb Freddie Witherden:
>> Hi Dennis,
> Hello Fred!
>
>> On 22 Sep 2008, at 13:06, Dennis Schridde wrote:
 Try playing 2.1_beta4, it is quite poor so far as releases go.
 2.1_beta5 is not going to go down well with people either if we  
 break
 their save games (will probably cause them not to upgrade).
>>>
>>> That reminds me that we need some way to have backward compatibility
>>> somehow.
>>> Savegame-wise and whatever else might need it. At least so much as
>>> there is a
>>> simple way of conversion.
>>
>> The main problem is game.c. It makes creating new save game versions
>> very difficult. Hence, the tagfile and SQLite proposals for save  
>> games.
> It's mainly copying the code, changing the version numbers, and  
> changing the
> parts which are different, right?

More complex than that, I estimate that between 400-500 lines are  
required per 'version'.

> How far are the tagfile and database ideas? Any progress there? I  
> know the
> tagfiles basically seem got stuck after the early phase of  
> implementing the
> framework functions...

Not too far along, they would both require weeks of work.

>>> Speaking of conversion: The only thing that makes =2.1_beta4 games
>>> not load in
>>>
 2.1_beta4 is that the static gateway and zone information is
 missing? Can't
>>>
>>> we just copy that from the original map again? (In a conversion
>>> step, maybe as
>>> an external tool if necessary.)
>>
>> It would be a lot of effort that would only be useful/used in beta5.
>> Furthermore it would need a lot of bug-checking, perhaps more so than
>> getting trunk 100% stable.
> Better than leaving a out a release and letting the ship sink in the  
> dream
> that the next release would come anywhere "soon".

To support save games with and without zones would be a massive  
undertaking. It would be paramount to adding a large amount of  
relatively untested code to a beta release, written under a tight time  
constraint, that would only ever be used in 2.1. Writing code for a  
single, already outdated release is foolhardy.

This is not a good use of developer time -- which could be better  
spent on 2.2 -- ensuring that we never get into this situation again.

>>> You may say, blahblah, it's just 2.1_beta5 and does not offer as
>>> many great
>>> things as 2.2 (which no one can tell me is going to arrive in the
>>> next week or
>>> even month). But we need some backward compatibility layer anyway,
>>> so we could
>>> use this as a testbed...
>>
>> That is what game.c provides, albeit badly.
> So even if game.c sucks, why not use what we have for now?
> And do not forget to implement a better compatibility layer for 2.2+?

The amount of work makes in prohibitive.

Regards, Freddie.

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

Re: [Warzone-dev] Vote for what you think is best.

[Per Inge Mathisen]

On Mon, Sep 22, 2008 at 5:24 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> How far are the tagfile and database ideas? Any progress there? I know the
> tagfiles basically seem got stuck after the early phase of implementing the
> framework functions...

There is a separate tagfile branch, which is very close to being able
to load savegames from the new format. There is a crash I need to sort
out, and the scripting stuff is not saved yet, which is the hardest
part. This work got much lower priority after several people agreed
that we should go with the sqlite idea instead. However, that idea has
no code going for it yet, while tagfile is nearly there, so maybe I
should reprioritize.

  - Per

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

Re: [Warzone-dev] Vote for what you think is best.

[Dennis Schridde]

Am Montag, 22. September 2008 15:29:09 schrieb Freddie Witherden:
> Hi Dennis,
Hello Fred!

> On 22 Sep 2008, at 13:06, Dennis Schridde wrote:
> >> Try playing 2.1_beta4, it is quite poor so far as releases go.
> >> 2.1_beta5 is not going to go down well with people either if we break
> >> their save games (will probably cause them not to upgrade).
> >
> > That reminds me that we need some way to have backward compatibility
> > somehow.
> > Savegame-wise and whatever else might need it. At least so much as
> > there is a
> > simple way of conversion.
>
> The main problem is game.c. It makes creating new save game versions
> very difficult. Hence, the tagfile and SQLite proposals for save games.
It's mainly copying the code, changing the version numbers, and changing the 
parts which are different, right?

How far are the tagfile and database ideas? Any progress there? I know the 
tagfiles basically seem got stuck after the early phase of implementing the 
framework functions...

> > Speaking of conversion: The only thing that makes =2.1_beta4 games
> > not load in
> >
> >> 2.1_beta4 is that the static gateway and zone information is
> >> missing? Can't
> >
> > we just copy that from the original map again? (In a conversion
> > step, maybe as
> > an external tool if necessary.)
>
> It would be a lot of effort that would only be useful/used in beta5.
> Furthermore it would need a lot of bug-checking, perhaps more so than
> getting trunk 100% stable.
Better than leaving a out a release and letting the ship sink in the dream 
that the next release would come anywhere "soon".

> > You may say, blahblah, it's just 2.1_beta5 and does not offer as
> > many great
> > things as 2.2 (which no one can tell me is going to arrive in the
> > next week or
> > even month). But we need some backward compatibility layer anyway,
> > so we could
> > use this as a testbed...
>
> That is what game.c provides, albeit badly.
So even if game.c sucks, why not use what we have for now?
And do not forget to implement a better compatibility layer for 2.2+?

--Devu


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] Vote for what you think is best.

[Freddie Witherden]

Hi Dennis,

On 22 Sep 2008, at 13:06, Dennis Schridde wrote:
>> Try playing 2.1_beta4, it is quite poor so far as releases go.
>> 2.1_beta5 is not going to go down well with people either if we break
>> their save games (will probably cause them not to upgrade).
> That reminds me that we need some way to have backward compatibility  
> somehow.
> Savegame-wise and whatever else might need it. At least so much as  
> there is a
> simple way of conversion.

The main problem is game.c. It makes creating new save game versions  
very difficult. Hence, the tagfile and SQLite proposals for save games.

> Speaking of conversion: The only thing that makes =2.1_beta4 games  
> not load in
>> 2.1_beta4 is that the static gateway and zone information is  
>> missing? Can't
> we just copy that from the original map again? (In a conversion  
> step, maybe as
> an external tool if necessary.)

It would be a lot of effort that would only be useful/used in beta5.  
Furthermore it would need a lot of bug-checking, perhaps more so than  
getting trunk 100% stable.

> You may say, blahblah, it's just 2.1_beta5 and does not offer as  
> many great
> things as 2.2 (which no one can tell me is going to arrive in the  
> next week or
> even month). But we need some backward compatibility layer anyway,  
> so we could
> use this as a testbed...

That is what game.c provides, albeit badly.

>>> 2.1_beta5 would add the gateway section back to savegames, right?
>>> And that would make them unable to load in trunk?
>>
>> They would be loadable in trunk. But anything created in 2.1_beta4
>> would not be loadable in 2.1_beta5 (although they would also work in
>> trunk).
> So the point that 2.1_beta5 savegames will break again in 2.2 is  
> simply
> misinformation?

Guess so.

Regards, Freddie.

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

Re: [Warzone-dev] Version numbering

[Dennis Schridde]

Am Montag, 22. September 2008 11:08:33 schrieb Per Inge Mathisen:
> On Mon, Sep 22, 2008 at 10:36 AM, Dennis Schridde <[EMAIL PROTECTED]> 
wrote:
> > I'd like to hear your opinions, ideas, insights.
> > Maybe you've got a different/better idea how to prevent long times of
> > silence between releases?
>
> I like the current way, and do not think we can manage to create
> releases so "rock solid" that we do not later wish to create bug fix
> releases to silence the critics and get less bug reports.
My "rock stable" was targeting at the bugfix releases. ;)
But yes, I thought about that too. Some bugs just *will* slip through and 
might annoy people. My idea was to just ignore that and go on with the next 
feature release. If someone cares about fixing those in older versions, he 
could of course backport and do an own release. The idea was to lift the 
burden of fixing bugs in old versions from the generic developer, so he has 
more time to work on new stuff.
In my dream-world, the x.y releases would come a lot more often than the x.y.z 
releases currently, which would make it less annoying.
Basically what we had in the 2.0 series, just leaving out the 0 from the 
version number.
At least we had full releases at all. And if we can put it onto more defined 
roads, I think the regression issues during the 2.0 series would not be 
repeated.

> After 2.0 we had massive changes and resulting instability in the
> codebase, making a lot of things no longer work as well as they
> should. With the new commit guidelines, hopefully this will no longer
> happen ;-)
"after 2.0" means "in what is going to be 2.1"?

Commit guidelines: Should it include savegame-versioning (I think that is 
possible with the .gam format, right?), backwards compatibility, etc?

--Devu


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] Vote for what you think is best.

[Dennis Schridde]

Am Montag, 22. September 2008 10:51:15 schrieb Freddie Witherden:
> Hi Dennis/Buggy
>
> On 22 Sep 2008, at 09:27, Dennis Schridde wrote:
> > Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
> >> While this has been discussed before, I feel that we need more
> >> input from
> >> everyone, so I created a poll to see what the community thinks is
> >> the best
> >> course of action.
> >>
> >> This concerns if we should do a 2.1 beta 5, or skip 2.1 beta 5, and
> >> do a
> >> 2.2 beta 1.
> >> In either case, there must be another beta.
> >
> > I vote for 2.1_beta5 for the reasons stated earlier.
> >
> > We cannot release 2.2 just now. You are giving a wrong impression to
> > the
> > community...
> > I *will* be full of bugs, several things may need to be removed if
> > you want to
> > start releasing it within the next one or two months, several things
> > will not
> > be finished till then, etc...
> > So you need at least till December for a release, imo.
> > Obviously not telling the community these things (in the question
> > already,
> > people are likely to click before they have read everything), and
> > making them
> > think "2.1 is crap, but we could get 2.2 just now" resulted in those
> > wrong
> > votes.
>
> Betawidget and some of Giel's stat stuff will need to be removed.
> However, I have been playing it recently (as have quite a few others)
> and would not consider it much more buggy than 2.1.
>
> Try playing 2.1_beta4, it is quite poor so far as releases go.
> 2.1_beta5 is not going to go down well with people either if we break
> their save games (will probably cause them not to upgrade).
That reminds me that we need some way to have backward compatibility somehow. 
Savegame-wise and whatever else might need it. At least so much as there is a 
simple way of conversion.

Speaking of conversion: The only thing that makes =2.1_beta4 games not load in 
>2.1_beta4 is that the static gateway and zone information is missing? Can't 
we just copy that from the original map again? (In a conversion step, maybe as 
an external tool if necessary.)

You may say, blahblah, it's just 2.1_beta5 and does not offer as many great 
things as 2.2 (which no one can tell me is going to arrive in the next week or 
even month). But we need some backward compatibility layer anyway, so we could 
use this as a testbed...

> >> http://forums.wz2100.net/viewtopic.php?f=6&t=2188
> >>
> >> The reasons have (more or less) already been discussed on this list
> >> already.
> >>
> >> But let me add that savegames are a very good debugging tool, and
> >> *if* we
> >> release a 2.1 beta 5 that will break savegames since beta 4, and
> >> trunk as
> >> well, there will be no easy way to load those games up, and see if
> >> the same
> >> issue is present in trunk or not.
> >
> > 2.1_beta5 would add the gateway section back to savegames, right?
> > And that would make them unable to load in trunk?
>
> They would be loadable in trunk. But anything created in 2.1_beta4
> would not be loadable in 2.1_beta5 (although they would also work in
> trunk).
So the point that 2.1_beta5 savegames will break again in 2.2 is simply 
misinformation?


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 phase 2 complete

[Angus Lees]

On Sat, Sep 20, 2008 at 1:02 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:

> On Fri, Sep 19, 2008 at 01:44:28AM -0400, bugs buggy wrote:
> > Phase 2 has been completed.
> > FMVs are now working for the intel screen, as can be seen by that thread.
> > I am using GL_TEXTURE_RECTANGLE_ARB to get around the NPOT textures.
>
> How about only using GL_TEXTURE_RECTANGLE_ARB when
> GL_ARB_texture_non_power_of_two isn't available? As
> GL_TEXTURE_RECTANGLE_ARB doesn't provide normalized texture coordinates.
>
> On another side note: I noticed that the YUV decoding is currently done
> in software. This is currently done by copying from one memory buffer
> (containing the image YUV or YCbCr encoded) and converting to RGB to
> another memory buffer. Not only will that probably take a lot of time,
> in addition it is quite likely that copying the RGB buffer after the
> YUV->RGB conversion will stall the pipeline.
>
> I have been looking into doing YUV->RGB conversion using a GL shader for
> school today and I think it might be a good idea to use that approach
> for Warzone as well. Falling back to the software approach if no shaders
> are available of course. Either way, I'll look further into this.
>

Fwiw, my fmv patch had GL YUV->RGB conversions using several different
opengl techniques - lifted from mplayer (and then cleaned up a bit).  See
gl_yuv.c in the patch.

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

Re: [Warzone-dev] Version numbering

[Per Inge Mathisen]

On Mon, Sep 22, 2008 at 10:36 AM, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> I'd like to hear your opinions, ideas, insights.
> Maybe you've got a different/better idea how to prevent long times of silence
> between releases?

I like the current way, and do not think we can manage to create
releases so "rock solid" that we do not later wish to create bug fix
releases to silence the critics and get less bug reports.

After 2.0 we had massive changes and resulting instability in the
codebase, making a lot of things no longer work as well as they
should. With the new commit guidelines, hopefully this will no longer
happen ;-)

  -  Per

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

Re: [Warzone-dev] Vote for what you think is best.

[Freddie Witherden]

Hi Dennis/Buggy
On 22 Sep 2008, at 09:27, Dennis Schridde wrote:

> Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
>> While this has been discussed before, I feel that we need more  
>> input from
>> everyone, so I created a poll to see what the community thinks is  
>> the best
>> course of action.
>>
>> This concerns if we should do a 2.1 beta 5, or skip 2.1 beta 5, and  
>> do a
>> 2.2 beta 1.
>> In either case, there must be another beta.
> I vote for 2.1_beta5 for the reasons stated earlier.
>
> We cannot release 2.2 just now. You are giving a wrong impression to  
> the
> community...
> I *will* be full of bugs, several things may need to be removed if  
> you want to
> start releasing it within the next one or two months, several things  
> will not
> be finished till then, etc...
> So you need at least till December for a release, imo.
> Obviously not telling the community these things (in the question  
> already,
> people are likely to click before they have read everything), and  
> making them
> think "2.1 is crap, but we could get 2.2 just now" resulted in those  
> wrong
> votes.

Betawidget and some of Giel's stat stuff will need to be removed.  
However, I have been playing it recently (as have quite a few others)  
and would not consider it much more buggy than 2.1.

Try playing 2.1_beta4, it is quite poor so far as releases go.  
2.1_beta5 is not going to go down well with people either if we break  
their save games (will probably cause them not to upgrade).

>> http://forums.wz2100.net/viewtopic.php?f=6&t=2188
>>
>> The reasons have (more or less) already been discussed on this list
>> already.
>>
>> But let me add that savegames are a very good debugging tool, and  
>> *if* we
>> release a 2.1 beta 5 that will break savegames since beta 4, and  
>> trunk as
>> well, there will be no easy way to load those games up, and see if  
>> the same
>> issue is present in trunk or not.
> 2.1_beta5 would add the gateway section back to savegames, right?
> And that would make them unable to load in trunk?

They would be loadable in trunk. But anything created in 2.1_beta4  
would not be loadable in 2.1_beta5 (although they would also work in  
trunk).

Regards, Freddie.

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

Re: [Warzone-dev] Vote for what you think is best.

[Dennis Schridde]

Am Montag, 22. September 2008 04:32:13 schrieb bugs buggy:
> While this has been discussed before, I feel that we need more input from
> everyone, so I created a poll to see what the community thinks is the best
> course of action.
>
> This concerns if we should do a 2.1 beta 5, or skip 2.1 beta 5, and do a
> 2.2 beta 1.
> In either case, there must be another beta.
I vote for 2.1_beta5 for the reasons stated earlier.

We cannot release 2.2 just now. You are giving a wrong impression to the 
community...
I *will* be full of bugs, several things may need to be removed if you want to 
start releasing it within the next one or two months, several things will not 
be finished till then, etc...
So you need at least till December for a release, imo.
Obviously not telling the community these things (in the question already, 
people are likely to click before they have read everything), and making them 
think "2.1 is crap, but we could get 2.2 just now" resulted in those wrong 
votes.

> http://forums.wz2100.net/viewtopic.php?f=6&t=2188
>
> The reasons have (more or less) already been discussed on this list
> already.
>
> But let me add that savegames are a very good debugging tool, and *if* we
> release a 2.1 beta 5 that will break savegames since beta 4, and trunk as
> well, there will be no easy way to load those games up, and see if the same
> issue is present in trunk or not.
2.1_beta5 would add the gateway section back to savegames, right?
And that would make them unable to load in trunk?

> And in my latest rounds of debugging things, this would not be something I
> would like that much, in fact, I would hate it.
>
> With such a small, active, development crew working on this project, I
> rather we all concentrate our efforts on trunk, and rebase from that.
You mean "rebranch"?

--Devu


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] Version numbering

[Dennis Schridde]

Hello everyone.

As we are in discussion mood already, what do you think about making bugfix 
releases? Is that something we should continue? Should we instead invest a bit 
more time into QA before each feature release (gather some testers from the 
community maybe?) and then stop caring about a release branch after we 
released the final version?
Instead of releasing betas before the release, making the .0 release and then 
pushing bugfixes afterwards, we would only push alphas and betas (just a 
difference in name, to distinct the grades of stability) and a final release, 
but those prereleases would be more and come more often.
After the final release we could fully concentrate on trunk and new features 
again.
On the other hand doing bugfix releases we are able to fix smaller issues 
after a release via backports, and also by investing time into the diverged 
codebases of branches/* and trunk.
It is mainly the choice between (rock?) stable x.y.z releases with more time 
to the next feature-release, or earlier feature releases with probably a few 
more bugs during the lifetime of the product. The later could be compensated 
if we'd find more of the bugs earlier, by having good testing (i.e.).
Two-weekly prereleases, no matter of the current state, sounds like a good 
plan, with alphas starting right when the major features are merged.

This is an idea to prevent those long times between releases as we had them 
for the 2.1 series.

I'd like to hear your opinions, ideas, insights.
Maybe you've got a different/better idea how to prevent long times of silence 
between releases?

--Devu


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