How not to use "new"

[slotdev]

Hi Laurent

Sure, here's the code for where I load the textures:

Code: [Select]


        int gfxNum = 0;
while (xml && xml->read())
{
if (xml->getNodeType() == EXN_ELEMENT)
{
if (!strcmp("TextureResource",xml->getNodeName()))
{
gfxEngine->gfxTextures[gfxNum].LoadFromFile(xml->getAttributeValue("file"));
gfxNum++;
}
}


The declaration of gfxTextures is:

Code: [Select]


sf::Image gfxTextures[5];


SpriteObj objects are destroyed in the destructor of the GfxEngine class.

[Laurent]

It becomes too complicated, you should try to write a complete and minimal code that reproduces the problem (without all your engine stuff around).

[slotdev]

Here's a VERY stripped down version (1 source file) which reproduces the problem. Please download it and try, you probably have to change the VC++ paths to the lib files. Try with your own version (SFML 1.6), but I included the debug EXE & all DLLs I use in the RAR also.

http://db.tt/1UAK2ut

It opens a small window 512x384 and displays multi colour tiles very rapidly (see testimage.png).

I have an idea of what causes the problem but if you can check, that would be great.

I think the problem is, each sprite is made from a sub-rect of testimage.png, so when the destructor gets called at the program end (automatically, not by me the sf::Image is deallocated/freed/whatever but it's the same image file for all sprites, so it's being deallocated every time ?? Just an idea.

Thanks
Ed[/url]

[slotdev]

Right, I have just done a test with that exact code, running SFML 2.0, and it seems to work OK. So either there is an SFML 1.6 problem or some wierd compiler issue.

Anyway I will continue with SFML 2.0, which is probably for the best!

[Roswell_r]

Just noticed in your original code you called a function GetName() of SpriteObj when destructing the Gfx class. But no where in SpriteObj constructor do you store any information about the name. Perhaps you were returning a static name all the time??? or perhaps you left that code out in your snippet.

So this is my guess, destructor would of been calling delete on a invalid iterator returned by the subscript operator of the map. But as previous posters have said no where do you desctruct the image in that code so it can't be the image pointer.

Regarding your new code, you're keeping everything on the stack (which is good for someone of your skill) There are some issues in your code and this would explain why you are facing problems with using pointers.

There is nothing wrong with using the stack.

[slotdev]

Roswell_r,

Thanks for the message. You may have guessed from the code my background is not in C++, but embedded systems (making hardware talk to one another, pretty much).

The stuff about SpriteObj - I had a separate vector of strings, and I use those to create the std::map and then reference it. It all worked fine - the only thing was the sf::Image falling over every time the destructor was called on the sf::Sprite, which I cannot fathom. This same method doesn't fall over on SFML 2.0, so I really have no idea what was going on.

I will try and get stuff off the stack where possible, but I am commercially constrained (i.e. the more time coding, the less money I make) so it has to work robustly, quickly. Such is life.

Cheers
Ed