Jump to content
The Dark Mod Forums

totallytubular

Member
  • Posts

    102
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by totallytubular

  1. Yeah, where to shove the load on shaders is the aggravating part. The shaders I worked on, I experimented with euclidean vs. manhattan distance to cut-down partial derivative decompression calculation of normals. Looked fine on some textures, but others it did not. But, performance didn't change noticeably, b/c...like you said.. texture calls are expensive, still need to get called, and it comes down to memory amount and bandwidth mostly.
  2. New here. I'm a data analyst by trade (sql, etc), but dabble in game dev stuff in my spare time. So, I'm def not a developer. Hence my question may sound dumb to seasoned devs... I dl'ed the Dark Mod source, and just scanned through some of it, mainly seeing if I could help tweak, optimize or help on the GLSL. (I worked on an HLSL mod for a game, so spent a lot of time learning shaders and tweaking them.) I looked at some of the .h and .cpp files, though, and noticed some redundant calculations... EG: In the /renderer/MegaTexture.cpp, there's several functions that have things like this... (I copied this from the "GenerateMegaMipMaps" func)... // mip map the new pixels for ( int yyy = 0 ; yyy < TILE_SIZE / 2 ; yyy++ ) { for ( int xxx = 0 ; xxx < TILE_SIZE / 2 ; xxx++ ) { byte *in = &oldBlock[ ( yyy * 2 * TILE_SIZE + xxx * 2 ) * 4 ]; byte *out = &newBlock[ ( ( ( TILE_SIZE/2 * yy ) + yyy ) * TILE_SIZE + ( TILE_SIZE/2 * xx ) + xxx ) * 4 ]; out[0] = ( in[0] + in[4] + in[0+TILE_SIZE*4] + in[4+TILE_SIZE*4] ) >> 2; out[1] = ( in[1] + in[5] + in[1+TILE_SIZE*4] + in[5+TILE_SIZE*4] ) >> 2; out[2] = ( in[2] + in[6] + in[2+TILE_SIZE*4] + in[6+TILE_SIZE*4] ) >> 2; out[3] = ( in[3] + in[7] + in[3+TILE_SIZE*4] + in[7+TILE_SIZE*4] ) >> 2; } } I'm a noob at understanding the optimizations compilers do.. In working with java & python, I'm pretty sure when calculations are done in a loop call, the compiler is smart enough to calculate something once. (So, I'm pretty sure a C-compiler is smart enough to do that, too). IE: the TILE_SIZE / 2 in the "for" statements will get calculated once, not each time the loops loop and the statement is evaluated. (I may be wrong, though. I'm projecting my experience from java / python after I ran tests when coding various projects. I've never done C++ development, so unsure how the C++ compiler would function.) But, in the body of the code after the 2nd "for", the TILE_SIZE/2 is calculated 2 more times on the byte out. So, pre-calc once for the first "for" to use over and over. Another time (?) for the next "for" to use over and over, then 2 more times in the body each time the 2nd for loop runs. And, I'm assuming each time that block is ran, it's calculating those 2 calc's each time. Also have TILE_SIZE * 4 calculating 8 times in the body, which, if those are re-calculated each time that block of code runs, would be a lot of redundant calculation. Does the compiler notice this, and optimize it down to a single one-time pre-calculation, or is it actually calculating this stuff over and over? I guess I'm wondering if a variable should get declared, and the TILE_SIZE * 8 and the TILE_SIZE / 2 should get calculated once and used wherever those parts are. Maybe it's written the way it is, b/c it's a case of losing precision due to floating point error? (IE: creating a var would "round" the result and create erroneous results, which is why the calculation is done each time it's needed?) I don't know. I'm a nub on that, too.. but from doing shader work, I learned that sometimes it's better to let a redundant calc run multiple times to avoid precision error. I'm not even sure if the code is being used.. but I was just looking at various files, and noticed some had redundant calcs. I was wondering if this was something I could tweak and submit changes for? Coming from the shader side of things, there's the push to reduce calculations as much as possible to prevent shaders from bogging down the FPS. IE: reduce instruction set use, use intrinsic functions, move as much stuff to vertex side instead of pixel/fragment. Having some redundant calculations in a global var the game engine calc's once before piping to shaders or something doesn't make any impact. But, having a shader-like function called many times to generate vertex / pixel could create performance impact with redundant calc's.
×
×
  • Create New...