Messages

61

General / Re: sf::clock not working (or maybe I am being stupid)

« on: August 17, 2012, 12:22:46 am »

Shouldn't it be movementloop == true? movementloop = true would mean that you set movementloop to true, I believe, same with movementloop2 = true should be movemementloop2 == true.

Also why are you using movementloop and movementloop2?

Wouldn't it be easier to do it like this

while (movementloop == true
{
 //do somethingelse
}

while (movementloop == false)
{
 // do something else
}
 

Also I would recommend altering the calling of movementloop = true; to something like this

if (Invader1Sprite.GetPosition > SCREENEDGE) movementloop = true

this would make sure that movementloop would only be switched to true when the Invader reaches the screenborder (you would have to define SCREENEDGE first of course)
Do the same in both loops and it should work.

... Also, listen to eXpl0iter

62

General / sfml 1.6 sprite::GetSize equivalent? and general 2.0 questions

« on: August 17, 2012, 12:00:09 am »

So I'm back with another fairly stupid question

Is there a 2.0 equivalent to 1.6 sprite::GetSize() function, or is getGlobalBounds() the closest thing to that that we get?

I'm just wondering because I am in the middle of changing my project from 1.6 to 2.0, so I would just like to know, since it would change the structure of some crucial functions.(Not in a bad way, I just wonder whether I have to rewrite them )

63

SFML website / Re: Search/Database problem

« on: August 16, 2012, 11:42:30 pm »

Happening almost constantly. It also gives an error where the browser says that the server sent no data.

64

General / Re: Collision "dont know how"

« on: July 21, 2012, 02:46:53 pm »

A simple solution, is to enlargen the rect if your pacman is going at high speed.

float speed;
if( pacman.getVecloity > 10) speed = 30;
else if (pacman.getVelocity > 15) speed = 45;
sf::FloatRect(pacman.getPosition + speed, etc);

As exploiter says there are tons of guides and/or ready made functions floating around on the web, so feel free to use one of them if you don't want make your own.

65

General / Re: If bug? SFML 1.6

« on: July 21, 2012, 02:03:22 pm »

So I jumbled the code around a bit and simplified it.

Here is how the new functions look:

        bool BoxCollision(sf::FloatRect FirstRect, sf::FloatRect SecondRect, sf::FloatRect& gap)
{
        this->RECT1 = FirstRect;
        this->RECT2 = SecondRect;
        return this->RECT1.Intersects(this->RECT2,gap);
}


bool ADVBoxCollision(sf::gEntity& player, sf::gEntity& sprite2, bool& pTop,bool& pLSide, bool& pRSide, bool& pBottom)
{
        float YVel = player.GetYVelocity();
        float HSLS = 0;
        if((YVel > -3.0f) && (YVel < 3.0f)) HSLS = 7;
        else if((YVel > -9.0f) && (YVel < 9.0f)) HSLS = 30;
        else HSLS = 50;
        /* HSLS stands for HighSpeed-LowSpeed. If the speed of one of the objects is high it is generally preferable to use a larger hitbox (to more accurately
        detect hits. However, at low speeds this results in alot of jitter as the sprites get pushed around the whole time. Therefore we modify the HSLS
        variable depending on the Velocity given to us */
        bool Firsttotheleft = false;
        bool Firsttotheright = false;
        bool Firstabove = false;
        bool Firstbelow = false;
        sf::FloatRect gap;
        sf::FloatRect FirstRect = sf::FloatRect(player.GetPosition().x - player.GetSize().x/2 - HSLS, player.GetPosition().y - player.GetSize().y/2 - HSLS,player.GetPosition().x + player.GetSize().x/2 + HSLS,player.GetPosition().y+player.GetSize().y/2+HSLS);
        sf::FloatRect SecondRect = sf::FloatRect(sprite2.GetPosition().x - sprite2.GetSize().x/2, sprite2.GetPosition().y - sprite2.GetSize().y/2,sprite2.GetPosition().x + sprite2.GetSize().x/2 ,sprite2.GetPosition().y+sprite2.GetSize().y/2);
        //ToS stands for Top or side. It tells whether the sprite collided with the top/bottom part or the side part. 0 = top/bottom, 1 = sides
        if(BoxCollision(FirstRect, SecondRect, gap))
        {
                if((FirstRect.Right - gap.GetWidth) - SecondRect.Left > 0) Firsttotheright = true;
                if((FirstRect.Left + gap.GetWidth) - SecondRect.Right > 0) Firsttotheleft = true;
                if((FirstRect.Top + gap.GetHeight) - SecondRect.Bottom > 0) Firstbelow = true;
                if((FirstRect.Bottom - gap.GetWidth) - SecondRect.Top > 0) Firsttotheright = true;
                if(Firstbelow) pBottom = true;
                if(Firstabove) pTop = true;
                if(Firsttotheright) pRSide = true;
                if(Firsttotheleft) pLSide = true;
                return true;
        }
        else return false;
}

66

General / Re: If bug? SFML 1.6

« on: July 21, 2012, 01:39:33 pm »

Tyvm for the replies guys! I'll read them through more carefully and see what I can learn/use from them.

To thePyro_13: BoxCollision is just a call to Rect::Intersect.

However I use collision between two different classes and also in the same classes.
This mean I have 3 ADVBoxcollision and 3 BoxCollision functions.

bool BoxCollision(sf::gEntity sprite1, sf::gEntity sprite2)
{
        this->RECT1 = sf::FloatRect(sprite1->GetPosition().x - sprite1->GetCenter().x ,sprite1->GetPosition().y - sprite1->GetCenter().y,sprite1->GetPosition().x+sprite1->GetSize().x - sprite1->GetCenter().x,sprite1->GetPosition().y+sprite1->GetSize().y - sprite1->GetCenter().y);
        sf::gEntity* localpointerrect2 = &sprite2;
        return BoxCollision(localpointerrect1,localpointerrect2);
}

bool BoxCollision(sf::FloatRect FirstRect, sf::FloatRect SecondRect)
{
        this->RECT1 = FirstRect;
        this->RECT2 = SecondRect;
        return this->RECT1.Intersects(this->RECT2);
}

bool BoxCollision(sf::gEntity* sprite1, sf::FloatRect SecRect)
{
        this->RECT1 = sf::FloatRect(sprite1->GetPosition().x - sprite1->GetCenter().x ,sprite1->GetPosition().y - sprite1->GetCenter().y,sprite1->GetPosition().x+sprite1->GetSize().x - sprite1->GetCenter().x,sprite1->GetPosition().y+sprite1->GetSize().y - sprite1->GetCenter().y);
        return this->RECT1.Intersects(SecRect);
}
 

EDIT: Just to clarify.
My function is built in such a way that the 4 if statements does not even get checked if the two rects are not intersecting (which is checked using the built in Rect::Intersects)
EDIT2: Pyro, from where did you get the GetPosition function? From what I know it is not part of the sf::Rect implementation.

67

General / If bug? SFML 1.6

« on: July 21, 2012, 03:32:20 am »

Hey so I've got this really weird expression that just flatout refuses to evaluate to true.

Here comes the function dump, which I will explain.

bool ADVBoxCollision(sf::gEntity& player, sf::gEntity& sprite2, bool& pTop,bool& pLSide, bool& pRSide, bool& pBottom)
{
        float YVel = player.GetYVelocity();
        float HSLS = 0;
        if((YVel > -3.0f) && (YVel < 3.0f)) HSLS = 7;
        else if((YVel > -9.0f) && (YVel < 9.0f)) HSLS = 30;
        else HSLS = 50;
        /* HSLS stands for HighSpeed-LowSpeed. If the speed of one of the objects is high it is generally preferable to use a larger hitbox (to more accurately
        detect hits. However, at low speeds this results in alot of jitter as the sprites get pushed around the whole time. Therefore we modify the HSLS
        variable depending on the Velocity given to us */
        bool Firsttotheleft = false;
        bool Firsttotheright = false;
        bool Firstabove = false;
        bool Firstbelow = false;
        sf::FloatRect FirstRect = sf::FloatRect(player.GetPosition().x - player.GetSize().x/2 - HSLS, player.GetPosition().y - player.GetSize().y/2 - HSLS,player.GetPosition().x + player.GetSize().x/2 + HSLS,player.GetPosition().y+player.GetSize().y/2+HSLS);
        sf::FloatRect SecondRect = sf::FloatRect(sprite2.GetPosition().x - sprite2.GetSize().x/2, sprite2.GetPosition().y - sprite2.GetSize().y/2,sprite2.GetPosition().x + sprite2.GetSize().x/2 ,sprite2.GetPosition().y+sprite2.GetSize().y/2);
        //ToS stands for Top or side. It tells whether the sprite collided with the top/bottom part or the side part. 0 = top/bottom, 1 = sides
        if(BoxCollision(FirstRect, SecondRect))
        {
                if((FirstRect.Left - 30) <= (SecondRect.Right - (FirstRect.GetWidth() - HSLS*2)) &&  (FirstRect.Left + 10 >= (SecondRect.Right - FirstRect.GetWidth())))
                        Firsttotheleft = true;
                if((FirstRect.Right + 30) >= (SecondRect.Left + (FirstRect.GetWidth() - HSLS*2)))
                        Firsttotheright = true;
                if((FirstRect.Top - 30) <= (SecondRect.Bottom - (FirstRect.GetHeight() - HSLS*2)))
                        Firstabove = true;
                if((FirstRect.Bottom + 30) >= (SecondRect.Top + (FirstRect.GetHeight() - HSLS*2)))
                        Firstbelow = true;
                if(Firstbelow) pBottom = true;
                if(Firstabove) pTop = true;
                if(Firsttotheright) pRSide = true;
                if(Firsttotheleft) pLSide = true;
                return BoxCollision(FirstRect, SecondRect);
        }
        else return false;
}

Most of it is fairly straightforward. I construct two rectangles from the sprite and then collide them.
The problem comes when I need to find a distinction between the sides( the

if((FirstRect.Left - 30) <= (SecondRect.Right - (FirstRect.GetWidth() - HSLS*2)) &&  (FirstRect.Left + 10 >= (SecondRect.Right - FirstRect.GetWidth())))
                        Firsttotheleft = true;
                if((FirstRect.Right + 30) >= (SecondRect.Left + (FirstRect.GetWidth() - HSLS*2)))
                        Firsttotheright = true;
                if((FirstRect.Top - 30) <= (SecondRect.Bottom - (FirstRect.GetHeight() - HSLS*2)))
                        Firstabove = true;
                if((FirstRect.Bottom + 30) >= (SecondRect.Top + (FirstRect.GetHeight() - HSLS*2)))
                        Firstbelow = true;

part)

It just flat out refuses to evaluate to true,
I've tried changing the if expressions to every goddamn combination possible.
At one point I simply wrote it as

if((FirstRect.Left > 0)
                        Firsttotheleft = true;
                if((FirstRect.Right > 0)
                        Firsttotheright = true;
                if((FirstRect.Top > 0)
                        Firstabove = true;
                if((FirstRect.Bottom > 0)
                        Firstbelow = true;

Not even then did the ifs evaluate to true (and before you ask, yes I put in breakpoints to find if FirstRect was null or set to zero. It was not).

I'm just wondering whether anyone else has encountered something similar.

68

General / Re: Weird graphical bug

« on: July 04, 2012, 06:20:45 pm »

Aaaaaaand it's gone...

A manual reinstall of vs2008 solved it, which kinda proves my theory that it was not my code that caused it. If laurent could mark this as solved or something I would be grateful.

69

General / Re: Weird graphical bug

« on: July 01, 2012, 05:10:00 pm »

I think I have found the cause of the graphical anomaly. Apparently the sprite gets a nearly infinitely large size (somewhere around 10^6) which of course causes some problems. I will try to correct it lol.

70

General / Re: How to make a class for displaying levels

« on: June 28, 2012, 07:40:40 pm »

Could you give some more precis info?

What kind of level?
What info (precisely) would you like to load?

I made a 2d platformer level loader which loads from a .txt file. Would that be relevant for you?

71

General / Re: Weird graphical bug

« on: June 25, 2012, 05:20:34 pm »

Yeah sure I'll post my class.
The problem (which I probably should have made clear) is that mysprite and *eniter is the exact same object(or atleast duplicates of each other, I'm not sure whether entering a object into a vector copies it or directly moves the original object).

Anyhow, here is the class implementation and declaration:


gEntity.h

#pragma once
#include "SFML\Graphics.hpp"
#include "SFML\System.hpp"
#include "SPClock.cpp"
#include <iostream>
#include <string>


namespace sf
{
class gEntity : public sf::Sprite{
private:
int id;
std::string name;
bool visible;
bool alive;
bool collidable;
int objectType;
int lifetimeLength;
SPClock lifetimeTimer;
float YVelocity;
public:
gEntity();
virtual ~gEntity() { };

void setID(int value) { id = value; }
int getID() { return id; }
void SetYVelocity(float value) { YVelocity = value;}
void IncrementYVelocity(float value) { YVelocity += value;}
float GetYVelocity() {return YVelocity;}
std::string getName() { return name; }
void setName(std::string value) { name = value; }
bool getVisible() { return visible; }
void setVisible(bool value) { visible = value; }
bool getCollidable() { return collidable; }
void setCollidable(bool value){collidable = value;}
bool getAlive() { return alive; }
void setAlive(bool value) { alive = value; }
int getLifetime() { return lifetimeLength; }
void setLifetime(int milliseconds) {
lifetimeLength = milliseconds; lifetimeTimer.reset();
}
bool lifetimeExpired() {

        return lifetimeTimer.stopwatch(lifetimeLength);
        }
int getObjectType() { return objectType; }
void setObjectType(int value) { objectType = value; }
};

}

gEntity.cpp

#pragma once
#include "gEntity.h"
#include <SFML\Graphics.hpp>
#include <SFML\System.hpp>
#include <iostream>
#include <string>

namespace sf{

gEntity::gEntity()
{
this->id = -1;
this->name = "";
this->visible = true;
this->alive = true;
this->collidable = false;
this->objectType = 0;
this->lifetimeLength = 0;
this->lifetimeTimer.reset();
}
}

EDIT: Celtic Minstrel, yea, after the loop is done, however sometimes I get the bad ptr problem if I interrupt during one of the loops using breakpoints.

72

General / Re: Weird graphical bug

« on: June 25, 2012, 01:00:14 am »

So, I've done some more troubleshooting. I have managed to ascertain some things.

Firstly the graphical anomaly does not appear if I render my objects directly (as opposed to retrieving them from a vector through an iterator loop and then rendering them).

so

App.Draw(mysprite)

would work, whereas

std::vector<sf::gEntity> Entities;
std::vector<sf::gEntity>::iterator eniter;

for(eniter = Entities.begin(); eniter != Entities.end();eniter++)
        App.Draw(*eniter);

does not.

Through some investigating I found out that at the end of each main loop(it ends right after the calls to App.Draw) eniter always points a non-existent object.

The mapping of the objects to the vector is correct, when checked using a breakpoint and the mouseover method.

EDIT: I should also have included this line in the second example

Entites.push_back(mysprite)
 

73

General / Re: Weird graphical bug

« on: June 20, 2012, 12:32:51 am »

...

Why couldn't you just implement (another) IsFlippedX/Y variables in your inherted class and create a FlipX/Y method of your own where you set your own IsFlippedX/Y variable and then call the parent FlipX/Y?

Mostly cause I didn't even think of doing it that way. Although I know my way around the syntax and structure of c++ and programs, I obviously have much to learn in building good inheritance and well-designed classes.

Anyway I'll state again the obvious: Stop using SFML 1.6 and start using SFML 2!

As for you're problem: Although you give quite a bit of information around it, the only thing stated really related to the problem is:

...

And the screenshots don't really help.

I have attached another screenshot, that I hope will help more. I will explain what you are seeing.
The long lines that stretch accross the screen? They are supposed to render that red enemy in the nonbugged.jpg picture.

Also you can see the "fading" of the left edge of the floor, and furthermore, the floor is not the colour it should be (check out the nonbugged.jpg picture). None of this is intentional.

If you want some futher help you need to provide a description what's 'weird' since we don't know how it should look like. Also using JPG will introduce some artefacts that people might see as 'weird'.

...

Did you also clear your solution and rebuild everything?

I did. It did not help anything.

I did however find something which convinces me that it is not a problem with sfml, but rather something with the std::vector class.

Can you see the solitary red square in the screenshot?
Upon collision with the player, it reacts, adding a copy of itself to 2 vectors. 1 filled with sf::floatrects which are then used for collision, and 1 filled with the actual image. It also resets itself, placing itself in a new, random position.

Now, before it is added to the vector it looks like it does in the screenshot, but when you "touch" it it becomes a long, drawn-out line/square, much like the enemy picture.


[attachment deleted by admin]

74

General / [Solved]Weird graphical bug

« on: June 19, 2012, 03:26:09 pm »

Hello. So I think I've fucked up pretty big time.
Apparently some coding I did broke something either in vs2008 or in one of the includes needed.

To give some background; I was coding to make a enemy turn to face me in 2d, and I wanted to use the sf::sprite::FlipX function. However I soon ran into a problem, namely that I could not, with any ease, check whether it had been flipped.

I decided to do some modifying to the SFML source code(not a good idea I know) to make the myIsFlippedX and myIsFlippedY variable of sf::sprite not private, but instead protected (since I have a class that inherits from sf::sprite I could then put in a IsFlipped function as a class member).

So basically I changed this

00154 protected :
00155
00160     virtual void Render(RenderTarget& Target) const;
00161
00162 private :
00163
00165     // Member data
00167     ResourcePtr<Image> myImage;      
00168     IntRect            mySubRect;    
00169     bool               myIsFlippedX;
00170     bool               myIsFlippedY;

Into this:

00154 protected :
00155
00160     virtual void Render(RenderTarget& Target) const;
00161     bool               myIsFlippedY;
               bool               myIsFlippedX;
00162 private :
00163
00165     // Member data
00167     ResourcePtr<Image> myImage;      
00168     IntRect            mySubRect;      

(the code is taken from the website documentation).

The problem is that when I did that, well the game looked really weird (check out the screenshot).
Furthermore, even after I changed back the code, and even removed the SFML1.6 folder and put in a new one the issue still appears.

I have only one clue. When I first recompiled after the inital, succesful but bugged out run, VS2008 gave me an error link to a file called xtree. Something about nodes and roots. Can't seem to find the file now tho.
From what I've read about it xtree might have something to do with vectors, which I use vigourously in my work.

Anyone got any clues on how to fix this?
If anyone needs the code for figuring it out, send me a pm and I'll send it over!

PS: I also posted a non-bugged screenshot, taken from a week-old release build.
PSS: Crap, just remembered that this should probabky have been in the Graphical help section T_T

[attachment deleted by admin]

75

General / Re: 2d tile system using 2d std::vectors.

« on: June 07, 2012, 08:38:06 pm »

Huh, that worked. I wouldn't ever have though up something like that myself (I mean, I have used << before, just didn't know that it skipped whitespaces!)

Thanks alot Laurent!