Off Topic : naming Functions

[Emil_halim]

Hi all

I want some help to name some of functions of my library.

I have implemented a 3 functions for pixel collision detection , the first one chack the collision between 2 static sprites , the second check the collision between a static sprite and animated sprite , the last one check the collision between 2 animated sprites.

so what is the best names for them?

thanks for any help.

[rain_storm]

can I get an example of a function name already used in your library

[Shockwave]

static_spritecol < - For 2 static sprites?

static_to_anim_spritecol <- 1 Static and 1 animated sprite?

anim_to_anim_spritecol <- 2 Animated sprites?

[Emil_halim]

@rain:

DLL_IMPORT bool ML_CheckPixelCollide(void* Sprite_1,float x_1,float y_1,void* Sprite_2,float x_2,float y_2);
        DLL_IMPORT bool ML_CheckPixelCollide2(void* Sprite_1,float x_1,float y_1,void* AnimSprite_2,float x_2,float y_2);
        DLL_IMPORT bool ML_CheckPixelCollide3(void* AnimSprite_1,float x_1,float y_1,void* AnimSprite_2,float x_2,float y_2);

@Shocky:

yes , it sounds good names but in my Library i did not use a shortcut name of function,
for examples the function name that set the color key of the sprite is ML_SetSpriteColorKeyFromPoint.

anyway thanks for your help.

[zawran]

ML_PixelCollideStaticToStatic
ML_PixelCollideStaticToAnim
ML_PixelCollideAnimToAnim

[Emil_halim]

ok , we are close to the write names.

i am thinking in replace To with Vs , I.E

ML_PixelCollideStaticVsStatic
ML_PixelCollideStaticVsAnim
ML_PixelCollideAnimVsAnim

so what do you think?

[p01]

can't you have a single method and check if the sprites are animated or static and do the appropriate test ?

[Emil_halim]

make it as you suggested is very simple , i will give it a try.

[rdc]

If you are using FreeBasic then you can wrap your functions using the namespace keyword. This way you can name your functions with human readable names and yet not conflict with other functions.

[Stonemonkey]

I was about to suggest this:

'If static and animated sprites are different types then you could use the same function name with overloading.'

until i noticed your code with void* so I take it that's out of the question, is that something like the 'any ptr' in FB?

or would it be possible to have some sort of ID or flag in the type telling the function if it's a static or animated sprite so as just to require a single function?

[Jim]

void * and ANY PTR are pretty much the same, yes.

Jim

[Emil_halim]

@rdc:

Actually when I made my library with  C++ for only using it with C++, I was using overloaded functions.

But after that I rewrote it for pure C code in the hope that I can use it with as many language as possible , so overloaded functions name may not work with other language that does not support that.

@Stonemonkey:

the animated sprite is extended structure of static.

As Jim said they are the same meaning .


Really I am little confuse , make it as Po1 said is easy , I.E one function for all types of sprites but it will take some more calculation and time , and If I make it as 3 functions the Static Vs Static is simple and will be faster than Static Vs Anim and so on.

Another problem that I want to take your own opinion about , each functions of collision detection will lock the 2 sprite , so if you have 100 sprites and want to test then Vs another sprite then we will do 200 lock and unlock process .

I think that , if the user will select one sprite with a certain function that will lock the selected sprite then check the collision with each 100 sprits , this will reduce the number of lock and unlock process from 200 times to 101 times.

So  do you have an other best solution?           
 

[ninogenio]

i would personally leave them as individual functions so that people really concerned with speed could extract as much speed as posibile from there code.

then people not to botherd about speed could always create there own single function that incapsulates the three.

[Jim]

I think that , if the user will select one sprite with a certain function that will lock the selected sprite then check the collision with each 100 sprits , this will reduce the number of lock and unlock process from 200 times to 101 times.

So  do you have an other best solution? 

Nope, you've got it absolutely bang on.  The only way to speed it up further is to eliminate some of the sprites you're checking against, and only you, or the user of your API knows how to throw some of those away.

Jim

[Emil_halim]

@nino:

yes it is the best solution , for the sake of speed and simplistic.

@Jim:

actually I have an other idea that will speed things a lot, instead of lock and unlock process to get a sprite memory data , I can store the sprite data in a system memory when loading the sprite and check the collision from that memory but this will take much more memory. 

[Jim]

If they're presently in video memory then it will speed up dramatically when you use system memory.  In my experience you quite often want to keep sytem memory copies of your sprites anyway.

Jim

[Emil_halim]

Yes all the sprite stay in video memory , and I will make a copy in system memory for collision purpose.

Now the question is , do I make a copy automatically when loading the sprite , or allow the user to make it when he want to check for collision by calling a specific functions , and if so what could be the name of that function ?

[Jim]

I'd have a user option that can be toggled on and off from the API that says 'this is a dynamic sprite that I might use for collision'.  Never mind the actual detail of how you plan to do the collision, I think this is something that naturally belongs to a sprite - whether it moves or not.  So you might want
ML_sprite_is_dynamic(boolean)

You should still allow collisions with non-dynamic sprites, I think.

Jim

[Emil_halim]

Ok , but I think that if the name of function is ML_AllowFastCollisionCheck (Sprite)  will be more accurate.

I can put a FastCollide Flag with Sprite structure data that I will check in the collision function , so if it is true it uses system memory and if it is false it uses the lock and unlock process, so we allow the both cases here. 

[Clyde]

Sounds fab what your doing, and all the best with it dude.