[RESOLVED] Snake

Code:

---

        static BOOL                        bKeyPressed;
        static HBITMAP                hBitmap;

---

are the two variables I want in my code.
If I compile it with them I have a problem.
If I compile without them I dont have a problem
Both these variables are put along with all other variables at the top of the WndProc Code

Quote:

---

Originally Posted by Igor Vartanov

Besides, this prototype looks really dangerous:

Code:

---

void MoveSnake(POINT pt[500][2],int iDirect,int iLength)

---

In case you cross the array bounds somehow, you spoil the stack with unpredictable behavior.

---

So what should the correct prototype be?

remove the array size... just put.. POINT pt[][].. so that it takes enough memory by itself..

Code:

---

static BOOL                        bKeyPressed;
        static HBITMAP                hBitmap;

---

Make sure are these system defined variables or user defined.. if not . rename them to some other name... to avoid the clash..

Quote:

---

Originally Posted by vinayak4gargya

Breakpoint at switch (msg) of WndProc
Step Into;
Takes me to WM_PAINT:
Step Into : hdc = BeginPaint(hwnd,&ps);
Step Into again : I am returned back to switch(msg) (??) (The rest of the code of WM_PAINT is not executed)(??)

---

You must be careful when debugging WM_PAINT messages.

You cannot debug them if you have the debugger popup over your window. The reason is obvious -- each time the debugger is closed, your app window has to be repainted, causing another WM_PAINT message to be generated and the breakpoint is hit again. Then you continue the program, causing the app window to be exposed, meaning another WM_PAINT message is generated, which hits the breakpoint, then etc. etc. etc. You are basically in a "debugging" infinite loop of breakpoint, WM_PAINT, show app window, breakpoint, WM_PAINT, show app window, ...

The way you debug WM_PAINT messages is either

1) Make sure your Visual Studio debugger window does not intersect anyway with your main app window. This means that you have to resize your app and/or Visual Studio IDE window so that they do not overlap each other.

OR

2) You have a dual monitor setup, where your app is on one monitor, and your Visual Studio IDE is on the other monitor.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by vinayak4gargya

So what should the correct prototype be?

---

This is much more flexible:

Code:

---

typedef double SnakeBoard[500][10];

void MoveSnake(SnakeBoard& myGameBoard,int iDirect,int iLength);

int main()
{
  SnakeBoard sb;
  MoveSnake(sb, 1, 1);
}

---

If you decide to use a different type, different dimensions, etc. all you need to do is change the typedef.

Regards,

Paul McKenzie

This is just a guess but is it possible that MoveSnake() is somehow getting called recursively? Since you pass the address of an array I can imagine all kinds of problems if something is trying to modify the array whilst a previous call is still in the midst of modifying it.

I'd check for something like that before you start blaming the static variables. I can pretty much assure you that if your app breaks after you add those statics, it's just a coincidence.

In any case (forgive me if you already explained this) but is the problem seen after the mere fact of adding the static variables? Or does it only happen after your program modifies them?

Done it!!!!!
There was definitely something overwriting the snake head!
Of course the weird scoreline!
See I print the scoreline --"Your Score __"
Well I had declared this to be a static char[10]...THAT was the problem.So everytime I wsprintf to update the score, it overwrote the snakes head.Now ive made it static char[15]
How Silly!! How so very silly!

Thanks a lot guyz I wouldnt have come back at this program without your help!

As is now obvious, you'd introduced an error that was completely outside of the code samples you posted. I hope you understand now why you should never provide incomplete code fragments that only tell part of the story. For problems like this one you should always provide a minimal (but buildable) sample program that actually exhibits the problem.