Re: [warzone2100-dev] Terrain redesign

[Freddie Witherden]

Hi,

> Perhaps also make a Windows app out of
> mapconv to help people convert. Once this is done, the current
> hard-coded distinction between arizona, rockies and urban will be
> gone, and their tiles and decals can be used interchangeably.

I can do this and should have some time over the next couple of weeks to
cook something up in Qt + deploy.

Polemically yours, Freddie.



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

[warzone2100-dev] wz2100.net Status and Future

[Freddie Witherden]

Hi all,

As many of you known http://wz2100.net is currently down.  It is my
understanding that the (virtual) server is currently unable to boot and
Kamaze, the sever-master, is away for at least another week or so.

In the interim the A record for the domain wz2100.net has been updated
to point to that of my own server.  Currently an apology page is hosted
in place of the usual site (including subdomains) and the lobby server
is operational.

However, much like our existing set-up, it is a single point of failure.
 I therefore think that the time is right to begin discussing procuring
a communal VPS server, whose operation is backed by a commercial
provider as opposed to an individual.

Naturally, this would come at a cost to the project and means of
financing, be it donations or otherwise, would need to be discussed.

Polemically yours, Freddie.



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

Re: [warzone2100-dev] Renaming sequences.wz

[Freddie Witherden]

On 24 Jul 2010, at 11:16, Kreuvf wrote:
> Guangcong Luo wrote:
>> We (dak180 and I) have been thinking about it for a while. We think
>> sequences.wz should be renamed to videos-sd.wz and videos-lq.wz.
> What does the "sd" stand for?

Standard definition/distribution would be my guess.  I presume lq is low 
quality.

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

[warzone2100-dev] Iniparser Clean-up Plans

[Freddie Witherden]

Hi all,

What follows are my plans to clean up the iniparser code in lib/iniparser/.

1) Add a dictionary_set_prefix function that will allow a string to be prefixed 
to all set and get queries. This should simplify section handling (which 
currently works by prefixing the section name onto a key).

2) Move all of the get/set functions to dictionary, so that the iniparser is 
just used for loading and dumping dictionaries and basic section management.

Polemically yours, Freddie.

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

Re: [Warzone-dev] Savegame incompatibility rc1->rc2

[Freddie Witherden]

Hi all,

Keep the fix _and_ make rc2 load rc1 savegames? Not sure if that's  
possible,
but savegame compatibility is important (esp. for campaign, which  
doesn't seem

affected - this time).


If campaign still works then leave it. That is the most important.

Regards, Freddie.


PGP.sig
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] 2.2_rc1 Mac Builds

[Freddie Witherden]

Hi all,

I have just uploaded FMV and non-FMV builds of 2.2_rc1 for Mac OS X.  
Enjoy. For some reason these are slightly smaller than the beta builds  
-- I guess some stuff was removed.


Regards, Freddie.


PGP.sig
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] Getting rid of third-party mods

[Freddie Witherden]

Hi all,

On 8 May 2009, at 07:52, Per Inge Mathisen wrote:

Note that these "balance" issues have almost entirely to do with the
given selection of droid templates that each AI has, and almost
nothing whatsoever to do with the AI script code itself.


Also worth pointing out that AIV was never tweaked for T3. It was  
designed primarily for T1 and early T2.


Regards, Freddie.


PGP.sig
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] [PATCH] Don't use the texture rectangle extension for video display

[Freddie Witherden]

Hi all,

On 12 Apr 2009, at 22:24, Dennis Schridde wrote:

tmp = malloc(texture_width * texture_height * 4);

glGenTextures(1, &video_texture);
   glBindTexture(GL_TEXTURE_2D, video_texture);
   glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texture_width,
texture_height,
   0, GL_RGBA, GL_UNSIGNED_BYTE, tmp);

Why not use a PBO instead?


GL 2.1.

Regards, Freddie.



PGP.sig
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] trunk & 2.2 changes for ports/ server code/ config directory

[Freddie Witherden]

Hi,

On 8 Apr 2009, at 08:46, Florian Schanda wrote:

> On Wednesday 08 April 2009 01:56:13 bugs buggy wrote:
>> And by low end, I mean systems that
>> have crappy openGL drivers, I think we require openGL 1.3 maximum for
>> this release?
>
> Will you support the open source ATI drivers -- as they currently  
> don't work
> for trunk/.

It is probably better if you ask the developers of the ATI drivers to  
support the features of the OpenGL standard which we require. We  
program to the OpenGL standard (+ extensions) as opposed to specific  
hardware/drivers.

It is likely that the situation will get better with the release of  
new Mesa/Gallium3D versions.

Regards, Freddie.

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

[Warzone-dev] Betawidget

[Freddie Witherden]

Hi all,

As of last night we finally have OpenGL support in betawidget! This puts us 
one step closer to completeness.

However, there is still quite a lot which needs to be done. Firstly the event 
handling is a bit flakey and has some bugs related to overlapping 
widgets/windows which needs to be fixed. Furthermore the animation API is 
clunky at best and could do with a re-write.

One decision that we need to make as a group is if we are going to allow Lua 
scripts to have direct access to Cairo. It has been our plan from the start to 
write as much of the interface as possible in Lua -- for multitude of reasons. 
In order to do this effectively, however, Lua scripts need to be able to 
define their own drawing functions -- which requires access to Cairo.

Therefore we need to decide if we want to allow this or not, - and if so what 
is the best way to map Cairo to Lua. I am sure Elio has some comments/ideas.

Regards, Freddie.


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] Release 2.2 (with port change) or go with 2.1.3 + port change or ?

[Freddie Witherden]

Hi,

On Sun, 2009-03-15 at 09:02 +0100, Kreuvf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Freddie Witherden wrote:
> > I'd rather just use the SVN revision of the game. It is simpler.
> What do you do when switching to another VCS? That value must be
> VCS-independent. And if I understand the git docs correctly (haven't really 
> read
> much of it :X) you have some hash-like strings as revision and you probably
> cannot derive from such a string if it belongs to an earlier or a later 
> version
> of the game. Correct me, if I am wrong.

One more reason to stick with SVN. However, I am sure that we could
extract the time at which the revision was committed and then convert
that to an integer. This would be reasonably fail-safe (what are the
chances of two people committing into repos at exactly the same time..)

Regards, Freddie.


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] Release 2.2 (with port change) or go with 2.1.3 + port change or ?

[Freddie Witherden]

Hi all,

> Proposed constants:
> NETCODE_VERSION_MAJOR=0, NETCODE_VERSION_MINOR=0, DATA_VERSION="2.2"
> (With the latter being the one used to concat mod version strings onto.)

I'd rather just use the SVN revision of the game. It is simpler.
Furthermore there are a lot of changes we could make to the game that do
not involve the netcode that could break stuff.

My proposal: SVN revision, int, locally modified, bool (just issue a
warning to both sides if any player has it as true), hash, string. For
the moment I suggest that we make the hash just an empty string, but it
will allow us, in the future to hash mods and compare game data,

Of course, for the moment an empty hash makes more sense, time wise.

This method is:
 - foolproof, as it handles accidental local modifications and game
changes (stats etc, as different rev numbers);
 - simple, thanks to autorevision;
 - extendible to handle mod hashing in the future.

Regards, Freddie.


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] Ready for the switch to git?

[Freddie Witherden]

Hi all,

+1 on sticking with SVN.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r6834 - /trunk/lib/ivis_opengl/tex.c

[Freddie Witherden]

Hi,

On Wed, 2009-03-11 at 13:03 +, Gerard Krol wrote:
> Do not use texture compression for interface textures. This makes the 
> interface look better and fixes bug #74.

Do we need to build mipmaps for interface textures? As I do think we
scale them.

Regards, Freddie.


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] Tag 2.1.2 and 2.2 alpha1

[Freddie Witherden]

Hi all,

I am not going to be around much over the weekend and so would  
appreciate it if we could get 2.1.2 and 2.2 alpha1 (or beta1) tagged  
so that I can build the required Mac binaries.


Unless there are any blockers which I am not aware of.

Regards, Freddie.


PGP.sig
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] 2.2 branch

[Freddie Witherden]

Hi,

On Thu, 19 Feb 2009 12:55:49 +0100, Gerard Krol
 wrote:
> I did slightly more work on it, and was not satisfied with the end
> result. It just didn't feel right (oooh). I think we should completely
> rewrite the joining/hosting code. Also, JSON is quite OK, but a way to
> send lua objects safely would be even better. We would have one
> dependency (+one interface) less.

Lua is fine with me -- so long as it is not too hard to parse on the Python
(server) side of things. The one advantage that JSON did have was that it
was possible to write an HTTP interface for the lobby server (using JSON)
allowing for web-based clients.

Therefore a better way might be to get a Lua script for serialising Lua
objects as JSON. That way we get maximum compatibility with minimum effort.

Regards, Freddie.


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

Re: [Warzone-dev] 2.2 branch

[Freddie Witherden]

Hi all,

On 31 Jan 2009, at 09:05, Dennis Schridde wrote:
> Nope, not much holding back 2.2.

I would like to see the new lobby protocol which Gerard was working on  
make it into 2.2. Will simplify things in the future.

Other than that, the sooner we branch, the better!

Regards, Freddie.


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

[Warzone-dev] Release 2.1.1?

[Freddie Witherden]

Hi all,

A week or so ago Giel committed some endian changes which fix several  
bugs on big-endian systems, namely loading and saving games. These  
fixes are very important for PowerPC users (mainly OS X, possibly a  
few Linux users).


Therefore, it is my recommendation that we tag 2.1.1 as soon as  
possible. I am not sure what else is fixed, but I am sure there is the  
odd bug or two squished as well.


(I think you all know what I think we should do with 2.2 as well,  
however, I am aware that it is slightly less practical to do so at the  
current time.)


Regards, Freddie.


PGP.sig
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] Nightly build of r6527 failed

[Freddie Witherden]

Hi,

Most of these failures originate from having too few disk space. I  
think

the size of trunk (in bytes) has increased causing this error.
Considering that I don't have any more diskspace on this system I'll  
be

disabling my nightly build script for now.


Can you not delete some of the older builds (or get it to scp them to  
Gna! when done)?


Regards, Freddie.


PGP.sig
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] Branching for 2.2

[Freddie Witherden]

Hi all,

On 25 Dec 2008, at 18:57, Dennis Schridde wrote:
>> BTW, I like EvilGuru's ambitious plan, if for no other reason than
>> that it sounds awesome and motivating.
> Sounds awesome: Yes.
> Motivating: For some time, yes.
> I just feel we will get stuck again in a situation like we have now.  
> Every now
> and then someone writes a little bit of code when they have time,  
> and the
> ambitious plans rot half finished.

Who cares if I takes a long time. 2.2 is for the long haul. Chances  
are a lot of hardcore fans won't like 3.0 (or 2.3 if you prefer) and  
will want to stick with it.

All of these sub-projects and ideas fit together extremely well, and  
are all fronted by different people. I can't work on the terrain  
branch as I have no idea how it works. So if we schedule it for  
2.3/2.4 I will have nothing to do (why write betawidget if it is still  
releases away from seeing the light of day).

Lua conversion is actually almost finished, as it is an automated  
process. Gerard seems to have made very good progress with it as well.  
(In that, give it a month or so and I would like to merge betawidget  
with it, as we also make use of Lua.)

An ambitious plan which needs as much manpower as possible will also  
serve will for attractive new developers. People don't want to  
maintain someone elses work, they want to make it theirs, do their own  
thing with it. Porting isn't that fun; fixing bugs is not fun;  
rewriting the terrain rendering or replacing the scripting language  
*is*. Getting more people interested is important, as we're all busier  
than we were a year ago.

So I still say that we tag 2.2 (with the intention of maintaining it  
for as long as people want to play it) and then go our own way with  
3.0. It also allows us to bump up the hardware requirements a lot  
easier.

Regards, Freddie.

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

Re: [Warzone-dev] Branching for 2.2

[Freddie Witherden]

Hi all,

I think we should look into branching 2.2 soon; couple of weeks of bug  
fixing (there are still some lurking) and we should be good to go.  
Giel might have something to say about the status of SQLite (I think  
it is partially used in trunk and not totally finished).

 From the OS X perspective: trunk is much better than 2.1 and contains  
many important fixes and has complete theora support. FMVs should be  
*no* problem.

Therefore, we should release a beta as soon as possible, with the  
prospect of 2.2.x releases further down the line (so 2.2.0 need not be  
perfect).

As for 2.3, I think we should call it 3.0. Lua + Terrain + Betawidget  
+ New save game format + WZM is what we should be going for. While it  
will no doubt take at least a year to do, the aforementioned  
components go together nicely. (Betawidget needs Lua, new save game  
format needed for big terrain changes, WZM will go well with improved  
terrain...)

An ambitious release plan also gives us a good chance at applying for  
GSoC 2009, which could be a good way to get new developers onboard.

What does everyone else think?

Regards, Freddie.


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

Re: [Warzone-dev] File Association For Mods

[Freddie Witherden]

Hi,

> While it's better than the current way, the problem with such a scheme
> is that it only allows one mod at a time. I much prefer the old
> Warzone way of simply renaming the mod to enable/disable it.
> Double-clicking it could even toggle its enable/disable state.

Mixing and matching mods is never a good idea. If we encouraged it  
then it would just lead to more useless bug reports.

> Other suggestions include simply bundling a separate mod manager (like
> the old Warzone Launcher), or including a mod manager in-game. The
> game should at least report in the main menu which mods are active.

Can do.

>> And another request, is it possible to register additional protocols
>> on linux/max, like "warzone://:" so that we can fire up
>> warzone from a server-list inside the browser, for example?

Not really. It is possible on Windows but that's about it.

Regards, Freddie.


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

[Warzone-dev] File Association For Mods

[Freddie Witherden]

Hi all,

I am interested in knowing what everyone things about the idea of  
associating .wz files with Warzone in the shell. This would mean that  
to start the game with a mod foo.wz all the user would need to do is  
double click it.

While it might not be a big deal for Linux users, who are usually  
familiar with the shell, it is much more of a problem on Windows  
(where you need to create a shortcut file) and on OS X (where you need  
to first open up a shell and then find the executable inside of the  
bundle and then add the parameter).

Adding a file association could be done quite easily on all operating  
systems. This could be done by the installer on Windows, make install  
on Linux and a special file in the bundle on OS X.

While it would be a little bit more work to do on OS X, on account  
that OS X uses Apple Events as opposed to command-line parameters.

This will make it easier to use and runs mods without needing to touch  
the command line or make short-cuts.

What does everyone think of this?

Regards, Freddie.

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

[Warzone-dev] Betawidget Update

[Freddie Witherden]

Hi all,

Although I have not been working on Betawidget as much as I would have  
liked to recently, development has been progressing, albeit slowly.  
(University is taking its toll.)

Things which still need to be done, include:
  - Adding SVG support;
  - adding a table/grid layout class (in progress, but complex);
  - more sophisticated event handling such that it is possible to see  
if a widget handled an event or ignored it (required for events to be  
handled on overlapping widgets correctly);
  - adding padding support to either containers OR widgets;
  - adding full drag & drop support;
  - re-working animation support, namely so that it support curved  
paths and variable acceleration.

While I am slowly getting around to implementing these things if  
anyone wants a break from debugging/bug fixing these tasks all need to  
be done eventually ;)

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]

Hi Giel,

On 24 Sep 2008, at 23:52, Giel van Schijndel wrote:
Not supporting trunk savegames with 2.1_beta5 should IMO be *no*  
problem

(i.e. no need to have forward compatibility). As for 2.1_beta4
savegames, what's the worst that could happen? People not upgrading to
2.1_beta5 (and incidentally 2.1)? Having them to wait for 2.2? How  
would
that situation be any different from the scenario where we don't  
provide

2.1?


People not upgrading undermines the whole purpose of releasing it. If  
we continue to devote time to backporting changes and fixes to the 2.1  
branch then it is less time spent improving the 2.2 branch/trunk. Once  
something has been branched we want to work as little as possible on  
it -- the bare minimum.


Extending the life-span of 2.1 (in an albeit crippled state, lacking  
beta4 save game functionality) means that we are still obligated to  
fix the 2.1 branch wherever possible.


Should we not provide 2.1 then:
 - People do not get angry that their save games have broken;
 - we can get 2.2 out quicker;
 - we can give people *what they want*.

IMO releasing 2.1 would only offer people a choice, and as long as  
we're
clear on what we won't support I don't think we should face any  
serious

trouble from 2.1.


The problem is choice. Just because we explain that it will break save  
games doesn't mean that people will take any better to it. Should we  
not face any trouble from 2.1 it will more than likely be because no  
one is downloading/using it.


Put simply we can not (easily) make 2.1 beta4 save games work with  
future 2.1 releases. We can, however, make them work with the newest  
version of trunk. It is silly to spend any more time on 2.1 -- it is  
clearly the inferior option. People value their saved games much more  
than you might think.


Our efforts are better focused on 2.2.

Regards, Freddie.


PGP.sig
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] Splitting the repository into source & data sections?

[Freddie Witherden]

Hi Dennis,

On 23 Sep 2008, at 08:28, Dennis Schridde wrote:

> Am Dienstag, 23. September 2008 06:08:37 schrieb bugs buggy:
>> I was thinking it might be a good time to either split the  
>> repository into
>> dedicated sections, or have multiple repositories.
> Can someone state the pros and cons for that? (esp. the pros...)  
> What led to
> that idea?

Easier for distributors/packagers (separate packages). We are not all  
forced to re-download ~20MiB of images when someone decides to re- 
compress the tiles/textures.

>> 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?
> What issues do they have? I was told by non-Gna-members that the SVN  
> server
> had been replaced? (Sadly my communications with the project itself  
> can
> somehow not be established... :( )

It works fine for me.

>> Is having multiple repositories allowed on GNA?
> I would have to investigate whether multiple repositories for one  
> project are
> possible via Savana. But having multiple projects for one thing on  
> Gna is
> afaik not an issue (this is not an official statement, will have to  
> ask for
> that, too :P ). I am building this view on the statement "Large  
> software
> distributions are not allowed; they should be split into separate  
> projects."
> as found on https://gna.org/register/.

Thanks, would really appreciate it if you could.

> To bring this up again: Why exactly can we not host our repository on
> wz2100.net? That sounds like the most effective and simple solution  
> to me...
> (In case we move away from Gna for whatever reason...)
> We'd lack the project management functions as found in Savana, but  
> then we are
> not that many people and adding a new SVN access every few months  
> doesn't
> sound too bothersome. Permission to do that can even be handed out  
> to other
> project members, so our admin (*waves to Kamaze*) does not have to  
> be bothered
> with it.

What if Kamaze gets hit by a bus? Or goes nuts and rm -rf's everything?

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]

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.

[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] 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] FMVs phase 2 complete

[Freddie Witherden]

Hi Giel,

On 20 Sep 2008, at 13:02, Giel van Schijndel 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.

I see no point; every card that has GL_ARB_texture_non_power_of_two /  
GL 2.0+ will also have GL_ARB_texture_rectangle. Might as well just  
use that everywhere, for simplicities sake.

> 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.

If it does prove to be a performance bottle-neck we can use liboil,  
which is Freedesktop.org project designed to provide MMX/SSE/SSE2/ 
AltiVec implementations of CPU intensive operations. One of the  
functions it provides is YUV -> RGB conversion.

Most systems with GPUs new enough to support fragment shaders also  
have a CPU fast enough to decode a 320x240 video.

If you are worried about the time required to upload the frame to the  
GPU, use a PBO, which allow for memory-mapping and copies via DMA.

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

[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-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] Call for testing of pathfinding patch

[Freddie Witherden]

Hi all,

On 16 Sep 2008, at 20:21, Giel van Schijndel wrote:
> Also, yes, I know that it breaks savegames, that's not a bug, that's  
> the
> lack of a feature (the feature being forward compatibility in r4637's
> savegame change). There's little, if anything, that can be done about
> that. But we'll just have to bite that bullet, as IMO non O^2 (or is  
> it
> O^3?) pathfinding behaviour is more important than savegame
> compatibility with *betas*.

Breaking save games is not acceptable. Enough people complain when we  
broke them for 2.0 => 2.1 (and that was when we were bumping a  
version), imagine what they will say if we do it between betas.

Chances are it will just force people to stay with 2.1 beta 4.

 From my point I think our options are:
  - Try *again* to backport the multi-threaded pathing.
  - Skip 2.1 and go straight to 2.2 with FMV support.
  - Re-base 2.1 from trunk.

Regards, Freddie.

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

Re: [Warzone-dev] Moving the repository off gna.org

[Freddie Witherden]

Hi all,

On 13 Sep 2008, at 17:02, Per Inge Mathisen wrote:

> Ok, I think we have given gna.org enough time to fix their problems.
> Can you people please indicate what _your_ preferred future direction
> for the repository is?

My vote is for 6, kind of. How about this: we use wz2100.net as our  
hosting service for subversion and then get Gna! to mirror that? That  
way we get to take advantage of their back-up service and those 'not  
in the loop' are still free to check-out from Gna!.

Whatever we do it would be foolish to move from subversion, think of  
the Windows and Mac users.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5964 - /trunk/lib/betawidget/tools/sdl-testapp.c

[Freddie Witherden]

Hi Dennis,

On 8 Sep 2008, at 17:53, Dennis Schridde wrote:

> On Monday 08 September 2008 11:00:03 Freddie Witherden wrote:
>> Hi Giel,
>>
>> On 8 Sep 2008, at 00:51, Giel van Schijndel wrote:
>>> Author: muggenhor
>>> Date: Mon Sep  8 01:51:21 2008
>>> New Revision: 5964
>>>
>>> URL: http://svn.gna.org/viewcvs/warzone?rev=5964&view=rev
>>> Log:
>>> Fix a memory leak which resulted from neglecting to call SDL_Quit()
>>
>> atexit for the win!
> Ain't that done already? Or was it just my own framework where I  
> wrote it like
> this?

Yes, the file does already contain atexit(SDL_Quit); The SDL_Quit call  
can probably be removed.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5963 - in /trunk/lib/betawidget: Makefile.am autogen.sh betawidget.i configure.ac hBox.h lua-wrap.h m4/ m4/ac_pkg_swig.m4 m4/swig_enable_cxx.m4 m4/swig_lua.m4 spac

[Freddie Witherden]

Hi Giel,

On 8 Sep 2008, at 00:47, Giel van Schijndel wrote:
> Author: muggenhor
> Date: Mon Sep  8 01:47:53 2008
> New Revision: 5963
>
> URL: http://svn.gna.org/viewcvs/warzone?rev=5963&view=rev
> Log:
> * Add a Lua interface to (parts of) betawidget
>  * Partially generated by SWIG
>  * Partially handcrafted
> * Already supports registering Lua functions as event handlers of  
> `widget` derivatives
> * Slight change in betawidget headers because the struct typedef's  
> somehow confused the compiler
> * Use libtool for linking with Lua

Some questions/musings:

  - My typedefs!?! Is it SWIG has a problem with typedef struct   
? As several of the typedefs at the start of widget.c can be  
converted to typedef struct { ... } . (Namely the event ones.)

  - The '_' burn my eyes, please reject them in place of the holy  
camelCase.

  - What is with all of the crazy const  * const WZ_DECL_PURE  
WZ_DECL_INNOCENT WZ_DECL_REALLY_REALLY_CONST  . I am sure that  
const  * will do. We don't want it turning into pie vector.

  - The widget class shouldn't need an allocating constructor (i.e.,  
one that malloc's memory). Widget should be considered an abstract  
class (there are several methods which it does not implement which are  
needed for it to function. The normal way to 'create' a class is with  
the *Create function, e.g. hBoxCreate which allocates the memory and  
calls the constructor. Not sure if it is possible to do this within  
the context of the C++ wrapper, however.

  - The lua_widget_addEventHandler and lua_widget_addTimerEventHandler  
can probably be generalised into one. The share such a large amount of  
code (just addEventHandler sets the interval to -1). Should be able to  
factor a common function out.

  - Do we have any ideas about how to make updating the interface file  
easier, so to reduce the amount of maintenance it will require?

  - Did we ever decide how we were going to provide lua? I know a  
while back we were talking of embedding it the same way we do with  
SQLite, comments anyone?

- Any ideas on how to best handle event structures, as they use the  
same kind of inheritance scheme widget and friends do. Since lua is  
much more dynamic than C there may be a nicer way of passing these  
structures, which are crucial for event handling.

- Shall we extern "C" { ... } all of the betawidget headers? As the Qt  
platform code (coming soon!) will be in C++ so it might be worth it.

- Finally, who wants to pay for Per's dry cleaning costs after he sees  
the size of the SWIG-generated file ;-)

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5964 - /trunk/lib/betawidget/tools/sdl-testapp.c

[Freddie Witherden]

Hi Giel,

On 8 Sep 2008, at 00:51, Giel van Schijndel wrote:
> Author: muggenhor
> Date: Mon Sep  8 01:51:21 2008
> New Revision: 5964
>
> URL: http://svn.gna.org/viewcvs/warzone?rev=5964&view=rev
> Log:
> Fix a memory leak which resulted from neglecting to call SDL_Quit()

atexit for the win!

Regards, Freddie.

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

Re: [Warzone-dev] Barrier Intel GMA

[Freddie Witherden]

Hi Dennis,

On 7 Sep 2008, at 13:17, Dennis Schridde wrote:
> On Sunday 07 September 2008 13:28:45 Kamaze wrote:
>> Looks like a stuck situation, at least for the renderer. Does someone
>> already have some ideas for the future? Different rendering parts to
>> stay GMA compatible or breaking GMA support some day?
> Can you get a bit more specific please?
> What exactly is broken about rendering on Intel chips?

More the drivers; modern Intel chips are quite capable (the X3100 in  
my Macbook, and by extension the X3000 have reasonable support for  
modern OpenGL extensions). (Although performance is another issue.)

The main issue is with their poor driver support on Linux and Windows.  
They claim to support framebuffer objects (but don't actually) —  
resulting in us having to workaround it ourself. No VBO support is  
another issue, even through it could be emulated should the card  
provide no real support for it. Most do not support fragment or vertex  
shaders.

On the Windows side of things some of their chips have been shipping  
without support for age-old extensions such as  
GL_ARB_texture_rectangle, again things that are easy to emulate should  
there be no hardware support (just pad the texture with transparent  
pixels until it is power-of-two).

The lack of FBO and VBO support is the main issue — down to nothing  
more than poor drivers. It is very hard to design a chip that does not  
support them [1] yet there is no driver support. This is poor,  
considering render-to-text has been part of DirectX (SetRenderTarget)  
since its inception and therefore has near perfect hardware support.  
VBOs, as I have already mentioned can be emulated if need be.

The lack of FBO support is something of a thorn in betawidgets side —  
having buttons with things such as rotating models becomes quite  
difficult.

Regards, Freddie.

[1] http://lists.freedesktop.org/archives/xorg/2008-May/034844.html
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Re: [Warzone-dev] Should we officially seek for a Pandora developer?

[Freddie Witherden]

Hi Per,

> The more important question: Does an RTS game like Warzone run well on
> a handheld console? I think the game requires a mouse, unless you want
> to play campaign with the drive mode, as in the PSX version.

It would appear so. A while back a group got 0.2.3 running on the  
Maemo platform (as used by the Nokia N800 and N810 series). 
http://www.internettablettalk.com/forums/showthread.php?t=16502 
  The game seems popular and works well with a stylus (the device  
having a touch screen).

Regards, Freddie.

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

Re: [Warzone-dev] Should we officially seek for a Pandora developer?

[Freddie Witherden]

Hi Giel,

> You mean GL ES doesn't support glBegin/glEnd? I thought that was  
> part of
> the minimal set that it *does* support?

Nope they got rid of a *lot* of old stuff in ES. OpenGL ES shares more  
in common with OpenGL 3.0 than it does with OpenGL 2.0.

glBegin/glEnd are mainly used by CAD applications and other legacy  
pieces of software; none of which fall into the same target market as  
OpenGL ES – so the functionality was removed.

Regards, Freddie.


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

Re: [Warzone-dev] Should we officially seek for a Pandora developer?

[Freddie Witherden]

Hi,

On 30 Aug 2008, at 15:25, Kamaze wrote:

> Pandora you may ask? Look here:
> http://en.wikipedia.org/wiki/Pandora_(console)
>
> Seems very interesting to me and I think that Warzone 2100 could be a
> Top-Tier application for that thing. Since it has already run on other
> Handhelds.
>
> So, should we may seek officially for Pandora-Owner/Developers in the
> near future?

Just taken a look at the page on wikipedia — we should be able to  
support it without issue, however it uses OpenGL ES which is not  
compatible with the pre-history version of OpenGL we currently target.

Assuming someone is willing to beat the renderer into shape (killing  
off glBegin/glEnd) I see no reason why it should not work. Our netcode  
is cross platform and most of our other dependencies are standard C.

Might be worth asking/begging them for a couple so that a couple of us  
may port Warzone to it. We are an established FOSS game and so do not  
see why it should be a problem.

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

Re: [Warzone-dev] Nightly build of r5877 failed

[Freddie Witherden]

Hi Giel,

On 27 Aug 2008, at 14:48, Giel van Schijndel wrote:

> Dennis Schridde schreef:
>> Am Mittwoch, 27. August 2008 05:39:02 schrieb Giel van Schijndel:
>>> NOTE: This message is automatically generated by the nightly build
>>> script.
>>>
>>> Building of the nightly build failed for revision r5877 [1] when
>>> trying to build a debug executable.
>> out-of-memory
>
> Nope, even funnier, out of disk space...
>
> Probably due to the 1,5ish GB worth of nightlies that have accumulated
> on my system. I'll write a script to automatically clean the nightly
> build dir to prevent this from reoccurring. Leaving just the last two
> nightlies seems sufficient to me.

Towers of Hanoi. They (the nightlies) are useful (even under Wine) for  
checking if r had a specific bug (considering they go back quite  
a long time and save 100s of check-outs).

http://en.wikipedia.org/wiki/Backup_rotation_scheme#Towers_of_Hanoi is  
a reference for it.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5877 - /trunk/macosx/Warzone.xcodeproj/project.pbxproj

[Freddie Witherden]

Hi Ari, Tim,

Good news about the Xcode project!

However, do you know if it is possible to comment out a target for  
10.5 (which ships with Bison 2.3)? So far as 10.5 goes, trunk builds  
(with a slight modification to multiint.c IIRC).

Regards, Freddie.

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

Re: [Warzone-dev] #41: New layout of menu

[Freddie Witherden]

Hi Giel,

On 26 Aug 2008, at 14:35, Giel van Schijndel wrote:

> bugs buggy schreef:
>> The only other question I have is for the  translations, and if  
>> there is
>> enough room?
>
> To my knowledge the only limit to the size of translatable strings is
> the amount of available memory. AFAIK gettext dynamically allocates
> memory to hold the translated strings.

I believe Buggies comment was with regards to the physical amount of  
space available on screen.

Regards, Freddie.

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

[Warzone-dev] Betawidget Directoy Layout

[Freddie Witherden]

Hi all,

As some of you may have noticed I have started to add clipboard  
support to betawidget (starting with OS X). The bad news, however is  
that it involves platform specific code.

Since one of the goals of betawidget is that it is portable and not  
tied to SDL/Warzone (integration into Warzone Studio), I propose the  
following directly layout for trunk/lib/betawidget:

betawidget
platform
sdl
clipboardOSX.c
clipboardX11.c
clipboardWin32.c
events.c
qt4
clipboard.c
events.c
widget.[ch]
window.[ch]
...

This will mean that the platform/library wrapper code is versioned and  
well maintained -- the idea being that by compiling betawidget +  
platform/ one will end up with a fully working (and usable)  
copy of betawidget (i.e., all helper methods are implemented, so no  
linker errors).

However, as usual I want to know what you all make of this.

Regards, Freddie.

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

Re: [Warzone-dev] Trac Ticket #38 - Adds Vsync Support

[Freddie Witherden]

Hi Per,

On 25 Aug 2008, at 13:12, Per Inge Mathisen wrote:

> On Mon, Aug 25, 2008 at 12:40 PM, Freddie Witherden
> <[EMAIL PROTECTED]> wrote:
>> The patch can be found here: http://developer.wz2100.net/ticket/38
>>
>> I believe, if deemed suitable for trunk that it should be a  
>> candidate for
>> backporting to 2.1 (otherwise OS X users will most likely experience
>> tearing).
>
> Looks good to me. Be aware that many systems will only appear to
> support vsync control and disregard the given setting, however. I
> discovered this to my dismay when I wrote this feature for SDL. There
> is also no easy and reliable way to query whether vsync is
> successfully set or not.

Am I okay to commit it to trunk?

The net effect is:
  - one new translation string;
  - one new configuration option which will need to be documented,  
with caveats.

(We don't have a translation mailing list do we?)

Regards, Freddie.

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

[Warzone-dev] Trac Ticket #38 - Adds Vsync Support

[Freddie Witherden]

Hi all,

Since one cannot commit a patch unless it is signed in triplicate, sent in, 
sent back, queried, lost, found, subjected to a public enquiry, lost again, 
and finally buried in soft peat for three months and recycled as firelighters 
I am hereby submitting my patch for formal review.

The patch can be found here: http://developer.wz2100.net/ticket/38

I believe, if deemed suitable for trunk that it should be a candidate for 
backporting to 2.1 (otherwise OS X users will most likely experience 
tearing).

Regards, Freddie.

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

[Warzone-dev] Trunk On OS X

[Freddie Witherden]

Hi all,

I have just got around to compiling off trunk on OS X 10.5. This  
required two changes:
  • Updating the QuesoGLC version to trunk r832;
  • Changing the include path for GLC so that revisions > r5833 compile.

However, there are several issues which I experience on my Intel  
MacBook running 10.5:
  1. Font rendering is fudged, see http://www.witherden.org/~freddie/wzosx.tiff 
  (non permanent link!).
- Might be due to new GLC version; will try older revisions.
  2. The game crashes on exit and requires a kill signal.
- Suspect OpenAL to be the cause (waiting on a mutex), more  
debugging needed.
  3. No v-sync (it could be due to GPU/OS version), however an option  
enable v-sync or not would be useful.
   - Space in "Video Options"?
   - Code is: SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1);
   - Useful on other operating systems.

Does anyone else have any other issues to add to the list (or would  
like a recent trunk .app, which I can do). The first two should be our  
priority without a doubt. (Do we have a Mac maintainer?)

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

Re: [Warzone-dev] Productivity is shot.

[Freddie Witherden]

Hi all,

On 19 Aug 2008, at 07:31, Per Inge Mathisen wrote:
> Got a suggestion for a new server? As long as we use svn (and not a
> fully distributed tool), I would like a host that has reliable
> backups, in addition to decent speed and uptime.

I quite like Gna!, advert free, provide hosting space and SVN for us  
and so am possibly willing to give them the benefit of the doubt for  
another week or so.

Changing SVN servers will probably be a fair amount more work — all  
developers will need to re-upload their keys, changed all checked out  
repositories etc. It seems like a lot of effort. Gna! claim that they  
are working on the problem and so lets see if anything comes of it.

Overall they have been quite good to us, and do normally have very  
good response times for issues (e.g., when we merged the old- and the  
new-repositories together).

Saying that, Gna! has been working very well for me — normally getting  
things checked-out or committed first time. So if anyone do need  
anything committed, I can probably do it on their behalf. This may or  
may not be serendipity.

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

[Warzone-dev] Tool-tip Proposal for Betawidget

[Freddie Witherden]

Hi all,

As outlined on the wiki page for betawidget one of the things still  
outstanding is tool-tip support – something which is proving to be  
quite a pain to implement.

Here is my current idea:
  - The root widget, a window, has two children – a container and a  
toolTip instance;
  - the widget class is modified so that it has a widget->toolTip  
member, of type const char*;
  - when the mouse remains stationary over the widget for ms (with  
there being no clicks) the tool tip is moved to the mouses location  
and shown if hidden;
  - when the mouse is moved the tool tip is hidden.

The current 'problem' with this method is that it will require  
widget.c to #include toolTip.h (i.e., have a dependency on it). I am  
unsure if this is desirable or not.

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

[Warzone-dev] [patch #1088] Various Netcode Improvements

[Freddie Witherden]

URL:
  

 Summary: Various Netcode Improvements
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Thursday 24/07/08 at 16:46
Category: Fix
Priority: 7 - High
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Here are a couple of netcode improvements I have been working on.

The first one sends the droids position and body points along with an order
-- this should fix some of the out of sync problems in trunk and beta4.

The second one updates the sync code so that it is purely limited by
bandwidth (as opposed to a frequency counter  timers per second).

Both, however need extensive testing.



___

File Attachments:


---
Date: Thursday 24/07/08 at 16:46  Name: multisyncrates.patch  Size: 2kB   By:
evilguru


---
Date: Thursday 24/07/08 at 16:46  Name: orderposition.patch  Size: 3kB   By:
evilguru



___

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] hello

[Freddie Witherden]

Hi,

On Monday 14 July 2008 18:56:05 d3f3nd3r wrote:
> hello,
>
> I'm a student and interested in working on Warzone!
>
> I know c (data structures, strings), c++ (gtk/wxwidgets + basics +
> basics templates) and python.
>
> Is there anything I can do, or can you recommend good resources on the web
> (or old fashioned books) for getting deeper into the stuff?

There is always something to do, or something that needs doing! So far as 
developer resources go I highly suggest that you check out the wiki 
(http://wiki.wz2100.net ), and pop-by on IRC; we can be found on #warzone2100 
at irc.freenode.net .

Regards, Freddie.



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] 2.1 beta4

[Freddie Witherden]

Hi all,

> PS: This includes not waiting for any MacOS bugs.
> Since it appears to me we do not have a maintainer for that  
> anymore, there is
> no sense in waiting for the bugs to be fixed by some magic.

To the best of my knowledge, all current OS X bugs (excluding build  
ones) are not directly the fault of Warzone; and correspond to  
similar problems other applications have been experiencing.

The SDL cursor trapping bug appears to be un-related to any previous  
cursor trapping bug, and is believed to be an SDL issue.

The corrupt skybox is currently believed to be a problem in Apples  
OpenGL drivers for nVidia and Intel cards under 10.5.

Since I do not have a 10.5 system, nor an Intel Mac I am not really  
up to task of maintaining it; however I am willing to help out where  
possible.

Regards, Freddie.

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

Re: [Warzone-dev] Status of SVG Rendering In Betawidget

[Freddie Witherden]

Hi again,

On 28 Jun 2008, at 19:28, Freddie Witherden wrote:
> I have written a test application (in Qt) to showcase the rendering
> capabilities of libsvg-cairo. This can be found here: http://
> www.witherden.org/~freddie/svg.tar.gz (I'll try to find a more
> permanent location for it).
I have uploaded it to Gna! It can be found here: http:// 
download.gna.org/warzone/development/libsvg-cairo-test/

Regards, Freddie.

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

[Warzone-dev] Status of SVG Rendering In Betawidget

[Freddie Witherden]

Hi all,

Today I have been looking at getting SVG rendering working in  
Betawidget. Initially I looked at librsvg (http:// 
librsvg.sourceforge.net/ ), however decided against it due to the  
dependency on glib/gobject.

So, instead I looked at libsvg and libsvg-cairo. While these  
libraries have minimal dependencies (just cairo and libxml2), they  
are un-maintained, having no public release in over two years.  
However, they are easy to use and do work . The problem is that they  
only support a subset of the SVG standard.

I have written a test application (in Qt) to showcase the rendering  
capabilities of libsvg-cairo. This can be found here: http:// 
www.witherden.org/~freddie/svg.tar.gz (I'll try to find a more  
permanent location for it).

I have been speaking to Elio about this and he is unsure if he can  
coerce the SVG files he has made into working with libsvg-cairo.  
Therefore, I am unsure about the best course of action to take. The  
way I see it, we can either:
a) Hope Elio can work around the limitations (anything but ideal);
b) Update libsvg[-cairo] ourselves (possible, it is not overly complex);
c) Use librsvg and add glib as a dependency;
d) Switch to PDF using popper (still investigating);
e) ?

Comments?

Regards, Freddie.

___
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

[Freddie Witherden]

Hi all,

> On Friday, 13 June 2008 at  0:19, bugs buggy wrote:
>> 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
>
> Skip every other line means inserting black lines, or doubling the
> lines? Inserting black lines will increase the needed bitrate way too
> much (if you want to do that, rather do it after decoding the video),
> and doubling the lines won't really make it look different, will it?
> (And also can be done as post-processing, rather than eating bits
> unnecessarily.)

I agree here. Doing it in software *after* we have de-compressed the  
video is the way to go. A lot of games, however, did use this  
technique of adding in alternate black lines. Namely, early C&C and  
TA spring to mind. It does work.

Regards, Freddie.

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

Re: [Warzone-dev] 2.1 beta3 again

[Freddie Witherden]

Hi,

> Note that due to school stuff (i.e. a lack of planning on someone  
> else's
> part, *does* constitute a problem on my part) I won't have a lot of  
> time
> to spend on Warzone...

I will have to time whatsoever until the 19th. Might be able to do  
the odd bit of tech support, but nothing major.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5232 - /tags/2.1_beta3/src/droid.c

[Freddie Witherden]

Hi all,

> A non-debug build *should* #define NDEBUG (to shut up the ASSERTs  
> among
> others). Hence I think the better fix would be to #define NDEBUG in  
> the
> XCode project when producing a non-debug build.

#ifndef DEBUG seems more than sufficient. More consistent too.  
Inconsistent debug/non-debug/whatever detection always comes back to  
bite you in the long run; just take a look at some of the early  
commits -- which were nothing more than making the #ifdef WIN32 and  
#ifndef PSX constant.

Regards, Freddie.

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

Re: [Warzone-dev] 2.1 beta3 again

[Freddie Witherden]

Hi all,

> Given that my binaries are subject to deletion anyhow, I'll let
> Freddie do it.  Have fun.

Per suggested that we should do some more testing first. Since Mac  
(PPC) <=> Anything else multiplayer games are now a reality I believe  
it is worth testing them some more. (This will be the first time that  
the netcode has been endian-tested.)

Since we are yet to announce beta-3 I am suggesting that we remove  
all beta3 builds from Gna! (there is always the nightly builds by  
Giel if you want bleeding edge) or rename them accordingly.

This will allow us to launch beta-3 with official Mac (PPC) multiplay  
support.

I have exams for the next few days and so will not really be  
available (Per, I believe also mentioned not being around until  
Tuesday, although he will have to confirm this). However, by Friday I  
should've had enough spare time to play a few multiplayer games on OS  
X. It does mean a small delay, but it is well worth it.

Thoughts?

Regards, Freddie.


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

Re: [Warzone-dev] 2.1 beta3 again

[Freddie Witherden]

Hi all,

> The extracted .app totals about 70MB.  I don't know if he did
> something differently or not.  The lack of communication led me to not
> even know he had created one - or, for that matter, how he created
> one, since the game would not build as originally tagged for beta3.

The 'warzone/tags/2.1_beta' built on my end with a couple of  
modifications (namely the replacing of some #ifdef NDEBUG with  
#ifndef DEBUG). Other than that I experienced no problems.

The reason my .dmg is probably a bit smaller is because I compress it  
once created. This is done by using the 'Convert' option in Disk  
Utility, which will produce a compressed read-only disk image from  
any other disk image. Helps to save a few Mb.

I got away without adding Bison to the auto-dep-fetch by manually  
updating Bison on my system. If it were not exam season I would've  
done it properly. As a result a newer version of Bison is required to  
build Warzone.

Regards, Freddie.

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

Re: [Warzone-dev] [Warzone-commits] r5122 - /trunk/lib/framework/trig.c

[Freddie Witherden]

Hi,

Please, please, please, leave this file alone! I have tried (and failed) in
the past to clean it up and it introduced a multitude of strange bugs.
Therefore it is important to test the patch for a couple of hours before
committing it.

Regards, Freddie.


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

Re: [Warzone-dev] Call for mac users?

[Freddie Witherden]

Hi,

> I do indeed normally build a .dmg whenever there's a tagged release of
> any form.  Right now, trunk won't build because Warzone suddenly
> requires a newer version of Bison than OSX has and I am avoiding
> having the build process depend on you having anything but OSX 10.4
> and Xcode installed.  But when that's fixed (which will be within the
> Xcode project just like all other dependencies of Warzone), it will be
> the same as it's been since I converted to Xcode:  svn co url warzone
> ; cd warzone/macosx ; xcodebuild ; open build/Debug/Warzone.app

I remember when I first compiled Warzone (under 10.4) that I need to  
manually fetch and install a fewer version of bison. So a pure 10.4 +  
Xcode build may prove to be impossible.

Regards, Freddie.

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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

On 9 May 2008, at 12:28, Dennis Schridde wrote:
> Am Freitag, 9. Mai 2008 12:17:43 schrieb Freddie Witherden:
>> On Fri, 9 May 2008 10:38:54 +0200, Dennis Schridde  
>> <[EMAIL PROTECTED]>
>> wrote:
>>> Just something I experimented with:
>>> #define CALL(OBJECT, METHOD) ((OBJECT)->vtable->METHOD)
>>> CALL(xob, xme)(p1, p2);
>>
>> Currently the way virtual methods (i.e., those which use the  
>> vtable) are
>> called is exactly the same as that of non-virtual methods:
>> , so: wigetSetLayout(...).
> So the API will be "C-style"? I somehow assumed it was intended to  
> provide a
> object oriented syntax, i.e. via GET_VTABLE().

The 'user' API will be C-style, yes. So the fact that there is a  
vtable is completely hidden from the user of an object.

>> This is somewhat useful, as in the virtual method functions (e.g.
>> widgetDoDraw), which is a pure virtual method, we can ASSERT that
>> object->vtable->method is NOT NULL. A macro may complicate this  
>> somewhat.
> So the idea is that there are wrapper functions, like widgetDoDraw 
> (), which
> call widget->vtable->method, which may point to buttonDoDraw()?

Exactly.

>> It may seem a bit strange, if, in the code we get:
>> button *btn = buttonCreate(...);
>> widget *root = widgetGetRoot(WIDGET(btn));
>> CALL(btn, setLayout)(...);
> Just wanted to mention this, since we talked about that recently.
> I got the idea that the above way might work, tested, and it did work.
> And since I saw some GET_VTABLE(obj)->method in the code, I thought  
> I might
> also tell you what I tested.

WIDGET_GET_VTBL is designed to get the vtable that should be used for  
calling widget methods. So if sub-classes export their on virtual  
functions they will also have a FOO_GET_VTBL.

It is very important to cast here. As ((widget *) self)->vtbl is  
different from that of say ((button *) self)->vtbl. The FOO_GET_VTBL  
methods are designed to make this a bit easier.

Regards, Freddie.

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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

On Fri, 9 May 2008 10:38:54 +0200, Dennis Schridde <[EMAIL PROTECTED]>
wrote:
> Just something I experimented with:
> #define CALL(OBJECT, METHOD) ((OBJECT)->vtable->METHOD)
> CALL(xob, xme)(p1, p2);

Currently the way virtual methods (i.e., those which use the vtable) are
called is exactly the same as that of non-virtual methods:
, so: wigetSetLayout(...).

This is somewhat useful, as in the virtual method functions (e.g.
widgetDoDraw), which is a pure virtual method, we can ASSERT that
object->vtable->method is NOT NULL. A macro may complicate this somewhat.

It may seem a bit strange, if, in the code we get:
button *btn = buttonCreate(...);
widget *root = widgetGetRoot(WIDGET(btn));
CALL(btn, setLayout)(...);

Regards, Freddie.


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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

On Fri, 9 May 2008 12:05:47 +0200, Dennis Schridde <[EMAIL PROTECTED]>
wrote:
> widget.h:
> int32_t userData;

I made it a fixed size so that people would not be tempted to store
pointers in it (we have pUserData for that). Knowing it is a fix size may
also allow it to be used for storing floating-point values.

> That is the size of the userData blob?
> Why does it need to be exactly 32bit long?
> Maybe size_t would be a good type?
> And userDataSize a better name?

size_t would be fine, also. Just so long as people will not store pointers
in it I am happy.

Regards, Freddie.


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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

> This kind of layout is designed for application GUIs, and I am not
> convinced they will work very for us. We have some rather complicated
> UI elements (eg the reticule), and I would like to be able to specify
> somehow the amount of offset there should be from one widget to
> another, rather than the GUI code spacing them out over the available
> area. For most use cases, I think we want widgets to snap to a border,
> instead of centering and evenly spacing items as such layout schemes
> usually do.

The reticule can be done by an n-gon layout. Whereby add elements are  
added they are positioned such that each widget is a vertex of a n- 
gon, where n is the number of widgets.

Regards, Freddie.


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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

On 5 May 2008, at 13:22, Dennis Schridde wrote:
> Am Sonntag, 4. Mai 2008 23:49:57 schrieb Freddie Witherden:
>> The problem I am having is how a widget should tell its parent where
>> it wants to be? Should it be relative to other widgets? Should it be
>> relative to a side (north, east, south, west)?
> My proposal is "stolen" from Qt: "layouts" and ~"hints".
>
>
> Layouts:
> myLayout = newHBoxLayout();
> myLayout->add( wdg1 );
> myLayout->add( wdg2 );
>
> Result:
> | wdg1 | wdg2 |
>
> (Similar for VBoxlayouts, etc.)
>
> In layouts any positional information of the widget is ignored.
>
>
> ~Hints:
> wdg1 = newWidget();
> wdg1->setMinimumSize( 0, 0 );
> wdg1->setMaximumSize( 1, 1 );
> wdg1->setDefaultSize( 0.5, 0.5 );

I like it. It is also the same method which GTK uses. Should be nice  
and easy to implement as well.

Regards, Freddie.

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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi,

On 5 May 2008, at 12:29, Per Inge Mathisen wrote:
> On Mon, May 5, 2008 at 1:02 PM, Freddie Witherden  
> <[EMAIL PROTECTED]> wrote:
>>> My suggestion is simply to make it snap to another widget (not
>>> necessarily a parent, could be a sibling), and then provide an  
>>> (x, y)
>>> constant offset from it in pixel independent values (millimeters?).
>>
>>  Seems good. So we could say something like:
>>
>>  widgetAdd(parent, child, northSnap, eastSnap, southSnap, westSnap);
>
> I was thinking more like widgetAdd(parentWidget,
> frameOfReferenceWidget, side, offsetX, offsetY);
>
> Putting an icon in the lowest right side of the main window:
> widgetAdd(screen, screen, BottomLeft, 10, 10);
> Adding the third button in a row inside a window: widgetAdd(window,
> second, Right, 20, 0);

We then have to make the assumption about the size of the first icon  
(that it is 10 units). This is basically what we have at the moment -  
adding widgets requires knowledge about the size of other widgets.

Lets say at a later date we decide to make our icons a bit bigger,  
say 12 units. We then need to find all of our widgetAdd calls and fix  
them.

Or am I missing something?

>>  Take a label widget for example, lets say it has worked out it needs
>>  to be *at least* 150 pixels large.
>
> I think we can safely assume that we have no or decide we shall have
> no widgets with such pixel precise requirements. Models, text, and
> textures can all scale to fit the allocated space.
>
>>> I would suggest specifying size exactly using a pixel independent
>>> value (millimeter? permille of screen size?).
>>
>>  On Linux this would work. This is because X computes the screen DPI
>>  on the fly. So a piece of 12pt text will be the same size on *all*
>>  linux systems. Windows assumes a DPI of 96, while OS X assumes  
>> one of
>>  72.
>
> It is not that hard.
>
> ( pixel width of screen ) / CONSTANT = x factor
> ( pixel height of screen) / CONSTANT = y factor
>
> We multiply all x, y values, which are in the range 0..CONSTANT, by
> these factors and get resolution dependent values. We could even
> decide to go the OpenGL way, and decide that the factor is 1.0 and
> that x,y values are floating point.

Nice idea. :)

Regards, Freddie.

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

Re: [Warzone-dev] New GUI Update

[Freddie Witherden]

Hi all,

On 5 May 2008, at 07:42, Per Inge Mathisen wrote:
> On Sun, May 4, 2008 at 11:49 PM, Freddie Witherden
> <[EMAIL PROTECTED]> wrote:
>>  The problem: we need a way for child widgets to position themselves
>>  within their parents. We do not want to use pixel co-ordinates and
>>  need the system to be flexible.
>
> My suggestion is simply to make it snap to another widget (not
> necessarily a parent, could be a sibling), and then provide an (x, y)
> constant offset from it in pixel independent values (millimeters?).

Seems good. So we could say something like:

widgetAdd(parent, child, northSnap, eastSnap, southSnap, westSnap);

Where 'snap' is a side of another widget. So to add a child widget to  
a parent we would do:

widgetAdd(parent, child_1, widgetNorth(parent), widgetEast(parent),  
widgetSouth(parent), widgetWest(parent));

Then if we wanted to add another child widget (child_2), splitting it  
horizontally we would do:

widgetAdd(parent, child_2, widgetSouth(child_1), widgetEast(parent),  
widgetSouth(parent), widgetWest(parent));

So we are making the north side of child_2 'touch' the south side of  
the first child.

Saying this, I am still very much open for suggestions. The simpler  
the better.

>>  Currently, when a child widget is added to a parent no location-
>>  related information is passed. Instead there is an arbitration
>>  process between the parent and the child. Most likely (this is still
>>  undecided) it will be: the parent asks the child where it would like
>>  to be and then offers it a location/size. The child will then either
>>  accept or deny it. The arbitration process continues until *all*
>>  child widgets are satisfied.
>
> Sounds complicated. I'd rather not worry about negotiation loops when
> adding widgets. On what grounds could a child refuse a location?

Take a label widget for example, lets say it has worked out it needs  
to be *at least* 150 pixels large. We add it to a parent container,  
which has say, 120 pixels free. The parent offers it 120 pixels.  
This, however, is too small, so the child would refuse. At this point  
the parent would have a go at reducing the size of other child  
widgets, offering the additional space to the label.

>>  Furthermore how should the size be done? Should widgets have a min/
>>  max/desired size? How can we have it so that a widget will fill  
>> up as
>>  much space as possible?
>
> I would suggest specifying size exactly using a pixel independent
> value (millimeter? permille of screen size?).

On Linux this would work. This is because X computes the screen DPI  
on the fly. So a piece of 12pt text will be the same size on *all*  
linux systems. Windows assumes a DPI of 96, while OS X assumes one of  
72.

Therefore a 10mm line on Windows/OS X will be smaller on a 20" screen  
than on a 15" one.

Regards, Freddie.


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

[Warzone-dev] New GUI Update

[Freddie Witherden]

Hi all,

As many of you know, the new GUI is taking shape - slowly but surely.  
The base widget code is there, with there being just a few more  
things to brush off before the fun can begin - designing the actual  
widgets themselves.

However, the remaining bits left to do are perhaps the hardest bits;  
the first one being the layout system. I have been thinking about  
this for a couple of days now and can not seem to come up with a one- 
size-fits-all solution.

The problem: we need a way for child widgets to position themselves  
within their parents. We do not want to use pixel co-ordinates and  
need the system to be flexible.

Currently, when a child widget is added to a parent no location- 
related information is passed. Instead there is an arbitration  
process between the parent and the child. Most likely (this is still  
undecided) it will be: the parent asks the child where it would like  
to be and then offers it a location/size. The child will then either  
accept or deny it. The arbitration process continues until *all*  
child widgets are satisfied.

The problem I am having is how a widget should tell its parent where  
it wants to be? Should it be relative to other widgets? Should it be  
relative to a side (north, east, south, west)?

Furthermore how should the size be done? Should widgets have a min/ 
max/desired size? How can we have it so that a widget will fill up as  
much space as possible?

Hopefully over the next couple of days we can come up with something  
and wiki it.

Regards, Freddie.

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

[Warzone-dev] [patch #1055] Droid.c Cleanup

[Freddie Witherden]

URL:
  

 Summary: Droid.c Cleanup
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Sunday 04/13/2008 at 11:30
Category: None
Priority: 5 - Normal
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

This patch cleans up a fair amount of code in droid. Most of it is dead-code
removal, nested if-statement elimination and indentation fixes.



___

File Attachments:


---
Date: Sunday 04/13/2008 at 11:30  Name: droid.patch  Size: 33kB   By:
evilguru



___

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

[Warzone-dev] [patch #1030] Anti-painting Patch

[Freddie Witherden]

URL:
  

 Summary: Anti-painting Patch
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Friday 28/03/08 at 18:18
Category: Feature
Priority: 5 - Normal
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

This patch is an implementation of:
http://forums.wz2100.net/?topic=1572.msg14526#new

It seems to work quite well, however the code could probably do with some
refactoring (as misson.c contains some very similar code to auto-build
structures on save).

Other than that it is ready for testing.



___

File Attachments:


---
Date: Friday 28/03/08 at 18:18  Name: antipainting.patch  Size: 3kB   By:
evilguru



___

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

[Warzone-dev] New GUI Proposal

[Freddie Witherden]

Here is a short proposal for the new GUI library to replace the  
current one in Warzone. As usual, comments are not only welcome, but  
mandatory.

The main problems with the current widget/form system are:
  * It is convoluted and hard to maintain.
  * It provides a limited set of widgets.
  * It is hard to develop for, requiring a lot of boiler plate code.
  * It is not really script friendly.

While the public interface is nothing short of awful, the actual  
implementation of some of the widgets it not that bad.

Therefore, the general consensus is that it needs to be redesigned.  
While many have proposed using an OpenGL widget toolkit instead of  
our own, I do not see this as being practical:
  * It would add an extra dependency.
  * It would probably use its own font rendering system.
  * It would need to be skinned.

Consequently I believe it is best if we redesign the widget system  
from scratch. Any replacement system will need to fulfil the  
following criteria:
  * It needs to be able to emulate the current widgets in Warzone.
  * It needs to be simple to use, sacrificing functionality if need-be.
  * Resolution/size independent, so scaleable.

The design which I am proposing (hopefully) solves these problems.  
Broadly:
  * It uses an object oriented system based off of GObject, albeit  
heavily stripped down.
  * Drawing it done using cairo, thus providing vector drawing  
capabilities.
  * General design borrowed from Swing.
  * All widgets are containers and so can contain children.
  * Events are passed bottom-up, so if we clicked on a button the  
click event would pass: Form =>... => Button

I have some rough code outlines here, however would like to know what  
you all think first. Then I might be able do a basic implementation  
to develop further.

Regards, Freddie.

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

[Warzone-dev] [patch #1006] Dead Code Removal

[Freddie Witherden]

URL:
  

 Summary: Dead Code Removal
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Sunday 03/16/2008 at 11:09
Category: None
Priority: 3 - Low
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

Exactly what it says on the tin! I mean, err, title.

The code in question had been disabled since before the source was released.



___

File Attachments:


---
Date: Sunday 03/16/2008 at 11:09  Name: resourceNames.patch  Size: 7kB   By:
evilguru



___

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

[Warzone-dev] [patch #1004] Cleanup featureType

[Freddie Witherden]

URL:
  

 Summary: Cleanup featureType
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Saturday 03/15/2008 at 20:20
Category: None
Priority: 3 - Low
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: None

___

Details:

The attached patch contains a re-written version of the featureType function
in feature.c

I would be interested to know what you make of it before I commit.



___

File Attachments:


---
Date: Saturday 03/15/2008 at 20:20  Name: featureType.patch  Size: 2kB   By:
evilguru



___

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] Warzone Studio Proposal

[Freddie Witherden]

Hi,

> That still doesn't change the possibility of texpage muckups.  If i  
> create a mod you like, and you want to add my mod as a dependency  
> -- adding models that use my texpages -- then it's all well and  
> good until i get into warzone studio and add another image for the  
> software to push into the texpage -- when i do this, the texpage  
> may get rebuilt in a different way, and although my models will  
> have their own texpage filenames and coordinates mangled correctly  
> to match the new texpage, anyone who depends on my mod won't have  
> that same benefit, and they'll have to ask me for my studio file or  
> will have to retexture their model (though they'll probably be  
> lucky enough to only need to translate each mesh as a whole to a  
> new location).  Nonetheless, I believe that any kind of "automagic"  
> behavior, especially with this kind of individual images ->  
> composite texpage transparency leave the possibility of problems if  
> not added on the engine level.  I understand that it's unmanagable  
> to do anything along these lines in the engine unless caching is  
> involved. i'll be thinking about a way implement a cache with  
> reasonably well performing cache-invalidations.

Why would the model depend on texpage co-ordinates? Currently  
all .img files have names, for example:

0,0,36,148,11,0,0,"IMAGE PBAR REQUIRED"

A mod/model should know its textures not by their position on a  
specific texpage but more by their name. Thus, one has freedom to  
change and reorder texpages as they wish.

Regards, Freddie.


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

Re: [Warzone-dev] Warzone Studio Proposal

[Freddie Witherden]

Hi,

> this could, in large part, be mitigated by taking any concept of  
> texpage-tesselation out of the mod studio, and putting it straight  
> into the engine, thus as we work on warzone studio, at the same  
> time we work on a dynamic tesselator for the engine, which will  
> take a lot of small texpages (of arbitrary size), and combine (and  
> cache) them into composite though 1024x1024 (or larger) texpages.

I was speaking to Per about this one actually. He seemed quite  
certain that the current way we do it is better than doing it at run  
time. I believe we do it for runtime with map tile sets, and it does  
seemed to have increase load time somewhat. I am not so sure about  
the caching, however.

What does everyone else think? (Looks at Per.)

> at this time i would recommend either an extension to the pie  
> format supporting multiple texture images per model, or the  
> official switch to a new format. if this is decided upon, i will  
> soon be able to promise a bit of my time to do a lot of the legwork  
> for the mod side of things (converting existing models, breaking  
> apart texpages, etc).

I think Per is currently working on something to do with the PIE  
format, so I urge you to make a post about it directly.

Regards, Freddie.

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

[Warzone-dev] Warzone Studio Proposal

[Freddie Witherden]

Hi all,

Following on from what Per suggested a couple of weeks ago about a  
Warzone Studio I have formulated a _rough_ proposal for what such an  
application would accomplish:

1) Simplify the creation of IMG files and texture pages. This  
includes splitting up a set of texture pages into their individual  
images as well as recombining a set of images to form texture pages  
(+ .img file).

2) Handle the creation and editing of .wz files, including all of the  
nasty stuff that goes with them.

3) Integrate the pie => foo and foo => pie conversion tools along  
with model viewers.

4) Allow for simple stats editing, be it the CSV files, or SQLite  
database files.

5) Provide modders with a cross-platform application to facilitate  
the creation of mods. Be it code, utility files, the works.

But more importantly: what do you all think, what have I missed and  
who wants to help?

Regards, Freddie.

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

Re: [Warzone-dev] SQLite

[Freddie Witherden]

Hi,

> Then maybe XML (yes, they are bloated) using XPath to query the
> information? Implementing a database engine just to load some stats
> looks for me like breaking a butterfly on a wheel.

Modelling such data in XML would be a poor use of it. XML makes sense  
for reports (as you can XSLT it to XML:FO) and semantic data. There  
is very little semantic information carried in a weapon/body statistic.

That is not to say it can not be done, mind you.

XPath also has performance issues. A few months back I was writing an  
SVG font class which handled SVG font files (.xml). These files are  
~100kb with 3000+ elements (glyphs and kerns). Glyph searching was  
done using XPath. Even though the XPath implementation was in C it  
was still extremely slow to work out character widths. The  
performance is very much linear.

An SQLite database also makes a lot of sense as we implement a  
primitive form of inheritance. Lets say all of the games statistics  
are stored in base.db. We then load the mod foo.wz which provides  
foo.db.

What we can do is open up base.db and then attach foo.db to it  
(allowing both databases to be accessed using the same connection)  
then CREATE VIEW on a UNION of foo.stats and base.stats and boom. Our  
view, created at runtime now has all of the base statistics, plus  
those overridden by foo.wz.

Should be change the base stats there is no need to update foo.[db, wz].

Regards, Freddie.

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

Re: [Warzone-dev] SQLite

[Freddie Witherden]

Hi,

On Mon, 03 Mar 2008 13:38:26 +0100, Kamaze <[EMAIL PROTECTED]> wrote:
> Throw in: What about JSON?

JSON does not make a lot of sense for the stats; one of the advantages to
SQL is that it can be easily queried. Storing the stats in a JSON file
would simplify the parsing (compared to what we have now) but that is about
it. We would still need to convert the stats into our own internal
array-like format.

Regards, Freddie.


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

Re: [Warzone-dev] 2.1 beta 2

[Freddie Witherden]

Hi all,

> So please vote now, for or against release of 2.1_beta2 by the end  
> of the
> week.

So long as GLC works as expected under Windows, I am for it. If not  
it might be worth holding off a few more days until we can get  
something together.

On the netcode front everything is suspiciously quiet. I am yet to  
get a chance to test it on OS X (big endian). While I expect there to  
be a few (unforeseen) problems, they will most likely be minor things.

Regards, Freddie.

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

Re: [Warzone-dev] Starter application - The second try.

[Freddie Witherden]

Hi all.

On Tue, 29 Jan 2008 20:55:22 +0100, Kamaze <[EMAIL PROTECTED]> wrote:
> Hi there,
> 
> i mentioned this already quite a while ago and want to talk again about
> it. Ok, i think it would be good if we would had an starting application
> for warzone, where you can setup game settings like the resolution
> etc... and features for managing mods and maps. As well it would be
> easier to implement a game (lobby) browser, instead of touching the
> awful GUI code - from what i heard about it.

We already have a basic lobby browser and resolution configuration options
in the current SVN version.

> My idea was to implement this application via wxWidgets and transfer the
> data from this application via a socket at startup. That means, the
> starter starts warzone with the "-extern" flag, warzone fires up, opens
> a local socket and the starter transfers all needed data trough it.
> (Instead of implementing it via long cmd switches)

I think that the time could be better spent working on improving the
in-game GUI code (we are missing a few widgets here and there). Then using
this we could add a mod switcher/loader to the game. From a user experience
perspective it is easier (and more the 'norm') to have a mod switcher in
game. In my experience (I haave not been a gamer for many years now) very
few to no commerical games use a started application to select mods.

I do, however, think there is a need/requirement for an external lobby
browser application. As a lot of people prefer external applications for
such a purpose as opposed to the built in browser. Just a thought.

Regards, Freddie.


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

Re: [Warzone-dev] Netcode Update

[Freddie Witherden]

> Here's to hoping that the Mac version can play along. :)

That is the plan. I have an PPC G4 iBook that I can test with and so when
all of the old-style netcode calls have been eliminated all should work.

Regards, Freddie.


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

[Warzone-dev] Netcode Update

[Freddie Witherden]

Hi all; hopefully this will be the last ever netcode update as the  
porting process is nearing completion.

Over the last week several important functions have been ported over,  
with all the remaining being a few one-liners in multiplay.c and  
multiinit.c along with the text message, beacon and colour/alliance  
code.

So far as workload goes me and Buggy should be able to deal with the  
remaining files over the next week or so, however they are minor,  
easy to test, changes.

As soon as it is all done I suggest we have a week of intensive  
testing of the netcode. Between us we have all of the valid hardware  
combinations for Warzone, so should be able to test it to death. 8  
player games are the ones which seem to be the most troublesome so  
think that we should focus on them.

As usual I am open to suggestions, but so far as the netcode goes  
things are going *very* well.

Regards, Freddie.

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

Re: [Warzone-dev] Proposal regarding automatic pausing on loss of focus

[Freddie Witherden]

> it mac osx, you do have a terminal... that gives you command-line
> capabilities right up there with any other unix.  besides which, svn
> already has what you ask for: you can change the resolution and fullscreen
> settings which take effect on the next program run.
While it does have a terminal Apple do not support launching GUI applications 
from the command line. And often it can be the cause of a lot of strange 
bugs/errors. The only real way to do it (in my experience) has to use Xcode 
to launch it.

Regards, Freddie.


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] [patch #913] Port multiplay.c over to the new netcode API

[Freddie Witherden]

URL:
  

 Summary: Port multiplay.c over to the new netcode API
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Thursday 01/03/2008 at 13:23
Category: Feature
Priority: 7 - High
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Here is what I have done so far of multiplay.c. This is one of the harder
files to do so I may need help with some of it.



___

File Attachments:


---
Date: Thursday 01/03/2008 at 13:23  Name: multiplayresearch.patch  Size: 4kB 
 By: evilguru



___

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

[Warzone-dev] [patch #910] Port multiopt over to the new netcode API

[Freddie Witherden]

URL:
  

 Summary: Port multiopt over to the new netcode API
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Tuesday 01/01/2008 at 00:54
Category: Fix
Priority: 7 - High
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Attached is what I have done so far so far as porting multiopt.c goes. It is
a particularly nasty file as it requires some changes all over the place.



___

File Attachments:


---
Date: Tuesday 01/01/2008 at 00:54  Name: multioptoptions.patch  Size: 13kB  
By: evilguru



___

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

[Warzone-dev] Netcode Update #2

[Freddie Witherden]

Hi all. Well the netcode has progressed in leaps and bounds since I  
my last update. Several parts have been ported over (including the  
majority of multibot.c, thanks to Giel!) and several tweaks to  
multisync.c by per and I.

Currently the biggest issue with the netcode is droids randomly being  
destroyed for what seems to be no apparent reason. No one so far has  
been able to work out why. I think it may come down to using the  
backtrace functionality that glibc provides (along with its symbol  
resolution capabilities) inside the droidDestroy function (droid.c)  
to see if any netcode functions appear in the trace.

So long as the droids being destroyed is a direct result of a netcode  
packet this should work. If, however, it is a in-direct effect then I  
am unsure about what we should do.

The only file that really needs porting is multiplay.c -- it has  
several netcode functions. I can clean up the others myself (expect  
patches for them soon).

In a weeks time I firmly believe that we will have cross-platform  
netcode. And if Ari has been able to get QuesoGLC working on OS X  
(best of luck!) I look forward to playing you all from my laptop.

Regards, Freddie.

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

[Warzone-dev] Netcode Status Report

[Freddie Witherden]

Hi all. Those of you who track the commit log or IRC will know that  
the netcode is slowly finding its way into trunk!

At this time the following files are complete:
- multistruct.c
- multigifts.c
- small parts of multiplay.c

With several more waiting in the patch tracker. Over the next couple  
of days I would like to clear as much of the backlog as possible so  
that we may begin porting the remainder of the code and more  
importantly testing it.

The sooner we do this the sooner we can start to work on the fun stuff.

Therefore I am asking anyone who can apply and split up a diff file  
to take a file that has not been completed/posted on the patch  
tracker and break down the functions in it so that it may be applied  
piece-by-piece.

Regards, Freddie.

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

Re: [Warzone-dev] Replacing the scripting language?

[Freddie Witherden]

Hi all,

> Please tell me what you think about switching to Lua as our scripting
> language.

I am an all-in or all-out kind of guy. Duplication is not a good  
friend of mine. I like the idea of using lua, it would serve to  
reduce the barrier-of-entry to modding/scripting Warzone (a lot of  
commercial games use it) and require less maintenance on our part.

I think this point is important as the only one who I would trust to  
edit the scripting language is Troman, who knows it like the back of  
his hand.

One of the things we have been criticised for in the past is breaking  
backwards compatibility -- there is a lot of good stuff from the 1.10  
days that is currently succumbing to bit-rot on Kim's hard disk. So I  
am for switching to lua if an automated converter can be devised (and  
am willing to help -- sounds interesting).

This way:
* We retain backwards compatibility, when repackaging a mod in .wz  
format they can run the converter at the same time.
* We allow people who do not like lua/are not familiar with it to  
work with the classic scripting language.
* We get all of the benefits of lua, such as reduced maintenance and  
a wider user base.

What does everyone else think about creating a branch for this  
endeavour? That way we can track progress and test easily.

Regards, Freddie.

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

[Warzone-dev] [patch #906] Links Droid Speed To Experience

[Freddie Witherden]

URL:
  

 Summary: Links Droid Speed To Experience
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Tuesday 12/25/2007 at 22:32
Category: Feature
Priority: 3 - Low
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This patch makes it so that the speed of a droid is now linked to its
experience, with more experienced droids being a little bit faster.



___

File Attachments:


---
Date: Tuesday 12/25/2007 at 22:32  Name: expspeed.patch  Size: 4kB   By:
evilguru



___

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

[Warzone-dev] [patch #901] Move multisync.c over to the new API

[Freddie Witherden]

URL:
  

 Summary: Move multisync.c over to the new API
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Monday 12/24/2007 at 19:22
Category: Fix
Priority: 6
  Status: In Progress
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

I have begun splitting up my large monolithic netcode API patch into smaller
chunks. Here attached are the functions of multisync.c which I have done thus
far.



___

File Attachments:


---
Date: Monday 12/24/2007 at 19:22  Name: multisyncdroid.patch  Size: 13kB  
By: evilguru



___

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

[Warzone-dev] [patch #894] Makes numKills A float

[Freddie Witherden]

URL:
  

 Summary: Makes numKills A float
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Saturday 12/22/2007 at 14:41
Category: Fix
Priority: 4
  Status: Works For Me
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

In order to fix a few problems with the new experience system (which only
showed themselves when the quality factor code was committed)
psDroid->numKills is now a floating point variable.

The patch makes a point of not touching any of the save-game code --- the
float is silently converted to a integer on save and back again to a float on
load. While this does mean that the droids numKills is rounded on save a
maximum of 0.... kills is lost (assuming that float => int rounds down).



___

File Attachments:


---
Date: Saturday 12/22/2007 at 14:41  Name: floatPartialKills.patch  Size: 16kB
  By: evilguru



___

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

[Warzone-dev] [patch #888] Netcode: multigifts.c

[Freddie Witherden]

URL:
  

 Summary: Netcode: multigifts.c 
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Tuesday 12/18/2007 at 20:41
Category: Fix
Priority: 7 - High
  Status: Ready For Test
 Privacy: Public
 Assigned to: per
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This is multigifts.c (+ other changes needed) from the netcode branch.
Updated to compile under TRUNK.



___

File Attachments:


---
Date: Tuesday 12/18/2007 at 20:41  Name: multigifts.patch  Size: 34kB   By:
evilguru



___

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] Stomping the new netcode into WZ

[Freddie Witherden]

> My experience is that just committing something to trunk is the easiest
and
> quickest way to test changes.
> Why not commit the entire patch this weekeind and have every developer
run
> the game in a debugger and play a few games? I suppose we can catch all
> bugs in a few hours then. We can always revert if it does not work out.

One or more of the function pairs in the patch are bad (ie, do not work).
Over the summer me and Per did have a go at tracking some of these down but
did not get very far.

So second time around I feel it is best if we commit it in small chunks (so
called function pairs) so that we can quickly identify broken functions
with little effort.

I am not so sure about comitting it into trunk - as in its current state it
*will* break the netcode.

Regards, Freddie.


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

Re: [Warzone-dev] Update on Mac OS X port

[Freddie Witherden]

> I managed to get the Xcode project to build QuesoGLC and Popt and add
> them to Warzone.

Excellent news!

> However, Warzone currently won't build because some
> game structures have been changed and the endian_*() calls made it so
> little-endian developers didn't notice that they had to change these
> things.

Luckily per is re-writing the save-game format so it should not be  
that much of a problem. I will however see if I can take a look at  
some of these problem functions.

Regards, Freddie.


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

[Warzone-dev] [patch #881] Update BASE_OBJECT to use Vectors

[Freddie Witherden]

URL:
  

 Summary: Update BASE_OBJECT to use Vectors
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Monday 12/10/2007 at 20:48
Category: None
Priority: 5 - Normal
  Status: In Progress
 Privacy: Public
 Assigned to: evilguru
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This replaces the x,y,z variables in BASE_OBJECT replacing them with a
Vector3i allowing the Vector functions to be used natively.

It still needs a lot more testing to ensure that it did not break anything.



___

File Attachments:


---
Date: Monday 12/10/2007 at 20:48  Name: vector.patch  Size: 253kB   By:
evilguru



___

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

[Warzone-dev] [patch #877] Remove + Update Energy Bars

[Freddie Witherden]

URL:
  

 Summary: Remove + Update Energy Bars
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Saturday 12/08/2007 at 19:59
Category: Feature
Priority: 3 - Low
  Status: Works For Me
 Privacy: Public
 Assigned to: evilguru
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

This patch removes the various energy bar types and replaces them with the
default. (I do not think anyone uses the alternative types/knows of their
existence and they were not that helpful either).

In addition the seemingly unused ability to remove/hide loading bars for
selected units has been removed. Its function is now a no-op (so to not break
key mappings).

Finally the key which the energy bar type toggle was bound to now changes
when energy bars are displayed. The default is the same as usual - for
selected units. But by pressing F9 by default one can change this to:
 * Default, same as usual
 * Always visible for your units
 * Always visible for your units and non-wall piece structures

I am also considering making it possible to see enemies/allies HP bars (you
currently need to mouse over and hold down the right mouse button to do so).



___

File Attachments:


---
Date: Saturday 12/08/2007 at 19:59  Name: energyBars.patch  Size: 10kB   By:
evilguru



___

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

[Warzone-dev] [patch #866] Adds A Video Options Menu

[Freddie Witherden]

URL:
  

 Summary: Adds A Video Options Menu
 Project: Warzone Resurrection Project
Submitted by: evilguru
Submitted on: Saturday 12/01/2007 at 16:24
Category: Feature
Priority: 1 - Later
  Status: In Progress
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Allows one to configure video options (such as fullscreen, cursor trap,
resolution &c) from the games GUI. Still a lot of work to be done as it does
not currently work.



___

File Attachments:


---
Date: Saturday 12/01/2007 at 16:24  Name: graphics.patch  Size: 7kB   By:
evilguru



___

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