Jump to content

  • Log In with Google      Sign In   
  • Create Account

Shannon Barber

Member Since 23 Jun 2000
Offline Last Active Yesterday, 07:10 PM

Posts I've Made

In Topic: Should video game mechanics be scripted?

Yesterday, 07:12 PM

Most will need to be coded.

You're unlikely to get the performance of the effect you want if you implement it all in script.


In Topic: Finding that balance between optimization and legibility.

16 July 2016 - 07:10 PM

There is no possible way that code speeds up the calculation of sin and cos values for vectors and it introduces problem with reentrancy (it's not thread safe).


When optimizing this sort of code there are three things you must do to achieve state-of-the-art performance.

1) Ensure you are using the greatest known mathematical reduction of the algorithm

2) Eliminate all branches (even if it means more calculations)

3) Use vectorizing operations, e.g. SIMD, NEON, AVX, et. al.  


Optimizing the code for vectoring operations can be very annoying.

Algorithms tend to favor separate arrays for each element/dimension as opposed to interleaved arrays which are more conveniently to deal with.
This cuts down on loading and packing time of the MD registers and that can be critical to utilizing all available computation units.


Doing the above and eliminating any IEEE-754 or C-standard overhead (e.g. if the rounding rules of the unit is different than the standards then it has to perform a conversion when storing) is how you make it fast.

The old fsincos instruction got it done in about 137 clock cycles; SSE2 and newer should have faster or more vectorized options.

If you can sacrifice accuracy then you can use an estimation of the sin and cos values and those algorithms are generally just multiplies and accumulates and you can get it done in a lot less than 100 clock cycles.

In Topic: The big face-off between inheritance/interfacing

16 July 2016 - 06:57 PM

Thanks for the swift response, guys. I've done some research and it actually seems like this approach would make much more sense than my current one. They really didn't touch up this at all when I did my degree, so it's refreshing to learn about. I do have to ask, though, what are the negatives? This approach seems better in almost every aspect? Is it more a case of inheritance still having its uses in niche situations?


The negative is that you are completely systematic and successful as found in a game like Dungeon Siege.  
They effectively created a another set of unbreakable laws of physics for this game which makes the entire thing feel monotonous.

Nothing unexpected ever happened in the game because they didn't break the laws of their universe to do it.


The other much maligned approached means every new object introduces new game mechanics (or at least has the potential to) - as found in a game like Minecraft.


I think those two games demonstrate the emergent affect of taking either approach to an extreme.

In Topic: responsiveness of main game loop designs

03 June 2016 - 02:53 PM

To do this optimally you need a buffer of input events with hardware time-stamps.

I was hoping that DirectInput would evolve towards that but it was abandoned and we're back to sucking messages from the pump.

That at least provides an ordered list of events but without the time-stamps you cannot even implement something as simple as pulling back the plunger for a pinball game accurately.

You get quantized to your polling rate and experience jitter corresponding to your input-stack and thread stability.


You could compensate for this by introducing the uncertainty of your input into your hit detection.

When you receive an event you know it happened between between 'just now' and one polling period ago which gives you a delta-time.


Humans do not act "at 5Hz".  

I can push a button for less than 10 ms and routinely demonstrate how HMI's cannot handle button presses that quick (and we show on an oscilloscope that the button was indeed pressed for 7~12 ms).


60 Hz vs. 120 Hz makes a notable difference for FPS games and it's probably due to the triple-buffering.

3 x 1/60 -> 50 ms. That's an eternity.

In Topic: Custom editor undo/redo system

10 May 2016 - 12:15 PM

The (de)serialization (second) approach can have a significant performance impact for moderate data-sets.

In a tool I wrote long ago we had to stop doing it that way and use the command pattern with undo/redo stacks (otherwise every time the end-user made a trivial modification there was a pause as the data was serialized.)