Function pointers

Started by
11 comments, last by MichaelT 18 years, 7 months ago
Hi Is it much slower when using pointer to the function insted of function it self? for example :


class Engine2D
{
    private:                                               
        void          DrawLine16bit(long x0, long y0, long x1, long y1,D3DCOLOR color);
        void          DrawLine32bit(long x0, long y0, long x1, long y1,D3DCOLOR color);
        void inline   PlotPixel16bit(long x,long y,D3DCOLOR col);
        void inline   PlotPixel32bit(long x,long y,D3DCOLOR col);
    public:
        void          (Engine2D::*DrawLine)(long , long , long , long ,D3DCOLOR );
        void          (Engine2D::*PlotPixel)(long x,long y,D3DCOLOR col);
};




When im initializing my 2D engine i'm testing depth and based on it pick right function to plot pixels and draw line but i'm not sure if it's better (faster) then simply make one function like this


PlotPixel(long x,long y,D3DCOLOR col)
{
 if(bbp=32)
 {
   // plotpixel
 }
 else
 {
   // plotpixel
 }
}




it's one "if" per pixel, but it's inline! When using pointers compiler won't be able to inline anything (even though PlotPixel16/32bit are marked as inline)! So the question is which way would be faster?
Advertisement
You're making a mistake in premature optimization, and hitting the wrong target. A vastly larger performance hit is going to come from drawing lines by plotting individual pixels; by comparison, any possible differences coming from in-lining and pointer dereferencing are going to be miniscule. You are passing a D3DCOLOR to your plotting functions, which leads me (obviously) to believe you are using D3D, so why in the name of all that's holy don't you allow D3D to draw the line for you?
I'm not sure. Give it a try yourself :]

Probably some completely different setup is the fastest.

That said, the difference is almost certainly negligable, and you shouldn't worry about it until it becomes a problem.

[edit: too slow]
It looks like you are trying to create different versions of functions for 16 & 32 bit (maybe even opengl in the future?)

Well, normally it should not be a problem for a device (directx) to internally convert between formats. Actually, you can test this in directx (look in the docs). If you are trying to create different paths for opengl and DX, then that is another issue. If so, you need to standardize the parameters and not use things like "D3DCOLOR". I think that maybe, just maybe, you didn't think this through at first and just wanted to see if it works. As for the performance, it should not be much of a difference. At least not where it matters anyway. Those are issues you deal with when you profile.
No no no no! :)
Well .. i'm using some D3D structures and few functions but mainly Dirct3D is only to provide backbuffer pointer so i can draw manualy :) I know d3d would do i faster but for onec i want to do it by my self .. for satisfaction and becouse of curiosity, i want to know how it works instead of using APIs.
Quote:Original post by Error98
Well .. i'm using some D3D structures and few functions but mainly Dirct3D is only to provide backbuffer pointer so i can draw manualy :) I know d3d would do i faster but for onec i want to do it by my self .. for satisfaction and becouse of curiosity, i want to know how it works instead of using APIs.


I see, well, if you need to use a different function to draw on a 16bit surface I have a suggestion for you. How about using 32bit internally for everything and simply convert to 16bit when you actually present the data?
No no no no! :)
Hehe i don't think using D3DCOLOR is a big problem it's just a typedef unsigned long :D

I just finished ColorTranslator class it take care of everything (i hope) related to color deptp and various formats :)
Quote:Original post by MichaelT
How about using 32bit internally for everything and simply convert to 16bit when you actually present the data?


I don't know if i got you right but i would be a waste of memory.
I woulnd have to create 32bit surfaces just to use only 16bit of it :/
Quote:Original post by Error98
Quote:Original post by MichaelT
How about using 32bit internally for everything and simply convert to 16bit when you actually present the data?


I don't know if i got you right but i would be a waste of memory.
I woulnd have to create 32bit surfaces just to use only 16bit of it :/


That's not the point. The point is that then you can focus on making one path work correctly first (namely 32bit). Then only at presentation, convert to 16bit. besides, memory these days is not something you need to worry about. Especially not in this case.
No no no no! :)
Assuming you are writing this for a 32 bit architecture, using 32bits will actually be faster. Your computer works fastest when everything is 32 bit aligned. When using 16 bit integers, or shorts, your processor must pad them to 32 bits anyways to load them into an Extended register. (At least on x86 hardware). The difference in performance is not major, but it is good practice to do all your calculations using the default data type of your processor. An exception to this rule is GPUs, from most everything I've read they seem equally at home with both 16 bit and 32 bit calculations.

This topic is closed to new replies.

Advertisement