CSFML-2 sfSprite_get* type issue

[col]

Hiya,

I'm writing a wrapper for SFML-2 using the C headers and win32 gcc .libs. I have 90% of it done and functioning , but I have a problem with the set of sfSprite_get functions.

sfVector2f pos = sfSprite_getPosition(sprite);

( where 'sprite' is a valid const sfSprite* proved to be valid in that I can see and move it around the screen ) but the compiler complains with 'error: invalid initializer' and points to that line. My first thought was to use sfVector2f* which compiles but crashes when I try to access the variables of the sfVector2f.

Are there any thoughts on this?

Many thanks.
Dave.

edit: I should note that this happens with all of the sfSprite_get functions. Very strange.

[Laurent]

Don't forget that you can't declare variables in the middle of functions in C (unless you force C99 mode).

[col]

Hiya,

Thankyou for the prompt reply.
Yes, that is already set. The funny thing is I'm using the technique through the rest of the wrapper and it works ok. Its all of the sfSprite_get* functions except getRotation which returns a float that are causing this issue. The other 'types' are working ok. I imagine its a silly issue, but the I can't for the life of me think what it could be.

Many thanks.
Dave.

[Nexus]

Are all the required headers included?

If so, come up with a complete and minimal example.

[col]

Hiya,

I'm sure the headers are included properly. I get 'type not found' errors if I comment out the #include statements.

In the exact same file I have :-

// This works as expected
void bmx_sfText_getPosition(const sfText* text, sfVector2f* position) {
        *position = sfText_getPosition(text);
}
 

and further down in the same file I have :-

// This function works as expected
void bmx_sfSprite_setOrigin(const sfSprite* sprite, sfVector2f* origin) {
        sfSprite_setOrigin(sprite,*origin);
}

// This function gives me an error
void bmx_sfSprite_getPosition(const sfSprite* sprite,sfVector2f* position) {
        *position = sfSprite_getPosition(sprite);
}

All of the wrapper functions are in the one file which includes the other type functions and also the other sfSprite functions too which are confirmed to be working.

As a part of trying to hone in with whats happening if I do this inside the above function body :-

sfVector2f position;
position = sfSprite_getPosition(sprite);

then I get 'error: incompatible types when assigning to type 'sfVector2f' from type 'int''

as opposed to this:-

sfVector2f pos = sfSprite_getPosition(sprite);

which gives the error in the original post.
Are there any clues in there? How is it possible for the compiler to get an 'int' reference from anywhere or is this a default of some kind?

I can't really give a 'working' example of it in effect as this is a wrapper bindings for a different language and there is only this one 'C' file that gets imported into the other language.

Thanks for your help.
Dave.

[Laurent]

It really seems like you forget to include Sprite.h.

[Nexus]

The int comes from the property of C, that not declared functions are assumed to return int. So yes, it really looks like sfSprite_getPosition() is not declared.

You should increase your compiler's warning level, then it also annotates other functions that are not declared, but still compile. Note that it is undefined behavior if the compiler's assumption about the declaration differs from the correct one.

[col]

Thankyou for the prompt help.

I knew it would be something silly! I was including the SFML/Graphics.h file which I assumed would include the sprite.h as it includes all of the other types header files in that directory. But alas the '#include <SFML/Sprite.h>' entry is missing from the list. Is that deliberate? I put the entry in myself and all the problems have gone.

I'll post back with links/references to the bindings wrapper when its complete.

Thank you again. Very helpful guys!
Dave.

[Laurent]

It was fixed a long time ago.

[col]

I see. Does that mean I'm using old headers? I downloaded them from the Downloads section linked from the front page of this website.

Dave.

Edit: Is there a link or somewhere with information on other issues that I may run into that are already resolved? Or better still where I could get the latest version. Thanks.

[Nexus]

You can get the latest CSFML version from GitHub:
https://github.com/SFML/CSFML

[col]

Excellent, thankyou.

Now this has opened a whole new can of worms
I've spent the last few hours trying to compile the source. I've had all of the problems countless others have had ( fixed through searching this site for solutions ), and I still can't get it to compile using CMake. There seems the FindSFML.cmake is missing as it isnt in the CSFML github repo. Its in the SFML one but not the CSFML one.

There are problems after problems. Maybe I should/shouldn't have done it but I used the FindSFML.cmake from the CSFML repo. I then get more errors of not finding the SFML library files. I searched this site again and theres mention of them being in the lib folder. But it seems that things just arent happening for me, there is no lib folder under 'program files/sfml' or 'program files(86)/sfml'.

To be honest, spending all this time trying to get it to compile is distracting me from the original project of creating the wrapper bindings, and at this stage I concede defeat. So I'm asking for saviour, for a kind soul that has the latest github repo of the CSFML2 library built for use with MingW on Win32 who may also have a link of where I could download it.

Many thanks.
Dave.

[Laurent]

It's not complicated

1. Copy FindSFML.cmake where CMake can find it -- the easiest is to copy it directly to your CMake folder (under share/cmake-x.x/Modules)

2. Tell CMake where SFML is, by defining the SFML_ROOT variable (as explained in FindSFML.cmake) to the directory that contains your SFML "include" and "lib" directories. Note that you must have the static SFML libs, since CSFML links to them.

After that everything should compile out of the box.

[col]

You're right. It's not complicated when you know how   
Everything is built and working great now.

Thanks agian for your prompt help.

Dave.