How do I undraw text

[ravenheart]

i have game loop and after that i draw my objects

Code: [Select]


loop
{
...
}
App.Draw(any object);



now it can be that some object does not exist anymore, or i just want it not to be shown

how can i realize that?

[Tank]

Uhm, just do not draw it anymore?! Or did I miss something?

[Laurent]

Why are your objects drawn after the game loop ? The only thing which should happen after the game loop is cleanup / shutdown of the application.

[ravenheart]

o sry i meant the event loop, something like

Code: [Select]



while app is running
{
       catch and handle events
       {
               ...
       }

       draw objects
}


now i could use booleans to stop drawing a certain object

something like:

Code: [Select]


if( bool draw_object_1)
   draw object_1


but there must be a better solution, lets pretend theres a missile shot from a starship, the missile is created should be drwn and if it hits something it should disappear...
there a two problems for me now:
first of al how can i do exact collisionmanagement (without bounding boxes),
2nd: i wanna call the destructor of the missilie if it hit something

can u explain me how to do it?- thanks

[quasius]

but there must be a better solution, lets pretend theres a missile shot from a starship, the missile is created should be drwn and if it hits something it should disappear...
there a two problems for me now:
first of al how can i do exact collisionmanagement (without bounding boxes),
2nd: i wanna call the destructor of the missilie if it hit something

can u explain me how to do it?- thanks

Really it depends on how much "solution" you want.  A good way to do it would be to make a separate "sprite manager" (or text manager) class that would hold and organize all sprites/text.  You would be able to add or remove sprites as needed.  Then you just iterate and render all sprites in the manager each frame.
As for "exact collision management..."  I've answered this question before, but some people don't seem to like the answer: http://www.sfml-dev.org/forum/viewtopic.php?t=589
The short answer is that "pixel perfect collision detection" is a fantasy not used in any serious project.  Instead you use various approximation techniques of various complexities to achieve what appears to be "pixel-perfect."
But if you're just getting started, I'd recommend ignoring that for now since collision detection and handling is a *very* complicated topic.  Just use bounding boxes.
Also, if you want to brute-force "pixel perfect collision detection" for learning purposes, I suppose you can iterate through every pixel of 2 sprites with overlapping bounding boxes looking for alpha overlaps.  But expect this to be slow for any reasonable application.

[zarka]

but there must be a better solution, lets pretend theres a missile shot from a starship, the missile is created should be drwn and if it hits something it should disappear...
there a two problems for me now:
first of al how can i do exact collisionmanagement (without bounding boxes),
2nd: i wanna call the destructor of the missilie if it hit something

can u explain me how to do it?- thanks

Really it depends on how much "solution" you want.  A good way to do it would be to make a separate "sprite manager" (or text manager) class that would hold and organize all sprites/text.  You would be able to add or remove sprites as needed.  Then you just iterate and render all sprites in the manager each frame.
As for "exact collision management..."  I've answered this question before, but some people don't seem to like the answer: http://www.sfml-dev.org/forum/viewtopic.php?t=589
The short answer is that "pixel perfect collision detection" is a fantasy not used in any serious project.  Instead you use various approximation techniques of various complexities to achieve what appears to be "pixel-perfect."
But if you're just getting started, I'd recommend ignoring that for now since collision detection and handling is a *very* complicated topic.  Just use bounding boxes.
Also, if you want to brute-force "pixel perfect collision detection" for learning purposes, I suppose you can iterate through every pixel of 2 sprites with overlapping bounding boxes looking for alpha overlaps.  But expect this to be slow for any reasonable application.

The simplest way of solving that problem is to simply move the object off screen that is a well tested way of doing things.. especialy in flash / shockwave games

And as for pixel perfect collision detection i belive you could have fast enough pixel perfect collision detection for a 2d game.. but it will take a lot of work.. the simplest solution is to use bounding boxes and try to keep them as small as possible. this will be enough for most simple games

[quasius]

The simplest way of solving that problem is to simply move the object off screen that is a well tested way of doing things.. especialy in flash / shockwave games

And as for pixel perfect collision detection i belive you could have fast enough pixel perfect collision detection for a 2d game.. but it will take a lot of work.. the simplest solution is to use bounding boxes and try to keep them as small as possible. this will be enough for most simple games

Re: moving stuff off-screen:
If that's common in flash, I'd suspect it has automatic off-screen culling.  Otherwise, it's not a good idea.  (SFML / OpenGL don't auto-cull.)  The goal is to have checks to make sure you don't draw things off screen, not to intentionally move things off screen and draw them anyway because you can't be bothered to just not draw it.
And how is that even simpler from a coding perspective?  If you have some sort of test to move it off-screen, you already know you don't want it; so why don't you just not draw it?

Re: Collision detection:
I really, really want to know where all this (brute force) "pixel perfect collision detection is fine" stuff comes from.  Yes, you can probably get it to work on a small scale if you're only doing a few collisions, and the sprites are small, and you don't mind artificially inflating system requirements, and you're not doing other silly things to burn your CPU.
Effective and efficient collision detection is an important part of game dev.  If you want to ignore the topic to focus on learning other things with the intent to come back later, that's fine (and probably even a good idea).  But stop pretending such code laziness is ok just because the game is 2D.

Edit:  Although with some of the unbelievably-slow flash stuff I've seen, I'm not surprised if this type of thinking is out there.


Edit Edit:  Real-world example:

I'm currently developing what will become a commercial product using (slightly) modified/added-on SFML.  The following optimizations are in place:

1) Map objects arranged in small blocks using hash tables for rapid searching and access based on location.
2) Offscreen-culling based on #1.
2) Intelligent, 3-phase collision detection.  (It even appears "pixel perfect!")

If I disable those, the game drops to slide-show framerates on a computer that run the likes of Bioshock beautifully.  The game is 2D.
Stop pretending this stuff doesn't matter.

[quasius]

One thing I meant to say in my original post...

The "sprite manager" was a high-powered solution suggestion.  If you are going for something simpler, you were actually on the right track.  Each frame, you'd either need to do some test to see if it should is draw.  Something like...

Code: [Select]


if (missile.IsOnScreen())
    missile.Draw();


Or just set a bool flag as you were doing when the missile is destroyed/offscreen/detonated/whatever.  Then check that each frame.  Then when the missile sprite is recycled, just re-enable it.

[elisee]

Just use some kind of container (std::map, std::vector or std::list depending on your needs) to store your sprites and remove them when they're not needed anymore. To draw your sprites, iterate on the container and draw each item in it.

[zarka]

Re: moving stuff off-screen:
If that's common in flash, I'd suspect it has automatic off-screen culling.  Otherwise, it's not a good idea.  (SFML / OpenGL don't auto-cull.)  The goal is to have checks to make sure you don't draw things off screen, not to intentionally move things off screen and draw them anyway because you can't be bothered to just not draw it.
And how is that even simpler from a coding perspective?  If you have some sort of test to move it off-screen, you already know you don't want it; so why don't you just not draw it?

Re: Collision detection:
I really, really want to know where all this (brute force) "pixel perfect collision detection is fine" stuff comes from.  Yes, you can probably get it to work on a small scale if you're only doing a few collisions, and the sprites are small, and you don't mind artificially inflating system requirements, and you're not doing other silly things to burn your CPU.
Effective and efficient collision detection is an important part of game dev.  If you want to ignore the topic to focus on learning other things with the intent to come back later, that's fine (and probably even a good idea).  But stop pretending such code laziness is ok just because the game is 2D.

Edit:  Although with some of the unbelievably-slow flash stuff I've seen, I'm not surprised if this type of thinking is out there.


Edit Edit:  Real-world example:

I'm currently developing what will become a commercial product using (slightly) modified/added-on SFML.  The following optimizations are in place:

1) Map objects arranged in small blocks using hash tables for rapid searching and access based on location.
2) Offscreen-culling based on #1.
2) Intelligent, 3-phase collision detection.  (It even appears "pixel perfect!")

If I disable those, the game drops to slide-show framerates on a computer that run the likes of Bioshock beautifully.  The game is 2D.
Stop pretending this stuff doesn't matter.

RE: RE: moving off screen
well it is all a matter of size. for your run-of-the-mill space invaders clone you do not need to worry much about culling or stuff like that. but ofcource it becomes an issue when you start making bigger stuff. and i think it would be better to start with optimising how you render before looking in to culling. SFML as of now uses immediate mode.. which in it self is horribly slow.

RE: RE: collision
I agree with you pixel perfect collision is in no way a sane approch.. your best bet for good collision would probably be convex polygon shapes wrapping the object snuggly (this is what 3d games do today). But (and this is the point im trying to make) it is possible to get pixel perfect collision if you put enough time into designing the collision engine.
If i had to implement it today (not saying that i whant to )i would probably make a system quite similar to your approch with the last step being the pixel perfect check. and it would most likely not be used by every object.. just important ones. and as a final step id check if the pixel checking algorithmn could be speed up with SIMD extensions or something like it.

[quasius]

RE: RE: moving off screen
well it is all a matter of size. for your run-of-the-mill space invaders clone you do not need to worry much about culling or stuff like that. but ofcource it becomes an issue when you start making bigger stuff. and i think it would be better to start with optimising how you render before looking in to culling. SFML as of now uses immediate mode.. which in it self is horribly slow.

RE: RE: collision
I agree with you pixel perfect collision is in no way a sane approch.. your best bet for good collision would probably be convex polygon shapes wrapping the object snuggly (this is what 3d games do today). But (and this is the point im trying to make) it is possible to get pixel perfect collision if you put enough time into designing the collision engine.
If i had to implement it today (not saying that i whant to )i would probably make a system quite similar to your approch with the last step being the pixel perfect check. and it would most likely not be used by every object.. just important ones. and as a final step id check if the pixel checking algorithmn could be speed up with SIMD extensions or something like it.

Fair enough.  As I said, using non-optimal techniques at first is fine for learning, but I still like to mention stuff like this so they know it's something to think about later.
As for immediate mode rendering, I've thought about that myself I'm not sure how big of a deal that is for 2D rendering in most cases.  Display lists make sense for 3D models with tons of verts to send, but the majority of 2D rendering is tile-based so you only have 4 verts per "model."
I did a quick and admittedly non-scientific test and found no read gains to rendering tiles with display lists.  You probably loose just as much time setting a transformation before each tile then just sending the offset verts.
Although I have used display lists for certain drawables I've made that contain many verts.
Is there a reason you think SFML would benefit from display lists in tile (sprite) rendering?
As for pixel-perfect collision detection, yes I'd just make it the final collision stage if I had to.  But I can't imagine a situation where that would be needed over a poly approximation.  If you needed a super-accurate simulation for some reason, you probably wouldn't even bother with the pixel data for collision; but use some internal spacial representation.

Edit:  I guess you could do something where you chopped static elements of a map into chunks and rendered chunks as display lists, but I doubt that would get you anywhere since I seriously doubt vertex bandwidth is ever going to be a bottleneck in a reasonable situation.  In fact that approach might even hurt you due to the extra drawing it would entail.  I'd image most 2D games are almost always going to be CPU-limited unless you are doing something silly like not culling for large maps.

[zarka]

Fair enough.  As I said, using non-optimal techniques at first is fine for learning, but I still like to mention stuff like this so they know it's something to think about later.
As for immediate mode rendering, I've thought about that myself I'm not sure how big of a deal that is for 2D rendering in most cases.  Display lists make sense for 3D models with tons of verts to send, but the majority of 2D rendering is tile-based so you only have 4 verts per "model."
I did a quick and admittedly non-scientific test and found no read gains to rendering tiles with display lists.  You probably loose just as much time setting a transformation before each tile then just sending the offset verts.
Although I have used display lists for certain drawables I've made that contain many verts.
Is there a reason you think SFML would benefit from display lists in tile (sprite) rendering?
As for pixel-perfect collision detection, yes I'd just make it the final collision stage if I had to.  But I can't imagine a situation where that would be needed over a poly approximation.  If you needed a super-accurate simulation for some reason, you probably wouldn't even bother with the pixel data for collision; but use some internal spacial representation.

Edit:  I guess you could do something where you chopped static elements of a map into chunks and rendered chunks as display lists, but I doubt that would get you anywhere since I seriously doubt vertex bandwidth is ever going to be a bottleneck in a reasonable situation.  In fact that approach might even hurt you due to the extra drawing it would entail.  I'd image most 2D games are almost always going to be CPU-limited unless you are doing something silly like not culling for large maps.

this could probably be a whole new thread in it's own since this discussion has severely drifted from the scope of the original question

but as for drawing. i noticed when profiling my particle system that when i had ~1000 particles in a system 50% of my CPU time was spent in the Draw function .. (you can try this yourself by downloading the particle system code(wiki) and running it through AMDs codeanalyst)the only thing that function does is first set states and texture then iterate through all particles and drawing their vertices using immediate mode. This really shows that you get a very large CPU overhead when using immediate mode. as for display lists they are only faster when working with static data. and are probably slower when working with dynamic data . I am in no way an expert in graphics/rendering techniques(I usually stay as far away as possible from that particular subject when it comes to making games) but it would definitely be worth checking out vertex arrays / Vertex Buffer Objects and the like. I have tried to learn how to use them and how to apply them to particles but i have thus far failed to make it work (mostly because the motivation isn't really there)

and as for the never ending collision question. i agree with you but i think it is important to point out that it is in fact possible it's just very hard to make it work well ( and your time is probably better spent making actual games (unless of course you are looking for a career in physics programing))

hmm if i use any more parentheses people are going to start thinking i am a lisp programmer :S

[ravenheart]

ok now for a beginner as far as i have understood, i should not move things out of screen, or should i just not draw them outta screen?

and when i should not move them out of screen, what should i do then and please no more experts discussions

[quasius]

ok now for a beginner as far as i have understood, i should not move things out of screen, or should i just not draw them outta screen?

and when i should not move them out of screen, what should i do then and please no more experts discussions

If the only time you don't want to draw something is when it's offscreen and you only have a few objects (not a large map, for example), just drawing off-screen should be ok.
If you are not drawing for other reasons such as detonation or whatever, just don't draw it.  You already have a test to know when you need to draw and not, so there's no reason to move it way off-screen when you can just not draw it.

[Avency]

The easiest solution to the problem is probably something like this:

Code: [Select]

class RenderObject
{
public:
void setVisible(bool visible)
{
m_is_visible = visible;
}

void render()
{
if (!m_is_visible)
{
return;
}

// actual drawing code here
}

protected:
bool m_is_visible;
}

@Laurent:
What about adding this kind of functionality to sf::Drawable?