Axe Raycaster

[squidgetx]

*ahem* introducing a little side project I've been working on: a raycasting engine in Axe
Runs faster on 15Mhz models (maybe a little too fast) and a bit slower on 6mhz models (almost too slow  )
It's very basic right now, and supports single color walls (no textures or sprites), but it does have collision testing and all the basic features of a raycasting engine (rotation, moving, etc.) and can be used to make a (sort of) enterntaining maze game It only uses the first 80 columns of the screen (for speed, and because I'm too lazy to change it. Also I'm sure this area could be used when making a real game for a user display or something)



use left/right to turn, up/down to go forward/backwards respectively. You can press Mode to view the map, and 2nd to quit the map. Press clear to exit the game.

Maps are currently 96x64, and the program will take the picture from OS Pic3 to be the map.

Source is in....RAYSRC, executable is in RAY (nostub) A sample map is included

Currently sits at under 1000 bytes

Things I might add sometime are textures (or at least another color of wall), scaled sprites (not too sure how that will work), and fixing any bugs you guys find. The only bug I've found so far is that everything looks kind of distorted if you get too close to it

[Happybobjr]

cool good job.

downloading to wabbit at my school.

[SirCmpwn]

Very nice!

[Yeong]

starts with nspire raycaster, and now the axe one...
*Yeong assumes that there will be FPS games for Axe later

[aeTIos]

starts with nspire raycaster, and now the axe one...
*Yeong assumes that there will be FPS games for Axe later

Of course they will be here!

[Yeong]

CoD games....? O_o

[squidgetx]

Actually worked on this quite a bit today: I've added shading according to distance and lengthened your line of sight. I've also located the bug that may cause some of the distortion but I haven't managed to fix it yet

[Runer112]

A while ago I was toying with the idea of a raycaster in Axe, but I couldn't get the math right. Looking at your source code now, it makes so much sense.

I figured the least I could do to help was to give it a bit more kick I could hardly avoid from crashing into walls it was so fast.

[squidgetx]

holy...... how did you do that?

[ztrumpet]

That looks awesome!  Nice job squidgetx!

Edit: Wow, Runer, that's quick!

[Munchor]

Hum... Axe Doom?

Very good job! Now, i have a doubt, is the map repeating a few times?

[Runer112]

Well that's at 15MHz, so it runs really fast. But I did some rough testing and my modification makes it run about twice as fast at either 6MHz or 15MHz.

I figured that the slowest part of the engine was probably drawing the lines, so I decided to work on that. I did cheat a bit, though, because the speed boost was from a hand-written assembly routine. It took me a few hours, but I managed to make a special case vertical line drawing routine. For drawing vertical lines, it's on average probably 5-10x faster than the normal line drawing routine. I might submit it to Quigibo so he can add it as a built-in feature, although I don't know if it has enough circumstances in which it would be useful to warrant its addition into the standard command set. But then using it wouldn't be cheating any more.

Anyways, I don't think Axioms are working right now so I had to sort of hack together a method to use it as a fake Axiom.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12

.X coordinate Z-{L1}+40Asm(E5) 32/E→H .Y1 coordinate 32-HAsm(E5) .Y2 coordinate H+32sub(VL) ... Later in the code, as a subroutine: Lbl VL Asm(D1C1EBE3C501A0FF093856E3AFCB7C2803676F3CCB7A2805B72046575FAF0EC00930033D676FEB093005B72034626A7B953003ED44EB3C012C8F545D29192929095FC13E0747A157A90F0F0F4F094204AF3F1F10FD4F43110C0079B6771910FAC9E1) Return

EDIT: I just realized that you could draw rectangles of width 1, too. It's slower than this routine, but it's built-in, simpler to use, and still a good deal faster at drawing vertical lines than the line routine.

[meishe91]

Wow, that is really neat Great job on it Keep up the good work. Can't wait to see what this leads too.

[squidgetx]

And I was thinking....If only there was a super-optimized vertical line command

Now if I am understanding your code correctly, Runer, I put Asm(E5) after the X coordinate, put the height into H, put Asm(E5) after the first Y coordinate, then the massive Asm() block in VL after the 2nd Y coordinate, right? Thanks....I'll be sure to credit you if this ever goes anywhere.

Next, scaled sprites.....

Oh and if anyone could help me with this bug/flaw in the algorithm:

You may notice that the height of the lines drawn on the screen are based on E, or R in the updated version, which is the length of the terminated ray. However, this is inaccurate: it should be based on the straight distance of the triangle instead:

______
|    /
|   /
|Z /
| /
|/
player
So you'd think that I'd then multiply the E (or R) value by cos(Z)/128, but it doesn't seem to be working...is there anything wrong with my trig?

Oh and @Scout David, the map isn't repeating the beginning just has two parts that are the same

[Runer112]

I noticed that bug/flaw too and tried to correct it, but it didn't work right for me.

I noticed another part of your code that could be improved upon, though. And this may actually be the cause of the above fix still not looking right. (Possibly not, though.) When you advance the ray, it doesn't always return a very accurate distance to the wall it collided with because of the relatively large, constant step system you use to advance the ray. You could reduce the step size, but then calculations would be much slower.

The method most commonly accepted as the quickest and most accurace raytracing method is to track where the ray hits cell boundaries. I'm not really sure how to explain it accurately without confusing both you and myself, so I made a picture instead.

The ideal method of tracing infinitely small steps is on the left. Your method of following a constant step size is in the middle. As you can see, the two illustrated rays will return the same length, although they clearly are not the same length. And the method that seems to be generally accepted as the best raytracing method is on the right. I've always had trouble wrapping my head around how to correctly implement that, but if you succeed, it should work quite well and speedily.