[A83] Re: I'm trying collision based on pixel states, using ionGetPixel
[Prev][Next][Index][Thread]
[A83] Re: I'm trying collision based on pixel states, using ionGetPixel
Yea, I guess your right, but I'm so fed up with myself never coding anything
correctly, so I wanted a little help on this stupid thing.
> So you expect _us_ to debug _your_ code for you? I'm not sure what that
> would make you, but it certainly wouldn't be a programmer. Debugging is a
> cruicial and integral part of programming. Remember, anyone can write
> code.
> But it takes a real programmer to debug code. Most of the time spent
> programming is spent debugging code, not writing it. Although if more time
> was spent up front designing it, less time would be needed to debug it.
>
> There are two kinds of questions that you can ask: general and specific. A
> specific question means that you probably understand the problem domain,
> but
> need some specific information about an aspect of it. A general question
> means you don't understand the problem domain. In such a case, you should
> be asking where to find more information, and not the actual question.
>
> Yes, there are times when it is warranted for someone else to look at your
> code. Quite often, someone else can easily spot what you have missed. But
> if you want to be a programmer, you need to learn how to debug your own
> code. If you can't debug your own code, then you certainly can't read and
> debug other people's code, which is an essential skill if you want
> programming to be anything other than a hobby.
>
> The first step to debugging your code is to read through it. If you can't
> easily see all the code at once, then you need to break it into parts.
> Writing the shortest and simplest possible code is helpful to being able to
> easily debug it. If you can break things into smaller routines, and assure
> that they work, then you will have an easier time.
>
> Read through it in your head, and visualize what is going on. Follow the
> data path and code path in your head. See what the code is really doing,
> and what you think it should be doing. You will often spot your mistake.
>
> It's difficult to use the "printf" method in assembly on the calculator.
> Many times, an easy debugging technique is to place a bunch of print calls
> in the code, and print what the code is doing, what a data value is, etc.
> This is difficult to do on the calculator, for a variety of reasons. But
> you have something even better.
>
> Load the code up into a debugger. You are lucky to have VTI, which
> contains
> an excellent debugger. Open the debugger, and place a breakpoint at the
> address where program exection begins. This would be the address used for
> the .org at the start of the program. Use the step command, and watch what
> the program is doing. Use the step over command to step over calls to the
> pixel routine, the sprite routine, etc., and just watch the code that you
> are interested in. You can see what your code is really doing, what the
> registers contain, and what your variables contain.
Follow-Ups: