Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Oct 2013
Offline Last Active Today, 02:09 PM

#5138486 Industrial Strength Hash Table

Posted by TheComet on 12 March 2014 - 01:08 PM

So let's see what the WTFs basically are...

  • Assigning a pointer generated from new to a type that is not a pointer
  • Using delete[] on objects created with new and not new[]
  • Using braces instead of brackets for trying to call the constructor of an object
  • Returning a pointer pointing to what is supposed to be an array of pointers pointing to pointers (given the new[] and delete[]), even though the value being returned isn't of type pointer (which is a double-WTF because if it were to compile, that would still be retarded)
  • using a lookup method of complexity O(n)
  • Attempting to declare a return type without template arguments.
  • Returning a nullptr in the case of not finding an entry, implying that the templated type is always a pointer.
  • Method names begin with a capital letter
  • not using std::map
  • code doesn't even compile




#5138380 Chained functions in C

Posted by TheComet on 12 March 2014 - 06:32 AM

(This is C btw, not C++)


I just came across the following. Regulator_t is a struct holding various parameters.

/* only one of these */
Regulator_t theRegulator;

int main()

    /* initialise regulator */
    set_coil_value( 0.0001f,                   /* 100uH coil */
    set_maximum_coil_current( 1.5f,            /* allow 1.5 amps */
    set_maximum_output_voltage( 200.0f,        /* cap output voltage to 200 volts */
    set_switching_voltage( 325.0f,         /* voltage from rectifier is 230*sqrt(2) = 325V */
    set_output_voltage_divider_ratio( 100.0f,  /* 1Meg to 10k is a ratio of 100 */
    initialise_regulator( theRegulator ))))));

    /* ---SNIP--- */

I'm not sure how to feel about this. Someone was obviously trying to be a smartass by defining all "set" functions with the pattern:

Regulator_t* set_whatever( float someValue, Regulator_t* regulator )
    regulator->someValue = someValue;
    /* do other important stuff */
    return regulator;

On one hand, it's a little confusing because the first section of code is executed "backwards", i.e. initialise_regulator is called first and then the chain is executed from the inside out.


On the other hand, it might actually be easier to read than doing it the traditional way:

initialise_regulator( theRegulator );
set_coil_value( theRegulator, 0.0001f );
set_maximum_coil_current( theRegulator, 1.5f );
/* etc */

Any thoughts?

#5138229 Function Pointers in Structs

Posted by TheComet on 11 March 2014 - 03:59 PM

@all - Thanks a lot, the information provided was very insightful to me, and I see that applying the "OO" style to my program is going to be overkill, adding unnecessary complexity.


Just makes me wish I was using C++ though - any reason you aren't?

Three reasons: Mainly because the program in question is simple, needs to be very close to the underlying hardware, and there actually isn't a compiler (that I know of) that is capable of compiling C++ code to the target architecture.


Even if there were a possibility to use C++, I'd neglect to do so. I feel more comfortable programming micro controllers in C because it keeps things clean and simple. Especially when others work with your code.

#5138070 Spritesheet Algorithms

Posted by TheComet on 11 March 2014 - 05:42 AM

If you cut them irregularly using some kind of recognition algorithm, you're just asking for the animation to screw up. How are you going to determine the correct offset for every frame so the animation frames are correctly aligned over one another?


Don't over-engineer things. Sprite sheets have always been designed so every frame has equal size. What purpose is there in changing this? The few bytes of storage space it could save is insignificant, and frankly, I don't see any other motivator to do what you propose.

#5137128 Reversing a procedural generation

Posted by TheComet on 07 March 2014 - 08:41 AM

Yet another example is MineCraft. The world is generated by a 32-bit seed, yet it is infinitely large (theoretically). Obviously, you can't reverse that back into a seed, as explained above.


I would like to point out that early versions of MineCraft used to save the differences between the original world generated by the seed and the modified world edited by the player. Alas, the longer the world existed and the more you mined, the larger the save-files became and the longer it took to apply the differences whenever you loaded the world.


I recommend saving absolute states and not relative states. You can optimize it in many ways, one way is only saving the sub-sections that are different than what was generated by the seed.

#5136834 Pathfinding avoid a list of polygon

Posted by TheComet on 06 March 2014 - 09:32 AM

As mentioned multiple times, use navigation meshes, they're your best bet.

Is there a more professional aproach to solve my problem?

The following are two libraries. Recast Navigation generates navigation meshes and Detour is a powerful pathfinder, capable of searching for paths as well as handling the movement of agents.



With that you can

  1. Automatically re-generate navigation meshes on the fly.
  2. Search paths for different sized agents.
  3. Control movement of agents using advanced flocking algorithms.

#5136350 Pathfinding avoid a list of polygon

Posted by TheComet on 04 March 2014 - 12:22 PM

Consider using A-star instead of dijkstra, it'll be a lot faster, and requires only a small modification to dijkstra's to make it work.


Secondly, don't rebuild the path every frame. Maybe space the rebuilds over 60 frames (1 second apart). You might even do it in a background thread so the main thread can continue with processing the game, and take over the newly generated graph once its ready.

#5136293 Unmaintainable code

Posted by TheComet on 04 March 2014 - 07:11 AM

I refuse to believe this is how it was programmed.


He's got to be screwing with us. Obfuscation, perhaps?

#5136291 Code lines number influenced by formatting style.

Posted by TheComet on 04 March 2014 - 07:06 AM

If you get paid by the number of lines created, or if your boss even cares about this as some kind of metric, it's time to switch job.

Or write the most inefficient, crappy code imaginable. Unroll your for-loops, replace arrays with variables having actual numbers in their names, and obviously add "hacker protection code" to impress your boss - that's far more enterprisey.


You'll become the top programmer in no time.


(warning: post contains severe sarcasm)

#5136181 Help with lighting options

Posted by TheComet on 03 March 2014 - 03:14 PM

Okay, upon closer inspection, I understand why the tangent transformation matrix is being used in the pixel shader. It's because there really isn't any other way to do it.


If you did the transformation in the vertex shader, you'd be limited to the number of texcoord channels, but by moving it to the pixel shader, you can go way over the 8-light-limit. You're just trading that off for speed, because for every single pixel on the screen you're doing light_count+1 number of transforms into tangent space.


My educated guess is that the slowdown has something to do with that transformation matrix.


The way I see it, you have two options:

  1. You could consider multipass lighting. Basically, the pixel shader is called once for every light in your scene, and you blend them all together. It's very speedy because no state changes are involved.
  2. You could optimise the crap out of the current shader, and cross your fingers in the hopes of it being a little bit faster.

If you choose number 1), I need to know something: Is it possible to use for-loops inside a technique?

#5136038 Help with lighting options

Posted by TheComet on 03 March 2014 - 03:25 AM

I see a few problems with this shader.


  • The TBN matrix is calculated and used in the pixel shader?! That makes zero sense, and is a slowdown in performance. You should never be doing transformations in pixel shaders. It's enough to do the necessary transformations in the vertex shader and pass what's really required to the pixel shader, since the rasteriser does the necessary interpolations. So: Don't pass the binormal, normal, and tangent to the pixel shader. Instead, construct your TBN matrix in the vertex shader and transform the necessary vectors required for lighting in the vertex shader, and then only output what the pixel shader needs.
  • You are unnecessarily sampling twice from the normal map. Sampling textures is an expensive operation.
  • The input datatype for your pixel shader is VS_OUTPUT. This means the rasteriser is forced to unnecessarily interpolate registers it doesn't really need (POSITION for instance).
  • On some cards, using integers for for-loops is a huge slowdown. I've observed this before on my laptop when writing a fractal shader. The solution was to use floats (you might want to consider using float16 to save space and computational power).
  • You're always allocating space for 16 lights, even though you might only be using 1. This seems inefficient to me.

You might also want to consider using a lower shader model as well. None of the commands in your shader require shader model 3.0.

#5135415 How can i convert texture formats?

Posted by TheComet on 28 February 2014 - 11:32 AM

I'm in no way a whizz in Java, but maybe this will help you:


#5135108 does a dll much differ to a lib?

Posted by TheComet on 27 February 2014 - 11:53 AM

Read this



#5134981 C++ Constructors vs. Init() Functions

Posted by TheComet on 27 February 2014 - 03:36 AM

For large/complex professional game engines, this commonly includes:

don't use the standard new/delete/malloc/free (use some engine-specific replacement / wrapper),
don't use std containers (as they will call new, and custom allocator mechanisms are broken),
don't use exceptions (as writing to satisfy the "strict exception safety" guarantee is hard in C++, there's a performance impact, and some gaming platforms may not even support them),
don't use RTTI or dynamic_cast,

and sometimes includes (these used to be common 10 years ago, but not so much today).

don't use anything in std,
don't use templates.

But that's just C without the ++, what's the point of having all of these fancy features if you can't use them? I'd also think that writing your own containers is more error prone. Then again, I was never affiliated with the gaming industry, I'm sure these decisions are for the best.

#5134728 name mangling..

Posted by TheComet on 26 February 2014 - 06:08 AM

I'm desperately trying to understand what you're trying to ask... Could you repeat that?


Are you asking why they didn't just use the function signature instead of a mangled name?