OpenArena Message Boards

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?

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:

Should read like this:

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

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.

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.

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

The difference doesn't matter since 1995.

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 :P )
so you can see the actual implementation

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.


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


Sorry to burst your bubble...


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



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.

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.

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

you can use strip to strip unused junk

with the caveat that you lose debugging information.

Location damage is server side feature.


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.

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

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

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



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



No sh*t Sherlock... :)

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.

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.

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

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.


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.

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.


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

stop it!
 I must be the only troll around

The discussion was around a code snippet in the game qvm and then you posted that your exe was smaller/faster. From that, it was not 'obvious' that you knew the two were different.


As it sits right now, the engine code is being done by the ioquake3 folks, so feel free to post away on their forums or submit bugs/enhancements to them.


That's the glory of open source, feel free to compile with whatever compiler fits your fancy if you don't like what the folks at OA use.

But if you use one of the proprietary compilers you should read the license to make sure their is no clause that prevents distribution under the GPL (intel's non-commercial compiler has such a clause).


Actually, there is a fairly serious show-stopping engine bug that is only affecting us, single player missionpack is dropping to desktop with the error: VM_Call with NULL vm, this only happens when either of the two bloom implementations is applied to the engine and hits all three platforms that I can test on (x86-linux, x86_64-linux, windows x86 via wine), I'm fairly certain that we don't want to be able to choose master servers as we only have one, and fromhell has mentioned that he wants DirectX.

(actually he stated that he wants a console window for error reporting which was replaced with stderr.txt, of course there is no documentation from upstream about this but, hey, why should they document major changes in the way errors are reported on the most widely used platform?)


You're no fun :D

If you would like some more eyes looking into the problem, post a little more detail regarding duplication steps and maybe some volunteers will step up...

are you talking about FBO bloom? does it work with ATi?

Create a fresh copy in VS2005 and compile from there.  Its a small enough app, so file management is not too difficult.


Well, I'm working on per-pixel lighting at the moment, I have working sample code, so I just need to find hooks in the engine where I can add it.


If you had read my posts in another thread, you would have known that I made .dlls out of the qvm files.  So, it should be obvious that I know the difference between a .exe and a .dll.

That some fine detective work there, Sherlock... :)



Using the .dlls, I don't get this error.  I added in tr_bloom without incident.  Adding DirectX support is no small decision to make.  Right now, its a choice between DX9c or DX10.1.  DX9c will give you about a 2 year life span and DX10.1 will have no real user base until the same point in time.  Then there is also OpenGL 3.0 to consider.

I really don't see what benefit DX would provide.



I have to agree with dmn_clown.  These forums would read like a technical manual without the trolls.

ICC costs big $$$ and GCC is far superior to any other compiler but ICC.


You're on wrong forum. Move along to xreal.

It starts around $400, so its not too bad. 


I'm checking out the source now.  If Open Arena were ported to Xreal, then the ioquake version would be pretty much dead.   I don't think it would take much to fully port the entire game.  It would certainly look a lot better, check out some of the screenshots:

http://xreal.sourceforge.net/xrealwiki/ScreenShots

I'm not saying that anyone should abandon ioquake, just make game assets available for xreal.

I'm going to play around with it and see how far I get.

Since you seem to like to call names when people try to help, let's call you out...


Hmmm... software libre... VS2005... Nice work Sherlock...


Hmmm... OA assets are already GPL...  Nice work Sherlock...

I recommended performing a compile from VS2005, instead of a cross-compile.



Nobody suggested they were not.  A lot of the assets need to be modified to support xreal.



You're not exactly the sharpest tool in he box, are you Sherlock? :)

There is more of a chance of me purchasing ICC than installing that POS.  It should also be noted that ICC actually costs less than VS2005, you see I would have to purchase a windows license, and quite frankly, I'd rather inject acrylic paint into my eyeballs than go through the 6-12 hour install, reboot, continue install, reboot, download-update then reboot, download-update then reboot, download-update then reboot, repeat ad nauseum until windows is fully up to date.


You misunderstood.


Somehow I doubt that, XreaL's system requirements are far too high and the engine does not perform nearly as well as it should on average hardware.

Yes.
Don't know haven't tested.

Hmmm... You recommended performing a compile from VS2005, instead of cross-compile... He asked for a replacement that was software libre...



Lets see now, first you say make the game assets available for xreal. Then, when you're called on it, all of a sudden you meant to say, they need to be modified...

Sounds like you're not the sharpest tool... You definitely are a tool, though...

You should be able to test this using the experimental binary and the current missionpack/vm.

Make sure you have your team_model and your team_headmodel (it won't default to anything until the default skins are committed - use the console)
start a single player game (any gametype though one flag seems to be the quickest game to beat)
hit next on the endofgame menu
VM_Call with NULL vm.

Also note this has been noticed against vanilla ioq3.

Would you speak to Watson like that? :)



I just got to test a version of xreal.  The engine is running perfect.  It doesn't appear to understand quake 3 jump pads, or teleporters, so the code must have been altered a bit.  Also, the lighting needs to be re-done as GLSL.

From what I've got running so far, it looks really damn good and slightly faster than ioquake.

This screenshot is from oa_bases3 as rendered using xreal.  I'm just using one of the test dynamic lights:

(http://aycu38.webshots.com/image/32677/2000457536943202246_rs.jpg)

not only that but the author is not interested in making it work on cards less than his own and ati cards

The OA team doesn't need to support xreal. It's not a need and definitely not a goal.

*yawn*

If you want to impress, submit a patch for arb_reflective water, per-pixel lighting that doesn't break q3's bsp format, and make the damned game brew a pot of coffee, otherwise you are just trolling.

As you can see from the screenshot, it works well on my system.  ioquake's rendering system is almost a decade old, that's ancient in computer terms.  The majority of new systems released over the last year would run the engine without any problems.

At this point, a staged migration would make sense.  It would give people with modern hardware the option of using those advanced features via xreal and older systems could use ioquake.  In terms of development and distribution, as far as I can tell at this point, the changes to the maps are minor and most assets can be used without any problems.  In time, xreal specifc assets could be made from modified OA assets that take advantage of xreal's extended features.

In the marketplace, its rapidly coming to the point where the basic specs required to run xreal is entry level.

Given that the major issue appears to be lighting, it shouldn't take more than a week or two to transfer all the assets and gameplay to xreal.  So, I'm getting started on this tomorrow.

Sorry but I'd like to not alienate the folks who have lives and debt that are not able to spend it on g80s and dual cores.

Try running xreal in linux and mac OH WAIT YOU CAN'T

xreal also dumps shaders for doom3 materials

Change is a fact of life.  The format is old and not designed to support the features of modern cards.



You won't be.  Offer two versions, one that supports legacy ioquake and one that supports more modern setups.


Well, that's just a matter of adding the appropriate code and most of that is included with the original q3 source.  GLSL will compile regardless of what platform it runs on.  I'm sure we can find a few linux developers to implement this.



I never checked for this, however, I don't think it would actually dump them, it just has no routines to do anything with those values.  That can be changed.

Feel free, just remember that by modifying OA's content you are bound by the GPLv2.  Unlike fromhell, I'm not polite about my copyright being broke.


Thanks that made my day... *Will let someone else point out the obvious*

xreal is a totally different project. its objective is not performance but state of art graphics (tr3b is trying to optimize it but it is not his primary objective) So it is not supposed to work on every HW and OS

on the other hand oa should work on as many platforms as possible But they would love to add GLSL support if it doesnt effect old hardware.

btw what do all these have to do with locational damage ? :D

Well, the idea is to get the bulk of the transfer done and fix any problems I come across.  Then I'll upload it somewhere.  I was hoping that you guys may take over at that point and polish things off.


Not working on all hardware I can live with, I'm not concerned about backwards compatibility.  As for every OS, well the graphics sub-system is openGL and there is no reason any other portion of the code cannot be modified to run on any system that supports openGL.

continue living in your pink world

Just remember to upload your changed sources as well.

At least it is per-pixel pink done in GLSL... :)


I have everything under a single folder, so I'll just zip that and upload it.

I'm building xreal's version of GTKRadiant now.  I'm downloading the sources to the necessary libs at the moment.  I haven't got to use this version, but I'm hoping that it supports GLSL vertex and fragment shaders.  If not, I will need to find some other method of integrating lighting.