Erik McClure

So after a lot of misguided profiling where I ended up just testing the stupid CPU cache and its ability to fucking predict what my code is going to do, I have, for the most part, demonstrated the following:

is slightly faster then

where funcptr is an array of the possible function calls. I had suspected this after I looked at the assembly, and a basic function pointer call like that takes around 11 instructions whereas a normal function call takes a single instruction.

In debug mode, however, if you have more then 2 possibilities, a switch statement’s very existence takes up almost as many instructions as a single function pointer call, so the function pointer array technique is significantly faster with 3 or more possibilities. However, in release mode, if you write something like switch(rand()%3) and then just the function calls, the whole damn thing gets its own super special optimization that reduces it to about 3 instructions and hence makes the switch statement method slightly faster.

In all of these cases though the speed difference for 1000 calls is about 0.007 milliseconds and varies wildly. The CPU is doing so much architectural optimization that it most likely doesn’t really matter which method is used. I do find it interesting that the switch statement gets super-optimized in certain situations, though.

Ok probably not the most bizarre error ever but it’s definitely the weirdest for me.

My graphics engine has a Debug, a Release, and a special Release STD version that’s compatible with CLI function requirements and other dependencies. These are organized as 3 separate configurations in my solution for compiling. Pretty normal stuff.

My example applications are all set to be dependent on the graphics engine project, which means visual studio automatically compiles the proper lib file into the project.

Well, normally.

My graphics engine examples suddenly and inexplicably stopped working in Release mode, but not Debug mode. While this normally signals an uninitialized variable problem, I had only flipped a few negative signs since the last build, so it was completely impossible for that to be the cause. I was terribly confused so I went into the code and discovered that it was failing because the singleton instance of the engine was null.

Now, if you know what a singleton is, you should know that this is absolutely, completely impossible. Under normal conditions, that is. At first I thought my engine instance assignment had been fucked, but that was working fine. In fact, the engine existed for one call, and then didn’t exist for the other.

Then I checked where the calls were coming from. What I discovered next blew my mind.

One call was from Planeshader.dll; The other call was from Planeshader_std.dll - oh crap.

Somehow, visual studio had managed to link my executable to both instances of my graphics engine at the same time. I’m not entirely sure how it managed that feat since compiling two identical lib files creates thousands of collisions, but it appears that half the function calls were being sent to one dll, and half the function calls being sent to the other. My engine was trying to run in two dlls simultaneously.

I solved the problem simply by explicitly specifying the lib file in the project properties.

Surely my skill at breaking things knows no bounds.

Syncing a game over a client server connection is not an easy task. It’s actually extraordinarily difficult and is almost completely reliant on the quality of interpolation. Due to the nature of interpolation, it gets exponentially more inaccurate the more time is spent doing it. Therefore, a game designer should want to minimize the amount needed. This is not an easy task, but it usually involves using the server as a middleman to halve the interpolation time. The only issue with this is that the server’s interpolation becomes reality, so while a client interpolation can be fairly inaccurate and simply corrected later on, the server’s world is reality.

This has two consequences, one is fairly obvious: the server interpolation between the time the player hit the move button and their current location must be extremely accurate, while the client interpolation can be fairly sloppy. If however, the server is a dedicated server (or has a parallel physics world), then a small trick can be employed - the server’s physics world need only be updated with every physics packet received, enabling an accurate physics simulation for a fraction of a second and eliminating a small amount of interpolation. An additional measure can be taken by utilizing a peer-to-peer connection between the clients and sending tiny packets of button notifications. These, if they happen to get to the client before the server packet does, can improve perceived responsiveness by giving the client a heads up on whether a player has fired something.

Another possible method of interpolation involves knowing where a shot should be and where it is currently in the view of a network player, and accelerating it until it reaches its intended destination. This is, however, problematic in terms of multiplayer shooter games because a shot quite often will hit another player or some object within the timespan of the ping and subsequently cause massive confusion on part of the player who thinks his shot is on the bottom of the screen rather then the top. In cases where accuracy is crucial, it is often best to simply have shots appear “out of nowhere” in front of the player that shot them, but play the shooting animation at the same time. This visual feedback triggers an instinctual “oh its lag” response, instead of “where the hell did that shot come from.”

All of these methods are applied in anticipation of a perfect interpolation function, which is of course impossible. Hence, while we can mitigate most of the problems that exist even with a perfect interpolation problem, it comes down to simply coding a better, faster interpolation function.