Messages

1

Graphics / Run into major slowdown when trying to draw 10+ sprites

« on: January 28, 2012, 06:14:29 pm »

Remember that your game can take long to manage all for (if you have for example 1 milion element)

Right, but the problem is I'm running into this with only ten or fifteen elements.

2

Graphics / Run into major slowdown when trying to draw 10+ sprites

« on: January 28, 2012, 05:49:01 am »

Looks like the version of Visual Studio I'm working in doesn't have a profiler. But my performance jumps right back up to full speed if I cut the contents of the draw loop. For full disclosure, this is what things look like:

Code: [Select]


while (App.IsOpened()){
//stuff

System::Draw(position, App, Player, Mobile, Immobile);

//stuff

}


Code: [Select]


void System::Draw(b2Vec2 position, sf::RenderWindow &App, PlayerObject &Player, std::vector<std::shared_ptr<MobileObject>> &Mobile, std::vector<std::shared_ptr<ImmobileObject>> &Immobile){
position = Player.Body->GetPosition();
Player.Sprite.SetPosition(10*position.x, -(10*position.y));
if(Player.isVisible) App.Draw(Player.Sprite);
for(std::vector<std::shared_ptr<ImmobileObject>>::iterator it = Immobile.begin(); it !=Immobile.end(); it++){
App.Draw((*it)->Sprite);
}
for(std::vector<std::shared_ptr<MobileObject>>::iterator it = Mobile.begin(); it !=Mobile.end(); it++){
position = (*it)->Body->GetPosition();
(*it)->Sprite.SetPosition(10*position.x, -(10*position.y));
App.Draw((*it)->Sprite);
}

}



3

Graphics / Run into major slowdown when trying to draw 10+ sprites

« on: January 26, 2012, 03:29:08 am »

I guess it's a pretty standard approach, I don't see why it wouldn't work well. I do the same with normal pointers and a list instead of a vector and it works fine with many sprites (althought I didn't test it well).

Are you sure that's the problem? Maybe you have some other issue. Try running a profiler.

I'm fairly certain that this is the issue since the slowdown scales with the number of objects populating the scene and this is the only iterative process that would vary with object count, but I'll try a profiler

4

Graphics / Run into major slowdown when trying to draw 10+ sprites

« on: January 26, 2012, 12:09:23 am »

So I have a class of ImmobileObjects, each of which has an SFML sprite as a member. They're populated into a vector using something like this:

Code: [Select]

ImmobileVector.push_back(std::shared_ptr<ImmobileObject>(new ImmobileObject(&World, 40, 60, 80, 10, 1)));

And then every loop I iterate like so:

Code: [Select]


for(std::vector<std::shared_ptr<ImmobileObject>>::iterator it = ImmobileVector.begin(); it !=ImmobileVector.end(); it++){

App.Draw((*it)->Sprite);
}


When I have even ten objects to draw I run into major slowdown. It runs fine with just three or four though. Is my general approach just messed up?[/code]

5

Graphics / Slightly more advanced collision detection (with graphics)

« on: August 21, 2011, 01:26:50 am »

Also, it is a pretty fast library; it uses a spatial partitioning system (I believe it is a KD-Tree) which is much faster then checking every shape to every shape individually.

I've never understood how spatial partitioning works. Say you're a programmer and you have 20 objects on screen. How do you have those objects stored? Individually? I keep them all in a vector. How does spatial partitioning speeding that up? Won't you have to examine each object for its co-ordinate values, so you're still cycling through the objects even if you aren't colliding with each one?

I mean I get that examining co-ordinate values is faster then running collision detection, I just had my own system in place that further sorted the vector on initialization into smaller groups based on proximity (I call it "chunking", think Minecraft) and then only cycled through the chunk in which the mobile sprite was positioned.

6

Graphics / Slightly more advanced collision detection (with graphics)

« on: August 11, 2011, 09:26:27 pm »

Okay, so this is definitely more of an advice seeking thread then a specific question. I'm working with the basic collision detection functions laid out here which work great for the actual "detection" part of collision detection. The problem I'm working on is this:
If two sprites partially overlap, then the collision detection returns true. If it returns true then I want to move one of the sprites (designated "mobile") until they no longer overlap. That way you get true edge-to-edge collision.
 (The reason I want this is that I don't want high-velocity objects getting "trapped" several pixels into the object they collide with)

I've been trying to think through a few ways to do this. The best I've come up with is to look at the intersection rectangle of the two objects and use its shape to determine the direction of the offset movement.
For example, if an intersection box has a greater height then it has width and the position value of the mobile object is to the left of the stationary object then the mobile should be offset left by a value equal to the intersection box's width.


This works, but I feel that its reliance on bounding boxes is going to bite me in the ass if I try to work with more complicated geometry, or with sprites who's images feature large concavities. Another issue is that for it to be compatible with a pixel perfect test I would have to draw all objects twice: once before collision test, and once after offset (since the pixel perfect test relies on alpha values)
So I'm curious to here the thoughts of anyone who wants to contribute.

7

Graphics / Drawing int or double with sf::String

« on: July 29, 2011, 08:16:43 pm »

You could cast it into a std::string and set it as text of the sf::String.

Code: [Select]

// Converts an int into a string
static inline std::string int2Str(int x)
{
std::stringstream type;
type << x;
return type.str();
}

Sorry to bump an old thread, but this was the exact problem I was working on. Unfortunately I ran into a problem using the quoted code: I get "incomplete type is not allowed" with regards to the "type" in that code.

EDIT: *sigh* my bad, I assumed that StringStream would be included in iostream.

8

Graphics / Checking the existence of an image?

« on: July 29, 2011, 05:44:06 pm »

There's no direct function to check if an image is empty or not, but you can easily make one:

Code: [Select]

bool IsEmpty(const sf::Image& image)
{
    return (image.GetWidth() == 0) || (image.GetHeight() == 0);
}

Excellent, thanks. I was considering that, but its nice to see it laid out like that.

9

Graphics / Checking the existence of an image?

« on: July 29, 2011, 05:44:42 am »

Is there any way to run a simple check on weather an image has been initialized/exists? I have a static image member as a class to share among all instances, and I want to only call image.create (or image.load) on the creation of the first object (obviously). There doesn't seem to be a method that would do what I want, and just trying "if(image)" and "if(!image == NULL)" don't work (two things I thought might)

I'm currently jury-rigging it with this, but it feels inelegant.

Code: [Select]


if(BrickImage.GetHeight() < 5){
BrickImage.Create(15, 80, sf::Color(100, 255, 255));
}


10

General / Re: Problem passing and accessing a vector

« on: July 27, 2011, 09:38:27 pm »

The following code compiles and runs fine:

Code: [Select]

std::vector<SolidObject *> bricks(6);
for(int i = 0; i <bricks.size(); i++){
App.Draw(bricks[i]->Sprite);
}


I don't think so. You create a container full of null pointers; dereferencing them is undefined behavior (but will instantly abort the program on most environments). Your error message refers to an address very close to 0, which often indicates null pointers.

Just use a std::vector<SolidObject> and initialize the elements correctly. If you really need pointers (because of polymorphism), allocate memory for them. But generally, I would prefer different containers with static types, i.e. a std::vector<Brick> etc. This also saves you from case differentiations at runtime.

Er, my bad, I omitted the code there where I loop through and fill the vector with new SolidObjects. The reason why I'm using pointers and polymorphism is so that I can (hopefully) efficiently handle collision detection between objects. That is to say if I have a moving object and I want to check if it collides with something else instead of using something like a QuadTree to break things down spatially I can just scan through a vector of all collidable objects for proximity as determined by the Sprite.position member.

Also I reworked things to work with an iterator, so my current code looks like:

Code: [Select]


void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile, std::vector<SolidObject*> &Immobile){
for(std::vector<SolidObject*>::iterator it = Mobile.begin(); it != Mobile.end(); it++){
App.Draw((*it)->Sprite); //make note of how this works
      }
}


11

General / Problem passing and accessing a vector

« on: July 27, 2011, 06:13:40 pm »

"const" is just how you pass the variable to the function, it applies only inside the function. Each function can decide or not to use const.

The rule is: if the function modifies the variable, pass a reference; if it doesn't modify the variable (like your draw function), pass a const reference.

Okay, yeah, that's what I thought. Thanks!

EDIT: Okay, I have no idea if this is related but I made that change, tried to recompile and I got a

Code: [Select]

0xC0000005: Access violation reading location 0x00000030. error. Visual C++ highlights this line:

Code: [Select]


const Matrix3& Drawable::GetMatrix() const
{
    // First recompute it if needed
   if (myNeedUpdate) //this line
    {
        myMatrix.SetFromTransformations(myCenter, myPosition, myRotation, myScale);
        myNeedUpdate = false;
    }

    return myMatrix;

in drawable.cpp

12

General / Problem passing and accessing a vector

« on: July 27, 2011, 06:06:10 pm »

void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile())

By the way, Mobile should be a const reference.

Will removing the parenthesis help? I'm pretty sure I tried that, but I'll give it a shot.
Also is "Mobile should be const" a hard rule, or a good programming guideline? Because I think there are times where I'll want to iterate through the entire vector and change the properties of every object inside it, including adding or deleting objects.

EDIT: Wow, I could have sworn I added and removes those parentheses like ten times last night and it never worked, but this time it did. Maybe I had other errors.

What you said about const got me thinking though. My current plan is to use vectors to handle the organization in any "game" I make. Is that a bad idea?

13

General / Problem passing and accessing a vector

« on: July 27, 2011, 05:55:05 pm »

Okay, so this feels like a really rudimentary question, but its driving me nuts. The following code compiles and runs fine:

Code: [Select]


std::vector<SolidObject *> bricks(6);
for(int i = 0; i <bricks.size(); i++){
App.Draw(bricks[i]->Sprite);
}


but when I try to work with it inside a method I get errors:

Code: [Select]


void System::Draw(sf::RenderWindow &App, std::vector<SolidObject*> &Mobile()){
for(int i = 0; i < Mobile.size(); i++){
App.Draw(Mobile[i]->Sprite);
}


The errors I get are:

Code: [Select]

error C2228: left of '.size' must have class/struct/union
1>          type is 'std::vector<_Ty> &(__cdecl *)(void)'
1>          with
1>          [
1>              _Ty=SolidObject *
1>          ]

 error C2109: subscript requires array or pointer type

error C2227: left of '->Sprite' must point to class/struct/union/generic type


I feel like there's something really obvious here that as a novice programmer I'm just not seeing.
Oh, and I use a vector of pointers because SolidObject is a generic class from which I derive many different types that I want to store all together.

Any help is greatly appreciated.

14

Graphics / Collision detection with many objects

« on: July 26, 2011, 10:51:47 pm »

Thanks for the response. You're right, 50 and 100 are still fairly few objects, but if I were to expand this into something like a simple platformer there might be upwards of 2000-3000 blocks in a "level" and it seems downright wasteful to check if the player sprite is in collision with every single block in a stage every frame. Note that I'm not comparing every object to every object here, just a few "mobile" objects against immobile objects and other mobile objects.

That might be easy in the first term, but just out of interest: How would you find out which collision function to call, depending on the types to check; e.g. paddle <-> ball, brick <-> ball, ball <-> ball (in case of multiple balls)?

The plan in that situation would be for each object to have a type identifier member. The actual Collision methods I linked to above would just be for determining if a collision exists, and the specific implementation for each different type of object would handle the multiple types of collisions. Basically a three step process:
1.)Scan the object array looking at coordinates to determine proximity.
2.)Run collision on objects in close proximity.
3.)If collision returns true, access the type member of the colliding object and preform the appropriate action.

I'll check out the link you posted as well. You're right that this isn't a problem for the scope of my current project, but I am very interested in the theory behind a more robust algorithm, since that's what I'm going to need if I ever scale my projects up to something truly large.

EDIT: Looking at some articles on Quadtrees and Space Partitioning. I'm not seeing a solution to the problem of having to examine the co-ordinates of every object in existence every frame, even if Quadtrees and SP seem to help with the proximity issues. Am I missing something, or is that just how things have to work?

EDIT2:Okay, this is interesting:

The QuadTree is designed to be faster at querying the spatial domain than iteration, but the performance of the index depends on the distribution of objects in the domain. If items are clustered together, the tree tends to have many items in one branch which defeats the strategy of being able to cull large regions, and reduce the number of intersection tests.

Culling large amounts of space isn't a problem in my system, since things aren't organized spatially. I don't expend time looking for empty regions since I'm iterating over an array filled with solid objects. So I'm not sure if the QuadTree is going to be very helpful specifically. What does interest me though is finding a way focus the search over time, to hone in on objects in proximity to the test object, and not spend time checking the co-ordinates of other objects. To do that I'm pretty sure I need a tree structure so that I can ignore branches. Perhaps initiating a one-time organization system once all objects have been created...

15

Graphics / Collision detection with many objects

« on: July 26, 2011, 08:26:02 pm »

So I'm still getting a handle on a lot of elements of SFML and I've got a few questions that I'm grappling with. I've been working with the Collision Detection methods laid out here: https://github.com/SFML/SFML/wiki/SourceSimpleCollisionDetection

Now this is great as long as I've got two objects to compare collision with, but if I'm working on say...a Breakout clone (I am) things get messier when I've got twenty objects on screen.
It would be easy to write a base SolidObject class, derive both the paddle and the bricks from that class, and make an array of SolidObjects containing one game's worth of paddle and bricks. From there I could scan through each element of that array, check for proximity to the Ball and if they're close enough pass them to one of the Collision methods. The problem is that that seems woefully inefficient, especially if I'm running it every frame. What about if I had fifty elements? Or a hundred?

I'm really looking for basic advice here, for anyone who has done major work with collision detection before. A direction to look in, an idea to try, any of that. Ideally what I'm looking to make is some kind of system that only looks at objects in close proximity to the Ball from the start, so that I'm not cycling through a huge array every time.