Hello, Im getting this error when I type this: p = new Player(window, clock, windowEvent, view);. This is allocating on the heap, correct? So, why would something like this occur? Also, there are many other pointers in the program that resemble this, so could this be causing the error? I am using SFML 2.0 also.
I can also provide the .cpp files if needed. Also, if it helps, when the error occurs, there is a variable called size which is an unsigned int of 236... It comes up in the small area where the 'locals' menu tab is. (I am using VC++ 2010).
EDIT: There are also many other files, one is called World and contains pointers to both class Enemy and Player. And there is another called Game which contains a pointer to World.
EDIT #2: Lastly, file opens called 'malloc.c'. This is the function that is shown:
> p = new Player(window, clock, windowEvent, view);
> Also, there are many other pointers in the program that resemble this
I doubt that you have a good reason for that. ¿why don't simply create objects?
Sorry if the game design sounds really flawed (its my first game). There are different files for many classes, so sometimes another object in a different file needs to access it. for example, the World class checks collision between player and enemy, and because it is in a different class, I decided to use pointers. I dont know if this game design is bad, but I just sort of 'go with it'.
Anyway, Ive sort of solved my problem. The World .cpp file included player.h, and enemy.h. I swapped enemy.h so that it was on top of player.h, and then removed a pointer in the player class which pointed to the enemy class. Then the pointer in the enemy class did not cause any stack overflows. But, I still dont understand why I cant have both of these pointers.
Sorry to say this, but your best bet would be to redesign this on paper, then try to recreate your classes with your new design.
I'm not saying rewrite it from scratch, keep as much code needed and redesign.
EDIT - The way I'm solving this in my game is by making a Player class and NPC class (There's no Enemy class, NPCs can be enemies, neutral, or allies) derive from a Unit base class. The classes are basically identical, there are some cases where the code is exactly the same from both classes, so why not that?
¿what point? OP has a runtime error, its code compiled.
> I swapped enemy.h so that it was on top of player.h
that should have no effect
> Then the pointer in the enemy class did not cause any stack overflows
... ¿are you sure that the problem was `stack overflow?
Maybe it was simply `segmentation fault'. Probably your links are incorrect (the pointers are pointing to garbage)
Run through a debugger, see the exact line where the crash occurs and go up
Hey! Thats a good idea! But im still confused about all this. Lots of people advise using different header files and cpp files to make the code more organised, but doesnt this end up in more function recursion? At the moment, every class has an update and render function which cdraws and calls other functions such as the move function, and then the next class has it's own update and render function which called those until it reaches the game class where it is called for a final time. But why would creating a pointer make the stack overflowed? Isnt this all allocated on the heap?
This can be easily solved by having a unit manager class
1 2 3 4 5 6 7 8 9
// The functions should be exactly the same as the functions in both classes.
// Just have a for loop to go through them
Then, each would update independently.
Updating would look like:
1 2 3 4
for(unsignedint n = 0; n < npcs.size(); n++ )
If you're dealing with multiple maps, like I am, I'm writing a command system that each map requires, and it loads a "command file" from each map area, and that loads required "non-map" objects. Basically a bare-bones scripting system.
I am not familiar with the term map in game programming. Are you saying the map is the level...? Then the non map objects would be things that would just make it look better, like rocks and trees... I think Ive heard of what you are saying, but I think it was referred to as a 'level editor'. This was a GUI, instead of a command system as you said. I might just consider a command system because it would take a lot less time than making a whole GUI just to load the level and different objects.