[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
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.
> Well, I wrote a demo for myself that uses ionGetPixel for collision. If
you
> press left, it checks the pixel 1 to the left of the x coordinate, and if
it
> is on, then don't move. If you press right, it checks the pixel 8 to the
> right of the x coordinate, and if it's on, then don't move. Same method
for
> the up and down keypresses, except using the y coordinate. Since this is
me
> writing this, it doesn't work. I know the entire prog can be optimized
right
> now, don't tell me what is faster and smaller, I just need an explanation
of
> what's wrong with it, and what the code should be for it to work.
Follow-Ups:
References: