Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Join Date
    Sep 2006
    Location
    Englandshire
    Posts
    249

    evilMonkeys crashes, but compiled ok

    Hi,

    I'm attempting to go through the evilMonkeys vtms, and I've just done the code that implements drawing the level.

    I'm using visual studio .net 2005.
    It compiles ok, but when I run it it crashes.

    I get a Debug Error! messagebox popup with abort/retry/ignore if I click abort the console output is "Press any key to continue"; same for retry.

    Ignore gives me...
    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    Press any key to continue . . .

    Or if I try to run it in debug mode I get
    "Unhandled exception at 0x7c812aeb in evilMonkeys.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012fbac.."

    The last VTM I followed, or am part-way through is C++_i3_07_Level.avi (on the CD).

    I've been through it from the start up to the point where they run the game to test it's drawing the level several times and I really can't see what I've done wrong.
    I'm not sure where to put a breakpoint in to see if i can see why it's crashing, because i'm rubbish at programming.

    Did anyone else run into this problem around this point, or have any idea what's causing it?

    Thanks, and sorry i'm rubbish.

  2. #2
    Join Date
    Sep 2006
    Location
    Englandshire
    Posts
    249
    Oh ffs I'm a complete moron. Right this second I just saw:

    Level::Level(DrawEngine *de, int w, int h)
    {
    drawArea = de;

    width = w;
    width = h;

    etc. etc.


    Ok, for future reference, how best is it to go about making sure everything gets initialised/set correctly?
    Maybe I was just staring at it for too long with manflu/bad cold.

    Thanks for reading, anyway

  3. #3
    Join Date
    Sep 2008
    Posts
    21
    One practice that I like to follow while doing the training videos, is to continually pause or rewind to check my code before continuing on. Some parts of the videos go by very fast, with Joel typing and flipping between different files, deleting and changing things. A lot of times I find myself struggling to keep up, let alone check my code and understand exactly what I'm doing. That's when the pause button comes in really handy

    If you run into an issue like this where it will compiles but crashes, run it in debug mode (F5 on MS C++ 2008) then when you get to the part where the game crashes, (don't close the game yet, and hit the break button if a window pops up) go back to your compiler and look in your Call Stack window. It'll have an arrow pointing at the area which caused the crash. It might not point to the code that's causing the error, it could point to code that is using the faulty code. That's when you look at that code and try to figure out what all is being called, then go backwards from there to figure out where you messed up.

  4. #4
    Join Date
    Nov 2006
    Location
    UK
    Posts
    3,774
    Best answer is when somethings stuffing up - you need to debug
    As teromous says, when it crashes if you run it in debug mode, you'll see a stack, working backwards through the stack you should start seeing either values you didnt expect, or its null, or such and then its easier to find the place you messed up - such as width=h .. you arent the first, and wont be the last to do stuff like that

    its worse with x/y especially if you dont use x/y for your loop variables and you're doing something like painting the map, its easy to end up with them round the wrong way
    Delphi !ROCKS!
    Got a question? Read this first!!!
    "You gotta help us, Doc. We've tried nothin' and we're all out of ideas"

  5. #5
    Join Date
    Sep 2006
    Location
    Englandshire
    Posts
    249

    Talking

    Ah the call stack. That always confused me, but now I think I know how it works (a bit)
    At least now if I put the mistake back in and run it I know what you mean....

    Before, if I'd hit the break button vs .net would open (or seem to be opening) onexit.c, and point at this line:

    __onexitend = (_PVFV *)_encode_pointer(onexitend);

    That means nothing to me - so I got confused. I'm still not entirely sure why it does this, maybe someone can explain?

    Anyway, now if I look in my call stack it looks like the last ish thing was (forgive the formatting):
    > evilMonkeys.exe!Level::Level(DrawEngine * de=0x0012ff28, int w=30, int h=20) Line 18 + 0xc bytes C++

    Line 17/18 of level.cpp:
    Code:
    for (int x = 0; x < width; x++)
    		level[x] = new char[height];
    Then if I expand "this" under the locals tab... I can see that
    width = 20
    height = -842150451 (garbage)

    It's all (almost) so clear now! Thank you very much the pair of you, have some lovely rep

    Oh, and I've been pausing/rewinding the video loads, i guess I just missed this continually :\

  6. #6
    Join Date
    Nov 2006
    Location
    UK
    Posts
    3,774
    problem is with 1 letter characters you type it and if you arent then changing it you dont tend to reread it.. so it can stay there for a long long time.

    if you had an app that went something like

    Code:
    main()
    {
      callfunc1();
      callfunc2();
    }
    
    void callfunc1{}
    {
      callfunc2();
    }
    
    void callfunc2()
    {
     barfhere();
    }
    when you ran it you would see a stack of something like

    callfunc2 ..
    callfunc1 ..
    main ..

    because its the reverse order of what was called so you can trace back where the calls came from to find if you switch some parameters around, or, sent it stuff you didnt initialize etc.
    Delphi !ROCKS!
    Got a question? Read this first!!!
    "You gotta help us, Doc. We've tried nothin' and we're all out of ideas"

  7. #7
    Join Date
    Oct 2005
    Location
    Seattle, WA
    Posts
    501
    When I was learning about the call stack it helped me to think of it as a scratch pad for the cpu. It allows the cpu to keep track of where it is at in the functions that are lower in the stack. When a function gets called a stack frame is created and placed on top of the stack, hence whatever is at the top is what the cpu is currently working on.

    The stack frame contains data the functions needs to do its work, things like the values of the functions parameters, the local variables, etc. If a function is called from inside another, then a new stack frame is created and placed on top of everything else. When a function returns, any return value is passed on to the calling function and its stack frame is removed. The cpu then resumes work on the next top item.

    This is where the scratch pad idea comes in. The stack frames can hold all the info about the function the cpu needs to be able to jump to a new function or 10 new functions, then jump back to the original and resume right were it left off without losing its place. And as soon as the function is completed it all goes away.

  8. #8
    Join Date
    Sep 2006
    Location
    Englandshire
    Posts
    249
    Re: The thread of information...

    Should I be making all changes listed in there to each of the classes/files mentioned?

  9. #9
    Join Date
    Nov 2006
    Location
    UK
    Posts
    3,774
    Probably - assuming you got to the relevant point in the tutorial.
    Delphi !ROCKS!
    Got a question? Read this first!!!
    "You gotta help us, Doc. We've tried nothin' and we're all out of ideas"

  10. #10
    Join Date
    Sep 2006
    Location
    Englandshire
    Posts
    249
    Well I made it through to the end of the mage/fireball VTM and ran into a problem...
    The program crashes whenever the fireball hits a wall tile - so I've made the changes listed in the thread of information - but Now I can't get it to compile, probably because I'm dense.

    I have 2 errors.
    Error 1 error C2839: invalid return type 'Sprite **' for overloaded 'operator ->' c:\documents and settings\wilkj\my documents\visual studio 2005\projects\evilmonkeys\evilmonkeys\fireball.cpp 22


    Error 2 error C2039: 'classID' : is not a member of 'std::list<_Ty>::_Iterator<_Secure_validation>' c:\documents and settings\wilkj\my documents\visual studio 2005\projects\evilmonkeys\evilmonkeys\fireball.cpp 22


    I'm sure I should know what's causing this, but I just don't

    I'll paste in some of my fireball.cpp.

    Code:
    void Fireball::idleUpdate(void)
    {
    	if ((isValidLevelMove((int)pos.x, (int)pos.y)) && ((facingDirection.x + facingDirection.y) != 0))
    	{
    		if (Sprite::move(facingDirection.x, facingDirection.y))
    		{
    			list <Sprite *>::iterator Iter;
    
    			for (Iter = level->npc.begin(); Iter != level->npc.end(); Iter++)
    			{
    				if ((*Iter->classID != classID &&  // this is line 22
    					(int)(*Iter)->getX() == (int)pos.x && (int)(*Iter)->getY() == (int)pos.y))
    				{
    					(*Iter)->addLives(-1);
    					addLives(-1);
    				}
    			}
    		}
    		else 
    			addLives(-1);
    	}
    }

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •