Messages

1

Graphics / Re: Collision with FloatRect

« 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

2

Graphics / Sprite.GetSize() advice needed...

« on: March 21, 2012, 02:43:10 pm »

you using 2.0? Because getSize does't exist.

In 1.6 GetSize() returns a Vector2f. A Vector2f has an x and y, so you'll need to use

buttonTwo.GetSize().x or buttonTwo.GetSize().y

3

Graphics / Sprite x and y

« on: March 18, 2012, 05:43:41 pm »

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Transformable.php#a6a0552d8cf155b7df25f6ceda8ee45a5

4

Graphics / Sprite layering

« on: March 16, 2012, 02:43:35 pm »

I decided to do away with the z-index ordering and programatically work out what sprite is at the top of the screen and draw them first, then come down the screen and then draw them secondly.

This works well and my character will now get draw correctly behind and in front of other sprites. However, this only works if my sprites are the same size as me character (32x32) if I use double height sprites (32x64) the object gets drawn top of my character if Im standing above the top half of the sprite.

5

Graphics / Sprite layering

« on: March 14, 2012, 09:14:06 pm »

Hay all, I've made a "SpriteManager" class which takes a bunch of "gameObjects" (which is a class which inherits from sf::Sprite) and sorts them by their zIndex. The SpriteManager then draws the gameObjects to the screen based on their zIndex.

This gives me a lot more control over the ordering of the sprites. However there still seems to be an issue where the ordering does sit right. It seems that the only way to do this correct is to sort them by how they appear on the screen. The sprites at the very top of the screen are drawn first and the ones at the bottom are drawn last.

Is this the only way to do this? What other ways are there to tackle this problem

6

General discussions / How's SFML 2.0 coming along?

« on: March 06, 2012, 10:44:35 pm »

SFML is near complete I think.

7

Graphics / Collision with FloatRect

« 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?

8

Graphics / Collision with FloatRect

« 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.

9

Graphics / Collision with FloatRect

« 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?

10

Graphics / Collision with FloatRect

« on: February 29, 2012, 11:43:57 pm »

No, the collision checks happen first, then the Update gets called (which Draws the shape).

11

Graphics / Collision with FloatRect

« 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

12

Graphics / Collision with FloatRect

« on: February 29, 2012, 02:49:35 pm »

Pretty please

13

System / Visual C++ Express 2008

« on: February 29, 2012, 02:44:25 pm »

I'm new to C++ but isn't

using namespace sf;

and then

sf::Event

completely wrong?

14

Graphics / Collision with FloatRect

« 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?

15

Graphics / Collision with FloatRect

« on: February 27, 2012, 05:18:43 pm »

sorry, I don't think I explained myself very well. I'm using Intersects and that successfully returns a boolean (true on collision, else false).

I'm having difficulties actually dealing with the FloatRects once they actually collide (making FloatRect A stop moving and revert to the boarder of FloatRect B).