UI Feature: Move order waypoints

Discussion in 'Planetary Annihilation General Discussion' started by coldboot, May 8, 2015.

  1. coldboot

    coldboot Active Member

    Messages:
    447
    Likes Received:
    112
    Have you guys considered implementing the ability to dynamically move queued order waypoints, like in Supreme Commander?
    tatsujb and ArchieBuld like this.
  2. Remy561

    Remy561 Post Master General

    Messages:
    1,024
    Likes Received:
    642
    Last time Jables commented on the steam forums that this was not planned. But this was several months ago so things could have changed ;)
  3. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    Moving waypoints, and merging command queues at arbitrary waypoints, both features are still missing.
    tatsujb likes this.
  4. pjkon1

    pjkon1 Member

    Messages:
    97
    Likes Received:
    43
    If we're asking for Supcom UI features why not ask for templates? Those would be more useful (the more APM challenges of us would be able to spam a mix of vehicle and air at the beginning rather then just vehicle without losing a huge number of factories to invisible build space restrictions or take up huge amounts of time placing the factories.
    Last edited: May 9, 2015
  5. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    this is something that's "a given" in terms of how badly we need it. I'm afraid as to Uber having the time to make it though.
    Remy561 likes this.
  6. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    Templates could actually be implemented by modders.

    Not in a very comfortable way since our beloved devs made sure that client side mods won't be able to access ingame coordinates in a comfortable way, or be able to issue any meaningful commands, but it's still a purely client side thing.


    Manipulation of the command queue (slicing, inserting, moving and merging commands) however is burried so deep in the closed source core of the server, that there is no chance for us users to get that working on our own.

    *Sigh* At some point I just wished Uber would come to reason and open up on the development of PA. It's rather clear that they just don't have the human capacities to finish the development of the game in a timely manner. The game has still a lot of completely unused potential, but especially with the JS API we have right now, there is only so much what modders can do to help.
    Last edited: May 9, 2015
    stuart98 likes this.
  7. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    and in effect already are if you look at hotbuild closely.
  8. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    Yes, but hotbuild2 only does it by fuzzing. It tries "random" positions in all directions around the tower until it happens to find screen coordinates which turn out to be valid ingame build coordinates for walls.

    It works, but it's minbogling stupid to be unable to work in world coordinates, rather than needing to fiddle around with screen space coordinates.

    That's completely unsuited for any kind of "real" templates which were supposed to include any information on spacing or alike, since there are no guarantees whatsoever on the transformation matrix used for world to screen space.


    I've been thinking... At some point it might be worthwhile to go the same path as with TA and Spring. Just reverse engineer the original product, rebuild from scratch and just use the assets and APIs from the original game. Sooner or later it will either go this way or the game will die when the servers are being shut of, anyway. I just wonder if it's really wise to wait until that point and watch the technical debt build up in the original software until the product has eventually reached its end of life. Because that would mean that the public domain variant could only be released 2-5 years after PA was canceled, with not much of the community being left at that point. At the current development speed it would be at least another 2 years before the game is even actually feature complete, and I seriously doubt that Uber will keep an entire team of full time developers dedicated to the game for that long. Not even to mention the refactoring on the graphic component (switchover from OpenGL to Vulkan) and several other technical components which would be necessary by that time.
    Last edited: May 9, 2015
  9. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    you've been doing alot of the same thinking I have.
  10. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,125
    Likes Received:
    16,255
    I don't think there is any gain there at all. The game is not limited by the client fps anyway.
  11. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    yes there is.

    the way the game looks (and perhaps runs) is in a big way limited by the ancientness of the opengl version they're using.

    to use certain graphical calls, they're having to recode and reinvent it for this opengl version. these calls are hacked in and will never compare to the counterparts that inspired them. I'm sure this impacts performance somewhat.

    moreover I'm sure we can tie alot of "why it is that linuxe's PA version is so beneath window's" to this factor as well.

    lastly these out of date components not only are themselves out of date but depend on other components that are themselves out of date. I want to cite X11 as an example.

    currently modding in units that have a lot more polies and detail does not agree with PA when this unit is in large numbers. There are also a number of graphical calls you may feel the itch to use but are entirely unavailable. And props to uber for reimplementing a lot of calls but that is not something a modder can do.
  12. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    @tatsujb I think you are confusing a lot of things right now....

    Yes, the Linux version being so far behind the Windows version on some hardware is partially due to a different optimization level of the OpenGL drivers, but it's also due to only a small subset of the devs ever using Linux, like at all.

    As for the constraints on poly count for custom models: The problem is actually the poly count itself. PA is not computing low poly imposters as other games do. That means if you have many instances of an high poly model in your view, even when you wouldn't be able to see individual polygons at your current zoom level, PA will still try to render every single model in full detail. This puts a huge, unnecessary stress on the GPU. The problem itself, however, isn't so much OpenGL in this case, but the lighting model used. These extremely stretched real time shadows during dusk and dawn would make any simplification of the units model very much visible - unless one would provide shadow imposters as well. Which once again belongs into the area of technical debt - optimizations which were never performed because there was no time to do so.

    What's slowing the PA client so much down isn't the "reinvention" of certain features either.
    Yes, newer OpenGL versions even have extensions for virtual texturing to start with, but that's not what's killing your performance in the first place. The actual problem is inherit to all current gen graphics APIs, and it is the bottleneck between your applications code and the GPU caused by the DX/OpenGL API. Bypassing it currently requires you to carefully tailor your data flow to delay the final assembly of command buffers as much as possible in order not to block yourself from using the API, ultimately resulting in weird structures where you are buffering your buffers in your own application code only to get at least some multi threading capabilities.
  13. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,125
    Likes Received:
    16,255
    Afaik PA has imposters for trees, can't see why it would not be able to use the same code for more models. However PA actually simply doesn't display units at all from a certain zoom level on afaik. Icons hide them anyway.
  14. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    @exterminans @cola_colin but there are big limitations with old openGL compared to, say, vulkan. the transfer could in the end lead to unlocking graphical techs and performance leaps, right?
  15. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    Imposters for trees are quite simple - given how simple the shapes of the trees are. You can just replace them by a simple cone, and nobody can tell the difference, not even from the shadow.

    Most units are slightly more complex than that, there is just no simple geometric form which could cover all the details. They don't only have self occlusion such as the different layers of the trees, but also holes, fragile details on the outline, and various other non-trivial shapes.
    That would require an entirely different type of imposter, where the unit is not resembled by a 3D model, but rather by a normal and (3D) parallax mapped, 1bit alpha, directional texture. That's the only way to achieve the desired level of detail in the shadow map without resulting to full detail models. You would need a few dozen imposter textures per unit, as even with extended parallax mapping, a single texture can cover only a small view angle without running into issues with occlusion.

    So yes, it would be possible to use high quality imposters for units as well. But it's slightly more complex and would require more effort than Uber had planed for that feature...
  16. crizmess

    crizmess Well-Known Member

    Messages:
    443
    Likes Received:
    319
    Not exactly. If you don't optimize your graphic pipeline (for whatever reason), you will end up on suboptimal performance on all systems (this includes DXD3 as well).
    My guess is that it would be even worse on Vulcan, since this is a low level API you have to get even more right in the first place.
  17. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    Quite the opposite actually. Your graphics hardware has several hardware capabilities which make it much, MUCH easier to utilize your hardware, than what the current gen of APIs allows you to.

    It's somewhat as simple as the following:
    With OpenGL and DX3D, you have to gather all resources for the next draw call, submit, and then wait for the result until you are allowed to prepare the next step. If you want to bypass that, you have to go a long way of building your own abstraction around the OpenGL oder DX3D API so you get the ability to prepare the buffers and alike for the next draw call without being blocked by current execution. But even then you are forced to wait until all your buffers have been transfered to the GPU before the execution even starts, and then correspondingly to wait until all results have been returned. And usually a single shader alone isn't going to utilize ALL resources of your GPU to full extent. One shader might bound by memory latency, another one by memory bandwidth, another one by the throughput of the rasterizer, another one by the tesselation engine. Meanwhile, all the other parts of your GPU are idling.

    With Vulkan and DX12, that limitation no longer exists, at least not in that form. The API provides you not only with entirely unrelated, distinguishable buffers, but actually even allows you to use multiple command queues in parallel.

    That means if you have e.g. hardware capabilities for 8 hardware command queues, you can easily already create and fill buffers for all the individual shaders in individual threads, and the enqueue whatever shader has its dependencies sattiesfied into one of the idle command queues.

    You no longer have to fiddle around with implementing your own abstraction level and transfer logic - the API allows you to use native buffers and data structures as early as you want, and to commit them whenever you feel like it.

    So you split your graphic "pipeline" into a depency graph of atomic actions, and then you let mostly the driver/hardware decide which of these actions it wants to execute first or in parallel. You no longer have to decide that consciously, you only feed new "options" in whenever you see that one dependency has been fulfilled.


    Of course there's slightly more detail involved, such as that you still have a hardware limitation of how many independent command queues your hardware actually supports, so you will still need to perform *some* scheduling to decide which commands you submit next when you have multiple choices.

    That's however much similar to how modern CPUs work, you also have a limited set of execution units (CPU cores), and with simultaneous multi threading (marketed as Hyperthreading by Intel, and also utilized by AMDs upcoming Zen CPU architecture) each of these cores has actually the capability to queue multiple threads (equivalent to shaders) in hardware, and to decide on its own how to interleave commands from both threads for maximum utilization.

    If you had to perform that instruction interleaving in software you could still reach the same utilization even if simultaneous multithreading didn't exist - but it would make the development of software so much harder, so most developers would result to a much simpler scheduling approach such as "execute thread 1 for 10ns, and then thread 2 for another 10ns" which inevitably results in wasted time as inside the control flow of a single thread there are always gaps where the thread is waiting on certain hardware resources to become available.

    PS: That thread detoured much, didn't it?
    Last edited: May 10, 2015
    tatsujb likes this.
  18. crizmess

    crizmess Well-Known Member

    Messages:
    443
    Likes Received:
    319
    You missed my point. It is true that DX12 and Vulcan will give programmers a lot more freedom in how to organize resources and draw primitives, but with that comes a lot more responsibility. In particular Vulcan expects the client to do all the resource management and while it is true that this enables far more sophisticated solutions then we have today, but this requires a lot more thinking and work.
    As you said it in your example:
    So while I strongly believe that high-end engines will actually get better and faster, I still see the danger that small projects will end up worse, simply by the fact that there is a lot more possibilities to mess up your own render pipeline.
  19. exterminans

    exterminans Post Master General

    Messages:
    1,889
    Likes Received:
    1,013
    I don't think that's actually true. While Vulkan allows you to perform memory mangment of your own, you still have the option to leave the memory management to the driver, it knows both modes.

    It's not like Vulkan would require you to provide any additional resources, or as if Vulkan would allow you more errors. On the contrary, strict validation by linking an additional validation layer is one of the core principles. So even though you have much more options during the setup phase, the validation layer protects you more than ever from issuing invalid or error prone commands.

    The example with simultaneous multi threading was there, to point out how having certain features in hardware can actually simplify the development process compared to the mistakenly "simple", naive way of treating the hardware as "stupid". It really just means that you no longer need to wrap your mind around bypassing an artificial limitation, but instead you can use a much more abstracted cognitive model, and leave the optimization to the hardware itself.
    tatsujb likes this.
  20. tatsujb

    tatsujb Post Master General

    Messages:
    12,977
    Likes Received:
    5,423
    ds.jpg

Share This Page