Helbreath Performance

All Helbreath Client Source Discussion here.
Jaap
Loyal fan
Posts: 390
Joined: Thu Apr 22, 2004 8:21 am

Post by Jaap »

> While you're right that these should be assertions, the impact on
> performance is negligible. It'll take all of 2 cycles to do the comparison
> and branch (the branch will be predicted correctly by the CPU unless the
> check fails, which you'd hope was never or at worst rare).

I meant that more for debugging purposes. Assertions can be switched of by just changing a precompiled header - removing the if-checks (who are 99% of the times unnecessairy because they always evaluate to the same, excepted result) is alot of work.


> Depends. If they're doing memory allocations then yes, but if the
> variables are all on the stack then moving them will make 0 difference
> to performance. Allocation a variable on the stack is nothing more than
> an addition to the stack pointer, so technically putting them all together
> would be slightly faster (a single addition to allocation them all at once
> instead of in several different locations)

Perhaps, never tested it. Might be interesting to do so.


> The dereference of the function pointer you suggested to use instead
> would cost just as much as the jump table the compiler would generate
> for this. Besides, if you want object-oriented you'd use virtual functions,
> not function pointers....

No, because alot of sprites (hunderds) are being drawn each frame, removing an unnecessairy if-check can make a difference. I'll try explain:

The CSprite class has alot of drawing functions (with transparancy, with colorkey, and so on). In each of them, when used, first is checked wether the sprite is loaded in memory. If not, it calls another function, else it continues. A function pointer to a member of CSprite can remove that check.
How?
When you create the CSprite object, in the constructor you change the function pointer to the "OpenSprite()" member. In the OpenSprite() member you change the function pointer to point to the correct "PutSprite()" member. Then, when CGame calls the method, the function pointer points to the correct member - thus removing the check.
If anything unloads the sprite, the function pointer is simply set back to "OpenSprite()". Hope that explains it.


> While they could have benefitted from this, I myself will not
> (Since I am using OpenGL I let the graphics card do this, not software)...

Helbreath uses DirectX 7. The alpha blending does occur through DirectX and is a software implementation that uses your RAM, not the video card memory.
MMX can speed up alpha blending significantly.


> Again, the performace impact is negligible. In fact, the suggestion you
> make would actually cost more than a simple comparison because of the
> need to dereference the function pointer :P

Again a point for testing. I think calling a function pointer is faster than checking what function to call (especially if you need more than checks like a switch-statement).

This:

Code: Select all

MyFunctionPtr(par1, par2, etc);
Costs less CPU cycles than:

Code: Select all

switch (iCurrentScreen) {
case 1:
  DrawMenu();
  break;
case 2:
 DrawOptions();
  break;
case 3:
  DrawLoginScreen();
  break;
case 4:
  DrawConnectionLost();
  break;
case 5:
  DrawGame();
  break;
//and so on...
}

> Afraid not. You could easily spend weeks implementing these changes
> only to discover that you gained a whooping 0.1 frames/second. What
> you're doing is called micro-optimising, which is totally useless unless
> you're in a loop that gets repeated many hundreds of thousands of
> times per second (the software blitter you mentioned above would be
> a suitable candidate for these sort of optimisations...if we didn't have
> hardware to do it for us).

True. It's lots of work and some of my suggestions might have little impact. But in case of Helbreaht... lol, everything minor improvement is a good improvement.


> What you want to look at instead is the high-level algorithms used.
> And then post your findings, please....I'm really curious, since I don't
> have the time myself, and it's a lot of work and all... :P

I'm suggesting changes to improve the game's speed. I'm not here to post the algorithms behind them.

Though, using the STL might actually improving alot of the game too. Those algoritms already exists, why not make use of that?
Post Reply