So, can you read error messages?
Look at this one:
Quote:Particle.obj : error LNK2019: unresolved external symbol "public: __thiscall Particle::Particle(void)" (??0Particle@@QAE@XZ) referenced in function "private: struct Particle __thiscall CParticle::CreateParticle(void)" (?CreateParticle@CParticle@@AAE?AUParticle@@XZ)
It says "I tried to look for an empty Particle constructor. I couldn't find it anywhere".
Sort of a strange error, because your struct Particle; is POD (plain old data).
The first thing I'd do is stop polluting the global namespace. I have no clue what garbage is in the global namespace from other libraries.
So place your code in your own namespace.
The second thing I'd do is stop using "using namespace std", or any "using namespace" commands. Doing it in a header file means you deserve any and all compiler bugs.
Import the symbols you need via using std::vector, or by typedef std::vector<blah> blah_vec. This is a matter of code sanitation.
The third thing I'd do is stop using #pragma once, and start using #ifdef header guards. In fact, I find this useful:
#pragma once#ifndef HeaderGuard#define HeaderGuard...#else#pragma warning ("#pragma once failed in " __FILE__)#endif
The possibility of multiple versions of the same header file existing can cause more bugs than you could ever dream possible. #pragma once is a poor guard against that eventuality.
Next, we have a chunk of code that isn't working. It is pretty self contained -- it uses CTexture and a few helper functions.
Move the self-contained part of the project into it's own project. Get it working all alone in a
sane environment. Once that happens, move it back.
Because once you have it working in a sane environment, you can be sure that your problem is your environment, not your source code.
Alternatively, reduce your code down to the point where you have a
minimal test-case that produces the bug. Then try to reproduce the bug in a slightly different way.
Good luck, and may the fish you catch be tasty.