You're drawing a dragon to your buffer, and then you're drawing that buffer to the screen. It looks like you assume you need to draw the buffer to screen each time you've drawn something to it, but that's not the purpose of such a buffer. The idea is to draw stuff to it first, and at the end, once everything is drawn, you draw the buffer to screen, so the screen gets updated instantly, without flickering. To ensure this, place the following line at the end of your pdraw() function, and only there:
draw_sprite(screen,buffer,0,0);Let's look a bit further. You declare some global variabeles in main.cpp, which are used in playercontrol.h, which also uses a variabele from wingtime.h... even the slightest change in include order can throw up your whole program! Not to mention that in most cases, it's a bad idea to put implementations inside .h files - that's what .cpp files are for. And you shouldn't forget inclusion guards in header files, either.
This article on code organization in C and C++ should be helpfull. Also note that globals are generally seen as a bad habit, because everything can access them, which can make it hard to track down what piece of code changed what variabele.
Your pdraw() function can be simplified a lot. Rather than repeating the same code for every dragon image, store those images in an array, or better, a
std::vector, and select the image you want to draw using wingcounter as an index for the array or vector. Don't repeat code if you don't have to, because it makes code much harder to maintain: if something needs to be changed, it needs to be changed in multiple places now, and it's easy to forget one.
And although this one isn't as troublesome, wingtime() can be written simpler, too, using the modulus operator:
wingcounter = (wingcounter + 1) % ANIMATION_FRAMES_COUNT;Note that using a variabele or define or such rather than a number can make code easier to comprehend. '4' doesn't really say much about it's purpose after all.
Those things probably won't help you solve your problem, although they may help you track down the problem faster. Learning better programming habits can certainly help you prevent such problems. And as superpig said, check what actually happens with a debugger. It should help you figure out where things go wrong much faster than we can help you. :)
@superpig: those seem to be Allegro macro's. Their purpose looks pretty arcane to me, however.