scroogie
-
Posts
76 -
Joined
-
Last visited
-
Days Won
1
Posts posted by scroogie
-
-
It happens right from the start (in the main menu) and then every few minutes. I can try to time it if it helps.
-
No, this is a Core i5-3570 on an Z77 chipset (no further sound card). Running Linux, Kernel 3.7.10.
-
Actually that is the first error (apart from the sound stuff I reported in the other thread):
<!DOCTYPE html>
<meta charset="utf-8">
<title>Pyrogenesis Log</title>
<style>body { background: #eee; color: black; font-family: sans-serif; } p { background: white; margin: 3px 0 3px 0; } .error { color: red; } .warning { color: blue; }</style>
<h2>0 A.D. Main log (warnings and errors only)</h2>
<p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
</p>
<p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
</p>
<p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
</p>
<p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
</p>
<p class="error">ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not defined
updateHero()@gui/session/session.js:452
onSimulationUpdate()@gui/session/session.js:413
__eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0</p>
<p class="error">ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not definedand then the last one is repeated endlessly.
-
"Reduced archer attack damage." --- nooo, my precious archers.
Looking forward to all those changes.
-
After some minutes in the game, I endlessly receive the following message:
ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not defined
updateHero()@gui/session/session.js:452
onSimulationUpdate()@gui/session/session.js:413
__eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0
ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not defined
updateHero()@gui/session/session.js:452
onSimulationUpdate()@gui/session/session.js:413
__eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0
ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not defined
updateHero()@gui/session/session.js:452
onSimulationUpdate()@gui/session/session.js:413
__eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0
ERROR: JavaScript error: gui/session/session.js line 452
-
I periodically receive this message on every game now:
ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
*Update*:
See http://www.wildfiregames.com/forum/index.php?showtopic=17314entry269697 for solution.
Default OpenAL version in OpenSUSE 12.3 has the bug mentioned there. Using the multimedia repository (http://pmbs.links2linux.org/project/repositories?project=Multimedia for 12.3: http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_12.3/) and doing a zypper dup fixes the issue.
-
I don't know why yet, but I'm getting
patch: **** malformed patch at line 1658: Index: source/simulation2/components/CCmpObstructionManager.cpp
-
So if I see that correctly, the WIP-Pathfinder is a hierarchical A* with JPS optimization on a Grid of 16 cells per terrain cell with unit-based clearance and using a points-of-visibility algorithm with higher precision obstruction edges on the local step (local being the way to the next high level waypoint?)?
That seems like quite a beast.
-
There is no such thing as "the boost". Boost is a collection of libraries, which you are free to use separately. Most of them are only made up of some header files that you can simply copy somewhere. iirc for 0ad you only need to build filesystem and signals, the rest is just headers.
-
Applied the patch for fun:
- doesn't apply cleanly anymore
- C++0x errors (need flag in all makefiles)
- ambiguous overloads in CCmpRangeManager (due to removal of implicit cast)
- misses some coding conventions (trivial things like position of pointer symbol etc.)
- duplicate isqrt (both in header and cpp)
- fast_blur_halide misses the intrinsics includes and is never used (?)
- contains some commented out code?
Don't know if its related, but also after a few minutes the game errored, printing this over and over:
ERROR: JavaScript error: gui/session/session.js line 452
ReferenceError: type is not defined
updateHero()@gui/session/session.js:452
onSimulationUpdate()@gui/session/session.js:413
__eventhandler34 (simulationupdate)([object Object])@sn simulationupdate:0
-
What situation did you measure the 20% performance improvement in? If I run e.g. Combat Demo (Huge) and start a fight for a couple of minutes, then the profiler indicates about 35% of the total runtime is in CFixedVector2D::CompareLength, which is called by CCmpPathfinder::ComputeShortestPath calling std::sort(edgesAA...). Almost all the time in CompareLength is doing lots of expensive-on-x86 64-bit multiplies, so that's the kind of thing that might well be made a lot faster by using floats (though I'd guess it could also be made quite a bit faster while sticking with ints, with some x86-specific code to do a 32x32->64 bit mul or with SSE2 or something). But the real problem here is that the short-range pathfinder is terribly unscalable - it needs a different algorithm, which'll mean it won't do a crazy number of std:sort(edgesAA...), and then the performance of CFixedVector2D::CompareLength will hardly matter. Were you measuring that performance issue or something else?
I was curious about this. Actually, the code of the pathfinder points to the "points of visibility" article in GPG. As I had that lying around I had a look, and the article specifically says that POV is a reasonable choice if you have 3D with few dynamic obstacles. For RTS it suggests a rectangular Grid approach. I think its also meant to have the edges precomputed instead of on the fly?
If I look at the code, seeing edges between passability classes, edges between obstruction squares, a sort for every open vertex etc. I'm wondering if this is actually much faster than simply searching the squares with heuristic directly?
-
1
-
-
As an addition to what quantumstate said, it depends on what your angle is supposed to mean. Is it relative to the current moving direction or global? Also, again rephrasing what quantumstate said, you have to make sure your turning direction is always equal. Usually you only have the smallest angle in arbitrary direction. How do you calculate the angle?
-
thanks for the info. my rendering stays somewhere between 15ms and 25ms(30 maybe?) but sim update is spiking to 125-210ms or so right at/after the freeze occurs so i'm guessing it has something to do with that (unless that's just a coincidence/indirectly related and is within acceptable limits). I'm not seeing anything else taking any time to speak of. also, turning off all graphics extras in settings doesn't seem to have a noticeable effect and i never had to turn any of that off before, either(assuming i keep it at or below 3 players on a 4 player map with default pop limit).
As has been said before, many things are cpu-bound right now. You can step into the different components with the number in front of the lines, so maybe you can localize the culprit by stepping into sim update.
-
Note that I never implemented flow fields. These are just my thoughts about the algorithm.
> What do you mean with oscilating paths? Units moving left-right-left-right ... ?
Yes. I would expect that relative to the original goal, units will periodically divert into orthogonal directions, as they toggle between taking an alternative route and completely following "the flow". This is basically the cost of approximating a global problem with local solutions.
> I think that can be solved by smoothing it out. Don't go to the exact pixel with the least cost, but look 3-4 pixels ahead. That's only a very small calculation,
> and if the resolution of the flow field is big enough (so that every obstacle is bigger than 4 pixels) it should not cause routing problems.
Principally, yes, but I would expect it to be a bit tricky in detail. What you describe works great with typical paths (bread-crumbs), but in this case your cells are much smaller (its your local direction after all).
-
Flowfields are just a stored routing tree. And you can store it because you have the same destination point for a bunch of units. So it will bring a higher performance to the game, but I do see some problems.
Since the flowfield is used by multiple units, the performance gain is because it doesn't have to be recalculated. So when you work with big units (think ships), if you want them to not go through each other, you need to edit (or re-calculate) the flow field. It looks like in that game, they allow units to squeeze together, which makes perfect sense for small units, but not for big ones.
Also, I don't immediately see this working with formations. It looks like that game mentioned will not have formations, so units more freely to the same point. While in 0AD, units will need to stick to a certain grid, but also break apart on the right times.
As far as I understand, a flow field is rather a vector field pointing to the cheapest local steering direction relative to the goal (or is that what you meant with routing tree?). So units are still free to choose the direction in which they steer, but diverting from the vector field direction will raise the movement cost. I would think you combine it with a dynamic cost map and coarse planning/replanning, so that units choose a different coarse path if the prior one is blocked. The fine movement will then be directed by the flow field. I guess you will get problems with oscillating paths, but it should work with formations etc.
-
Very interesting read. Its great to gain some insight like this!
Its already enjoyable to play against Aegis, although I noticed some glitches when I tried it yesterday. I played on Sahel Watering Holes and at some time the AI, apparently undaunted by death, intended to build a CC in one tight corner that was left neutral territory. Of course I had some defense at the entrance to my island, but it kept trying to squeeze through with a horde of workers and civil soldiers. So I guess the point "No sense of "this is a dangerous area, I should avoid going/collecting/building there"." is indeed quite important. Looking forward to even more great improvements!
-
Are you sure that a relational database is a good fit for this feature? I'd guess that you'd rather need a more specialized graph database, of course depending on which approach you want to take (game trees etc.). Performance will most probably also get critical.
-
quantumstate: Wouldn't it be enough to implement a quadtree for the map/entities? Or would you need the 3rd dimension somewhere?
And could you elaborate the idea in your last post a bit? Isn't the sim interpolation also for calculating positions etc. (which would still be needed for units out of sight)? Sorry, but maybe others are also interested.
-
I see, thanks for the info! As I said, I was just wondering about the integer square root.
-
You so clever. Look up Manhattan distance.
I was not trying to be clever. I don't know why you start getting like that. I was stating a simple fact. Why would you use an approximation if you're slower? Makes no sense.
And I know fully well what the manhattan distance is. It is not an approximation, that is for sure.
-
If the sqrt is being used to compute distance, it may be an acceptable approximation to get rid of it completely.
Yes, but an approximation should be faster, not slower.
There's a built-in profiler, accessible with F11 in-game. I never thought to check.. but please don't tell me it's running always, even in the Release builds!?
This is not it I think. There seem to be different generations of profilers.
Floating point arithmetic isn't safe in the simulation code due to hardware and compiler differences, it must produce identical results for each player in a multiplayer game.
Ok, thanks for the hint. I'll have to think about this.
-
In a small callgrind run, I've seen that the fixed point integer square root function consumes quite some time in path computation. The attachments show three cases of CCmpPathfinder_Tile::ComputePath recorded through a CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION in the function itself (otherwise valgrind was too slow for me to use).
Has the isqrt64 been benchmarked against the "normal" lm function? I don't have much time, but some initial tests seem to suggest that a casted sqrt is faster than the custom function in my case, even when casting from u32 to double and back. Or do I miss some other reason for this function?
And out of curiosity, is the CProfiler2 stuff visible in two of the graphs required for some kind of runtime performance adaptation?
The callgrind run is from saturday mornings SVN iirc, in case something was changed recently.
-
Confirmed. Thanks.
-
Here is a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00000000008494e5 in CRenderer::GetMaterialManager (this=0x0) at ../../../source/renderer/Renderer.cpp:2116
2116 return m->materialManager;
(gdb) bt
#0 0x00000000008494e5 in CRenderer::GetMaterialManager (this=0x0) at ../../../source/renderer/Renderer.cpp:2116
#1 0x0000000000806571 in CTerrainTextureEntry::CTerrainTextureEntry (this=0x11b13f0, properties=..., path=...) at ../../../source/graphics/TerrainTextureEntry.cpp:109
#2 0x00000000007e06f4 in CTerrainTextureManager::AddTexture (this=0x1174ae0, props=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:103
#3 0x00000000007e09aa in CTerrainTextureManager::LoadTextures (this=0x1174ae0, props=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:138
#4 0x00000000007e0cdc in CTerrainTextureManager::RecurseDirectory (this=0x1174ae0, parentProps=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:169
#5 0x00000000007e0c8a in CTerrainTextureManager::RecurseDirectory (this=0x1174ae0, parentProps=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:166
#6 0x00000000007e0ebb in CTerrainTextureManager::LoadTerrainTextures (this=0x1174ae0) at ../../../source/graphics/TerrainTextureManager.cpp:176
#7 0x000000000067cced in CReplayPlayer::Replay (this=0x7fffffffe1d0) at ../../../source/ps/Replay.cpp:138
#8 0x00000000004a64a3 in RunGameOrAtlas (argc=2, argv=0x7fffffffe4f8) at ../../../source/main.cpp:471
#9 0x00000000004a6b0b in main (argc=2, argv=0x7fffffffe4f8) at ../../../source/main.cpp:550
[FIXED] ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345)
in Bug reports
Posted
Can I toggle/force a track change somehow to test that?