So a few bugs that still seem to be present: Enemy commander spawned near a crevice, walked to the edge of the crevice and got stuck after a couple minutes. Don't know if this is a pathing or an AI problem though. PiP is still causing problems. While it is active, the circles for area commands will flash smaller/larger when trying to give the order in the main view. Vision circles also flash. I also had a fairly large, square area of the map turn pitch black when viewed at specific angles and/or distances. At some angles, only a portion of the area would be black. I'm assuming that it has to do with the LoD system used for planets' textures, it seems that one level of detail for that area was missing, or something of the sort.
Fabber assist is still problematic. At the moment when fabbers are ordered to assist another, they will approach while the target is moving, and they hold their position while it's building.
Yeah happend to me aswell, although it's less problematic then it was a while ago. So it seems they are working on it as we are speaking about it right now.
We were about to go live with this build. For the problems, it was still overall a huge improvement, but we held up on the fact that 9 and 10 player games were breaking. On the plus side, Ben found and fixed what was going on with nuke/combomb on ATI cards.
Code: --- a/pa/terrain/earth.json +++ b/pa/terrain/earth.json @@ -69,14 +69,14 @@ }, { "elevation": [ - 0.4, + 0.6, 1, 3 ], "spec": "/pa/terrain/mountain/mountain.json", "temperture": [ - -1, - 1, + -0.8, + 0.8, 1 ], "water_distance": [
For those curious, the reason why the effect was broken ended up being pretty simple. The reason why it worked at all on NVidia is more interesting. So the reason it was broken deals with how we setup vertex data for meshes. I hadn't set them up to properly be saved with normal, binormal and tangent vectors, so they only had surface normals. For normal maps to work you need all three vectors (or you can do some extra math in the shader to make a good guess, which I almost fell back onto). For those curious they can do a google search on the topic to learn more. On AMD the game was handing over the mesh with just normals, and then the shader was trying to use the normals, binormals and tangents, that later two of which didn't exist. Since they didn't exist the data the shader was getting was just random data and nans. Instead of rendering essentially random junk data to the screen it nicely just threw out those pixels and pretended they weren't there. On NVidia the game was handing over the mesh with just normals, and the shader was trying to use the normals, binormals, and tangents. However NVidia drivers were magically realizing the shaders wanted that information and generating usable vectors somewhere behind the scenes from the data it had!
Did you give Nvidia all the data it needed in the end or just let it do its own thing as it seemed to be working fine? If it was having to try and recreate the data I guess it has to work a little harder so better to give everything upfront right? Plus that way you can guarantee consistent results?
We don't differentiate the content files themselves between video card vendors, which is where the data was missing. Fixing it for AMD means NVidia gets all the data too, though it made me wonder if NVidia might always throw out that data anyways and reconstruct it to save on bandwidth costs.
Should have reported this earlier, but the battleship now has working sound banks! (it has sounds when it fires) I wondered what broke the battleship's sound banks in the current stable build?
Sorry if it is mistaken you for someone else, it's just an awesome avatar. I already used this avatar on my steam profile page
bgolus assumed that Nvidia "guessed" some data points. If it has normals, usually random (pluasible) tangent+binormal pair can be generated with very little cost. Can work quite well if you don't care about orientation of the tangent vector. Breaks horrible when you encode additional information in either tangent or binnormal vector, e.g. two-dimensional shaders (as opposed to the regular one-dimensional shader which only uses view angle, but doesn't care about orientation of the material). Example where this is doomed to break horribly: Shaders simulating velvet or similar materials. So: No, Nvidias driver probably won't dare to discard tangent or binormals when provided. Even though it MAY try to optimize them out when compiling the shader whenever it detects that the additional information is not actually used. What's probably also what it did in the case of the shader bug in PA, it detected that tangent and binormals were not actually required and substituted them with the tangent vector. Good explanation what these vectors are in the first place: http://gamedev.stackexchange.com/a/51402
Just wonder. Is this problem was in shader code only? E.g can I copy some shader from old version to compare them and test it?
