Pages: 1 [2] 3
  Print  
Author Topic: G_LocationDamage() creates hang  (Read 53193 times)
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #25 on: November 14, 2007, 04:45:45 PM »

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

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.

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

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.

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

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.
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #26 on: November 14, 2007, 05:26:52 PM »

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

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

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

stop it!
 I must be the only troll around

You're no fun Cheesy
« Last Edit: November 14, 2007, 06:23:31 PM by dmn_clown » Logged

beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #27 on: November 15, 2007, 03:11:28 AM »

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

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...
Logged
iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #28 on: November 15, 2007, 03:14:28 AM »

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


Cakes 0
Posts: 28


« Reply #29 on: November 15, 2007, 03:16:34 AM »

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

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

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

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.

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

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

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


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.


Quote
You're no fun Smiley

I have to agree with dmn_clown.  These forums would read like a technical manual without the trolls.
Logged
next_ghost
Half-Nub


Cakes 0
Posts: 76


« Reply #30 on: November 15, 2007, 06:55:53 AM »

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

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

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.

You're on wrong forum. Move along to xreal.
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #31 on: November 15, 2007, 08:16:09 AM »

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

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

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

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.
Logged
beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #32 on: November 15, 2007, 02:20:33 PM »

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

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

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

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

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

Hmmm... OA assets are already GPL...  Nice work Sherlock...
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #33 on: November 15, 2007, 05:06:12 PM »

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

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


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

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? Smiley
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #34 on: November 15, 2007, 06:00:11 PM »

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

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.

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

You misunderstood.

Quote
If Open Arena were ported to Xreal, then the ioquake version would be pretty much dead.

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.
« Last Edit: November 15, 2007, 06:11:11 PM by dmn_clown » Logged

dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #35 on: November 15, 2007, 06:12:22 PM »

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

Yes.
Don't know haven't tested.
Logged

beast
Lesser Nub


Cakes 0
Posts: 142



« Reply #36 on: November 16, 2007, 12:13:13 AM »

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

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

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

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

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...
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #37 on: November 16, 2007, 12:18:59 AM »

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

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

randombloke
Nub


Cakes 0
Posts: 28


« Reply #38 on: November 16, 2007, 06:28:03 AM »

Quote
You definitely are a tool, though...

Would you speak to Watson like that? Smiley


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

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.
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #39 on: November 16, 2007, 09:04:24 AM »

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



Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #40 on: November 16, 2007, 09:20:18 AM »


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.

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.
« Last Edit: November 16, 2007, 09:22:14 AM by leilol » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #41 on: November 16, 2007, 09:33:43 AM »

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

randombloke
Nub


Cakes 0
Posts: 28


« Reply #42 on: November 16, 2007, 09:44:15 AM »

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

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.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #43 on: November 16, 2007, 09:47:13 AM »

As you can see from the screenshot, it works well on my system.

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
« Last Edit: November 16, 2007, 09:49:27 AM by leilol » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
randombloke
Nub


Cakes 0
Posts: 28


« Reply #44 on: November 16, 2007, 10:03:08 AM »

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

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


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

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

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

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.


Quote
xreal also dumps shaders for doom3 materials

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.
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #45 on: November 16, 2007, 10:19:30 AM »

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.

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.

Quote
The format is old and not designed to support the features of modern cards.

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

iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #46 on: November 16, 2007, 10:27:33 AM »

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 ? Cheesy
Logged
randombloke
Nub


Cakes 0
Posts: 28


« Reply #47 on: November 16, 2007, 09:54:00 PM »

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

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.

Quote
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

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.
Logged
iLeft.bye
Member


Cakes 1
Posts: 187



« Reply #48 on: November 16, 2007, 11:26:39 PM »

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

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.

Quote
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

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
Logged
dmn_clown
Posts a lot
*

Cakes 1
Posts: 1324


« Reply #49 on: November 17, 2007, 01:06:10 AM »

Then I'll upload it somewhere.

Just remember to upload your changed sources as well.
Logged

Pages: 1 [2] 3
  Print  
 
Jump to: