Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A first-person engine in 265 lines of JS

playfuljs.com

Post reply on HN
Print view View original

51–60 of 99 posts

Re: A first-person engine in 265 lines of JS

#51

Post by skybrian »

roryokane wrote: post #28

It is very interesting to me that you need to multiply the distance-to-wall by the cosine of the angle to transform the image from fisheye to normal. It makes me wonder, why is it that our eye in real life sees straight lines as straight, the way this demo renders the image? To illustrate the question, see https://en.wikipedia.org/wiki/File:Panotools5618.jpg – why do we see the world as in the bottom image instead of…

Sometimes after getting new glasses, I would see the world this way until my eyes adjusted.

Re: A first-person engine in 265 lines of JS

#52

Post by Almaviva »

roryokane wrote: post #28

It is very interesting to me that you need to multiply the distance-to-wall by the cosine of the angle to transform the image from fisheye to normal. It makes me wonder, why is it that our eye in real life sees straight lines as straight, the way this demo renders the image? To illustrate the question, see https://en.wikipedia.org/wiki/File:Panotools5618.jpg – why do we see the world as in the bottom image instead of…

I think it's simpler than some of explanations here. You're not rendering onto the curved eye, you're rendering onto a flat monitor. If you imagine the game view as a window, a straight line outside always projects toward your eye onto a straight line on the window.

Re: A first-person engine in 265 lines of JS

#53

Post by hunterloftis »

pearjuice wrote: post #46

I feel very pathetic from this. You could have given me 265K lines and I wouldn't have figured it out.

Don't feel pathetic! I certainly didn't invent anything here, I just distilled an old technique as much as I could in JS.

Besides, we all start somewhere mate.

Re: A first-person engine in 265 lines of JS

#54

Post by nppc »

s-macke wrote: post #23

My raycast engine in Javascript needs a few more lines and works a little bit different, but gives also impressive results I think :) . http://simulationcorner.net/index.php?page=comanche

I really like how your code uses much less cpu than that of the article. whats the trick ?

Re: A first-person engine in 265 lines of JS

#55

Post by stepstep »

roryokane wrote: post #28

It is very interesting to me that you need to multiply the distance-to-wall by the cosine of the angle to transform the image from fisheye to normal. It makes me wonder, why is it that our eye in real life sees straight lines as straight, the way this demo renders the image? To illustrate the question, see https://en.wikipedia.org/wiki/File:Panotools5618.jpg – why do we see the world as in the bottom image instead of…

> After all, our eye really is at different distances from different parts of a straight wall, so it sounds logical that we would see the fisheye effect describe in the article.

It's not the distance to the points in the scene that determine where they appear in a perspective projection, it's the angle. For any single point on the screen/retina/projective plane, it can actually correspond to any distance from the camera/eye (i.e., a ray of possible points).

Re: A first-person engine in 265 lines of JS

#56

Post by ANTSANTS »

DanielRibeiro wrote: post #40
ygra wrote: post #34

Earlier quoted context omitted.

2D canvas should be hw accelerated too on most browsers.

Yes, however the raycasting is drawing pixel by pixel. That part is not hardware accelerated, and that is the expensive part. That is that part that shaders speedup a lot, by delegating a lot of the work to the GPU. Just compare with this pure fragment shader demo: https://www.shadertoy.com/view/MsS3W3

That page froze my browser (Firefox 29) and started leaking oodles of memory until I killed it (along with a bunch of other shit I was working on), so I guess I'll count that as a point in favor of software raycasting.

Re: A first-person engine in 265 lines of JS

#57

Post by olegbl »

I remember being amazed how simple raycasting was when I wrote a similar (though much simpler) engine in Java for a high school project. The "engine" itself was like ~200 lines of code in just 2 or 3 functions. Raycasting is a really clever technology. Cool demo!

Re: A first-person engine in 265 lines of JS

#58

Post by s-macke »

nppc wrote: post #54
s-macke wrote: post #23

My raycast engine in Javascript needs a few more lines and works a little bit different, but gives also impressive results I think :) . http://simulationcorner.net/index.php?page=comanche

I really like how your code uses much less cpu than that of the article. whats the trick ?

Don't know. But here some possibilities:

1. No fullscreen

2. I update the screen only if a key is pressed.(No rain, that has to be rendered all the time)

3. I don't use any costly canvas functions. I render everything myself in a pixelbuffer.

4. Typed arrays

Re: A first-person engine in 265 lines of JS

#59

Post by pervycreeper »

This demo unfortunately uses an incorrect perspective transformation. There is no reason to go to trig if you represent the camera plane as a vector, and step along it one pixel at a time, and allowing the wall height to vary linearly in the distance to the camera vector (taking lines to lines). In addition to being correct[1], it has the added benefit of being faster if implemented well.

My (admittedly n00bish and embarrassing) attempt at doing the same thing is here: https://github.com/pervycreeper/game1/blob/master/main.cpp

[1] in the sense that lines map to lines, as in most photography, Renaissance and later painting, and most computer graphics

Re: A first-person engine in 265 lines of JS

#60

Post by sillysaurus3 »

pervycreeper wrote: post #59

This demo unfortunately uses an incorrect perspective transformation. There is no reason to go to trig if you represent the camera plane as a vector, and step along it one pixel at a time, and allowing the wall height to vary linearly in the distance to the camera vector (taking lines to lines). In addition to being correct[1], it has the added benefit of being faster if implemented well. My (admittedly n00bish and e…

Why is it incorrect? From looking at the demo, it doesn't seem incorrect at all. If it's incorrect, then the incorrectness doesn't affect the end product, which is all that matters. Lines seem to map to lines, so it seems mistaken to call it incorrect.

I'd be interested in further explanation about why you feel the underlying math could be improved, though.

Post reply on HN