Homesource Forums

Homeworld Source Editing Talk
It is currently Wed Aug 27, 2014 6:06 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 32 posts ] 
Author Message
 Post subject: gcc v4 code change
PostPosted: Thu Nov 16, 2006 12:03 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi,

I've uploaded changes to the following files:
Quote:
M Linux/INSTALL
M src/SDL/font.c
M src/SDL/texreg.c
M src/SDL/Queue.c
M src/rgl/asm.c
M src/Game/KNITransform.c
M src/Game/StatScript.c
M src/Game/NIS.c
M src/Game/FEFlow.c
M src/Game/Task.c
M src/Game/ETG.c
M src/Game/Mesh.c
M src/Game/MeshAnim.c
M src/Generated/Makefile.am
to allow the code to compile on linux using gcc v4.
I've had to make cosmetic changes to some lines of code due to the more stringent rules of the compiler, most of which are along the lines of
Code:
(ubyte *)newHeader->objPath += (udword)newHeader;

replaced with
Code:
newHeader->objPath = (udword)newHeader + (ubyte*)newHeader->objPath;

Personally I don't think that this'll cause a problem with any other compilers, but if it does the sooner someone lets me know the sooner it can be removed from svn. I'll have to work on using #IFDEFs if that's the case.

Also I've left in the -fwritable-strings in the Makefile.am in src/Generated but if anyone can try removing this and seeing if they have a problem with compiling or running the game then please let me know.


Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 12:33 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Great work Aunxx.

Compiled and worked for me.

Game is launching, seems to work. Now, we need to correct the code that the removable of -fwritable-strings broke.

I will try to look at this, as the rest of the work has been done by aunxx :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 4:16 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Cheers.

Good to know it works for other people too. :)

From what I know, attempting to write to strings when it's not enabled (not using -fwritable-strings in gcc v4) causes a segfault, or some other noticable error. I cannot find any indication of a problem so I'm hoping that someone will find a fault and then I/we can find where it originates. Ideally it's just legacy code and can be safely removed. :)

Aunxx.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 5:08 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Yes, it leads to segfault here too.

Actually, I am investigating from where it could comes from.
I have some clue, but don't really have time now to post it. I will do that later ;)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 5:35 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Ahh.

I couldn't get it to fail at all.

Could you post where the game crashes when you get chance and I'll see if I can re-create it?

Cheers,
Aunxx.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 6:17 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
I'm having the segfault when trying to launch the training. It's segfaulting after the loading screen.

But I have tried to start the campaign and it works. Strange. I wonder why it segfaulting in one case and not in the other...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 16, 2006 8:08 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
It's because of this piece of crap:

Tutor.c L1044 wrote:
Code:
char *tutGetNextTextLine(char *pDest, char *pString, long Width)

which takes a string (pString) and the Width of the area that the rendering of that string will be constrained by. It then steps through the string a char at a time. Once it encounters a word terminator (space or newline), it zaps that char with a '\0' in place in order to generate a NULL-terminated string it can then pass to fontWidth(), which calculates the string's rendered width. :shock: It keeps doing this until the parsed string would be more than Width, at which point it copies the parsed string into a buffer (pDest) which ultimately gets rendered.

Now what it should do is copy directly into pDest (bounds-checked obviously) and pass that NULL-terminated string to fontWidth() instead so that the original remains untouched. Doing it this way does mean that the return value (the end location of the parsed string so the function can be called again continuing where it left off) has to be calculated in a slightly different way.

I found this by following through the code so it's possible that there are other instances similar to this...

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject: Doh!
PostPosted: Fri Nov 17, 2006 11:33 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
You know, it never occurred to me to test the tutorial. :(
I picked several missions including cut scenes, started the game from scratch, traded with the Bentusi (Still think that the ION technology is a good deal!).
Switched resolution from high (1280x1024) to low (640,480) to try and get some kind of error I could work with, but no, it's the blooming tutorial. :)

I'll have a look this weekend unless someone else is already working on it.

Apart from this do the changes I made still compile on the other platforms? I'm trying to sort out a build environment on a Windoze machine, but I'm not quite at home on MS as Linux. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 17, 2006 7:03 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

Well this seems to fix the tutorial so it runs, but it's not the most elegant piece of code I've ever added. :)
Code:
Index: src/Game/Tutor.c
===================================================================
--- src/Game/Tutor.c    (revision 272)
+++ src/Game/Tutor.c    (working copy)
@@ -1047,17 +1047,21 @@
 char    *pstr;
 long    Done = FALSE;
 char    temp;
+char   writable_string_space[120];    //Arbitrary size whilst I test this.
 
     StringLen = 0;
     WordLen = 0;
     *pDest = 0;
 
-    if(pString[0] == 0)
+    strncpy(writable_string_space, pString, 119);
+    writable_string_space[120] = 0;
+
+    if(writable_string_space[0] == 0)
         return NULL;
 
     do {
         // Skip leading whitespace
-        pstr = &pString[StringLen];
+        pstr = &writable_string_space[StringLen];
         while( *pstr && *pstr != '\n' && (*pstr == '-' || tutIsspace(*pstr)) )
         {
             WordLen++;
@@ -1074,7 +1078,7 @@
 
             temp = *pstr;
             *pstr = 0;
-            if(fontWidth(pString) > Width)
+            if(fontWidth(writable_string_space) > Width)
                 Done = TRUE;
             else
             {

I tested this and gave up on the tutorial at lesson 5 but it all seemed okay. Tried it at a few resolutions, and I hope that there aren't any lines longer than 119 characters. :)
I'll commit this later unless there's a flaw in it I've missed or it'll break too much.
I've tested the change on a gcc v3 build whilst not using -fwritable-strings as well and it works. :)

Thank you lmop for for finding the offending code. I've used a temp variable to test the theory, but I'll probably re-write it with a bit more sanity checking before I commit anything.

Almost out of Whisky, so time for bed I think. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 17, 2006 8:18 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
I think a more efficient way of doing this would be to:

1) pass the pDest buffer size in as one of the parameters; as it happens, 256 in its use-cases: Line[256] in both tutDrawTextFunction() and tutShowText()

2) strchr to see if you have an embedded \n, indicating multiple substrings

3) strncpy the \n or \0 -terminated line into pDest and reset the last char to \0 if necessary

4) while(strlen(pDest) > Width), work your way backwards from the end of the string in pDest, looking for spaces and \0 them as you go

This algorithm should be faster since if the original length of the string (3) is shorter than what the rendered width allows then no char-iteration needs to be done at all. If the string is longer than the maximum width it is more likely to have an overrun shorter than the maximum width so you have less string to iterate over before finding the substring of the required length.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 18, 2006 12:35 am 
Offline
coder
User avatar

Joined: Wed Oct 04, 2006 8:13 pm
Posts: 92
Location: UTC -0500
Quote:
"aunxx: Apart from this do the changes I made still compile on the other platforms? I'm trying to sort out a build environment on a Windoze machine"


yes it compiles on win32*1, but I can't say much, and i quote from windows/building.txt
"However, aaron has successfully compiled and played HWSDL-win32 revision 44 (and up to rev80 something).
nova has only compiled HWSDL, he hasn't gotten it so far as to load into the menu."

*1: it compiles, but with some new vc7/8 warnings:
Code:
j:\src\hwsdl\src\Game\NIS.c(4776): warning C4133: '=' : incompatible types - from 'ubyte *' to 'camerapath *'
j:\src\hwsdl\src\SDL\font.c(852): warning C4133: '=' : incompatible types - from 'ubyte *' to 'charheader *'
j:\src\hwsdl\src\SDL\texreg.c(1726): warning C4133: '=' : incompatible types - from 'ubyte *' to 'color *'
j:\src\hwsdl\src\Game\MeshAnim.c(126): warning C4133: '=' : incompatible types - from 'ubyte *' to 'madobjpath *'
j:\src\hwsdl\src\Game\Mesh.c(785): warning C4133: '=' : incompatible types - from 'ubyte *' to 'normalentry *'
j:\src\hwsdl\src\Game\Mesh.c(786): warning C4133: '=' : incompatible types - from 'ubyte *' to 'polyentry *'
j:\src\hwsdl\src\Game\Mesh.c(789): warning C4133: '=' : incompatible types - from 'ubyte *' to 'polygonobject *'
j:\src\hwsdl\src\Game\Mesh.c(793): warning C4133: '=' : incompatible types - from 'ubyte *' to 'polygonobject *'
j:\src\hwsdl\src\Game\Mesh.c(797): warning C4133: '=' : incompatible types - from 'ubyte *' to 'polygonobject *'
j:\src\hwsdl\src\Game\NIS.c(4632): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\Game\NIS.c(4635): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\Game\NIS.c(4790): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\Game\NIS.c(4796): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\Game\MeshAnim.c(139): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\Game\MeshAnim.c(146): warning C4133: '=' : incompatible types - from 'ubyte *' to 'real32 *'
j:\src\hwsdl\src\SDL\texreg.c(2837): warning C4133: '=' : incompatible types - from 'ubyte *' to 'sdword *'
j:\src\hwsdl\src\Game\NIS.c(4602): warning C4133: '=' : incompatible types - from 'ubyte *' to 'spaceobjpath *'
j:\src\hwsdl\src\Game\FEFlow.c(1827): warning C4133: '=' : incompatible types - from 'ubyte *' to 'tagfeatom *'
j:\src\hwsdl\src\Game\FEFlow.c(1826): warning C4133: '=' : incompatible types - from 'ubyte *' to 'tagfelink *'
j:\src\hwsdl\src\Game\NIS.c(4631): warning C4133: '=' : incompatible types - from 'ubyte *' to 'tcb *'
j:\src\hwsdl\src\Game\NIS.c(4789): warning C4133: '=' : incompatible types - from 'ubyte *' to 'tcb *'
j:\src\hwsdl\src\Game\MeshAnim.c(140): warning C4133: '=' : incompatible types - from 'ubyte *' to 'tcb *'
j:\src\hwsdl\src\Game\Mesh.c(784): warning C4133: '=' : incompatible types - from 'ubyte *' to 'vertexentry *'


i still do crash at the same spot as with previous revisions.
For the record, i just made a short post on where i crash: http://homesource.nekomimicon.net/sourc ... .php?t=121

_________________
http://againsttcpa.com/what-is-tcpa.html
http://google.com/search?q=c+programming+faq
http://research.att.com/~bs
acronyms.ch, neworder.box.sk


Top
 Profile  
 
 Post subject: Nova
PostPosted: Sat Nov 18, 2006 8:23 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

I get similar errors about the pointer types when compiling the Linux binary.
Just taking the first example:
Quote:
it compiles, but with some new vc7/8 warnings:
Code:
j:\src\hwsdl\src\Game\NIS.c(4776): warning C4133: '=' : incompatible types - from 'ubyte *' to 'camerapath *'


is fixed by this:
Code:
-    newHeader->cameraPath = (udword)newHeader + (ubyte *)newHeader->cameraPath;    //fixup the object motion path array
+    newHeader->cameraPath = (camerapath *)((udword)newHeader + (ubyte *)newHeader->cameraPath);    //fixup the object motion path array

I'll go through the list of errors you supplied and tidy up the changes I made. :)

Aunxx


Top
 Profile  
 
 Post subject: lmop
PostPosted: Sat Nov 18, 2006 9:48 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

Quote:
1) pass the pDest buffer size in as one of the parameters; as it happens, 256 in its use-cases: Line[256] in both tutDrawTextFunction() and tutShowText()
2) strchr to see if you have an embedded \n, indicating multiple substrings
3) strncpy the \n or \0 -terminated line into pDest and reset the last char to \0 if necessary
4) while(strlen(pDest) > Width), work your way backwards from the end of the string in pDest, looking for spaces and \0 them as you go

1) Done.
2) Done.
3) Done.
4) Not sure about this. I agree in principle, but wouldn't this allow any space characters on the front of the string to be displayed? Do we need to identify the type of character we're pointing to in pString and make sure that it's not a whitespace or \n character before returning it?
Shall we leave the single character processing in place for this as it's not that time sensistive?

Mostly done, but having a few inconsistencies with the english and the french showing up on the tutorial page. :(

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 20, 2006 8:07 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Mornin'

Well, I ammended, chopped, changed and totally managed to stop the tutorial displaying any text at all. :(

I found that there were things happening I couldn't understand why, so I reverted most of what I'd done and started again.

Long story short is that it's mostly as it was processing the text one character at a time, but I trust this to show what it's supposed to and not be selectively discarding the end of a string.

Homeworld should now compile using gcc 3.3+ and 4.x and run correctly using either. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 20, 2006 10:19 am 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
aunxx wrote:
Mornin'


Mornin' Ralph

aunxx wrote:
Homeworld should now compile using gcc 3.3+ and 4.x and run correctly using either. :)


Unfortunately you broke sound event tracking so that the soundtrack for the single-player start NIS goes on and on and on even if you abort the sequence via spacebar or escape key and go directly to the starting play.... it's kinda weird to hear the Mothership drives ramping up in the Scaffold while you're busy destroying drones :)

Also, my visually-enabled family members assure me that ship explosions are AWOL too ...


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 20, 2006 10:37 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
:)

K. I'll have a look when I get some time. The explosions are still there in v3 so it's gotta be something i missed. :(

I guess it'll be to do with the casts, so I'll sort those first. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 21, 2006 1:29 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Well, I still have a segfault when launching the tutorial. I am back from weekend and I will try to find out from where it comes... :(


Top
 Profile  
 
 Post subject: Update
PostPosted: Wed Nov 22, 2006 12:17 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

I'm surprised that the Tutorial isn't working for you as I thought it was fixed. :(

I'm trying to find out what's wrong with the explosions and I've narrowed it down to one file, and I suspect I should be able to find what's wrong soonish.

I'll post here if/when I progress any further. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 6:52 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Aunxx,

I think it's a different problem as the segfault doesn't occur in the function you corrected :)

I am still investigating.

Btw, I confirm, we have lost explosion!!! ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 7:09 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
Azurief wrote:
Btw, I confirm, we have lost explosion!!! ;)

Please don't let it be the 3Dfx cleanup. Please. Do you get explosions in r290 but not r291?

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 22, 2006 8:06 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
lmop wrote:
Azurief wrote:
Btw, I confirm, we have lost explosion!!! ;)

Please don't let it be the 3Dfx cleanup. Please. Do you get explosions in r290 but not r291?


Don't worry... this is a gcc 4 thing, not an rgl thing :)

Note: The tutorial works for me with gcc v4, but no explosions.

We have lost explosions... repeat we have lost explosions in gcc 4. Be on the lookout for lost-looking explosions looking for a place to happen. Salvage corvettes should be especially careful of such explosions.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 23, 2006 4:57 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
LMAO!

I've traced the lost bangs to UnivUpdate.c. They aren't limited to just the explosions, but include some other effects due to damage as well.

The funny part is that I can compile the game using v4, and just compile the offending file with v3, then link with v4 and the explosions are there!
Very strange, but I'll keep trying to identify the offending code. :)

Aunxx


Top
 Profile  
 
 Post subject: Found them!
PostPosted: Thu Nov 23, 2006 9:50 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.

The pesky pops were cunningly hidden behind the fridge! :)

I'm testing what I've done, and making sure that the scaling is now correct for distroying the larger ships. Very simple change, but a little troublesome to find.

Also need to remove about 50 dbgMessagef entries where I've been trying to work out where it's gone awry.

Aunxx.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 23, 2006 3:43 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
My bad, tutorial is working... It was my mistake...sorry... :)


Top
 Profile  
 
 Post subject: WTF
PostPosted: Thu Nov 23, 2006 4:34 pm 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi all.

I've fixed the problem with the explosions using gcc v4. The problem I have is that I have no idea why the fix works.

Anyone who can explain to me why this sorts the problem out would be much appreciated.

I'll commit the code tomorrow some time, but please feel free to examine the subtleties and elegance of the fix. :) :) :)

Code:
Index: UnivUpdate.c
===================================================================
--- UnivUpdate.c        (revision 301)
+++ UnivUpdate.c        (working copy)
@@ -4073,6 +4073,7 @@
 //                {
                     colSize *= ship->magnitudeSquared;
 //                }
+dbgMessagef("Don't delete this or the explosions fail!"); // I have no f**king clue why this fixes it!!!!!
                 colSizeDword = TreatAsUdword(colSize);
 
                 maxVelocity = ship->staticinfo->staticheader.maxvelocity;


Strangely it still works with v3 as well. :)

Any ideas? I could probably try tidying the code as well, but it all just seems a bit freaky.

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 23, 2006 6:10 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Strange, this work for me too.

But it seems to be related to the cast define by TreatAsUdword which must should not be done immediatly after doing the multiplication operation.

Code:
Index: Game/UnivUpdate.c
===================================================================
--- Game/UnivUpdate.c   (rĂ©vision 301)
+++ Game/UnivUpdate.c   (copie de travail)
@@ -4073,7 +4073,6 @@
 //                {
                     colSize *= ship->magnitudeSquared;
 //                }
-                colSizeDword = TreatAsUdword(colSize);

                 maxVelocity = ship->staticinfo->staticheader.maxvelocity;
                 if (maxVelocity != 0.0f)
@@ -4085,6 +4084,7 @@
                 {
                     velMagnitude = 0;
                 }
+                colSizeDword = TreatAsUdword(colSize);
                 velMagnitudeDword = TreatAsUdword(velMagnitude);


Simply moving the colSizeDword fix it. I suspect some optimization in asm in gcc that must mess up this kind of instruction.


Top
 Profile  
 
 Post subject: Re: WTF
PostPosted: Thu Nov 23, 2006 6:15 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
That looks exactly the same as the original code but with just an extra debug line. Are you really saying that without the dbgMessagef call we lose explosions under gcc 4?

If so, you're right, that's just weird. Since you're not using the string formatting provided by dbgMessagef does it make any difference if you use dbgMessage instead?

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 23, 2006 6:21 pm 
Offline
coder

Joined: Wed Nov 15, 2006 8:15 am
Posts: 100
Well it's more likely to be the sequence of
colsize *= ship->magnitudeSquared;
and just after
colSizeDword = TreatAsUdword(colSize);

Maybe some dependencies problem when compiling, I can't really say...

Should I commit my changes?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 23, 2006 6:49 pm 
Offline
coder
User avatar

Joined: Tue Dec 14, 2004 3:24 pm
Posts: 324
Location: UK (UTC+0)
I prefer the second version over the first and if it fixes the problem, well, go for it.

_________________
MacHomeworld | HomeworldSDL.org


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 24, 2006 4:34 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
I agree that moving the cast later in the sequence is the better option.

I was just so shocked that adding what ammounts to a comment resolves the problem that I just had to post it. :) Didn't get chance to look further into the problem last night but the squence makes sense, so it looks like a compiler issue.

Thank you for updating the svn Azurief. :)

There is one place in the code where there is a similar style of code. The code is in "DeleteDeadDerelict" in the same file. I lost my save games in a freaky mke2fs accident, so if anyone can try blowing up a derelict and let me know if the explosions are missing there as well. I'm guessing it's suspect so we might just want to alter the code there as well.

On a side note, if anyone has the default save games they can "lend" me for testing then I don't have to complete the game again to get them. I will, of course, be completing the game again anyway. :)

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 28, 2006 4:40 am 
Offline
coder

Joined: Tue Nov 07, 2006 4:40 am
Posts: 236
Hi.


zapkitty wrote:
Quote:
Unfortunately you broke sound event tracking so that the soundtrack for the single-player start NIS goes on and on and on even if you abort the sequence via spacebar or escape key and go directly to the starting play.... it's kinda weird to hear the Mothership drives ramping up in the Scaffold while you're busy destroying drones Smile


I've played this a few times, and I think it's supposed to do that. I need to check but I think that's correct. :)

Apart from this, are we happy with the updated code, and should I ammend the README, et al?

Aunxx


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 03, 2006 7:17 pm 
Offline
Site Admin
User avatar

Joined: Tue Dec 14, 2004 12:41 am
Posts: 326
aunxx wrote:
Hi.

zapkitty wrote:
Quote:
Unfortunately you broke sound event tracking so that the soundtrack for the single-player start NIS goes on and on and on even if you abort the sequence via spacebar or escape key and go directly to the starting play....


I've played this a few times, and I think it's supposed to do that. I need to check but I think that's correct. :)


Nope... It's broke, needs fixed eventually :)

The kas mission files have code that explicitly shuts down the NIS letterbox effects etc when tab, space or esc is hit during the sequence and soundtrack stuff should be shut down as well. It works in win32, so should also work in SDL...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group