[Solved]Weird graphical bug

[natchos]

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]

[eXpl0it3r]

... modifying to the SFML source code ...

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?

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:

The problem is that when I did that, well the game looked really weird (check out the screenshot).

And the screenshots don't really help.

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

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.

Did you also clear your solution and rebuild everything?

[natchos]

...

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]

[eXpl0it3r]

I've no idea what you're doing wrong in your code.

Try to reduce as much as you can, it will either then reveale your problem, or you could then post this minimal example code here and we can figure out.
It certantly isn't SFML's or std::vector's fault, it's something with your code.

[natchos]

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)
 

[Celtic Minstrel]

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.

This is intentional; a pointer to a non-existent object just past the end of the list is the STL's way of signalling the end of an iteration. You'll find that Entities.end() also returns an iterator that points to a non-existent object, and that it's the same one; and that's why the loop terminates.

[eXpl0it3r]

as opposed to retrieving them from a vector through an iterator loop and then rendering them

There's no logical reason why using a std::vecotr should have influence on your rendering stuff, unless you don't initialize your entities right.

App.Draw(mysprite)

App.Draw(*eniter);

Is mysprite an entity too? I mean if you first render directly a sprite and then compare and render an entity the possibility is still there that your entity class is causing the strange behaviour.

Maybe if you post more of your entity class, we could tell if it's that class.

[natchos]

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.

[natchos]

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.

[natchos]

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.