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

Author Topic: Collision with FloatRect  (Read 11392 times)

0 Members and 1 Guest are viewing this topic.

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #15 on: February 27, 2012, 11:22:11 pm »
Ok, I'm getting somewhere now.

main.cpp - http://pastiebin.com/?page=p&id=4f4c0145b3656
tile.h - http://pastiebin.com/?page=p&id=4f4c0178e3182
tile.cpp - http://pastiebin.com/?page=p&id=4f4c019a11ace

If you set these files up and run them you can move around with WASD

The problem I face is when the block collides it correctly collides, but it also draws the overlapping frame, then the reverted position frame. I'm not sure why this happens, surely the calculations and repositioning is done before the next Draw() is made.

Can anyone lend me a hand on this please?

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #16 on: February 29, 2012, 02:49:35 pm »
Pretty please :)

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Collision with FloatRect
« Reply #17 on: February 29, 2012, 09:14:21 pm »
I cannot see any of your .cpp files.

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #18 on: February 29, 2012, 09:58:49 pm »
Really? Works for me using Safari.

Try these - main.cpp http://pastie.org/3491192
tile.h http://pastie.org/3491196
tile.cpp http://pastie.org/3491200

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Collision with FloatRect
« Reply #19 on: February 29, 2012, 10:39:18 pm »
Do your Update calls before the CheckCollidingWith ones.

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #20 on: February 29, 2012, 11:43:57 pm »
No, the collision checks happen first, then the Update gets called (which Draws the shape).

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Collision with FloatRect
« Reply #21 on: March 01, 2012, 04:23:21 am »
You must change your logic then, because the drawing is being done right after the movement, and the collision step is only done at the begining of the next loop.

I suggest you do your collision calculations inside your update function, or draw your sprites outside of the update function (or both).

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #22 on: March 01, 2012, 02:15:54 pm »
Ok I get you, so should I be change my Update() to Update(tiles) and pass the tiles vector?

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Collision with FloatRect
« Reply #23 on: March 01, 2012, 07:01:29 pm »
You can do that, or make the vector global.

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #24 on: March 02, 2012, 01:45:29 pm »
The global root sounds better. Is it a good idea to have ALL my "collider FloatRects" stored within a global vector? There could be hundreds.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Collision with FloatRect
« Reply #25 on: March 02, 2012, 07:51:59 pm »
Global is never better :P

Why don't you write a class that is responsible for the collision of the rectangles?

And why does the tile class store the RenderWindow? It could provide a Draw() function, this shouldn't be in Update() anyway. Furthermore, especially in the presence of many tiles, it might be better not to store any graphical data in the tiles. You could for example construct sf::RectangleShapes on the fly...

You have to experiment a little, I personally like to separate responsibilities (like graphics and physics), as it makes maintenance and interchangeability easier.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Collision with FloatRect
« Reply #26 on: March 03, 2012, 12:49:06 pm »
Nexus, I read up on global variables after I posted my reply, and all the articles mentioned why you should never use global variables unless you absolutely need to.

The rectangles will eventually become sf::Sprite's.

The reason I passed a reference of RenderWindow to my tile class was so that I could handle all my logic in tile class, so my main loop would call only the Upate() method, then the Update() method in my tile class would do everything it needs to. Is this a bad idea? I wanted to sort my code that everything is self contained within each class. I guess this way of doing stuff was from moving from Unity3d, where every game object has it's own Draw() and Update() method.

What would the collision class do? Would it take 2 FloatRects then work out collision, or would it take 2 tiles?

unranked86

  • Newbie
  • *
  • Posts: 37
    • View Profile
Collision with FloatRect
« Reply #27 on: March 03, 2012, 02:43:21 pm »
I think, your collision class should take 2 FloatRects.
And instead of creating the rects "by hand" for your Sprites, take a look at Sprite.GetGlobalBounds

dotty

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
Re: Collision with FloatRect
« Reply #28 on: March 25, 2012, 02:56:34 pm »
Sorry to bring this up again. I've got the grasp of checking and dealing with collisions using IntRect now, however I can't seem to handle multiple collection checks.

My project is zipped up at https://legacy.sfmluploads.org/file/112

Bascially move around with WASD if you collide into the upper right box then "slide" to the left (using W and A), the moveable block gets stuck when trying to deal with the collision between 2 boxes.

Can someone please lend me a hand on this, I've been trying to deal with this problem all weekend and just cannot get it working! I think it's the way the blocks are added to the vector.

If you don't want to download the zip file, the files are located at pastie.org

main - http://pastie.org/3654696
player - http://pastie.org/3654701
spriteManager - http://pastie.org/3654702
gameObject - http://pastie.org/3654708