The idea here is this routine goes from your current angle-5 to current angle +5, in increments of 1. The result is an 11-entry stack, with either $FF for nothing found, or the type ID and distance of the object found. The renderer will then parse that stack to update the screen.

Feel free to correct/optimize, but let me know what, if anything, I did wrong so I learn. Thanks!


Code:

bump

bump again.

At least one glitch i've spotted already, but not sure how to resolve.

in getTempVectors, each time the trig routine returns hl, an 8.8 Fixed Point, I save 'l', the .8 part, into iterVector. So iterVector is .8 for the X and .8 for the Y. Yet, the player position we use is the integer parts. Right after rc_loop_ray, I have hl, which is player position, and bc, which is (iterVector) and I add hl and bc. This is wrong. I may have to do two additions, one for X and one for Y, but I was hoping to avoid that.

Are you worried about under- and over-flowing in the individual parts? If so, you definitely can't do it as a single addition. I see plenty of things that could be optimized in the code in the first post, but before optimization, you should worry about functionality. Does this code work? I'm a firm believer in incremental development: you should never, ever write big chunks of untested code. Instead, you should write one small core piece, test it and make sure it works, add another piece, test, and so on. Is it safe to say you haven't run this code yet?

It compiles and runs without crashing. However, without a set of graphics to render, I can't actually see if its working as it should, or looping, or somehow getting stuck.

Ah, that makes sense. Well, it sounds like you have a very clear next step in your project, then.

You can tell if it's looping/getting stuck easily enough just by checking if the routine finishes. However i agree with Kerm that you should work on your program in pieces. If you have no way to test if the output is correct, perhaps you should work on something else. Otherwise you'll just have more trouble debugging it later as you aren't as familiar with the code anymore. Write some of the graphic routines so that you can actually check if the code works.

You can also enter default values and check to see if the results from the routine are correct. For example, check if the bytes at (rcStack) (ie smallEditBufer) = $FF. Then add some objects in and check if they are detected.

But if you really have no way of testing if a routine works, in my opinion it's much too early to be writing that routine. I can't remember the last time a piece of code i wrote worked the first time. Actually, that's not exactly true, a couple days ago working with add a piece of code worked perfectly on the first assemble, but that's definitely the exception, not the rule. Writing blind assembly is just asking for trouble later.

Ok, I made some changes and revisions work, however I'm having an issue where the same "object" is returned twice because two adjacent rays happen over the same box. Would an adequate way to resolve this be to simply strike out duplicates from the stack?