Newsgroups: comp.os.msdos.djgpp Date: Mon, 11 Aug 1997 12:42:08 -0400 From: Insomnia Subject: Re: Optimization and bug smashing.. a lot of other questions too :) In-Reply-To: <33ee3f7f.4973504@news.inlink.com> Message-ID: References: <33ee3f7f DOT 4973504 AT news DOT inlink DOT com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII NNTP-Posting-Host: degobah.core.binghamton.edu Organization: Binghamton University Lines: 68 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Mon, 11 Aug 1997, [vecna] wrote: NOTE: My replies are mainly based on my DJGPP/gcc/C/C++ experience, and this message has not been crossposted to r.g.p. > vgadump() > copytile(int x, int y, char *spr) > tcopysprite(int x, int y, int width, int height, char *spr) > These all look pretty good to me (I didn't whip out the microscope tho).... One suggestion, since these are all asm anyway, just make them asm functions in a separate .s file and compile them separately, and then link them. This will allow you to save regs on your own, and eliminate any unnecessary overhead of the __asm__ call. Best way to do this IMHO is to put all of these functions in a separate .c (or .cpp) file than "gcc -S -Whatever" it, giving you a .s file. You could then remove any extra asm and just compile in the .s file (as you already seem comfortable programming in AT&T asm). > and debugging is virtually impossible. One thing that's come to mind: > I have no formal C training. I compile my code with -w .. without it, > a pretty decent amount of warnings are generated. Could this be a > source of the seeming unstable code generated? The thing is, most of > these warnings are stupid things like: > > char *ptr; > ptr=malloc(65000); > > instead of ptr = (char *) malloc(65000); This seems to make no > functional difference.. I'm just wondering if a buildup of these > warnings could give me unstable code (BTW, I only recently learned of > how to fix that particular warning.. there are a lot of other warnings > that I'm not even sure how to fix.. all of them seem to be stupid if > you ask me, but then, I'm an Assembly diehard :). > You should IMHO always compile w/ -Wall. Warnings do not stop the compilation process, and can alert you to problems that would take hours to debug otherwise. Compile all with -Wall, and pipe the warnings to a file and spend the time to fix all of them (by fixing a warning, you know in each case you do in fact mean to do what it is warning you is happening). You may find something that you missed (best example of a bug that is tough to find, but can be detected with -Wall is a signed/unsigned bug, these can take days to track down w/o -Wall, but show up as a warning w/ it). Also, in my experience there are a few general rules in C/C++ debugging: If a bug occurs at random times during random situations, look for pointer errors. If a bug occurs consistantly during some specific conditions of a piece of code, yet this code works otherwise, look for a math, or boundry error (signed/unsigned, overflow, mod by wrong value, exceeding allocated buffer...). If a bug occurs every time a piece of code executes, yer code's broke (duh...). And, earlier in your mes, you mentioned something about your game crashing when you got near the edge of your map (I think I deleted this part of your mes (oops)). I've hit this before, odds are you are looking at a greater area of your map than you want to be (i.e. you aren't just looking at what is drawn on the screen, but are looking farther down, and to the right than the edge). When you get to the edge of the map, this will cause you to look off the edge of the map (out of bounds of your buffer), and this will cause a page fault. Check the bounds of the routine where you look at the map buffer.... Hope this helps. As usual, any comments welcome.... --Insomnia --Sleep is for the weak!