Recently, I installed AXE onto my calculator, to expand what I could do on my calculator. I thought that it would be a fun idea to make a raycaster, as I had done so before in TI-BASIC, but AXE is much faster. Unfortunately, AXE's sin and cos functions work very strangely, but I was still able to make it work:
It runs very smooth at what I estimate to be 5-10 fps.
I don't really have any plans for this project, so any ideas would be nice.
Edit: I looked at the linked image, and I would like to mention that it runs much smoother on an actual calculator or in an emulator.
Very impressive. Raycasting is drawing a line from the camera to a point on the screen and continuing till it hits an object, correct? I once was making a 3d engine in axe but stopped after getting a wire frame renderer. Maybe you make OriamKart.
Yes, precisely what raycasting is.
I did a bit of testing on my calculator to get a more accurate reading of the FPS, so I made it loop through one hundred frames and timed how long it took. The new reading of FPS is 8.3 Frames per second on a physical calculator, which for a calculator is pretty good.
Doom.
(it has been done before, but not with Axe)
I did think about possibly making some version of doom with this, but doom has much more in its rendering system than just raycasting. Also including textures and sprites would be a real pain.
Oh. Thought that if Griffpatch could do it in scratch... Well, you could do some cool thing, like ELITE.
I recently optimized this code to run at 10 fps rather than 8. I will likely post this version to the archives.
Something I want to add to this project is wall textures. I know enough about raycasting to know how to texture the walls, but I don't know enough about AXE to understand how I could do it. I think I could use bitmaps, but I would have to scale them down and only grab them in a single column. Based on how bitmaps are stored, I should likely have the actual bitmap rotated so I can take a single row as a column, since bitmaps are stored that way. But pointers are scary... Could anyone provide an insight as to how I could do this?
Maybe show some example C code or code in a language you understand and we can help you convert it to AXE.
I've always wondered if it's possible to use some form of logarithm collision detection algorithm for raycasting. I remember seeing a video over logarithmic collision detection on YouTube but the video didn't reference any resources for me to look into or save for later, apparently it was used to create a demo for realtime collision with a 3D Mandelbrot shape and could be used for smooth collisions with curves. I'd need to do some research on it...
In fact that'd be a fun next project...
Anyways, impressive! I've always had trouble with optimizing raycasting and ESPECIALLY detecting collisions. So great job!
The way this raycasting has good precision while being fast is by doing what I call 'backtracking.' It probably has been done before, but I've never seen an example of it. Instead of going forward in tiny increments, each ray moves forward at a rate of one, and when it hits a wall it moves backwards in tiny increments until it is no longer in the wall. This uses less steps overall, so it is more optimized.
Another thing I did was changing the precision (how small each step was) so it was inversely proportional to the initial distance, meaning things further away are drawn less accurately, because they can be without much of a difference.
I have figured out what I am going to do with this project:
Wolfenstein 3D
Things I want to accomplish:
Adding functioning doors - I already have a plan for how I can accomplish this, it temporarily wouldn't render past the door when the door is opening.
Textured Walls - I have ideas for this, using bitmaps to draw each section, but I would likely need help with scaling and sections of the walls
Sprites - It wouldn't be true Wolfenstein without any enemies. I probably only need to render a single one at a time, since it would be better for speed and easier to make
And...
Playability - I want to keep the fps above 4, which I think would make it still playable. Right now, it sits at 10 fps, so I have a lot of wiggle room.
There is a Wolfenstein 3D port for the Casio 9750GIII-type calculators, although it is a completely different language and calculator, maybe you could take some inspiration from that.
(I can't find the link right now, I'll post it later, but you could probably find it by searching)
Looks great! Do you have an example download to check out?
With your walls, are you drawing each column as a rectangle currently?
claculator wrote:
There is a Wolfenstein 3D port for the Casio 9750GIII-type calculators, although it is a completely different language and calculator, maybe you could take some inspiration from that.
(I can't find the link right now, I'll post it later, but you could probably find it by searching)
Here is the link: https://www.planet-casio.com/Fr/programmes/programme1967-last-wolfenstein-3d-kelli-jeux-add-ins.html
Znak_Pares wrote:
The way this raycasting has good precision while being fast is by doing what I call 'backtracking.' It probably has been done before, but I've never seen an example of it. Instead of going forward in tiny increments, each ray moves forward at a rate of one, and when it hits a wall it moves backwards in tiny increments until it is no longer in the wall. This uses less steps overall, so it is more optimized.
Griffpatch does that too 😛.
tr1p1ea wrote:
Looks great! Do you have an example download to check out?
With your walls, are you drawing each column as a rectangle currently?
I will try to upload the current version of it to the archives later today for anyone to look at, and yeah, each column is drawn as a rectangle. I also have forgotten to mention or show that there is a way to look at the map, which is by pressing mode.
I've come across a problem with textured walls:
Since the height of each wall is 60 pixels, that would mean I need a 60*60 bitmap for one square of the wall, meaning if the player is directly against a wall, I would need 15 separate bitmaps for the wall. Unless...
I don't know whether or not it is possible, but if I store the bitmap in a certain way, would it be possible for me to grab a section of that bitmap? I'm not too experienced in AXE, so I'm not sure if this is possible
Znak_Pares wrote:
Recently, I installed AXE onto my calculator, to expand what I could do on my calculator. I thought that it would be a fun idea to make a raycaster, as I had done so before in TI-BASIC, but AXE is much faster. Unfortunately, AXE's sin and cos functions work very strangely, but I was still able to make it work:
It runs very smooth at what I estimate to be 5-10 fps.
I don't really have any plans for this project, so any ideas would be nice.
Edit: I looked at the linked image, and I would like to mention that it runs much smoother on an actual calculator or in an emulator.
can it make doom
As I have said in this topic, doom uses a much more advanced 3d engine than just raycasting. Wolfenstein3D, however uses raycasting, so I will try making Wolfenstein3D, Which I see as an attainable goal
I have uploaded a file of the current raycaster into the archives:
https://www.cemetech.net/downloads/files/2882/x3837
I also made a new map for it, being the starting room in Wolfenstein:
Znak: I really do hope you can at least post the code for the raycasting section of the code. That way, everyone can learn from you. (We like 3D games too!)
Jeff calc 84 wrote:
Znak: I really do hope you can at least post the code for the raycasting section of the code. That way, everyone can learn from you. (We like 3D games too!)
Good to know, I'll edit my raycaster file to include the source code.
In other news, I've discovered how I am going to texture the walls. Since each vertical column can be set to a width of 4 pixels, since one hex number is 4 pixels. I can use Pt-On() to draw sprites as the textures, but how to set the sprite is the complicated part.
I have to rearrange the hex data of the wall tile, so that it is in arranged vertically, and each hex value will have a 0 added after it, to make sure than when trying to make a 4*2 sprite, it doesn't act like an 8*1 sprite. From there, all I need to do is scale the vertical rows, which shouldn't be too difficult. It would go as such:
Code: change_value = 10 * actual_wall_height / perceived_wall_height
repeat until at the top:
position += 1
scaled_position = position * change_value /10
Pt-On(x,y,texture+scaled_position
I hope this makes sense. I can see it in my head, but I am not the greatest at explaining
Well, I meant that you should post the code here or in the zip...
Side thought: Why can't you do this column by column instead of square by square?
