Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
I was told it couldn't be done. albeit by the non-programmer types
That got me agitated, so I did it.

I made the first (to my knowledge) completely pure TI-Basic raycaster.

For those who don't know what raycasting is, it is a method of drawing a 3D environment from a 2D map. It is also my area of expertise

Just input any 10x10 matrix in to [A], then it will render the first screen.
For example, I loaded the matrix displayed as a demo on the CC19 thread into [A], and got this:


There are a few things to notice:

The minimap, on the bottom right. Believe it or not, this is essential to the program, as it does all of its detection and ray projection on it. I also spent more time making the bevel look right then anything else. (This is an old version, and I forgot to put a marker for where the player is.)

The shading, which represents distance. I chose this color shading, as it was easier on the eyes. In theory, you could easily edit the program to do any color of shading you want.

The glitch, slightly left of center. This is a WIP, but I doubt I will be able to fix that. (as it is due to the way I am calculating my rays' paths/intersections, and there is no other efficient way.)

This program is not complete and I have a bit left to implement. Here we go:

1) Optimization. Currently, the 'game' is unplayable, as it takes it like 2 min to render a screen. Most of this is due to the programming language, but some of it can probably be sped up.
2) Key recognition. Not only is the 'game' too slow to be played, it does not recognize any keypresses. This is due to the fact that I wanted to post this early so you guys could all see it. Compared to the main bits, this should be really easy. (but still take awhile, arbitrary rotation measurements are not fun to work with. For example, looking forward (right on minimap) is 310 degrees. Don't ask me why.) Complete! (wow that was quick!)
3) Prettifying the code. Perhaps.
4) You tell me. I don't really know where to go with this...

I have submitted my program to the archives (for approval), if you want to play around with it.

litrosaist had a speed modification. x2
womp shows me I cannot type. x2
_iPhoenix_ (yay that's me) fixes stuff everything (i.e. movement, rotation).
_iPhoenix_ did some speed modification. x3

Code is currently ~628 bytes, which is really cool!

Code here:

Code:
Degree
0→Xmin
{BLACK,DARKGRAY,GRAY,MEDGRAY,LTGRAY,WHITE,WHITE→L₁
70→Xmax
-20→Ymin
20→Ymax
90→θ
310→R
119→S
219→T
For(A,1,51,-1
For(B,1,100,50
Pxl-On(163-A,263-B,GRAY
Pxl-On(163-B,263-A,GRAY
Pxl-On(164-A,264-B,GRAY
Pxl-On(110+A,210+B,MEDGRAY
Pxl-On(110+B,210+A,MEDGRAY
Pxl-On(109+B,209+A,MEDGRAY
Pxl-On(109+A,209+B,MEDGRAY
End
End

For(A,1,10
For(B,1,10
If [A](A,B
Then
For(C,1,5
For(D,1,5
Pxl-On(110+(5A-4+C),210+(5B-4+D),BLACK
End
End
End
End
End
Repeat Ans
For(A,6,13.5,.45
Line(Xmin,A,Xmax,A,WHITE
End

DelVar N
Pxl-Off(S,T
For(A,70-R,1-R,-1
N+1→N
DelVar C
cos(A→P
sin(A→Q
Repeat K=45 or C>20
C+1→C
pxl-Test(int(S+CP),int(T+CQ
End
If C<20:Then
int(C/3→V
int(40/C)/2→W
If W>4
4→W
For(B,-W,W
For(D,1,2
Pt-On(N,B,D,L₁(V
End
End
End
End
Pxl-On(S,T
Repeat Ans
getKey
End
Pxl-Off(S,T
Ans→K
If K=24
R-45→R
If K=26
R+45→R
R-220→θ
If K=25
Then
int(S-3cos(θ→S
int(T+3sin(θ→T
Else
If K=34
Then
int(S+3cos(θ→S
int(T-3sin(θ→T
End
End
Pxl-On(S,T
Pause
End
The reason nobody has made something like this before is because pure basic is far too slow for this kind of thing. There have been very nice things made in asm though such as JamesV's Zargul thing, (even though it was never completed):



I think this might actually be the first time I've seen someone attempt this in pure basic. Instead of putting an incomplete program in the archives so that people can look at it, you should post the code. This thread would then become more of a discussion thread where people comment and change up your code (if that's something you're cool with). Also, I'm quite curious to see what the code looks like Smile
mr womp womp wrote:

Instead of putting an incomplete program in the archives so that people can look at it, you should post the code. This thread would then become more of a discussion thread where people comment and change up your code (if that's something you're cool with). Also, I'm quite curious to see what the code looks like Smile


Ditto on mr womp womp's comment
Yeah. Code posted, but with some errors. If anyone fixes them, I will add their fix, citing the fix in the original code.
I think this is a good conceptual thing, for asm is kinda difficult to translate into human thought. In my opinion, that is basically [har har] what basic programs are useful for after learning asm.
prgmTrouble wrote:
I think this is a good conceptual thing, for asm is kinda difficult to translate into human thought. In my opinion, that is basically [har har] what basic programs are useful for after learning asm.


Yeah. I have not learned ASM, (well, I did, but it was like 5 years ago, and rip longterm memory, it must have RAM cleared...) so I cannot compare in that sense, but I have noticed myself writing TI-Basic code for my Java projects. The funny thing is, I actually did the opposite for this, since I have (or had, at least) a fair amount of experience in that field.
I am very impressed to be completely honest! I see you seem to enjoy taking on these "pure TI-BASIC" challenges... Try making all these things in ICE! you'd be a hit in no time.
Okay, So I think the clear problem with this is the speed. We are now looking at seconds per frame rather than frames per second. Your code takes like 42 seconds for the first frame to show up (although that includes the maze on the right, which hopefully, does not have to be redrawn every time). What you need to do is use commands that depend on the graphscreen more. I noticed the clever little D trick you used here:
Code:
For(D,1,2
Pt-On(N,B,D,L1(V
End


If you draw the small maze using this method of 2 different mark types instead, it draws MUCH faster. Same for the Lines at the beginning, there is a command to draw lines Wink and you can make them 1 pixel wide by using 1 as the linestyle. As for the actual raycasting, you are already using pretty much the best way I can think of, even though its painfully slow, that's just one problem you get when using pure-basic.
mr womp womp wrote:
Okay, So I think the clear problem with this is the speed. We are now looking at seconds per frame rather than frames per second. Your code takes like 42 seconds for the first frame to show up (although that includes the maze on the right, which hopefully, does not have to be redrawn every time). What you need to do is use commands that depend on the graphscreen more. I noticed the clever little D trick you used here:
Code:
For(D,1,2
Pt-On(N,B,D,L1(V
End


If you draw the small maze using this method of 2 different mark types instead, it draws MUCH faster. Same for the Lines at the beginning, there is a command to draw lines Wink and you can make them 1 pixel wide by using 1 as the linestyle. As for the actual raycasting, you are already using pretty much the best way I can think of, even though its painfully slow, that's just one problem you get when using pure-basic.

Yeah. Most of it could be optimized, but I am going to leave out your suggestion about drawing the minimap on the grounds that I like the animation. (It initially was done with lines, but it didn't have the same effect.)

I am posting from mobile, so the changes you suggested will be posted tomorrow.

CalcMeister wrote:
I am very impressed to be completely honest! I see you seem to enjoy taking on these "pure TI-BASIC" challenges... Try making all these things in ICE! you'd be a hit in no time.


Thanks!

The problem with doing this in ICE is that people have already made Raycasters in ASM, as womp pointed out. A new raycaster in ASM is cool, but it is not as innovative as one in Basic. My goal (here, at least) is to inspire and teach others. I also do this for my own enjoyment. It is much, much easier for one to get started in an on-calc and intuitive language like TI-Basic, then progress towards less easy-to-use/off calc languages like ICE, C, and ASM.
_iPhoenix_ wrote:
The problem with doing this in ICE is that people have already made Raycasters in ASM, as womp pointed out. A new raycaster in ASM is cool, but it is not as innovative as one in Basic. My goal (here, at least) is to inspire and teach others. I also do this for my own enjoyment. It is much, much easier for one to get started in an on-calc and intuitive language like TI-Basic, then progress towards less easy-to-use/off calc languages like ICE, C, and ASM.

Nope, that is not ICE. ICE really looks like BASIC, and it's on-calc, and it's even more challenging than TI-BASIC, in my opinion. It's very easy to learn, although a bit harder than TI-BASIC of course. I would surely give it a try (although only a few people did...).
PT_ wrote:
_iPhoenix_ wrote:
The problem with doing this in ICE is that people have already made Raycasters in ASM, as womp pointed out. A new raycaster in ASM is cool, but it is not as innovative as one in Basic. My goal (here, at least) is to inspire and teach others. I also do this for my own enjoyment. It is much, much easier for one to get started in an on-calc and intuitive language like TI-Basic, then progress towards less easy-to-use/off calc languages like ICE, C, and ASM.

Nope, that is not ICE. ICE really looks like BASIC, and it's on-calc, and it's even more challenging than TI-BASIC, in my opinion. It's very easy to learn, although a bit harder than TI-BASIC of course. I would surely give it a try (although only a few people did...).

I did, but raycasting needs Trig and decimals...
_iPhoenix_ wrote:
I did, but raycasting needs Trig and decimals...


You could always write a floating point library in ICE. It would only take, like what, way too much time.
CodertheBarbarian wrote:
You could always write a floating point library in ICE. It would only take, like what, way too much time.

Does ICE support this? -.-
The only thing you could do, if you want ICE, to create a sin/cos table yourself in a giant list or so.
PT_ wrote:
CodertheBarbarian wrote:
You could always write a floating point library in ICE. It would only take, like what, way too much time.

Does ICE support this? -.-
The only thing you could do, if you want ICE, to create a sin/cos table yourself in a giant list or so.
I was going to mention, I'd love to see trig commands in ICE. I'm making a Spirograph CE Plus program, since Spirograph CE didn't get as much love as I had hoped.
PT_ wrote:
CodertheBarbarian wrote:
You could always write a floating point library in ICE. It would only take, like what, way too much time.

Does ICE support this? -.-
The only thing you could do, if you want ICE, to create a sin/cos table yourself in a giant list or so.


There should already be 8.8 fixed point CORDIC trigonometry algorithms in z80 assembly somewhere online. Probably some multiplier-based ones for the ez80 too.
lirtosiast wrote:
PT_ wrote:
CodertheBarbarian wrote:
You could always write a floating point library in ICE. It would only take, like what, way too much time.

Does ICE support this? -.-
The only thing you could do, if you want ICE, to create a sin/cos table yourself in a giant list or so.


There should already be 8.8 fixed point CORDIC trigonometry algorithms in z80 assembly somewhere online. Probably some multiplier-based ones for the ez80 too.


I searched for like half an hour (also, this is for the CE/CSE, which are ez80) and could not find anything (of use/interest). I probably missed something obvious, though. Also, I fixed the movement code, which was a stupid, glaring, and easy mistake (I assumed that getKey always stored to K without me telling it to. Let's all have a collective facepalm on that one).

I also did some optimizations, and I noticed that the code took an extremely long time to render points that were far away, even though it didn't have to.
By adding some code that limits how long it can wait for a collision, this problem was solved.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement