Create sprites immediately in a certain spot

[Toby]

I've been trying for hours to fix this issue that is driving me mad. I have two zones that can be captured with soldiers in my game. My problem is that when reinforcements are created for the enemy faction, for one tick, the soldiers are at 0, 0. Which is covered by the player's capture zone, this causes the zone to think that there are more enemies than friendlies in the zone during that tick, thus triggering a game over state.

I've tried and tried to make sure that the enemies are created on the spot, but it doesn't seem to be possible, I actually have to create the sprite at 0, 0 and THEN move it to the place it should be. I tried to solve this by having an isActive flag on the soldiers, which are only set to true after I've set their position. This worked initially but since then I had to revert some code that I changed attempting to fix the problem. But once I discovered that I could do it by having the isActive bool I reverted those changes. And suddenly that solution no longer works. It is really hard to explain but my question is just if it is possible to initialize an object to spawn at a certain position right from the get go, instead of being created at 0, 0 and then moved.

Some help would be greatly appreciated.

[StormWingDelta]

Doesn't the Sprite class have a parameter for Vector where it lets you set the position?  You can use setPosition to put it where you want.  Not sure what the default is though.



Also we can't help much without an example.

[Toby]

The problem is that it still seems to be created at 0, 0 before the set position line is performed. So for a split second all enemies are inside the player zone, "capturing" it.

Code: [Select]

SSprite.setPosition(initialPos); //Move the Soldier into an initial position
isActive = true; //IMPORTANT: We set the active bool to true AFTER we move the actor into place

This is from inside the soldier constructor. I only activate it after it is made. For whatever reason this was fine but not anymore. But unless I show all of my code I won't solve it this way. Which is why I'm looking for a way to initialize the sprite at the right position right away. Like I do with certain variables in the constructor.

Code: [Select]

Soldier::Soldier(Side Faction, sf::Vector2f initialPos) : moveSpeed(100), HP(100), bBoxSize(14, 28)
{
//Constructor code
}

movespeed is a float value that is set to 100 just as it is created, instead of being assigned a junk value and then made equal to 100. Is there no way to do that with the sprite position?

[victorlevasseur]

During that split-second you are talking about, the window isn't even displayed (and no other functions are executed) so there is no problems.

[Toby]

I thought so too. But it is apparently enough to trigger the capture zone. Because for a split second the zone says that there are enemies in the zone just as they spawn on the other side of the screen and then you lose the game. And my capture zone is set to ignore things that have their isActive bool set to false.
Ah well, I guess I'll just have to rewrite the code for the capture zone tomorrow and hope for the best, since you can't initialize sprites to be in the right spot as they are created it seems.

Unless I create the Sprite in a temporary variable, move it and then set it equal to the Sprite that the soldier actually uses or something.

[StormWingDelta]

hmm I tend to make my own subclass using SFML's sprite class as the base but unless you have to don't bother.  In any event aside from putting in a request on the github for a position parameter to be added the only real way around it is to do this number of creating a subclass.

class MyGameSprite : public sf::Sprite
{
public:
        Ship(sf::Vector2f);

}
 

This is my only excuse for creating a subclass of something in a library like SFML.  If I need to add one or more of the set methods into the constructor as parameters.


Also a plan B would be to make the area around (0,0) out to the largest sprite size an area nothing important can happen in like collisions and other things that might happen a bit too fast.

[Toby]

Thanks for the replies. I'll have to look into it tomorrow. Getting pretty late here. Hopefully I don't have to resort to plan B.

[StormWingDelta]

Thanks for the replies. I'll have to look into it tomorrow. Getting pretty late here. Hopefully I don't have to resort to plan B.

I had to when working with Digipen's Fun Editor.  Was very annoying to say the least since they stored the main copy of an object on the map at (0,0)      That said the only way to bypass the issue of create sprite than set position here would be to either create a subclass of sprite or get someone to make a few more constructors with the position setable from them on the github.

[eXpl0it3r]

It's simply an issue with your game logic, nothing SFML can do about it.
When you first create a new sprite you shouldn't run your game logic on it, before you have actually initialized the sprite.

It doesn't even make sense to create a sprite, run the game loop, set the sprite position. Your capture detection doesn't "randomly" start, that's not how programming works. You have full control over the execution of your code.

[Toby]

But the thing is, unless SFML makes my code multi threaded, there is no way for the capture check to occur while the sprite is being made. Evertyhing is done in sequence. Actually, doesn't SFML make multiple threads? Sure looks like it in the output window when the program closes.

[eXpl0it3r]

SFML only uses multi-threading for audio.

If everything is done in sequence, i.e. create sprite, set position, capture check, then it's a bug in your capture check or somewhere else.
When you set the position of the sprite, the sprite's position will have changed, there's no "delay" or anything.

Start a debugger and check the values.
Also make sure you don't create temporary sprite objects.

Without a minimal and compilable code example, we won't be able to help you further.

[Toby]

It's a damn mystery, that's what it is. Kind of hard to show more code since I would have to dump so much in here. But it doesn't make sense since the zone only checks for active soldiers and they are only made active after their position has been set. Which means that the soldier is in position in the enemy capture zone before they are active, so how they still manage to trigger the player's zone is beyond me.

But I'll keep digging around and rewriting the code for the zone checking again.

[Nexus]

As already indicated, you should read this post...

[Toby]

I'm pretty sure I solved it now anyway. I added a capture timer, you have to stay in the zone for at least a second to capture it, so when they spawn in they won't be in the zone long enough to capture it.

[Rosme]

That is not a way to solve it. That is a hacky workaround. You really should investigate and find out why the capture zone is triggered when you create an invalid sprite instead. It might reveal other flaws and problems in your code.