"destination-over" equivalent

[battosaijenkins]

Hello there,
I'm coming from javascript where if you're experiencing objects flickering when getting rid of objects in an array, you can do a reverse loop to prevent objects from flickering, however the rendering of the images are in front of the initial object (such as in a trail effect) and to remedy this you use something called ctx.globalCompositeOperation = "destination-over" where the trail effects will be drawn behind the initial object instead.

Is there a similar remedy in sfml c++? I can't seem to find any documentation or anything related through google searches for drawing objects behind something. I know you can literally window.draw() after another to show it in the foreground but when Im looping through an object's trail it doesnt seem to work.

What happens is when I use a normal incrementing for loop, the ball created will show a trailing effect behind the new ball (correctly) but during removal of each ball there is a 'flickering' for existing balls. This can be solved by doing a reverse loop decrement instead but then the rendering is changed where each new ball will be behind the older created ball.

I want the no flickering AND where the new object will be in front of the ball but a reverse loop doesnt seem to solve both these issues. An incrementing for loop will solve the draw placement but flickering occurs, but decrement for loop will solve the flickering but draw placement is wrong. And there doesn't seem to be a "destination-over" or "source-over" equivalent to solve this issue.

Is there a way to solve both the flickering and the new ball to be drawn in front of the older? Thx in advance!

[Laurent]

Since your problem is the flickering, let's solve this and forget about that "destination-over" thing, that is probably not possible with SFML anyway.

Can you explain with more details what happens, and why it is caused by iterating forward?

[battosaijenkins]

Sure thing. What happens is when I iterate forward to draw my ball objects, later I want to remove the 1st element in that vector. The problem with removing the 1st element in the vector during an increment loop is that element at index 0 is gone, and so the vector shifts and then the next iteration there's a split second where nothing is drawn, hence that little flicker.

However when I do a reverse iteration loop, it checks backwards and so I can now remove the 1st element in that vector (0) ,and it wont affect my next draw so it's one way of preventing flickering But the problem is now the trail effect is placed in front the ball object.  Conversely when I do a forward loop the placement of the trail effect is correct (trail is behind the inital ball object) but flickering occurs when those balls are removed.

My problem is, is it possible to have the correct placement of the trails effect using the correct loop and not have flickering as well.

I can take pictures if you need more info. Hopefully it wasnt more confusing.

[battosaijenkins]

Holy crap, I slept it over and spent all morning on this breaking it down step by step. I figured it out. SFML is so simple. You don't need destination-over because the way you draw it or call the function to draw will determine if its in front or behind.

So another thing was I didn't realize vectors had .insert() instead of push_back() and that completely changed everything. So doing a reverse iteration loop and insert instead of push_back solved my issue.

Now I have no flickering when removing objects and the trail effect it leaves behind is correctly placed behind the ball objects. Oh man, this was the most headache inducing problem I had to face yet. Now I can happily port javascript canvas rendering to c++ sfml to determine the performance!