x86_64 patch

[pseudonym404]

I just can't understand using a non-free compiler on a platform where gcc is available (mind you, I can't understand using a non-free platform when there's free platforms available either)

I'd completely agree with Consistency is Goodâ„¢ of course

Anyway, slightly neater version of my loadfx/savefx patch attached (as an svn diff)

[Giel]

I just can't understand using a non-free compiler on a platform where gcc is available

Neither can I. Especially not when GCC has proven to be the better of the non-free compiler.

mind you, I can't understand using a non-free platform when there's free platforms available either

Believe me, you'll learn to understand that when you've got people (read "teachers") (litterally) cursing at you and declaring you mad because you're not using the holy & mighty newest version of whinersâ„¢ from microknowledgeâ„¢. Especially when these teachers judge your papers on the fact that you're not using font X from the before mentioned brand.

[pseudonym404]

Believe me, you'll learn to understand that when you've got people (read "teachers") (litterally) cursing at you and declaring you mad because you're not using the holy & mighty newest version of whinersâ„¢ from microknowledgeâ„¢. Especially when these teachers judge your papers on the fact that you're not using font X from the before mentioned brand.

Ah yes, the fun of hoop jumping. Never been a favourite passtime

Oddly enough, I've never run into the font thing myself, although did have to install msttcorefonts on my sisters computer (running Kubuntu) so she could use the required font (and point size!) for her essays for her art degree..

I could rant for hours on this stuff, so I won't

[pseudonym404]

And a small patch to work around asWeaps[n] still being set for IDES_SYSTEM turrets when numWeaps == 0
Stops segfaults when hovering over a different propulsion type button than currently selected for an existing non-weapons turret

Also stops system turrets being 'forgotten' when changing propulsion type on an existing design (effectively reverses the current behaviour of intCheckValidWeaponForProp considering all existing system turrets invalid for all propulsion types)

[Per]

I disagree. Not having to browse to the top of the function to see what type a variable is when you see it first used is a luxury IMO. Also the knowledge that the variable didn't exist before a certain line is nice to know, because that tells you it can't have undergone changes before that line/statement.

But when you find a variable that you do not know the definition of, at least you know where to find its definition. In the define-whereever-you-want style, the definition could be at any line above the one you happen to be reading.

[Giel]

Anyway, slightly neater version of my loadfx/savefx patch attached (as an svn diff)

Well, while looking at that code I found that most of the code in there was a bit of a mess (i.e. the original code before applying your patch). So instead I just rewrote those functions in a 64bit safe manner, and somewhat cleaner (I hope ).

Thanks for drawing my attention to those functions though .

But when you find a variable that you do not know the definition of, at least you know where to find its definition. In the define-whereever-you-want style, the definition could be at any line above the one you happen to be reading.

In short: both styles have their advantages and disadvantages.

[pseudonym404]

Well, while looking at that code I found that most of the code in there was a bit of a mess (i.e. the original code before applying your patch). So instead I just rewrote those functions in a 64bit safe manner, and somewhat cleaner (I hope ).

looks better to me

Although, in lib/framework/frame.h, couldn't
uint32_t writeValue = *(uint32_t*)&val;
simply be
uint32_t writeValue = (uint32_t)val;
to avoid "frame.h:235: warning: dereferencing type-punned pointer will break strict-aliasing rules"?

This is one of the "ambiguous cases that are safe" that -Wstrict-aliasing=2 (enabled by -fstrict-aliasing, which is enabled by -O2) warns about of course

[Giel]

Although, in lib/framework/frame.h, couldn't
uint32_t writeValue = *(uint32_t*)&val;
simply be
uint32_t writeValue = (uint32_t)val;
to avoid "frame.h:235: warning: dereferencing type-punned pointer will break strict-aliasing rules"?

Nope, it needs to be cast through a pointer to make sure I don't get a conversion from a float to uint32_t, instead I need a reinterpretation of the bits. Which AFAIK can only be achieved by pointer casting. So instead I've added a void cast:

Code: Select all

	uint32_t writeValue = *(uint32_t*)(void*)&val;

Applied in r2379.

This is one of the "ambiguous cases that are safe" that -Wstrict-aliasing=2 (enabled by -fstrict-aliasing, which is enabled by -O2) warns about of course

Thanks that helped in triggering the warning myself.

[pseudonym404]

Another animobj/hashtabl patch (hopefully better)

lib/gamelib/hashtabl.[c,h] are only used by lib/gamelib/animobj.c, which passes an object pointer and an additional id.
hashtable functions changed to accept a pointer and an integer rather than two integers, replaced hashing functions with crc16 hashing function, on the basis that it'll work on any pointer and integer, regardless of table size (and I had it lying around).

I can't think of a system where (sizeof(void*) + sizeof(int)) % 4 != 0, but maybe add an assert anyway..

[Giel]

And a small patch to work around asWeaps[n] still being set for IDES_SYSTEM turrets when numWeaps == 0
Stops segfaults when hovering over a different propulsion type button than currently selected for an existing non-weapons turret

Also stops system turrets being 'forgotten' when changing propulsion type on an existing design (effectively reverses the current behaviour of intCheckValidWeaponForProp considering all existing system turrets invalid for all propulsion types)

Applied in r2397.

[pseudonym404]

Some minor warning cleanups.

adding *.tab.c to BUILD_SOURCES and CLEANFILES before *.tab.h in applicable Makefile.am files causes *.tab.c to be the file that triggers the %.tab.h %.tab.c: %.y rule, resulting in the command run being "bison -y  -d -o[...].tab.c [...].y", not "bison -y  -d -o[...].tab.h [...].y", which (aside from being correct syntax ) stops "warning: conflicting outputs to file `[...].tab.h'"

chat_parser.y had %token _T_A declared twice, second instance removed

audp_parser.y had trailing | signs (presumably from when NULL wasn't commented out)

[pseudonym404]

Oh, and (about as trivial as it gets ) gettext warnings "file `data/mp/messages/strings/*.txt' extension `txt' is unknown; will try C" can be suppressed by specifying the language (-LC) as in the attached patch.

[HansdeGoede]

Hi all,

First a quick intro I'm a Linux enthousiast / developer. I'm lately mainly active as a contributer to the Fedora Linux dsitribution (where I maintain 150+ packages) and writing hw-monitoring kernel drivers. Of those 150 packages about half are games (of which some were ported to Linux by myself).

On a users request I've started looking into making warzone 64 bit safe. Stupidly enough I started out with 2.0.7, as taking the -m32 stuff in ./configure into account I thought that you (upstream) had kinda abandoned 64 bit. Luckily after only 3 hours of work  I hit the big script problem (which you seem to have nicely fixed) and then I did a (second) more thorough google search on warzone and 64 bit and found this thread.

I have plenty experience with making things work on 64 bit. Although most things were easier then warzone, the only thing I did which was about this hard was getting Glide, the hardware abstraction layer for 3DFx Voodoo cards (remember those) run on 64 bit (yes I've used a voodoo 2 in my x86_64 for a while).

So if there is an area I can help in let me know, also I wonder what the status is, I've read the entire Forum thread, but still a status update would be nice, reading this thread I get the impression that things are almost done / finished.

Regards,

Hans

[HansdeGoede]

looks better to me

Although, in lib/framework/frame.h, couldn't
uint32_t writeValue = *(uint32_t*)&val;
simply be
uint32_t writeValue = (uint32_t)val;
to avoid "frame.h:235: warning: dereferencing type-punned pointer will break strict-aliasing rules"?

This is one of the "ambiguous cases that are safe" that -Wstrict-aliasing=2 (enabled by -fstrict-aliasing, which is enabled by -O2) warns about of course

Actually

Code: Select all

	uint32_t writeValue = *(uint32_t*)&val;

Is not one of the "ambiguous cases that are safe", I've seen code doing this (taking the content of memory with a float type as int without conversion), using the same take address, cast pointer, dereference approach break with (very) recent versions of gcc.

Usually it went like this:
I receive a bug: app foo misbehaves in way bar
Hmm, foo is an app I maintain in Fedora, so I'm responsible for fixing this
Can I reproduce? -> Yes
What do the compiler warnings say. Hmm, deref. type-punned pointer will break strict-aliasing rules warnings, lets build it with -fno-strict-aliasing
Hey its gone now
Fix those warnings, hey look they are doing: take float address, cast pointer to int pointer, dereference
Now works if build without fno-strict-aliasing too.

I've seen this several times already.

The proper way todo this is:

Code: Select all

void funcfoo(float float_in)
{
   union {
      float f;
      int i;
   } u;
   int should_get_mem_contents_of_float_in;
   u.f = float_in;
   should_get_mem_contents_of_float_in = u.i;

  /* ......
     .....
     ...... */
}

Not pretty but this will _always_ compile correctly as you are now telling the compiler _exactly_ what you want, you want to treat one memory location in 2 totally different ways.

Regards,

Hans

[lav_coyote25]

your best bet is to go here - https://gna.org/projects/warzone/


mailing lists are kept up to date.  combination of the forums and this site - should get you up to speed quickly.