Re: [Warzone-dev] [Warzone-commits] r6037 - /trunk/lib/betawidget/widget.h

[Dennis Schridde]

Am Donnerstag, 18. September 2008 13:24:37 schrieb Freddie Witherden:
> Author: evilguru
> Date: Thu Sep 18 13:24:36 2008
> New Revision: 6037
>
> URL: http://svn.gna.org/viewcvs/warzone?rev=6037&view=rev
> Log:
> Fix the inclusion of GLEE in betawidget; this fixes the blending problems
> under nVidia Linux. Plus some minor indentation fixes.
We normally use SDL_opengl.h there...

--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] [Warzone-commits] r6037 - /trunk/lib/betawidget/widget.h

[Freddie Witherden]

Hi,

On 18 Sep 2008, at 12:51, Dennis Schridde wrote:

> Am Donnerstag, 18. September 2008 13:24:37 schrieb Freddie Witherden:
>> Author: evilguru
>> Date: Thu Sep 18 13:24:36 2008
>> New Revision: 6037
>>
>> URL: http://svn.gna.org/viewcvs/warzone?rev=6037&view=rev
>> Log:
>> Fix the inclusion of GLEE in betawidget; this fixes the blending  
>> problems
>> under nVidia Linux. Plus some minor indentation fixes.
> We normally use SDL_opengl.h there...

No guarantee betawidget will be running under SDL. The core library is  
designed to be as portable as possible (none of lib/betawidget has any  
dependancy on SDL).

I have plans for a Qt back-end as well, so SDL_opengl.h would not be  
suitable for widget.h Furthermore, SDL_opengl.h does not perform  
automatic extension checking/loading. This is needed by widget.c (and  
the SDL test application) for the blend colour functions (glBlendColor  
+ constants) which some OpenGL headers, namely nVidias on Linux do  
*not* provide.

This is what was causing the greyscale problems under Linux -- lack of  
a function prototype. Therefore the only other real option is GLEW,  
which is more hassle, IMO.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r6037 - /trunk/lib/betawidget/widget.h

[Dennis Schridde]

Am Donnerstag, 18. September 2008 14:02:18 schrieb Freddie Witherden:
> Hi,
>
> On 18 Sep 2008, at 12:51, Dennis Schridde wrote:
> > Am Donnerstag, 18. September 2008 13:24:37 schrieb Freddie Witherden:
> >> Author: evilguru
> >> Date: Thu Sep 18 13:24:36 2008
> >> New Revision: 6037
> >>
> >> URL: http://svn.gna.org/viewcvs/warzone?rev=6037&view=rev
> >> Log:
> >> Fix the inclusion of GLEE in betawidget; this fixes the blending
> >> problems
> >> under nVidia Linux. Plus some minor indentation fixes.
> >
> > We normally use SDL_opengl.h there...
>
> No guarantee betawidget will be running under SDL. The core library is
> designed to be as portable as possible (none of lib/betawidget has any
> dependancy on SDL).
Ok, forgot that.

> I have plans for a Qt back-end as well, so SDL_opengl.h would not be
> suitable for widget.h Furthermore, SDL_opengl.h does not perform
> automatic extension checking/loading. This is needed by widget.c (and
> the SDL test application) for the blend colour functions (glBlendColor
> + constants) which some OpenGL headers, namely nVidias on Linux do
> *not* provide.
I just recognized I read the reverse patch...
Makes a lot more sense now...

> This is what was causing the greyscale problems under Linux -- lack of
> a function prototype. Therefore the only other real option is GLEW,
> which is more hassle, IMO.
So glBlendColor was not broken?
Good to hear that has been fixed.

Will betawidget stay where it currently resides? Maybe we want to make it more 
obvious that it does not directly belong to Warzone 2100.

--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] [Warzone-commits] r6037 - /trunk/lib/betawidget/widget.h

[Freddie Witherden]

Hi Dennis,

On 18 Sep 2008, at 13:34, Dennis Schridde wrote:
> Will betawidget stay where it currently resides? Maybe we want to  
> make it more
> obvious that it does not directly belong to Warzone 2100.

I am quite happy with it in lib/. Ideally all of the code in lib/  
should be useful/usable outside of Warzone 2100, in utilities such as  
Warzone Studio, Pie/model converters, EditWorld etc.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone 2100 Trac] #71: "Fix" 2.1's bad pathfinding performance

[Warzone 2100 Trac]

#71: "Fix" 2.1's bad pathfinding performance
+---
Reporter:  Giel |   Owner:  Giel
Type:  enhancement  |  Status:  accepted
Priority:  major|   Milestone:  2.1 
   Component:  other| Version:  2.1 
  Resolution:   |Keywords:  
Operating_system:  All  |  
+---
Changes (by Giel):

 * cc: warzone-dev@gna.org (added)


Comment:

 If no one objects I'll commit this patch (to 2.1) next Saturday or Sunday
 (20 or 21 September 2008).

-- 
Ticket URL: 
Warzone 2100 Trac 
The Warzone 2100 Resurrection Project
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Call for testing of pathfinding patch

[Giel van Schijndel]

Freddie Witherden schreef:
>  From my point I think our options are:
>   - Try *again* to backport the multi-threaded pathing.

I've tried that *before* reverting r4637, and failed miserably. (Way too
much API changes to do within 2 whole days).

>   - Skip 2.1 and go straight to 2.2 with FMV support.

How about providing an optional 2.1 release for those who wish to use
that first?

>   - Re-base 2.1 from trunk.

No, IMO current trunk should become 2.2, definitly not 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] Call for testing of pathfinding patch

[Giel van Schijndel]

Per Inge Mathisen schreef:
> On Tue, Sep 16, 2008 at 10:09 PM, Giel van Schijndel <[EMAIL PROTECTED]> 
> wrote:
>> That area of memory is currently memset(0) before writing to disk right?
>> We could try to take some "fail gracefully" approach and reject the
>> savegame if that piece of memory is zero. Where "fail gracefully" means
>> display some nice error message to the user explaining the problem.
>>
>> Unless someone has some other way to handle this.
> 
> We are actually so lucky that the zone information is at the very end
> of the savegame, so we can check for EOF when done with everything
> else, and return false from the load functions if nothing is found.

I updated the patch to check for the absence of zone information and
return false if that's the case.

> What then happens next, I do not know, but I fear there are lots of
> asserts waiting in ambush...

Nope, no asserts, several debug() calls yes, but no asserts.

Also I've traced the calling tree down to one function: loadGameInit
which'll return false whenever game loading fails. This function is only
called by initSaveGameLoad (main.c) and startMission (mission.c), the
latter being only used to load campaign missions (not savegames).

Thus the only function that should be of a concern to us in this regards
is initSaveGameLoad. Currently this function calls exit(EXIT_FAILURE) if
loadGameInit fails. That's the place where the behaviour should probably
be altered such that instead we display some in-GUI message to the user.
(Especially for the non-terminal systems: Max & Windows).

-- 
Giel




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

[Warzone-dev] FMVs phase 2 complete

[bugs buggy]

Well, since pictures tell 1000 words...

http://forums.wz2100.net/viewtopic.php?f=6&t=2174

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.
(note, the FMVs for the intel screen have no sound, and they launch  a audio
stream depending on what user clicked on.
Would anyone object if I encoded the sound into the video?  Or is it better
to leave it as it is now?)

The resolution is pretty low, and there isn't much that can be done about
that, unless we do that scanline doubling that we talked about before.  That
helps a bit, but is no real substitution for higher-res FMVs.

Phase 3 is code cleanup.

Still looking for feedback here, and also a way for mac people to test.
http://developer.wz2100.net/ticket/64
This is only working with trunk, and make note of the comments on how to get
the sequences working in that ticket.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Call for testing of pathfinding patch

[bugs buggy]

On 9/18/08, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>
> Freddie Witherden schreef:
>
> >  From my point I think our options are:
> >   - Try *again* to backport the multi-threaded pathing.
>
> I've tried that *before* reverting r4637, and failed miserably. (Way too
> much API changes to do within 2 whole days).
>
> >   - Skip 2.1 and go straight to 2.2 with FMV support.
>
> How about providing an optional 2.1 release for those who wish to use
> that first?


Does this optional 2.1 become 'stable' version then? Or ?
Can we get nightly builds of 2.1 also?
It would seem to be the best indicator of how the community would react, and
then we can go from there.

My thoughts are, go ahead, stick the path finding fix in now, make a build,
and release it in the forum in a special thread, call it 2.1 RC 6 or
something, and have people give feedback.



>   - Re-base 2.1 from trunk.
>
>
> No, IMO current trunk should become 2.2, definitly not 2.1


The longer we wait, the worse it keeps getting IMO.  Both in terms of out of
sync with the trunk, and the overall status of the project.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] If you got the time...

[bugs buggy]

On 9/17/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>
> Am Dienstag, 16. September 2008 04:54:36 schrieb bugs buggy:
>
> > On 9/15/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > > Am Monday 15 September 2008 21:17:24 schrieben Sie:
> > > > On 9/15/08, Dennis Schridde <[EMAIL PROTECTED]> wrote:
>
> > > Aren't there any Mac gamers forums/mailinglist/newsgroups anywhere?
> > > Mac gaming news sites? ModDB? GameDev? ...
> > > Maybe we can draw testers from one of those locations?
> >
> > I am sure there are, just nobody I know, knows about them...
> > We got a few people in the forums, but with the timezone differences, it
> is
> > really, really hard to get everyone in one place to test.
>
> Maybe we can ask those people whether they know good places to ask for more
> help? Maybe we can make them test among each other and just report bugs?
> Maybe we can even get them to recruit testers for us...


What say you Mac people?



> Then just post that on the front page of the site asking people to test
> > those.
> > The only problem I see is that we have no way to automate mac builds, so
> > they will, once again, be left out of testing, unless we can find a way
> to
> > make nightly builds for them also.
>
> Building Mac builds is only possible on Macs, correct?
> That would be an issue. Maybe someone has a spare (or always-on-and-unused-
> during-the-night) Mac we could use for that.
> In 2 months I could investigate into finding that Mac and setting it up for
> nightlies. Cannot guarantee that I will get it and whether it will work
> though.


The other option is to have a better / easier way to maintain mac build
system.
I don't know what is involved with xcode, but it seems it isn't very easy to
add/fix stuff in it.


> > Maybe someone wants to do one commit a day less to some random parts,
> but
> > > instead add one line to the ChangeLog per day. That would probably
> > > already have fixed the issue entirely, if it was done since the first
> > > time I talked about it.
> > >
> > > If everyone was adding a line to the ChangeLog directly for everything
> > > important (and be it unordered), that would of course make it *even*
> > > simpler.
> > >
> > > Per: Care to add this to the development/commit guidelines?
> >
> > I was thinking, how about adding a changelog entry (or 1 line summary)
> into
> > the svn log, then we can use a bot to parse the logs, and then it can
> auto
> > add it to the changelog by date /time.
>
> Wouldn't that be the same work for everyone as adding one line to a file?


No, since everyone *must* enter something in the svn log, so 1 additional
summary line at that point in time, isn't getting in the way of anything.
I was trying to make it a automated process, since, we can see what happens
when it isn't automated, things don't get written in that file at all.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev