Re: campaign game fails to start in 24881 ** FOUND **

[keybounce]

Here you go

Code: [Select]

Index: src/common/scripts.c
===================================================================
--- src/common/scripts.c (revision 24881)
+++ src/common/scripts.c (working copy)
@@ -245,11 +245,12 @@
  *writtenBytes = ALIGN_NOTHING(0);
  break;
 
+
  case V_BOOL:
  if (!strcmp(token, "true") || *token == '1')
- *b = qtrue;
+ *(int *)b = qtrue;
  else if (!strcmp(token, "false") || *token == '0')
- *b = qfalse;
+ *(int *)b = qfalse;
  else {
  snprintf(parseErrorMessage, sizeof(parseErrorMessage), "Illegal bool statement '%s'", token);
  return RESULT_ERROR;



I do not know where to submit it to besides here.

[Mattn]

well - that's not really a fix - even if it works for you. the problem is the alignment here. variables are 4 byte aligned on a mac. that's why a qboolean is 4 byte on a mac in ufo - not 1 byte (afair - never really got a mac under my fingers). and the assignment seems to suffer from endian issues in the way we are dealing with it (though i don't see why at the moment, as we are writing the first byte and we only access the first byte when we query the variable from some struct. it would be nice to know whether the alignment works on your system.

[Mattn]

missed something - the alignment is done in Com_AlignPtr. The interesting part is at the top of scripts.h and ALIGN_NOTHING in scripts.c - maybe change ALIGN_NOTHING to ALIGN (should come with the mac headers) in the parsing functions.

[bayo]

Hi. i dont know if it's an alignement problem, anyway, a cast here is need. In r24889  i patch it with a qboolean.

Anyway, nice catch, it is hard to found. I hope it will work.

We must call Com_AlignPtr before Com_ParseValue when the use a buffer (when we dont use a buffer (ie. an attribute adress) the adress is already right) else we will have align problem.

About, ALIGN_NOTHING, it is the old code i rename ALIGN_NOTHING, while we are not sure everything work well with PPC. We should remove it, if every thing work again, because align must be set before (according to the data type we want to align), and not after (we dont know what we must align).

[keybounce]

well - that's not really a fix - even if it works for you. the problem is the alignment here. variables are 4 byte aligned on a mac. that's why a qboolean is 4 byte on a mac in ufo - not 1 byte (afair - never really got a mac under my fingers). and the assignment seems to suffer from endian issues in the way we are dealing with it (though i don't see why at the moment, as we are writing the first byte and we only access the first byte when we query the variable from some struct. it would be nice to know whether the alignment works on your system.

As far as I can tell, it is a 4 byte item on the mac (I could run a sizeof on it to be sure).

When I accessed it by casting the pointer to an int *, instead of a byte *, I got the proper value. It looks like it really is being read as a 4 byte int normally, on the mac.

Yes, it does look like an endian issue -- on one machine, the lowest byte is where the pointer is, on the other machine, the lowest byte is at the other end. By forcing all reads/writes to use a full int, you get consistent results on both machines, although the address that changes between 0 and 1 differs.

[Mattn]

is it fixed in current trunk?

[keybounce]

Confirmed as working on G4 in trunk rev 24913