How feasible is a port to OpenGL 4.5 ?

There are a number of new api's beyond DX12 (Vulkan is the one that succeeds Open GL and is cross platform). The point though is as @ace63 said, PA doesn't need faster rendering speed. It needs a faster simulation to cope with more units (also with respect to planets, it memory that limits planet size rather than rendering in my experience).

PA really could use a multi threaded simulation for units and projectiles to really make it fly, as that is currently the biggest bottleneck. Doing that would shift the bottleneck back to the render engine, at which point then maybe there are some gains to be made on a newer render API but doing that first is kinda pointless as is.

PA / Titans isn't going to get that as a multi thread simulation represents a serious undertaking on the core engine side and would cost a lot to do. TA, SupCom, FA, SupCom2 all ran on single thread simulation engines as far as I'm aware. The only successful multi thread simulation as far as I know of is the multi thread fork of the Spring RTS engine (which is btw *seriously* fast), however that's also closed source which is why it was removed from the core engine and know one besides the author knows how it works.

I'd like to think if Uber ever get the opportunity to make a fully fledged new game that builds on from PA, maybe they could look into a multi-threaded engine to allow for even larger scale craziness, unlikely but we can dream

Just in case you wonder how it could look:
cheatengines memory view, the optcode column shows really some low level code which you obviously can read but understanding...


it would take you weeks to learn that type of assembler and then months to understand the pa code, both fulltime ofc

its basically a step by step guide for the pc

not to mention the fiddling when pa gets an update on that end


i dont think pa needs better graphics they are sharp enough for their purpose (like tf2 where the graphic doesnt look too old after years) the only thing that doesnt look good is the shadow which divides day and night on a planet:

The funny thing about the shadow, it's significantly better than it was originally and is probably as good or better than almost any other engine out there if you were to try to recreate the requirements. Shadows are an unsolved issue in traditional rasterized rendering. Every shadowing technique gives up something, and almost all of them fall down on the issue that screenshot is of. Neither DX12 nor Vulkan can fix that. About the only thing that can be done is blur the crap out of the shadows, which has the side effect of making small objects not have shadows or appear to be floating (the shadow doesn't quite meet the point where it touches the ground, referred to as "Peter Pan"-ing).

Hey that is the tool I spent many days on to be able to read out unit positions and stuff from the client for the first version of the ubermap My results were enough for what I wanted, mainly only understanding the data layout in memory. Actually understanding the asm code to the level of rewriting it.... yeah you are way better of just rewriting it from scratch instead in C++.

Am I correct in my understanding that a Ray trace based rendering engine would solve the shadow problem? Obviously I'm aware that high definition Ray trace rendering at high frame rates isn't there yet.... Might be a thing in a couple more gpu generations though?

Raytracing brings a whole separate set of issues with it, but yes with enough computing power you can get perfect geometric shadows with Raytracing. This also means you need all of the geometry to do the shadows so normal maps are out else you get stuff like doom 3, which isn't raytraced but the volume shadowing technique gets the same results for cheaper.

In addition to the above, there are some really interesting hybrid methods: Unreal engine for example uses a method known as ray marching for soft shadows (distance field shadow feature). In this case you use an normal rasterizer, but on each pixel (in the Fragment shader) you do a special form of ray trace against the light source.

Ah crap, I can't find the MT spring page anymore, it seems to be lost.

It can be found here: http://rtsmp.com/

thanks m80

Varrak did some cool blogs about engine earlier, but now he is not online for a long time. Maybe make some update on engine how it changed with Titans in a blog? Pretty please :3

I don't care so much about the shadows or optimisation as I do the ability to load complex models made up entirely of curves into PA having tessellation ect... is that currently possible?

There's nothing stopping you from using a high poly model in PA; the Helios is ~25k polys which exposed some bugs with our high poly handling that's been fixed. If all the game models are upgraded in a similar fashion you're going to have performance problems, especially since we don't have an LOD system for our models beyond not rendering them at far enough away.

Tessellation isn't happening, even if we were a OpenGL 4.5 engine to begin with.

well I need to decompile something for a different game to find an encryption key that's hidden somewhere, so maybe that will work

Will there be LOD system for models in the future for better performance?

Edit. Probably buildings and titans, because normal units are gone under icons if you are far away enough.

No. It's unneeded for PA because our units are so low poly. When we first added the feature to turn off models hidden behind the icons we expected a decent performance win, but the result was the performance improvement was so small we couldn't tell which was the before vs after performance log. The "big win" came from turning off animations when units are small, but not yet hidden by the icon. Animation is purely CPU side still, so it alleviated some pressure where our bottlenecks already exist.

Did you guy investigated how much LODs for planets would bring?
Because I have would guess that these can get a really high poly count, especially if you go beyond 1000r and you use a lot of CSGs.

Can't be done since the game is coded in opengl and that would require not only a total rewrite but also maintaining two game engines since DirectX12 is windows only, and we would still require opengl for linux, and macs

To me the REALLY interesting question to the devs is how possible would be changing the game for a multi-threaded sim.. that is where we would notice huge benefits.

Most of the poly count of larger planets actually came from the "features" (trees, small rocks, greebles, etc.) which do have something of an LOD system.

Really large planets with lots of CSG are still probably only a few hundred thousand polys. That sounds like a lot but with features a large, tree covered planet was getting to tens of billions of polys. At one point we had the game crashing because we were running out of video RAM from the planet mesh alone.