Am I the only one being very confused by the fact that passing a the Entity hero as a parameter to its own member function seems extremely weird and pointless? This basically feels less like it should be "which is faster" and more "somebody please explain the point of member functions".
Your member function already has access to all the members of hero, so why would you pass it at all? Take the second one, remove every last "hero->" (or replace with "this->", depending on preference) and stop passing the object as a parameter to itself.
I'm sure I posted this a lot, but: just because something "seems" to be working just fine, doesn't mean it's actually right. C++ is a language where half the standard seems to say "this is undefined behavior, and this, and this, and this". It is absolutely the last language you should be using for trial and error coding, because stuff will work just fine when you "try something" and will blow up in your face two days later. Why? Because somewhere something completed unrelated in your code will affect the memory layout or eventually overwrite the objects memory you have so happily been accessing and executing after you already deleted it.
The language itself does little to no error checking for you, the compiler will mostly point out syntax errors and many things won't trigger a warning. There is no hand holding and you are expected to know what you're doing. That's also why most people on this forum will tell beginners to stay away from it and start with another language. Not because it is so hard to make something compile. Not because the syntax is difficult or the standard library is so complex. Because you can write horribly bad and bug ridden code and it will still let you believe that everything is working perfectly fine... until it doesn't.
So the usual reply to 99% of all "but it was working before" is "yes, because you have been incredibly lucky".
Reasons why it worked before? Maybe you never called it with a different state. Maybe it kept using the deleted state and you never noticed. Maybe you were incredibly lucky that your new state was placed at exactly the location of your previous state. There's lots of reasons why something happened to work in C++ when it never should have.
A plane is infinite and therefore has no "shape" (unless you consider being flat a shape). A trapezoid has its name because of it's shape. So no, it's not a plane, but it is _on_ a plane.
For above reasons a plane doesn't have "corners" either, you simply need to have three points to define a plane.
You can use a plane to quickly filter out all objects that aren't intersecting the plane your trapezoid is on, but you still need to check if they are actually inside or intersecting the actual shape. The easiest way I could think of is to do 4 more plane tests for each edge of your shape to see if an object either intersects or is inside.
So basically it's exactly the same as frustum culling, except that you have a special case where the top and bottom plane of the view frustum happen to be the same. You could safe yourself one of the 6 plane checks (top and bottom are the same, there is no "inside" in that dimension and so the result of checking for objects "between" top and bottom is the same as objects intersecting either).
If you already have code that does frustum culling, I'd probably not even waste time to write any new code for this particular special case and just use that instead.
in real world application things like defining 1 to be true and 0 to be false with defines(like in C++) are just as stylistic as anything else.
Uhm, true and false aren't defines in C++, because they aren't something that is just commonly tagged on like in C. That's actually making a very big difference, because in C a BOOL(EAN) is typically defined as int, while in C++ it is an actual type.
BOOLEAN b = 5;
if (b == TRUE)
is going to fail. Best example of that I found in the source of a certain game. Some genius decided to return "2" from a BOOLEAN function, because he needed a third result. Of course he didn't bother changing the function to int or some meaningful enum. Even less did that person bother to check all places where that function was already used. So other code that explicitly compared to "TRUE" was now broken.
So in C I would actually very much advice _against_ making explicit comparisons for the very reason that it's just defines (so to be safe, you would always have to either compare against FALSE or use some ridiculous trick like "if (!!variable == TRUE)").
Now, in C++
int x = 5;
if (x == true)
should work just fine (unless I'm getting my promotions wrong), because x will implicitly be turned into an actual bool of value "true". The compiler hopefully still slaps you with some kind of warning for doing this, though.
Still, just because explicit comparisons with "true" are "safe" in C++ doesn't make them any less pointless and redundant to me. The only argument I consider somewhat valid is that a "!" can easily be missed when browsing code, while "== false" is clunky enough to be noticed.
So I made sure I was always set to Debug mode after this thread, and so far I haven't had any errors. But then I switched to Release to test something out, and now everything has been thrown into chaos again.
Which generally means that you still have some major bugs in your code and are simply lucky that those bugs don't have any visible consequences in debug mode, either because your data has a different and less tightly packed memory layout or because stuff is being initialized for you.
The most important lesson in programming: just because it compiles, doesn't mean it's working and just because it appears to be working, doesn't mean it isn't full of serious bugs. Especially when it comes to C/C++, "trial and error coding" will bite you and you should be knowing what you're doing every step along the way. Never "try" something and decide that if it doesn't crash right away it must be "correct" to do it that way.
If your bugs don't show in a debug build and a release build is too optimized or lacking debug symbols to be useful, you will want to copy your release configuration and change the settings, hopefully finding one where the bugs are still happening and you can decently debug. Otherwise, there is always caveman debugging, where you spam debug outputs all over the place to figure out where things are going wrong.
As for "how I can be sure it will work on other computers". That's why "testing" is a very complex subject of its own, involving unit tests, black/white box tests, regression tests and all kinds of other test strategies. Essentially writing tests will take up about the same amount of time as writing the actual code (at least if you want to do it "right").
Forward declarations should be used if you only need a pointer or reference to minimize includes. Making every member a pointer and basically screwing up your design, just so you can use forward declarations isn't going to make your code cleaner. The consequences will be far messier than just having that include. Are you deleting the object behind the pointer in the destructor? Did you create a copy constructor and assignment operator to prevent crashes from deleting it twice (or at least make your class noncopyable)? That's a lot of extra code and effort just to be able to avoid that one include.
I'm also not sure how it's supposed to save you code. Whether it's "include xxx" or "class xxx", you are going to have this one line of code.
Of course replacing the static value of sqrt(i) with a multiplication that needs to be done on every iteration will eventually be slower, if your i gets really big (as in "unlikely big").
The biggest performance issue in the original code would seem to be doing the sqrt in the loop condition and pointlessly calculate it every single time (unless the compiler is friendly enough to optimize that out).
You seem to be getting lost in your own variable names. pHeap is created, assigned and then never used for anything.
It's also weird that the code in front of your loop is exactly the same as the one inside the loop. Also, where are you setting up the next pointers? From what little code I can see, all your nodes next pointers are either pointing to the original list or to random garbage.
Your test should be to print out both lists with the players name and the address. If your code is working, all the names must be the same, but the addresses must be different.
If you don't mind a bit of headache, you can usually avoid all the "is this the head?" or "is the head NULL?" special cases by using pointer to pointer (ie. pointer to next pointer instead of using next pointer directly, so your head elements turns into just the first "next" element). But that isn't something to worry about until stuff is actually working in the first place.
4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.
This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.
Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.
Not sure why anyone would want to deal with angles, when your problem sounds like all you want is "mousePosition - shooterPosition". If all throws are supposed to be equally strong, normalize and multiply with appropriate value. Otherwise just multiply with appropriate factor (and maybe clamp). However if distance to player decides initial speed, it makes aiming weak throws more difficult.
Neither is going to help you learn C++, especially since both are pure C APIs. You might be better off trying to use C++11 features or boost. While it's not a big difference, SFML might be a better choice than SDL in that regard as well.