Sprite fucking up

[N64vSNES]

Okay I think it's fair to say I've tried really hard with this one...

I was screwing with how stuff got loaded in EQ and here is how I'm trying to load data for the items:

Code: Select all

void Eternal::ItemSystem::Initialize() {
	DbgLog *Dbg = DbgLog::GetInstance();
	Dbg->Print("Loading items\n");
	std::ifstream file("Data/ItemSet.txt");

	// How many items were loaded
	unsigned int n = 0;

	// Just to load crap into
	std::string str;

	// Holds the item sprite paths
	std::vector<std::string>lines;
	while(!file.eof()) {
		file >> str;
		lines.push_back(str);
		std::getline(file,str);
		Descriptions.push_back(str);
		n++;
	}

	// Resize the vector to fit our sprite amount
	Sprites.resize(n);

	// Loop through them all and load them
	for ( unsigned int i = 0;i < n;i++ ) {
		Sprites[i].Load(lines.at(i));
	}
	
	file.close();
	Dbg->Print("Loaded items successfully\n");
}

Here is the file that's being loaded:

Code: Select all

Data/Graphics/Items/Item1.png -- sprite path
WORK YOU PILE OF SHIT! -- description

Each item has a short description that gets displayed and a path to the sprite.

When I add a item to the map like so:

Code: Select all

ItemSystem->AddItem(200,200,1);

Here is my output:


But if I make the sprite vector public and do this:

Code: Select all

ItemSystem->Sprites[0].Load("Data/Graphics/Items/Item1.png");
ItemSystem->AddItem(200,200,1);

Here is my what I get:


Any suggestions?

Oh and I moved the item down and right a little bit in the second screenshot, don't worry about it xD

[Milch]

Well, there is no obvious error atleast.
Maybe make an debug-output before the Sprites-loading-loop and inside, so you'll see if it gets actually called + with what argument?

[N64vSNES]

Here is part of the debug output where the item gets loaded.

Code: Select all

Loading items

Allocated texture- Data/Graphics/Items/Item1.png

I had a similar issue when working in linux with GCC, where it fucked up because it read in the newline aswell. Think this could be it?

[dandymcgee]

The first one looks like it's scaling your entire tile sheet to the size of one tile and displaying it. Check your clipping coordinates.

[N64vSNES]

The first one looks like it's scaling your entire tile sheet to the size of one tile and displaying it. Check your clipping coordinates.

Nah 32x32 is it's native size

It MUST be loading correctly because I set the clipping width and height to it's native size when it's loaded.

Also the I've tried removing the RenderSprite() call and just calling Sprite.Render() but it made no difference. ( RenderSprite renders it by camera coords )

[pubby8]

First, fix:

Code: Select all

   std::vector<std::string>lines;
   while(!file.eof()) {
      file >> str;
      lines.push_back(str);
      std::getline(file,str);
      Descriptions.push_back(str);
      n++;
   }

Dunno exact behavior, but it looks like you are copying file into str multiple times, and you also forget to add '\n' onto descriptions. Oh, and you it will be at end of line after first run.

[N64vSNES]

First, fix:

Code: Select all

   std::vector<std::string>lines;
   while(!file.eof()) {
      file >> str;
      lines.push_back(str);
      std::getline(file,str);
      Descriptions.push_back(str);
      n++;
   }

Dunno exact behavior, but it looks like you are copying file into str multiple times, and you also forget to add '\n' onto descriptions.

Yes I copy it from the file, push it back and then copy it for the description. Why allocate another string when I can recycle the first?
And I don't need a newline on the end of the descriptions because they're only supposed to be one line. It's supposed to be something like "Health Potion", "A Cookie", "Strange Object" etc.

Oh, and you it will be at end of line after first run

What?

[Falco Girgis]

First, fix:

Code: Select all

   std::vector<std::string>lines;
   while(!file.eof()) {
      file >> str;
      lines.push_back(str);
      std::getline(file,str);
      Descriptions.push_back(str);
      n++;
   }

Dunno exact behavior, but it looks like you are copying file into str multiple times, and you also forget to add '\n' onto descriptions. Oh, and you it will be at end of line after first run.

You're a fucking moron.

1) "file" is an ifstream handle. He's reading both a name and description from the stream and temporarily storing it within str before copying it to its respective location. Copying file into string? Do you know how C++ streams and the '<<' operator work?

2) Be at the end of the line after first run? Considering he's deserializing strings from a file where each string is OBVIOUSLY on its own line, is this not the point?

3) And yes, not adding '\n' to the end of a description is going to cause his textures to be distorted? Obviously he preferred it that way, smartass.

Seriously, you're clearly a very inexperienced, shitty programmer. Your attempts to help people are just you streaming shit out of your asshole (you understand those streams, but not ifstreams?) while radiating your inferiority complex by being a condescending prick.

You are obviously a far worse developer than anybody you are trying to help on these boards. Feel free to get on our level or get the fuck out of here.

Ignore him, N64vSNES, you're definitely a far better programmer than he is.

Honestly, it really does look like a texture coordinate issue.

[Ginto8]

N64vSNES, could you post what the spritesheet you're using looks like? Cuz it's looking to me like either texture corruption (which, honestly, is unlikely) or as falco said, you're messing up the texture coordinates somehow.

[pubby8]

First, fix:

Code: Select all

   std::vector<std::string>lines;
   while(!file.eof()) {
      file >> str;
      lines.push_back(str);
      std::getline(file,str);
      Descriptions.push_back(str);
      n++;
   }

Dunno exact behavior, but it looks like you are copying file into str multiple times, and you also forget to add '\n' onto descriptions. Oh, and you it will be at end of line after first run.

You're a fucking moron.

1) "file" is an ifstream handle. He's reading both a name and description from the stream and temporarily storing it within str before copying it to its respective location. Copying file into string? Do you know how C++ streams and the '<<' operator work?

2) Be at the end of the line after first run? Considering he's deserializing strings from a file where each string is OBVIOUSLY on its own line, is this not the point?

3) And yes, not adding '\n' to the end of a description is going to cause his textures to be distorted? Obviously he preferred it that way, smartass.

Seriously, you're clearly a very inexperienced, shitty programmer. Your attempts to help people are just you streaming shit out of your asshole (you understand those streams, but not ifstreams?) while radiating your inferiority complex by being a condescending prick.

You are obviously a far worse developer than anybody you are trying to help on these boards. Feel free to get on our level or get the fuck out of here.

Ignore him, N64vSNES, you're definitely a far better programmer than he is.

Honestly, it really does look like a texture coordinate issue.

Why are you getting so upset?
I was only trying to help.

[Falco Girgis]

First, fix:

Code: Select all

   std::vector<std::string>lines;
   while(!file.eof()) {
      file >> str;
      lines.push_back(str);
      std::getline(file,str);
      Descriptions.push_back(str);
      n++;
   }

Dunno exact behavior, but it looks like you are copying file into str multiple times, and you also forget to add '\n' onto descriptions. Oh, and you it will be at end of line after first run.

You're a fucking moron.

1) "file" is an ifstream handle. He's reading both a name and description from the stream and temporarily storing it within str before copying it to its respective location. Copying file into string? Do you know how C++ streams and the '<<' operator work?

2) Be at the end of the line after first run? Considering he's deserializing strings from a file where each string is OBVIOUSLY on its own line, is this not the point?

3) And yes, not adding '\n' to the end of a description is going to cause his textures to be distorted? Obviously he preferred it that way, smartass.

Seriously, you're clearly a very inexperienced, shitty programmer. Your attempts to help people are just you streaming shit out of your asshole (you understand those streams, but not ifstreams?) while radiating your inferiority complex by being a condescending prick.

You are obviously a far worse developer than anybody you are trying to help on these boards. Feel free to get on our level or get the fuck out of here.

Ignore him, N64vSNES, you're definitely a far better programmer than he is.

Honestly, it really does look like a texture coordinate issue.

Why are you getting so upset?
I was only trying to help.

Because not only are you downright incorrect, but you are also an arrogant prick. I have zero patience for that kind of bullshit around these parts. People come here for help, not to be bombarded by your pompous arrogance and general lack of self esteem.

[pubby8]

Fine, I'll stop.

[N64vSNES]

Ignore him, N64vSNES, you're definitely a far better programmer than he is.

Yay I level up!
I feel like I just killed my first dragon quest slime

Honestly, it really does look like a texture coordinate issue.

Yah, I think I may have misread dandymcgee's question slightly.

The item isn't clipped from the level tileset.

Here you can see the items are each their own sprite for size variety.


Here is the level tileset (mixture of chrono and lussika land):


Now if you look at my original screen-shot as dandymcgee pointed out it's this tileset^ However it's scaled down to 32x32. But 32x32 is the size of the potion item. Also all my debug output shows everything loading correctly. So it looks like OpenGL is binding the wrong texture, I'm sure I'm doing something wrong.....

[pubby8]

Have you tried running gDEBugger?

It lets you view every texture loaded and show their gl ID.

[Van-B]

Could it be a problem with the image height and width? - I remember a similar problem with OpenGLES, it wouldn't calculate the image size accurately which caused problems with the UV coordinate calculation. I was using integers to refer to tile number X and Y, then working out the UV coordinates from that.