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!

**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.
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!