Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: void pointer  (Read 3323 times)

0 Members and 1 Guest are viewing this topic.

nilodevelopment

  • Newbie
  • *
  • Posts: 5
    • View Profile
void pointer
« on: May 21, 2015, 12:45:47 am »
Hi there guys. Is it just me or would it be nice to have a void* variable for the sprites which the user can set in order to distinguish between sprites.

For example, lets say that i'm making a map-editor and wants to play the game at the same time. I'm drawing the the game objects on top of the screen and when i click on them with the mouse, i pretty much spawn that item. Its kind of hard to distinguish those sprites from the other sprites which might be the rest of the UI.

If we had a void* i could just see what sprite contains the mouse coordinates and get the void* from the variable and cast it back to whatever i set it to and see if the sprite is the editorItemSprite for example.

Just a though.
« Last Edit: May 21, 2015, 12:58:11 am by nilodevelopment »

Lo-X

  • Hero Member
  • *****
  • Posts: 618
    • View Profile
    • My personal website, with CV, portfolio and projects
Re: void pointer
« Reply #1 on: May 21, 2015, 01:14:34 am »
I dn't see how a void* pointer would help knowing what sprite the mouse is on, you can check that by getting the mouse coordinates and use the contains() method of the sprites bounding rects.

But if for any other reason you need to embed data along with your sprite, you can simply create your own class and inherit from sf::Transformable and sf::Drawable. That class would contain a sprite or whatever you want to draw and any other information you need.
See this tutorial chapter for an example

Do this solve your issue or did I missed the point ?
« Last Edit: May 21, 2015, 01:19:11 am by Lo-X »

nilodevelopment

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: void pointer
« Reply #2 on: May 21, 2015, 01:30:26 am »
Thats pretty much how I'm solving it now, but would be nice if they just made it so its there in the official release. Would save me a lot of time and I don't have to write extra code to achieve more or less the same thing.

If no one wants to use it, they simply ignore it and the void* is just the to hold user data.

Quote
I dn't see how a void* pointer would help knowing what sprite the mouse is on

Well you said it yourself. Lets say that i cast a string to void and put it inside userdata variable for the sprite. Then i simply check if the sprite contains the coordinates of the mouse and get the userdata variable, cast it back to string and see what the sprite is. It could even contain a pointer to a class object and stuff.

That would make life alot easier.
« Last Edit: May 21, 2015, 01:32:45 am by nilodevelopment »

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: void pointer
« Reply #3 on: May 21, 2015, 08:50:52 am »
That's not good in terms of separation of responsibilities. An sf::Sprite does what a sprite does -- which also includes *not* holding foreign user data. The link between your data and sprites has to be created outside of sf::Sprite, preferably in the form of aggregation.

If we did this, we would have to add a void* member to literally any class, because someone might need that.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: void pointer
« Reply #4 on: May 21, 2015, 01:27:57 pm »
I agree with Tank. There's no reason for a sprite to hold arbitrary unrelated data.

By using your own class you can also use the right type and a meaningful variable name instead of void* userData. Plus, you can provide storage -- memory for the void* pointee object would need to be allocated somewhere else.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

nilodevelopment

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: void pointer
« Reply #5 on: May 21, 2015, 02:14:20 pm »
Ye guess you guys are right. Wanted to be lazy but guess its a bad solution long term.