Hey all, just wondering if anyone knows the framework of a doom-style 3d engine, in pseudocode?

I'm hoping to be able to do this using sine and cosine with an input range of 0 to 255, and an output range of -255 to 255.

I'm mainly stuck on how to perform the rotation matrix with that restriction.

What kind of a question is that

Are you referring to a raycasting engine? I know Wolfenstein 3D used it, but Doom may have built off of it. I found a good tutorial here

http://www.playfuljs.com/a-first-person-engine-in-265-lines/. patrickdavidson also made one for the CE here:

https://www.cemetech.net/programs/index.php?mode=file&id=1588.

Hope this helps!

**OldNewTimer wrote:**

Something like that, exept instead of using a grid, I would be using a list of coordinates, then using two indexes of that list to make walls.
**MateoConLechuga wrote:**

What kind of a question is that

What I need help with is how to make that -255 to 255 range useful, and I can't use decimals, unless I store them seperately.
**OldNewTimer wrote:**

The original Doom 3D was not a raycaster (though Wolfenstein was) . It used something a bit more complicated called binary space partitioning. I can't do it justice; check out the article.

For your purposes, raycasting is a good option. I recommend doing it in C, because C lets you do decimals and is much better than ICE at this stuff. (More graphics than math? Use ICE. More math than graphics? Use C. Want to give yourself headaches for the rest of your life while failing to accomplish your goal for an entire year or more? Use Assembly.)
vertexs go spiny spiny around the camera as the camera rotates thanks to the spiny spiny formula:

x′=xcosθ−ysinθ

y′=ycosθ+xsinθ

then get projected from from 3d space into screen space. The formula for that, if you dont want to use matrices, would be something like this iirc:

x' = x/z*screen_width+(screen_width/2)

y' = y/z*screen_height+(screen_height/2)

once you know the on screen pixel potion of two points you can draw lines between them or whatever to make a wireframe model

**c4ooo wrote:**

vertexs go spiny spiny around the camera as the camera rotates thanks to the spiny spiny formula:

x′=xcosθ−ysinθ

y′=ycosθ+xsinθ

then get projected from from 3d space into screen space. The formula for that, if you dont want to use matrices, would be something like this iirc:

x' = x/z*screen_width+(screen_width/2)

y' = y/z*screen_height+(screen_height/2)

once you know the on screen pixel potion of two points you can draw lines between them or whatever to make a wireframe model

Yes, I've done that before; what I need is how to make a number between -255 to 255 useful when sine and cosine are normally decimals, and I can't use decimals.
**beckadamtheinventor wrote:**

**c4ooo wrote:**

Yes, I've done that before; what I need is how to make a number between -255 to 255 useful when sine and cosine are normally decimals, and I can't use decimals.

Its just a different range, use the normal formulas:

x′=xcosθ−ysinθ

y′=ycosθ+xsinθ

but divide by 256 at the end:

x′=(xcosθ−ysinθ)/256

y′=(ycosθ+xsinθ)/256

(Dividing by 256 is faster then by 255, and the visual difference is negligible)

see also: https://www.omnimaga.org/axe-language/how-to-calculate-(using-trig)-rotation-in-axe/msg399875/#msg399875
I agree on using a power of 8 to represent +/-1.

I've used the +/- 64 range for scaling trig in the past to keep things in 1-byte and also for math routine optimisation - but it's more of a horses for courses kind of thing.

**c4ooo wrote:**

**beckadamtheinventor wrote:**

**c4ooo wrote:**

Yes, I've done that before; what I need is how to make a number between -255 to 255 useful when sine and cosine are normally decimals, and I can't use decimals.

Its just a different range, use the normal formulas:

x′=xcosθ−ysinθ

y′=ycosθ+xsinθ

but divide by 256 at the end:

x′=(xcosθ−ysinθ)/256

y′=(ycosθ+xsinθ)/256

(Dividing by 256 is faster then by 255, and the visual difference is negligible)

see also: https://www.omnimaga.org/axe-language/how-to-calculate-(using-trig)-rotation-in-axe/msg399875/#msg399875

**tr1p1ea wrote:**

I agree on using a power of 8 to represent +/-1.

I've used the +/- 64 range for scaling trig in the past to keep things in 1-byte and also for math routine optimisation - but it's more of a horses for courses kind of thing.

Thank you!

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

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