mifritscher

Community Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

1 Neutral

About mifritscher

  • Rank
    Tiro
  1. Only as an hint: even on an i7-640LM, the integrated GPU (which can handle OpenGL 2.1 and inofficially even OpenGL 3) isn't fast enough to enable GLSL 2.0 shaders - its way too slow, even if the graphics quality is set to low. Without its working fine. So if all shaders etc. are converted to OpenGL 2.1 GLSL, there should be "extra low quality" versions available - also to ease porting to Android, running it on compute sticks etc. Regarding suptertuxkart: Yes, the old renderer is still available. The i7-640LM can be forced to claim OpenGL 3 and then its technically running, but practical unplayable because of way too few fps. The old renderer is running fine on the same maschine.
  2. Which via s3 do you have? And which cpu? AoE II uses a pseudo 3D mode (doesn't use 3D capabilties from the GPU at all) while 0ad uses "real" 3D
  3. @rendering: one finding for me is, that the profiling result for rendering is totally different on Linux & Windows (On Linux there is no difference if GLSL is enabled or not). The other thing is that the bottlenecks are either on "unlogged" things (as on Windows) or on clearing ( & and switching) buffers. The unlogged thing could be a overlooked thing which is worth to be profiled, the buffer thing could be a surprising ineffectiviness on a specific function. @Transfering differences vs transfering commands: transfering commands means that the non- host computers need to calculate more, which could lead to problems if e.g. something gets out if (timely) sync or do have slightly different calculations (e.g. floating point, which you try to avoid partly because of this) To help mitigate the problem about deviating states (which shouldn't occour if only the host calculates the "true" data and the other computers only calculate things for interpolating for e.g. smoother displaying) checksums could be used - and if any difference is catched then the raw data is requested, perhaps only section-wide @Pathfinding: Caching paths could be useful e.g. for gathering ressources. The civs are walking much more often than ressources are exhausted or new buildings get built ;-) The local cirvumventing could be used as a first try and in a way to get back on the planned track at quick as possible. If that doesn't work in e.g. 3..5 seconds, a global replaning could be triggered.
  4. At least it should be raised only to 1280x768 - so both the 1280x800 and 1366x768 gets covered. But "normal" XGA is still widely used And I think that a GUI which can be used at any resolution (and any dpi!) would be more usefull. Perhaps slightly different arrangements für 5:4 (1280x1024), 4:3 (the "classic"), 16:10 (1280x800 and the lie) and 16:9 (1366x768) would be usefull, but I think it would work without it as well.
  5. For me the speed hasn't changed much between Alpha 15 and 18. I'm playing mostly 1vs1 with max. 150 civ. The biggest problems are rendering -> patches -> render terrain base -> unlogged and rendering -> models -> rendering bucketed submissions (Windows Visa, Core2Duo, x3100, lowest graphics settings within GUI, needed to disable glsl because it can't compile the shaders) - so rendering is the biggest problem for me ;-) Edit: Under Ubuntu (14.04, 64 bit, same computer, glsl enabled) It looks different: here te problem is render -> render submissions -> clear buffer Even if the gamestat is a few 100 kB (which sounds rather big to me to be honest, perhaps it could be may more effective with a binary encoding - yes, there is a binary form of JSON) It could be worth to transfer only the differences What are the biggest problems in path planing now? To be honest, it's surprised me that this should be the bottleneck - even on big maps and many (>1000) civs) Some random ideas for optimisation (don't know if they are already used ): * If a civ runs this way (source->target point) for several (>1?) times, assume it is free -> no recalculation of the path. If there is a new obstacle then recalculate once when the obstacle is (almost) hit * I hope that it not recalculated every 50 ms or so? * Stick to "static" pathplaning, only recalculate if there new obstacles occuring which are on the path * First try to find local cirvumventions on obstacles and not recalculate the whole path * Formations: As already being said: Do the global pathplaning only for one person (master) in the formation, the other do only a local "follow the master" algorithm. This gobal pathplaning could even estimate the width of the formations (as already being said) * Formations: If formations are crossing each other, but shouldn't interact (by e.g. attacking) try to keep the masters a bit apart so the "follow the master" algorithm doesn't need to calculate circumventions very dynamically