itch.io

That’s indeed weird. I’ve changed nothing tbh since uploading the version 0.0.7 with the Quake demo, apart from adding a GIF preview of E1M1 as you’ve pointed out. 🤔 It may or may not be related to that, but more often than not I’ve seen new browser versions effecting how the engine performs against demanding maps/models with high number of meshes. (My engine is highly dependent on the optimizing performance of the browser JIT compiler it runs on since everything’s done on the CPU with 0 GPU utilization) Did you have a chance to test it out in different browsers, I’m currently getting somewhere between 20 to 30 FPS in Chromium-based browsers.

Thanks! Yup, it’s 100% on the CPU and all written from scratch in JavaScript. Just loaded up Quake E1M1 in the demo today, the framerate is crap right now due to not having implemented any scene management, occlusion culling or any sort of fancy stuff whatsoever, but it’s still somewhat a progress that the engine can handle (i.e., doesn’t actually shit itself lol) 6k+ polygons that I throw at it.

Hey there, sorry for the late reply! =(

Well, if you know your way around JavaScript, then it’d be pretty trivial to setup something very similar. I’m using the "2d" context of the HTML5 <canvas /> for all the 3-D work. Think of it as a 1-D array of bytes, where each 4-byte group represents a color (with 4 distinct channels that make up a pixel: red, green, blue, and alpha) at the corresponding pixel. At each frame I’m filling up that array and handing it over to the <canvas /> for it to actually display on the screen.

If what you’re looking for is to get into 3-D math, then my ultimate advice would be to use a pen and paper to try to come up with solutions by yourself, and only resort to looking up solutions online if you’re stuck. 3-D math is a journey you have to go through on your own. (Or you can follow along a tutorial or two, and speed up the process in the expense of not totally understanding the underlying theory of linear algebra.)

Hey, thanks!

Hey there! Sorry for the late reply, I’ve just seen your post.

Well, thanks for the kind words, really appreciate it. Handling collisions with non-axis-aligned geometries has by far been the most difficult thing I got to implement for my engine! Lots of late-night debugging sessions and pulling my hair out due to the inaccuracies caused by floating-point rounding errors, haha! I’m glad how it turned out though. As for the collisions against the y-axis, you are right, they are non-existent right now. That seems a lot more straightforward though, when compared to handling collisions in the x-z plane.

As for the mouselook issue, I haven’t really invested in resolving that one since I would have no real way of verifying/testing my fix as I have never been able to reproduce the issue on my end, sadly.

Hey man, thanks for checking out! The thing with the mouselook is that the mouse-move + pointer-lock API is acting weird depending on the mouse/browser used. I am getting more accurate movement when testing on the Brave Browser and using my laptop’s trackpad. Bluetooth mice also do not work that great. Also, I would suggest disabling any browser extensions that might collide with mouse tracking. Those aside, you can always use the arrow keys for freelook and curving around corners.

Hey thanks! I never really realized until now that tiling up a few textures properly could make things a lot more look appealing to the eye. Other than that, some quality of life improvements were made in this version to the perspective-projection code along the y-axis of the screen.

I‘m currently in the process of migrating the project to a more “organized” and decoupled codebase. I will be dissecting it into 3 major modules–engine, game, and data. It should be complete soon, in the next version.

This is really cool. I really like the effect at the start. Good job man! I really wish there were only a couple of “textures” though. This many can be disorienting, or it might just have been me. XD

Hey man, sorry for the late reply. I was pretty occupied with my actual dayjob. XD Anyways, thanks for sharing this with me.

Hey man no worries.

Well I don’t particularly see a problem with the way you’re texture mapping, however to overcome that fish-bowl distortion I think you should try casting a ray for each pixel column of the screen and work out the angle of the ray that way, rather than shooting a ray at each angular increment of the fov.

I would be interested in checking out your engine btw, if you ever released it somewhere.

Hey man, thanks for taking the time and checking out my little engine! I really appreciate it. Yeah, texture-mapping floors and ceilings was indeed a challenge for me too. It may not be perfect, but I’m pretty happy with what I’ve been able to accomplish so far. That aside, would you mind elaborating on the sawtooth artefacts you had with your engine, I may or may not be suffering from the same with mine.

As for the mouse look, yeah, I did notice some of the browsers behaving differently with the movementX and movementY–especially on Safari and Firefox, the values for movementX & Y are literally all over the place and can be a pain to use the mouse to turn around etc. I have never cared for it that much since I thought it was actually a behavior of the pointer lock and mouse listener apis and there was not much I could do about it. Now that you mention it, your approach seems sensible to me, combining it with clamping the values in a window could in fact be a decent workaround for the issue. I will try that and let you know. Thanks!