Pages: [1] 2 3
  Print  
Author Topic: G_LocationDamage() creates hang  (Read 53185 times)
randombloke
Nub


Cakes 0
Posts: 28


« on: November 10, 2007, 05:57:31 AM »

I implemented location damage from the following site:

http://code3arena.planetquake.gamespy.com/tutorials/tutorial14.shtml

The problem is that the application hangs anywhere between 30 seconds and 5 minutes into a level.  There is obviously a condition that has not been accounted for.

I put in a couple of GPrintf() statements around the calling statement, but the funny thing is that it does not always crash when this statement is called.  Sometimes, the statement is not being used when it hangs.

If I comment out the calling code, then the app no longer hangs.

Any ideas?

Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #1 on: November 10, 2007, 09:03:42 AM »

For future reference, the code at code3arena needs to be modified for this version of quake.  When doing checks against targ, actually do a check against targ->client.  The client does not always exist.

So, this calling code from code3arena:
Code:
// Modify the damage for location damage
if (point && targ && targ->health > 0 && attacker && take)
take = G_LocationDamage(point, targ, attacker, take);
else
targ->client->lasthurt_location = LOCATION_NONE;

Should read like this:

Code:
// Modify the damage for location damage
if (point && targ->client && targ->health > 0 && attacker && take)
take = G_LocationDamage(point, targ, attacker, take);
else if (targ->client)
targ->client->lasthurt_location = LOCATION_NONE;


Logged
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #2 on: November 10, 2007, 01:02:24 PM »

Just wrap the existing code in an if statement...

Code:
// Modify the damage for location damage
   if( targ->client )
   {
      if (point && targ->health > 0 && attacker && take)
         take = G_LocationDamage(point, targ, attacker, take);
      else
         targ->client->lasthurt_location = LOCATION_NONE;
   }
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #3 on: November 10, 2007, 08:45:22 PM »

Just wrap the existing code in an if statement...

Code:
// Modify the damage for location damage
   if( targ->client )
   {
      if (point && targ->health > 0 && attacker && take)
         take = G_LocationDamage(point, targ, attacker, take);
      else
         targ->client->lasthurt_location = LOCATION_NONE;
   }


Whilst it makes it easier to read, if I remember my optimisations correctly, there is a slight performance penalty for wrapping the entire statement.  One or two statements like this won't hurt, but if there are quite a number, then it will become noticable under a heavy load.  Cutting that overhead will make complex scenes run more fluid on lower end machines.

I'm actually going over the code to find stuff like this in an effort to speed up the new code.
Logged
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #4 on: November 11, 2007, 03:46:27 AM »

If point is set, you check targ->client.

If point is not set, you check targ->client.

So, wrapping the statement in the 'if' as I suggested is not only easier to read, it will result in the most optimized solution... Regardless of the value of point, you always check targ->client, so you might as well get that out of the way first...

There is no performance penalty, you are doing the check anyway.

(Of course, the compiler optimizer may take care of it anyway, so they might be the same in the end. If they are, you might as well go with the more readable solution...)
« Last Edit: November 11, 2007, 03:53:17 AM by beast » Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #5 on: November 11, 2007, 09:54:40 AM »

If point is set, you check targ->client.

If point is not set, you check targ->client.

So, wrapping the statement in the 'if' as I suggested is not only easier to read, it will result in the most optimized solution... Regardless of the value of point, you always check targ->client, so you might as well get that out of the way first...

There is no performance penalty, you are doing the check anyway.

(Of course, the compiler optimizer may take care of it anyway, so they might be the same in the end. If they are, you might as well go with the more readable solution...)

That's not how it works at the processor level.  Using the nested if statement you describe, results in a different setup of the stack.  By having the checks inline with the code, certain registers don't need to be changed.  Computation is not the real issue, its the time it takes to load the registers, reset the stack and setup the new check that causes the performance penalty.

The method you described is optimised from a human view-point, but not from a processor view point.
Logged
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #6 on: November 11, 2007, 01:49:50 PM »


That's not how it works at the processor level.  Using the nested if statement you describe, results in a different setup of the stack.  By having the checks inline with the code, certain registers don't need to be changed.  Computation is not the real issue, its the time it takes to load the registers, reset the stack and setup the new check that causes the performance penalty.

The method you described is optimised from a human view-point, but not from a processor view point.

Well, I hate to be the one to break the bad news to you, but, the compiler takes care of optimization and all of the stack setup, so you have little control of it.

I give up... Good luck...
Logged
next_ghost
Half-Nub


Cakes 0
Posts: 76


« Reply #7 on: November 11, 2007, 03:07:10 PM »

That's not how it works at the processor level.  Using the nested if statement you describe, results in a different setup of the stack.  By having the checks inline with the code, certain registers don't need to be changed.  Computation is not the real issue, its the time it takes to load the registers, reset the stack and setup the new check that causes the performance penalty.

The method you described is optimised from a human view-point, but not from a processor view point.

The difference doesn't matter since 1995.
Logged
iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #8 on: November 12, 2007, 12:26:08 AM »

take a look at tremulous
I am saying it a lot because it has a lot of code/ideas from http://www.quake3hut.co.uk/q3coding/
( I hope there is no copy-paste though Tongue )
so you can see the actual implementation
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #9 on: November 12, 2007, 03:07:22 AM »

Quote
Well, I hate to be the one to break the bad news to you, but, the compiler takes care of optimization and all of the stack setup, so you have little control of it.


An optimising compiler is only as intelligent as those that programmed it.  Whilst you can hope that the more readable expression would be optimised in the same fashion, you can't really guarantee it.  By presenting it in an inline fashion, there is a better chance that the optimisation will be used.

The best way to test it is by disassembly and a sample app with a high resolution timer.

Quote
I give up... Good luck...

Calm down, I just don't trust the compiler to optimise properly.

Quote
The difference doesn't matter since 1995.

Sorry to burst your bubble...

Quote
However, optimizing compilers are by no means perfect. There is no way that a compiler can guarantee that, for all program source code, the fastest (or smallest) possible equivalent compiled program is output; such a compiler is fundamentally impossible because it would solve the halting problem.

http://en.wikipedia.org/wiki/Compiler_optimization#Problems_with_optimization

...but it matters a lot, especially when you have processor/GPU intensive tasks.  A little shove in the right direction never hurts.

Perhaps this explains why the Openarena.exe is 2002KB and my version is only 1036KB, even with full ogg, OpenAL and vorbis support.

Why is Openarena.exe so large???


Quote
take a look at tremulous
I am saying it a lot because it has a lot of code/ideas from http://www.quake3hut.co.uk/q3coding/
( I hope there is no copy-paste though  )
so you can see the actual implementation

Thanks for the link, there is a lot of good stuff there.  I find the fastest way to learn an engine is to mod it and there are quite a few features I would like to add.
Logged
next_ghost
Half-Nub


Cakes 0
Posts: 76


« Reply #10 on: November 12, 2007, 05:04:23 AM »

Quote
The difference doesn't matter since 1995.

Sorry to burst your bubble...

Location damage is on average calculated less than once a second and it's done in constant time. If the difference means big performance hit in your code, then you have much bigger problem than stack setup and order of instructions.
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #11 on: November 12, 2007, 07:13:32 AM »

Quote
Location damage is on average calculated less than once a second and it's done in constant time. If the difference means big performance hit in your code, then you have much bigger problem than stack setup and order of instructions.

As I said, the issue is not that instruction.  Its when unoptimised code is executed together, 10 cycles here, 10 cycles there, it all adds up in the end.  You notice the effect on lower end machines, especially when the engine tries to execute a players death, while rendering all the effects on full.  There is intensive slowdown for one or two seconds.

I'm adding in a lot of mods and its quite processor, GPU and I/O intensive at certain points.  So, I need to tweak a little.  As I mentioned, my custom .exe is fully featured and yet nearly half the size of OpenArena.exe.  It also executes about 15% faster at present.  I'm obviously doing something right.

I just see it as good practice at this point, it means that I won't need to come back later if I need to insert a new feature, like ragdoll physics.
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #12 on: November 12, 2007, 09:50:02 AM »

Why is Openarena.exe so large???

Because gcc doesn't optimize worth a damn and mingw32-gcc is worse.
Logged

iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #13 on: November 12, 2007, 01:01:55 PM »

you can use strip to strip unused junk
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #14 on: November 12, 2007, 01:47:43 PM »

with the caveat that you lose debugging information.
Logged

next_ghost
Half-Nub


Cakes 0
Posts: 76


« Reply #15 on: November 12, 2007, 01:54:01 PM »

As I said, the issue is not that instruction.  Its when unoptimised code is executed together, 10 cycles here, 10 cycles there, it all adds up in the end.  You notice the effect on lower end machines, especially when the engine tries to execute a players death, while rendering all the effects on full.  There is intensive slowdown for one or two seconds.

Location damage is server side feature.

Quote
I'm adding in a lot of mods and its quite processor, GPU and I/O intensive at certain points.  So, I need to tweak a little.  As I mentioned, my custom .exe is fully featured and yet nearly half the size of OpenArena.exe.  It also executes about 15% faster at present.  I'm obviously doing something right.

I just see it as good practice at this point, it means that I won't need to come back later if I need to insert a new feature, like ragdoll physics.

Good practice is to use gprof to gather real runtime statistics and then optimize code that takes most time to execute. Anything else is premature optimization and the best way to create write-only code.
Logged
iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #16 on: November 12, 2007, 02:43:38 PM »

with the caveat that you lose debugging information.
heh is it used anywhere? I dont think you need debug info with release version anyway
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #17 on: November 12, 2007, 03:44:57 PM »

heh is it used anywhere? I dont think you need debug info with release version anyway

There is that, and anyone that needs it can certainly recompile the binary...
Logged

beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #18 on: November 12, 2007, 07:07:49 PM »

As I mentioned, my custom .exe is fully featured and yet nearly half the size of OpenArena.exe.  It also executes about 15% faster at present.  I'm obviously doing something right.

The code that you are playing around with is not in openarena.exe. The code is in the game qvm file (or dll if you are using that).
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #19 on: November 13, 2007, 02:58:02 AM »

Quote
Location damage is server side feature.

Which still can cause a bottleneck in single player mode, as the local PC is the server.


Quote
Good practice is to use gprof to gather real runtime statistics and then optimize code that takes most time to execute. Anything else is premature optimization and the best way to create write-only code.

I just use a high resolution timer, it does the same job.


Code:
The code that you are playing around with is not in openarena.exe. The code is in the game qvm file (or dll if you are using that).

No sh*t Sherlock... Smiley

I optimised the .exe before moving on to the game logic and UI.
Logged
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #20 on: November 13, 2007, 08:47:27 AM »

I optimised the .exe before moving on to the game logic and UI.

All we've tried to do is help and all you've done is try to tell us how impressed we should be with you.

We're not impressed. Go troll somewhere else.
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #21 on: November 13, 2007, 01:26:31 PM »

I optimised the .exe before moving on to the game logic and UI.

Too bad you won't be able to distribute any of it so others can benefit.  Code found on code3arena is _not_ GPL and cannot be included in any distribution of GPL code legally.  Any and all ideas can be used but they have to be done differently unless the author of the code has specifically stated that his code is GPL.

Your solution for locational damage is obviously cut + pasted + hacked to work with the current code base and isn't an original implementation, sorry.
Logged

randombloke
Nub


Cakes 0
Posts: 28


« Reply #22 on: November 14, 2007, 06:15:49 AM »

Quote
All we've tried to do is help and all you've done is try to tell us how impressed we should be with you.

I mean no offence, but you were pointing out the obvious Sherlock.  Smiley

Actually, I was hoping you guys would tighten up the code a little.  Open Arena is a very good clone of quake, it would be much better if the .exe, libs and dlls were better optimised.  Whether you choose to add the little tricks I mentioned is up to you, but you should at least compile the release code with a better compiler.

Quote
Too bad you won't be able to distribute any of it so others can benefit.  Code found on code3arena is _not_ GPL and cannot be included in any distribution of GPL code legally.  Any and all ideas can be used but they have to be done differently unless the author of the code has specifically stated that his code is GPL.

Don't worry, I understood this when I integrated the code.  I've been using it to get my head around the layout of the engine and what is required to implement certain features.

To be honest, many aspects of the engine are out-of-date now anyway.  It needs re-written from scratch with more modern features integrated into the codebase.  The team at ioquake have done a fantastic job, but its time to break backwards compatibility and unleash one hell of a modern engine that supports both in-door and out-door scenarios well.
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #23 on: November 14, 2007, 03:52:56 PM »

but you should at least compile the release code with a better compiler.

Sure, find me another cross-compiler that works on a GNU/Linux x86_64 systems that is software libre and I'll gladly use it.

Quote
To be honest, many aspects of the engine are out-of-date now anyway.  It needs re-written from scratch with more modern features integrated into the codebase.  The team at ioquake have done a fantastic job, but its time to break backwards compatibility and unleash one hell of a modern engine that supports both in-door and out-door scenarios well.

This is where I got my current signature.  Adding modern features to the engine and breaking compatibility with id's game will only serve to cause more flame wars due to the religious devotion of certain individuals[1] to id tech 3 and its low spec requirements.

[1] not necessarily people that post to this forum
Logged

iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #24 on: November 14, 2007, 04:19:29 PM »

stop it!
 I must be the only troll around
Logged
Pages: [1] 2 3
  Print  
 
Jump to: