Okay, can someone please look at the following code and tell me why the statements int theSequence[4] = {0,1,2,3}; theAnimMaster.SetTotalAnims(1); theAnimMaster.SetFrameCount(1,4); theAnimMaster.SetSequence(1, theSequence); wouldn't work (assuming the rest of the object was correct) ?? "SetFrameCount" appears to be the killer... This is crashing my app and I don't know why. Being a beginner programmer I have, of course, little in the way of knowlede eregarding debugging or anything; so any tips there would help, too... Code follows... Thanks! --HB

void AnimMaster::SetTotalAnims(int numAnims)
{

	this->totalAnims = numAnims;			//Set the total anim seq value.
	this->frameCounts = new int [(this->totalAnims+1)];	//Init the frame-counts array.
	this->sequences = new int *[(this->totalAnims+1)];	//Set the first dimension of
						//sequences (two dimensional)
							//to be equal the number of animations
							// + 1.  This is to avoid a ton of 
							// "-1" code later.  Sequence[0] will
							//not be used.

	ZeroMemory(&this->frameCounts, (sizeof(this->frameCounts[0]) * (this->totalAnims+1)));
					//Wipe the frame counts array.
	return;
}



void AnimMaster::SetFrameCount(int seqNumber, int numFrames)
{
	this->frameCounts[seqNumber] = numFrames;		//Set the number of frames in this seq.

	return;
}



void AnimMaster::SetSequence(int seqNumber, int *frameSeq)
{

	this->sequences[seqNumber] = new int [this->frameCounts[seqNumber]];
							//Allocates the 2nd dimension for this
							//sequence.

	for (int index = 0; index < this->frameCounts[seqNumber];index++)
	{

		//Set each element for the seq.
		//REMEMBER THAT "BitInOb.images" (AND HENCE THIS OBJECT) IS 0-BASED!
		this->sequences[seqNumber][index] = frameSeq[index];


	}

	return;
}

   

Edited by - HBringer on 11/14/00 1:06:49 AM

One point is you don''t need all the this-> that you used. You normally only use it when there are parameters or local variables by the same name or you need to pass a pointer to yourself to another function. Second look at the faq for this board and see how to include source. These two items make is a little easier to read the code. I''m rather impressed by this considering you call yourself a beginning programmer.

If you are running a debug version of the program under the development tool you are using then when it crashes the debugger should take control. You will either be on the line that caused the exception or in a function called by the line that caused it. Within this example that would be the news. If you are not in your source then the call stack will show you when you were last in your code. You will need to refer to the help for whatever you are using to determine how to build a debug version or verify that you already are. You should also check how to set breakpoints. Sometimes with memory errors the debugger doesn''t recover well so you set a break point at the start of the section you are interested in. You then either step over or trace into each statement. Trace/step into goes into an functional calls on the line while step over does not. Right clicking on a variable name while debugging should give you a menu that has some options like inspect, watch and evaluate. These allow you to view values of variables and change them. So you first find the line that causes you to crash and then you look at the variables that line uses to determine why it is wrong.

All that said try taking the & off the this->frameCounts in the ZeroMemory call. It is already a pointer. You are zeroing the pointer, whatever data members follow it and who know what else.

Well, doing so rectifies the crash; but now on application exit I get a Debug error!

The error is:

"Debug Assertion Failed. dbgdel.cpp line 47"

"_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)"


*sigh* I''m going to have to find a resource for learning about the debugger in MS Visual C++ 6....

Any ideas on this error? Running a Help search on this stuff al talks about MFC stuff or manually telling the debugger to do something... Nothing to clue me in on why this may be happening.

Also, anyone have any ideas or tips on debugging a fullscreen DirectDraw app? If I use breakpoints I can''t ALT-TAB over to the debugger! :-P

Thanks!

--HB

P.S. LilBudyWizer - I''ll take that as a compliment! I saw a collection of basic DirectDraw sprite / drawing functions in a book, and decided that they were incomplete and not O.O. at all. So I felt it''d be a good way to learn the nuts and bolts, if I were to create a collection of classes that formed a rudimentary 2d sprite engine... Ended up re-writing them from scratch. Looks like I may have gone for too much, though :-P BTW, the "this->" prefixes are just in there to guarantee readability and clarity down the road. They shouldn''t affect anything, right?

The assert is triggered, because you have written over array boundaries IIRC. I think the debug library adds guard bytes after each allocation and checks those on app exit; if they were changed, you have written too far and it tells you.

As for debugging a DX app.. go through the trouble and add an option for windowed mode (shouldn''t be that hard with dx8 anymore). It''s the only viable solution on a single monitor system. Another possibilty would be remote debugging using a second computer.
You could check out NuMega SoftICE, if you feel hardcore.. it works in fullscreen mode too. I think it''s used mainly for driver development.

hope that helped!

.entrox

The this-> is a matter of style I suppose so it is whatever you prefer. I doubt it has any impact on the code generated. I don''t see any other errors though there is a bit of code I question. I normally don''t use array subscripts with pointers. Until you learn the debugger you will have to do it the old fashioned way. That is either writing to a log file or commenting out code. Start by commenting out the function calls starting at the bottom and working your way up. Comment out the SetSequence and run it. If the problem goes away then it is in that function. Once you have it down to a function then comment out lines of code. Considering the problem the statement in the for loop in SetSequence and the ZeroMemory call would be where I would look closest. Once you identify the statement you can print data values out to a file to see why it is causing a problem.

Once you learn the debugger you just tell it to log to an event log at the break points instead of stopping. There a number of options at a breakpoint and one of them is whether you actually stop. The help file should give fairly good guidance to the debug options. You might want to play with it with something other than a DirectX application. Personally I write all my classes in a program dedicated to testing that function before moving it into the main code. It makes it much easier to setup test conditions. When I''m testing the actual drawing I use the logging options on the debugger.

I am a beginer also,(though not as good as HBringer!) but I also would like to learn about debuging programs. Right now, I do the comment out and I also use message boxes. Very hard and very slow. Is there any place that can teach you how to use the debuger? Do they teach this in most computer courses? Also, I have read about people useing profilers(VTune and such) and would like to learn about those? I haven''t really seen much on any development site for this infomation and my searchs come up with sites that have nothing to do with programming. Maybe I''m using the wrong keywords or somthing. Anyone have any pointers or even keywords to try?

"I kinda think, therefore, I kinda... am?"

Starting point: Debugging Your Program. vTune is not a debugger, it is a performance profiler. When you get to a point where something is running too slow and you don''t know why go to vTune and download it. It will tell you where you are spending most of your time. It is rather expensive and you will get the best feel for if it is worth it to you when you have an actual problem. The demo is only good for 30 days, so while I would recommend reading through the web site, I would urge you to wait until you actually have a practical application of it before evaluating the actual software.