OK, I took the time to download SFML (I was curious about it, anyway, so it wasn't a big deal), and compiled and tested your program. After setting some breakpoints at various places, I found that it is raising a SIGSEGV (that is, a segmentation violation) in the initialization of PlayerA , on the line
PlayerFeet.SetImage(iFeet);
The call stack at the point where it segfaults reads like so:
#0 00A18C6B std::_Rb_tree_decrement(__x=0x406044) (../../../../gcc-4.4.0/libstdc++-v3/src/tree.cc:89)
#1 00A02CAF std::_Rb_tree_iterator<sf::ResourcePtr<sf::Image>*>::operator--(this=0x28fd48) (d:/programmes/mingw-4.4/bin/../lib/gcc/mingw32/4.4.0/include/c++/bits/stl_tree.h:199)
#2 00A10E3E std::_Rb_tree<sf::ResourcePtr<sf::Image>*, sf::ResourcePtr<sf::Image>*, std::_Identity<sf::ResourcePtr<sf::Image>*>, std::less<sf::ResourcePtr<sf::Image>*>, std::allocator<sf::ResourcePtr<sf::Image>*> >::_M_insert_unique(this=0x406040, __v=@0x28fdfc) (d:/programmes/mingw-4.4/bin/../lib/gcc/mingw32/4.4.0/include/c++/bits/stl_tree.h:1179)
#3 00A09B48 std::set<sf::ResourcePtr<sf::Image>*, std::less<sf::ResourcePtr<sf::Image>*>, std::allocator<sf::ResourcePtr<sf::Image>*> >::insert(this=0x406040, __x=@0x28fdfc) (d:/programmes/mingw-4.4/bin/../lib/gcc/mingw32/4.4.0/include/c++/bits/stl_set.h:411)
#4 009C83A6 sf::Resource<sf::Image>::Connect(this=0x406040, Observer=...) (../../include/SFML/System/Resource.inl:77)
#5 009C4678 sf::ResourcePtr<sf::Image>::operator=(this=0x4062cc, Resource=0x406040) (../../include/SFML/System/ResourcePtr.inl:102)
#6 00922CB4 sf::Sprite::SetImage(this=0x406220, Img=...) (D:\dev\sfml\sdk\SFML-1.6\src\SFML\Graphics\Sprite.cpp:72)
#7 004016CA PlayerClass::PlayerClass(this=0x406220, natl=UK) (C:\Users\Schol-R-LEA\Documents\Programming\Projects\Quick Tests\Battlefront\PlayerClass.cpp:15)
#8 00402D16 __static_initialization_and_destruction_0(__initialize_p=<optimized out>, __priority=<optimized out>) (C:\Users\Schol-R-LEA\Documents\Programming\Projects\Quick Tests\Battlefront\Battlefront.cpp:13)
#9 00000000 _GLOBAL__sub_I_MainWindow() (C:\Users\Schol-R-LEA\Documents\Programming\Projects\Quick Tests\Battlefront\Battlefront.cpp:29)
#10 0040244F __do_global_ctors() (../mingw/gccmain.c:59)
#11 00401098 __mingw_CRTStartup() (../mingw/crt1.c:236)
#12 00401284 mainCRTStartup() (../mingw/crt1.c:264)
The most relevant part of the call stack is highlighted in red; it shows that the code where it is failing is being called in the static initialization, which takes place before main() begins.
Now, the image files are supposed to get loaded in MatchSprites() ; however, because you are initializing PlayerA as a global variable, the c'tor is actually being called before MatchSprites() has run (and in fact before the beginning of main() , with the result that iFoot hasn't been initialized at the time when you are setting the the image as part of the PlayerA object, with the result that an invalid pointer is being passed to _Rb_tree_decrement() (don't worry about what that is, it is a standard library call that the SFML libraries are using).
The best way to avoid this is to move the declaration of PlayerA out of the global namespace, or at the very least, not actually initialize it until after MatchSprites() has run. Unfortunately, this means changing how you are accessing the icode]PlayerA[/icode] object in other parts of the code; on the other hand, it should improve the generality of your code, and will reduce the scope that PlayerA is visible through, which is all to the good.
BTW, could you zip up a copy of the sprites in question, so I could follow along through the whole process? As it is, even if you got the program running on your system, we wouldn't be able to help you debug it as we wouldn't have the sprite files.