Flickering Textures? Nvidia card?
I have been testing it this morning with 186.xx and it seems to be working well. I want to make sure this is holding up with the most stable driver series before I start messing with the others. I am also going to download some developer version of the TBB library and hopefully I can figure out what pointers the ETW EXE is using so i can compile some binaries myself. The download above is a precompiled binary.
I also need to find the shader code wherever it is buried in ETW. I am an HLSL programmer and can make any neccessary changes that need to be made, assuming the issue lies in the shader code itself. The EXE will contain the core engine components which i will not be able to change at all.
Harrr! I hath found the shader files. They be located in main.pack.
The seem to be raw HLSL which is great, which means I am free to do any modification neccessary. WOOT! The code structure is confusing as there doesn't seem to be a main header file with pointers *facepalm*. I am going to have to go through and just find where everything is manually. Shame on CA, who the heck doesn't include a main or common.h header?
Here is something VERY interesting. So going through ETW shaders I can already tell you how they work.
Essentially, ETW is Shader model 2. No wonder it runs like **** under SM3.0 with the newer drivers. Memory allocation issues aside, the only difference between the SM 2.0 model used by ETW and the SM3.0 option is a fake BRDF algorithm.
You what makes it all worse?! The SM3.0 shaders wheren't even DEVELOPED by CA. They are 3dsmax and Maya shader code with a creative commons license!!!
WTF?
So our issues with nvidia cards (can't speak for ATI, I don't own an ATI card) are going to be found in a mere 3 files worth of source code more than likely. CA used some strange hybrid SM2.0 and SM3.0 garbage, and didn't even code thier own SM3.0 shaders to boot.
In layman terms, CA used an old shader model to point to a newer shader model, and compiles them concurrently and expects them to play nice with each other. What nonsense. I have to go get ready for work and leave and I'll pick back up on this tonight. I can't even begin to describe what I am looking atright now. It's like someone stitched up frankenstein code.
EDIT2: Okay, last edit before work. I know what the issue is basically. With the new nvidia drivers, the alpha maps are being incorrectly calculated, thus the disappearing buildings and trees. I think anyway. The reason SM2.0 works is because alpha blending of shadows is turned off. I do believe ships being visible still with the new drivers is because the shadows have no alpha blending on the water, but I'll have to do more research into this. There is a lot of code to go through. Tonight I am going to try and disable alpha blending of shadows in SM3.0 and see if that temporarily solves the SM3.0 issues under the latest nvidia driver set, and if that works, at least we can play the game with SM3.0 under the latest driver set until i can figure out how to fix alpha blending.
I'll have to recode the shaders once I get it nailed down and repack it as a mod, so It'll be just as easy as installing any other mod. Anyway, off to work. Updates tonight (10pm CST).
I am having a real hard time understanding the code structure of ETW. Shader language uses header files like C and C++. Each shader file is bound to 6-10 different other dependent files. Instead of being depended on a header which then points to another shader file and so forth, in a linear arrangement, the code is set up like a bowl of spaghetti.
It is going to take time to go through this and determine the exact source of the issue. I have narrowed it down to a few shader files that seem to be culprit, but I have to be able to change the code without breaking any dependencies. The best way to describe the situation is by imagining a game of jenga. Your getting down to the very end and everything is about to collapse, but to win you need to find a piece to remove without destroyign the entire stack.
I am not sure, try it out, I haven't tried anything yet as far as the latest drivers are concerned as I have been studying the shaders carefully.
Give it a shot and see. The more I look at the shader files, the more I think it is the shaders causing the disappearing models problem. I am going to start moving work away from the GPU side of things and over to the CPU, and that'll help narrow the issue down. I can however say for sure that the new TBB.dll I linked as well as the TBBmalloc.dll improve multithreading some.
Another note...
In shader model 2.0a and 3.0 ETW basically copies all of the meshes that are used alot in game in the GPU, such as trees, buildings, units... This isn't really neccessary with a modern CPU because the CPU will always require the same amount of resources to make a mesh and copy it, whereas the GPU will get bottlenecked by making all of the copies of the coordinates. I may be able to move these instructions over to the CPU side of things and see if we can now see trees and buildings on the campaign map. In the very least, it may create a performance boost in doing so if and when i narrow the actual problem down.
Hmmm, I am somewhat at a loss.
It seems, from being up all night looking at spaghetti code, and testing things out, it is a z buffer issue. I am uncertain as to how to solve it The code for it in the shader fragment file looks like it is supposed to, but the nvidia driver keeps putting the trees and buildings on Z plane below the terrain on the campaign map. Nvidia does use a strange z buffering technique that I have not messed with much so it might take a while before I can pin this down. This may also be the reason why ATI users aren't having such problems...well, that I know of anyway.
I am also used to deffered rendering techniques, and the ETW engine is a forward renderer, so I am somewhat having to learn as I go here with this type of layout. The code is the same but the structure is different.
Does anyone have a card that is NOT an Nvidia 8xxxx 9xxxx or GTX series? The zbuffer implementation changed between the 7 series and the 8 series so I need someone with an FX, 6, or 7 series card to let me know if they are having any issues with the latest drivers.
Just to add something unrelated to the above...
Let's say in the instance I can't figure out the issue, or the code that is breaking the engine is compiled in the empire.exe (which part of it is), I can always still recode parts and make it look better. So if all else fails, at least we can make it look cooler. I am going to try and fix this, but like I said in an earlier post, the forward renderer used by ETW is not what I am used to, so it may take a while.
Anyway, if anyone with a geforce 7 series or older that can run shader 3.0, let me know how your game is going.
I honestly don't think i am going to be able to fix it. I think i have turned over every rock and change every code entry seemingly related to the issue, and nothing at all.
Based on what i have seen with experimentation, and how the code in game reads, the issue is caused by either A) the depth buffer or B)Campaign map overlays
It seems this code, in both cases, is hard coded into the empire.exe file, which i cannot change. I believe the cause to be a combination of both really. The trees and buildings are being culled (removed from screen space) which is great if you cant actually see them with the camera, but in our case it effs the game up. I also think this is caused by bad code in the trees/buildings overlay. I am willing to bet nvidia fixed a z-buffer fighting problem in another game and it busted ETW. The buildings and trees may be too close to the terrain overlay plane and the driver is culling them. Hell I don't know, I am baffled myself.
To support my theory, if you open up the etw campaign map under the latest nvidia drivers, obviously you wont see anythingbut terrain and units. Alt+tab out and back in. You'll see the trees and building overlay load and the terrain overlay will then load on top of it!
I'll keep looking into it, but I am not sure what I'll be able to do at this point. I may find a work around to bypass the hard coded coordinates in the executable through the vertex shaders, but who knows.
I really REALLY don't want to buy NTW, but I REALLY REALLY want to so i can disassemble it and figure out just what the hell they changed....that's assuming it works with nvidia's latest driver revisions.
In the mean time while looking into the problem further, I am going to look into the BRDF shaders and see if I can improve them. Hey, you may have to run older 181/186.xx drivers but at least it'll be prettier!
By the way, BRDF basically, is what simulates the lighting effects to real world light reflections in the game. They used some stock 3ds max and maya shader garbage intended for geforce 6 and 7 cards. I may be able to improve that because ALL of that code is ran on the GPU independantly.
I've actually had the best luck with the 186.18's.
I'll do a brief explanation of what I am talking about. Sorry for all the mumbo jumbo
Basically, with current generation 3d graphics, everything is put on screen by a vertex shader, which assigns either 1,2,3 or even 4 dimensional coordinate for every single pixel and polygon on the screen. These individual pixels then have to be colored, and colored dependant on the light source, material surface, shadowing, etc. Mathmatical algorithms take the coordinate information which was computed earlier by the vertex shader, and determines the color a pixel needs to be based on the coordinate position of the lights and the preset material reflectance (which can also be dynamic in some cases)
This is done for every single pixel on screen, for every single frame, using 100's of variables that where precomputed before and will be computed again for the next frame. Your video card is a very VERY powerful number cruncher.
Just to use an example, let's say we have a boat floating in water on screen. The sun above is casting light down onto the water surface and the boat itself. Each pixel making up this picture has a coordinate in 3 dimensional space according to the video card (4 dimensional actually, but that makes things more difficult to explain). Now, the video card has to determine where every single pixel is in relation to everything else on the screen. Remember, we have a light source, a boat which casts a shadow, and water which will be reflective in some places and not in other relative to the viewer. So the video card computes where the viewer is, where the light source is, where the boat is and compares it to the location of x,y,z pixel. It can then determine what color the pixel needs to be. For example, a wave crest may appear almost white at the sharp crested edge, due to light reflectance, and the boat will be dimly colored on one side due to the shadow cast by the light source. The GPU computes the coordinates based on however number of variables (light, shadow, material, etc.) then flattens the screen to a 2d image and colors it. It is much more complicated than that, but that is the most basic explanation I can provide.
Anyway, the way ETW works, is all of the models are computed based on an X,Y,Z axis space on the screen. Basically, we have a broken Y axis. Trees and buildings (guns and cannons in some cases) being rendered underneath other objects such as terrain. The GPU KNOWS what will be and what will not be visible on the 2d screen once rendered based on coordinate information. Thus, technically, the trees and buildings are not in fact being rendered. They fall on the z axis below the terrain, the gpu recognizes this, and they are no longer computed. This is done to save on resources and processing power. This is a good thing, sorta. Why compute something if it will not be visible in the final image? Basic explanation, the gpu is not computing buildings or trees because it physically sees them below the terrain on the Y axis, thus not going to be visible to the viewer on a 2 dimensional screen space.
Now, it is just a matter of figuring out why exactly this computation is going wrong. Obviously, the trees and buildings are not supposed to be computed below the terrain. ETW computes the campaign map in overlays. Terrain first, buildings and trees second, flags and units third. For whatever reason The overlay (order in which the campaign map is layered) is being computed in correct order, but with the wrong coordinates in 3d space with the buildings and trees.
Make sense?
Edit: I keep reffering to the Y axis as the Z axis... I have no idea why. I edited my explanation but if I missed somethign and said Z axis, i actually mean Y axis.
Freaky....really freaky.
I Just bought windows 7, did fresh install, and bam 196.34 drivers work.
Hmmmm....
181.xx or 186.xx
The 186 driver was supposed to be fixed for ETW. I would try that first.
On the flip side, I want to know what happened with ETW when I installed windows 7. How frustrating yet good at the same time. I have no isses at all now with windows 7 64 and the latest driver.
Is anyone else running windows 7 64 and having issues with the latest driver? I wonder if an old DX redistributable is at fault?
Darthmod Moderator
Re: DMUC 5.4.1: THE MOST FREQUENT ISSUES AND THEIR SOLUTIONS
Civis
NEVER SUBMIT
Originally Posted by hammeredalways
Semisalis
I havent played Napo as I dont have 18GB free in my computer and my new computer is still on routte so I can only serve as mouth of others in this issue but I understand from darth's review (and some more people that have try it so far) that the new BAI is vainilla in its heart as were all the previous ones.
Dont ofuscate yourself! It's pointless to resist . . .
Decanus
Campidoctor
