Mail Archives: djgpp/1997/08/11/23:32:35
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!
- Raw text -