My AnimationManager didn't like being a pointer.

Apprentice
Posts: 6
Joined: 2006.03
Post: #1
Hi. Long term lurker here but today I've been on a personal roll. Really having fun now although it's blatantly obvious that I'm getting into more serious territory. I'll head the life-story off at the pass and just tell you as quickly as I can what I'm doing.

My goal is to move a box around on the screen. That's come and gone, now I'm really trying to get a neat design to the point that I say "ok that's how I'd do it, now let's learn Unity". So far, I have a few components:

Box.cpp - My game object. Has x,y,height,width which is enough information to make a quad even if it's not smart.
Code:
    float width;            // the width of the box
    float height;            // the height of the box
    float posX;            // x coord
    float posY;            // y coord

BoxScene.cpp - A wimpy class until I figure out if what I really want is a scene graph (something I haven't grok'd yet). Right now it describes how the scene changes. Tells my one box to draw itself, will eventually tell all objects to draw itself which means it'd have to know what's in the scene.
Code:
//the scene lays out objects
//for now, this scene is hard-coded
class BoxScene {
    private:
        Box *box;
        AnimationManager animationManager;
        
    public:        
        BoxScene() {
            this->box = new Box(25.0f, 25.0f, 25.0f, 25.0f);
            std::cout << "In BoxScene Constructor.\n";
        };
        
        ~BoxScene() {
            delete this->box;
        };
        
        void doScene();        // manipulate the model, move the box
        void drawScene();    // tell game objects to draw themselves
};

main.cpp - glut skeleton code. Display function tells everyone to draw themselves via BoxScene. glutIdleLoop tells everyone to move via BoxScene. It's pretty long but it doesn't have much logic in it.

AnimationManager - manages "animations". Doesn't know what's inside an animation. Loads, starts animations and keeps track of what's playing in a vector.

Animation - base class for Line,Bounce,FloatUp or whatever. Animation attaches to game object, this might be bad.

Line - An animation that moves in a straight line at a fixed speed. I just make up the values and store them in a vector. Later I'll externalize this to a file (if I can). Lines knows what its path is, inherits the rest from Animation. IE: a Line Animation has points that are in a straight line, an animation is an object that knows how to step through some set of points.


Anyway, a lot of these things need work. Right now, it very simply moves the box across the screen and I have a long ways to go before I'm really pleased. Anyway, when I tried:

Code:
class BoxScene {
    private:
        Box *box;
        AnimationManager animationManager;
...

I got some terrible errors about pushing a vector, a SIGBUS error. Nevermind the actual error. No other code seems to have a problem with *box being a pointer, I'm passing it around by reference and everyone is happy about it. I'm like: "What is going on? Why would they behave differently?"

So I did some looking for an hour and realized my error. My problem is understanding memory. See, above in that BoxScene class, *box is a pointer but animationManager is a straight up object. So I suppose it gets memory assigned to it. Where I was making a horrible mistake is when I assumed both those things have memory. I found I was doing different things for both objects in the scene constructor:

Code:
    public:        
        BoxScene() {
            this->box = new Box(25.0f, 25.0f,25.0f,25.0f);
            // notice there's no "new animationManager()" here

So later on, I'd so something like animationManager.doSomething() and I'd get this unrelated and horrific vector error. The error was kinda misleading, GDB would fire up, etc. Hey, who said this was easy right?

So I changed the animationManager declaration to be a non-pointer variable, and I got it (sort of). When I change animationManager to be a plain variable, then memory is allocated. So then I saw that I also have the option of making them both pointers. I refactored and verified that it works the same. My little box putted across the screen very happily as long as I make sure that pointers have "new" before I try to use them.

Ok, sorry for the horrific post. I guess I have a few questions:
  1. Should I avoid pointers? If not, am I at least coming close to grasping at the implementation differences?
  2. Anyone have a better term for AnimationManager that I could search for sample code?
  3. I searched this forum for similar simple projects, if anyone has represented motion or paths really simply, I'd love to check it out.
  4. Can anyone provide a cool way to represent a path of motion? Right now, I'm creating structs representing 2d points and pushing to a vector. It's kind of lame but I don't have much option in my current state of overwhelm-ocity.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #2
The trick isn't to always use pointers or always avoid them, but to know when to use them and when not to use them. If you have a member variable that's an object, if you only keep one copy of it and never need to move it around much, then it's best to have it not be a pointer. If you need to create and possibly destroy objects on the fly, pointers are very good options. Regardless, if you have a sigbus error, that means that you're not handling the memory correctly, and it doesn't mean that you shouldn't use pointers, but that you should learn how to use them correctly.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #3
Quote:Can anyone provide a cool way to represent a path of motion? Right now, I'm creating structs representing 2d points and pushing to a vector. It's kind of lame but I don't have much option in my current state of overwhelm-ocity.

Its common to describe a motion that you are not fully certain what behaviour it will have in 2 seconds, or 10 minutes later is to describe its current state and a set of rules that it will (approximatly) follow. For the current state, position and velocity are usually sufficient (but acceleration is also stored sometimes).
Then you can use Newton's equations of motion to calculate what the state might be at a particular time after your current state.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2006.03
Post: #4
akb825 Wrote:The trick isn't to always use pointers or always avoid them, but to know when to use them and when not to use them. If you have a member variable that's an object, if you only keep one copy of it and never need to move it around much, then it's best to have it not be a pointer. If you need to create and possibly destroy objects on the fly, pointers are very good options. Regardless, if you have a sigbus error, that means that you're not handling the memory correctly, and it doesn't mean that you shouldn't use pointers, but that you should learn how to use them correctly.

That's certainly good advice. I'm embarrassed in my lack of memory handling confidence. Right now I'm biting off more than I can chew and it's a painful learning process but another year of books and contrived Hello Worlds are meh.

I'll use pointers as they are working for me. I can't predict my design to tell if I'll need to destroy objects on the fly. I suppose I will. As in, when an animation motion has stopped, completed or cut-off in the middle of it. Hmm, now I'm thinking about flexibility, and relative motion vs absolute. Like what if Mario jumped again in mid-air (relative)? What if I wanted that flexability? Hmm.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #5
milkfilk Wrote:Hmm, now I'm thinking about flexibility, and relative motion vs absolute. Like what if Mario jumped again in mid-air (relative)? What if I wanted that flexability? Hmm.

To put what I said in another way, I was describing an often used technique where you combine a single type of motion, an object traveling along a straight line with a constant velocity, with some way to alter that motion (changing the velocity via tried and tested equations).

It saves you having to define linear motion (zero gravity), parabolic motion (gravity in a single direction), oval motion (planetry orbit), various combinations thereof and heck knows what for 3 or more bodies in orbit.
Using things like linear motion and approximatly solving ODEs each frame is much simpler to program and more flexible as well.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #6
Trying to use pointers "as you are" and not learning about them properly before using them can be very dangerous. You run a very major risk of accessing freed memory and creating memory leaks. It won't take a year to learn how to properly manage memory, since there isn't that much to cover, but it will take a little while to get used to how everything works. It may seem a little complicated, but once you do get the hang of it, you can use it to your advantage to make your program as efficient in memory usage (both in amount and speed) as possible. (of course, that isn't necessary for every project, which is why garbage collection can be popular in many situations, but that's another topic)
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #7
akb825 Wrote:Trying to use pointers "as you are" and not learning about them properly before using them can be very dangerous. You run a very major risk of accessing freed memory and creating memory leaks.

This is not dangerous because you dont know how to use them but its dangerous because of the various problems/crashes and security flaws it can cause. It shouldnt be a humans task to repeatedly write the same patterns of code (eg malloc/free or ref-counting) when it can be automated (which, if done correctly, stops any possibility of memory leaks or accessing a null pointer which you free'd accidentally).

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  memory pointer tricks? Toontingy 2 4,003 Mar 31, 2009 02:35 AM
Last Post: Ingemar
  pointer cleanup questions kendric 7 4,252 Mar 29, 2009 07:48 PM
Last Post: kendric
  pointer or not? kensuguro 17 7,565 Aug 15, 2007 04:12 PM
Last Post: AnotherJake
  Pointer-related woes (C/C++) sealfin 2 2,514 Jan 18, 2006 01:22 PM
Last Post: sealfin
  Hide Mouse Pointer JonTrainer 9 6,954 Nov 10, 2005 10:46 AM
Last Post: Jordan