I do plan on posting the code in the zip file of the raycaster. Sorry if that was unclear.
I have to do it square by square because I can't think of another way to scale the walls without changing the width

Hope it goes well and looks well too! 🙂

Texturing is typically a significant performance hit but there are some ways to optimise the approach.

Regarding your texture size thoughts, you're right in that storing separate textures for each possible scaled wall height is extremely space intensive to the point where it's not really practical on calc.

This means your other option is to scale in realtime as you're drawing. This also lets you pick a more space friendly texture size.

An example being if you had 32x32 textures and your wall height is 32 pixels high then you step through and draw every pixel in your texture as you're drawing, since they're both 32. But if your wall height is only 16 pixels high (because the wall is further away) then you would draw every 2nd pixel in your texture to the screen. Effectively your texture scaling factor would be: texturesize / wallheight, so 32/32=1 and 32/16=2. If you were really close to the wall so that the height of the wall slice you were trying to draw was 64 pixels high then: 32/64=0.5 so you would step through your texture in half steps, effectively drawing every pixel twice. Doing this per pixel can be very slow so there are some creative methods around this, such as pre-computing the texture steps into a table to avoid division etc.

What I plan on doing is having the texture for the wall be a 60*60 bitmap, then I'll take a 4*2 sprite from there. Rather than do pixel by pixel, I plan on doing 8 pixels at a time.
Edit: I also believe I am quite close to being able to do so

Dosen't the *10 /10 cancel out. If the /10 was first then you would get the original val - (val mod 10) but what does * first do?

Since AXE only uses integers, the only way I can find to get precise numbers is to do something like this.
So for example, if the change value somehow were to be 33, it would represent 3.3. I multiply it by the position before dividing it by ten so that it gets a more accurate result, and therefore better scaling
Also, to access the source code: https://github.com/ZnakPares/TI84-Raycaster-Wolfenstein
(Or I'll eventually post it in the archives with the rest of the program)

An update regarding texturing:
Unfortunately, I haven't been able to find any sort of technique that would allow me to texture the walls. I would need some way of scaling down a bitmap, and some way of drawing the back buffer or some other buffer to the front buffer without replacing the front buffer, but rather drawing over it. I've looked into Axioms, but I couldn't find either that worked. (There is an axiom for scaling, but it didn't seem to work on my calculator)
This said, I'm afraid I must put a hold on texturing the walls, unless there is some other way to do so. I will begin working on openable doors until a solution is found.
Also: I found that using hex data, I can make a custom icon for the program. If anyone would want to, they can create an image for the icon, which I might use in the final product

Comment your code. I'd checked the github repo. Go and explain, at least in short terms, what every variable, every instruction means. 😛

One small bug that I found and fixed:
In the "If getKey(55)" loop, add a "getKey" before the "Repeat getKey". That fixes the "When I press mode, it quits" bug.
Also, like, why d'ya add colons to the end of If and Repeat? They aren't needed.

Code:


Secondly, the walls sometimes disappear, mostly when you ram into it, but also a bit randomly. 😕
I'm pretty sure it's because the walls are too big. And the fix is here:

Code:

You know which part that was, I know you do.

Thirdly, you can see through [s]some[/s] corners. Collision not working well? Might try using DDA.

Fourthly, I recommend using these keys:
[Up] Move forward
[Down] Move backward
[<-] Turn left
[->] Turn right
[ALPHA] Strafe left
[XT0n] Strafe right

Strafing is done by moving perpendicular to the direction of the player.

One important thing, though:
When I set S to 1, I found that there was a "fisheye" effect.

This should be fixed, even if it's not very noticeable when S is equal to 3.
(When it's 3, there is a "bump" on the wall. May bug people.)
Here's a website that might help: link

One hell of a engine, though. 🙂

Just went and optimized+commented the code:

Code:


The lines behind "." are comments. Now compiles to 1990 bytes!
The effect:

😎

Firstly, thank you a ton for showing interest in this, I will definitely look through all this advice and try improve my raycaster.
With that said...
I don't write comments because a) I write my code on the calculator, so comments are annoying to type and to scroll past, b) I didn't expect anyone to read my code, so I didn't bother. I will try adding more comments now, knowing that people are looking through stuff.
I haven't really found the error with the minimap, but if it affects you, it might affect more, so I will fix that. I'm not entirely sure why I add colons.
I am aware of the walls randomly disappearing, but I thought I fixed that in the version(s) I released. Are there any specific spots where that happens so I can analyze the problem?
Seeing through the corners is a bug that I'm going to fix by just making there be no corners to see through. I can just change the map to fix that bug.
I don't think I'll add strafing, especially with the key you recommended, since I plan to use [Alpha] for something else, such as opening doors, which is the current focus
I have tried multiple times to fix the fisheye effect, and it works to some extent at the cost of completely screwing up everything else. I'll still look into that.
I will look through your optimized code and make changes where I see necessary. Thank you so much for your help, I will definitely give you credit in the description when I post it here


Thanks a ton

ti_kid spent some time figuring out texturing

The current texture is a placeholder for hopefully a brick-like sprite. ti_kid made it take a 4*16 texture as the wall texture, then scale it for each section of the wall to properly texture the walls. It still runs quite smoothly, which is one of the main goals in this project. I think this is an amazing step forward in this project, getting to the point of completing or almost completing texturing. Great thanks to ti_kid for showing interest and putting in the effort to figure this out.

The version with textures is here:
https://github.com/ti-kid/TI84-Raycaster-Wolfenstein

Here's a brick sprite that you might find appealing: 🙂
[FFA4FF92FFA4FF92]
The effect: (# is black, _ is white)
########
#_#__#__
########
#__#__#_
########
#_#__#__
########
#__#__#_
You can see that the left side makes the right side "complete", and the upside makes the down side "complete".
May need to be split into two sprites for texturing.

There is a bug where walls far away are drawn faster than walls "in your face".
And, uh, it crashes my calc :/
Still nice, though!

Bug report:

What is that bump in the middle?

Fear not, the calc-crashing bug has been fixed (simple error of less than 0 being above 60000). Also, a bit of a speed improvement, since it no longer renders the entire 62 high walls, but rather a 50 tall area to make there be room for a soon-to-come hud. In terms of fps, it is now at about 7, which is still playable and above the goal of 4. It is a small dip from 10, but that's to be expected from texturing, and definitely worth it.

I also designed a simple brick pattern that I think works quite well, and added an intro. Again, thanks a ton to ti_kid for making the texturing possible.
The bug where there's a bump on the wall ahead is a fisheye error, and I think it's too small to try fixing, since all my attempts tend to make the rendering engine break and it's a very small amount of fisheye.
A question to any moderators: I originally released this on Cemetech as a raycaster, since then it is now going to become Wolfenstein3D. Would it be okay to release it now as a new file as Wolfenstein 3d? Or should I just update the raycaster archive file?

Yeah, it's ok, they don't care what you publish, they just check if its README is good or not.

Also, I don't think that's a fisheye error, it only happens to an orientation, and I was very far away too...

I think it was a fisheye error, since the way I programmed it is that it gets less precise the further away the initial ray is, so larger errors will happen further out. I can't think of anything else that it would be besides fisheye, since I have done no error correction for fisheye, and I don't think I will. It's a small visual bug, and doesn't matter much

I found that you can use /* and ** with floats to handle decimals.

Code:

A float is 9 bytes large, remember that so you don't corrupt anything. Also the typical * will remove the decimal, same for division. So you have to use the alternate options for all of it.
I might be a little late saying this cause you've probably already implemented your solution, which in my opinion works better cause that's what I use anyways.

Hilarious. Yes, you should make a new file for your Wolfenstein-inspired game, rather than keeping it in the lineage of the raycaster, especially because someone else might want to explore building on the raycaster framework in the future.

A version of Wolfenstein 3D with textured walls has been uploaded to Cemetch here: https://www.cemetech.net/downloads/files/2888/x3846

I am currently working on primitive enemies. Attempt 1 had 2 weird bugs, 1 I still don’t know the cause of. I have also had more motivation to work on my [REDACTED] and Znak on I believe AX-Bert so progress on this will slow a little.

[spoiler]Check my GitHub for the least complete repo.[/spoiler]