• Advertisement
Sign in to follow this  

Function pointers

This topic is 4560 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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 :/

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Hehe it's not that i'm worried about memory, indeed i have a lot of it.
And i don't want to realese, sell this engine or something :)
BUT even though it's only for fun i want to make it as efficient as i can.

It's 1AM in my place :/
I realy need some healthy sleep :D

Thanks for conversation ;)

Share this post


Link to post
Share on other sites
Hmm it's true CPU likes multiples of 32bit to procces but copying 4mb surface (32bit) or 2mb (16bit) is something diferent (isn't it?) the smaller the faster. My engine works in both 32 and 16 bbp and 16 IS faster :)
Just like any game i think you always suffer few FPS for rising bbp form 16 to 32.

Sleeeeeep ......

Share this post


Link to post
Share on other sites
Quote:
Original post by Error98
Hmm it's true CPU likes multiples of 32bit to procces but copying 4mb surface (32bit) or 2mb (16bit) is something diferent (isn't it?) the smaller the faster. My engine works in both 32 and 16 bbp and 16 IS faster :)
Just like any game i think you always suffer few FPS for rising bbp form 16 to 32.

Sleeeeeep ......


:) Smaller doesn't automatically mean faster. It depends on what you do while trying to deal with that information. As you know, 16 bit is not exactly the best format to use while calculating RGB values. Anyway, that is a side issue. I think it is best for you to just follow one path for the time being (16 or 32), and then move on to the other once you've nailed one down. Otherwise you will be working inefficiently, and likely to be distracted by other problems than what really needs to be adressed at this time.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement