Games 60 Day Non-euclidean FPS Build

While I'm continuing work on my longterm project Mittens' Adventure, while I'm out of work due to the virus, I've been thinking about doing a handful of short projects just to bring in a little extra revenue. I've had this unique idea in my head for a while, but kept it on the back burner while I develop my other game, and also aren't sure how to make it a full size game, but it's perfect for a mini game.

The standard features will include

• 4-6 arenas
• 3-5 modes like deathmatch, CTF...
• Inventive takes on standard shooter guns
• 4 player local mode
• AI bots with a variety of settings

The unique features will be

• Heavy use of non-euclidean geometry, especially big places stuffed inside small containers.
• Dynamic gravity, allowing "down" to be whatever direction the map says it is, and wall/ceiling running is important to the combat loop

I will try to release the game publicly before the end of summer.


Month 1:
Make an virtual controller, which handles possibly mismatched input types
Pin down the dynamically facing gravity and how sticky the character is
all players together and make movement/weapon controls
Add the non-Euclidean geometry effect
Build navigation technology, use wall geometry as well as object placement markers (health packs, weapon upgrades, ammo...)
Build AI to take control of virtual controllers
Build a functional arena, playlets it to learn how it flows with the extra degrees of freedom. Use greybox.
Finetune weapons/movement/combat loop

 

Day 1
Imported some assets that I've already created for other projects. Wall running and gravity re-orientation is functioning, just needs to be tuned. Also started work on the non-euclidean geometry feature. Got it partially working, I expect to be able to create a short video featuring impossible geometry tomorrow. The math was a little more intense than I predicted and spent most of the morning doing geometry and calculus.

 

Day 2
I made what I had more robust and a little more optimized. I cleaned up the code so that it was easy for me to follow and debug later. I also started working on a haunted house style level. I'm starting to learn how to use different slopes to grant and restrict access to certain areas as well as setting up the room so that the non-euclidean illusion is never broken. I also have to make sure that two seams aren't able to see each other. I wrote a recursive algorithm, but it was too render heavy, so better to just work around it.

Here in the video, I start by showing a long hallway that passes through a small object with a perpendicular hallway. Then I use the stairs as a ramp to jump to the wall and start running around on the ceiling.

 

Day 3
Sort of got the non-euclidean traversal done. I'm learning how towrope my head around level design with such a strange space. I'm learning to think it in traversable pieces, playing spaces that are sectioned off by walls of 90 degrees. I've decided to color code them in Blender so that I can fully understand the space and how it will be traversed. Besides understanding, it also has a future use of verifying that the nav system that I’ll need to write works correctly and them at AI can go everywhere the player can.

I expected to be able to visualize the geometry better than I am because I do a lot of general relativity, but gravity and spacetime is simple, it only stretches, it doesn't fold or break. This is more topography, which is much less of a strong suit.



The yellow area represents one area, where the player can get to pretty much anywhere else on it through any path. The brown is another area that can be easily run around, but there is only a few locations where you can traverse from brown to yellow. This means that you can be physically right next to each other like where they meet at a corner, but have no real way to get to each other.

By next Friday I plan on having something ready for feedback Friday. Since I’m building this game as such an insane pace and the geometry is so bizarre, I want feedback immediately.

 

Day 4
I got most of the functionality of the non-euclidean geometry part working, there are minor hiccups here and there that can be cleaned up tomorrow. Meanwhile, I've been learning the limits of how I can and can not construct the world. Spaces need to fold over correctly and not have any way to jump between one and the other. It's very easy to loose track of where I actually am.

Here is a short demo. First, I show off wall walking, and how you can move around at different angles. Then in the room I'm calling the kitchen, you can see a 90 degree turn that somehow leads through the middle object, as well as if you look from the other direction, you see a huge space inside the small table. In the bedroom, I then show off a bed that somehow has five right angle corners. This is mostly to test the frame rate, and I was relieved to see that it remained stable.

 

Day 5
Fine tuning the controls and the space warping. I have to make sure everything is set up properly. I had the movement vector actually backwards and was subtracting positions instead of adding. That works fine in 3D space, but in my world, it wasn't, so I had to correct everything.

I also realized that the topography of my five corner bedroom wasn't going to work mathematically, there was alway going to be a loose end. I actually went through and did a proof in the process of trying to find the right configuration. So instead, now it's two bedrooms that overlap and make one continuous bedroom with 11 right angle corners.

 

Day 6
I built myself a nice shader to use, allowing fog that has different colors at different distances, making it much more eerie. I'm actually using an unlit shader, as Unity's lighting engine doesn't support what I'm trying to do. I may end up creating my own light mapping system to allow for some dynamic and static lighting, but I haven't decided how to do it yet. I also added some coins for the gameplay demo that I plan on sending to people just so they have something to do while I watch them navigate.




EDIT: Check this out. I've always loved the look of some older games, true color just does something to it that makes it too sterile looking. I want to replicate the effect of textures using palettes, without actually having to use pallets. So once everything is calculated smoothly, I round each of the components to the nearest tenth. This essentially gives the entire game a color depth of 15,000 colors. The top has this feature disabled, and the bottom one has it on. The second one to me looks far more jagged and foreboding. Since it's in the shader, and the textures are all smooth, it's not as jagged as say doom, details kind of creep into view through the fog.

 

Day 7
Added some moving perils noise to my shader, which gives the illusions of fog and shadows moving around in 3D space. I took a music track from my other game and pitched it down my a factor of 8, which gives it a ridiculously creepy ambient sound.

 

Cool! How does the non-euclidean effect work (portals)?

 

Hello @DebugLogError! There are actually two different systems to achieve this effect. One is smoke and mirrors and one isn’t. To navigate around the world, it’s all fake: teleporters and duplicate rooms. I pulled the tech it from a Brackeys video but had to modify it because he’s either smart enough to have optimized this on the fly, or not quite as good at math as he thinks. His rotation code was completely wrong and only worked if the “up” direction was the same.

The second system is a true hyperspace mesh system. Most of the objects will be made out of these and rotate in 4D. I calculate a 3D cross section, then project that to a billboard. A powerup I plan to have has a tesseract as a model, and you can’t just take a gif of a rotation 4D cube and put it on a billboard because your movement should affect its rotation.

Day 8
The fog looked cool, but I also need lighting, which put me in a pickle because unity’s lighting system can’t be told about my teleporters, so I either had to fake it or come up with my own. I did the latter and spent the day building a static lightmapper. And not gonna lie... it looks beauuuuuutiful.

I thought for like an hour how to pull it off. Ultimately, I decided to ignore the concept of a light source entirely. At the beginning of the rendering everything is black except objects that glow (lightbulbs, fires...). I Then move a camera along every pixel of the UV and actually render, calculate the light that hit the camera and add it to a high precision value, which turns into this pixels current light map value. It then applied that light map, and repeats. The first couple of repeats can have a multiplier indication that they are the initial source of the waves of light passing over everything. Bouncing then fills in the rest of the room as it loops over and over until the average light per pixel reaches a predetermined threshold. Then it dials all the light back to darken the room, and continues bouncing light and moving up to the theshold again, then it will loop there until I manually stop it. Since most of the work is don’t involve the GPU, it’s quite fast and I’m able to bounce dozens of times, where unity is limited to like 5. Fine tuning it today and will post a screenshot in the next post.

 

Day 9
Put the finishing touches on my light mapper, and tested it extensively so that I'm sure it'll work in a variety of circumstances. I find it both fun and useful to analyze it's bake.

On the very first frame, everything is black because the only thing that gets lit is directly exposed to the single lightbulb, which is the lampshade (and to a lesser extent the ceiling and part of the desk.) The lampshade ends up being the main source of spreading around early photons. The light bleeds through because I put both sides on the same spot in the uv.


By 4 bounces in, the amount of light has increased dramatically, so the multiplier for each frame is being reduced, though it it still filling the room with photons. You can start see a nice shadow on the bookshelf and I see some white light hitting the floor next to it, indicating that it actually has direct sight of the lightbulb under the lampshade.


By 8 bounces, light has reached all corners of the room and even inside of the bookshelves. Obvious dark spots are forming behind the monitor and computer and the shadows are softening. A dark shadow still exists behind the pillar in the room, but that should fade away as light moves around walls a lot more now. Light is still being added.


By 12 bounces, the room's full of photos and each additional bounce is contributing less and less, but each iteration gets it closer to the true value.


At 24 bounces, light is really smoothing out, bouncing all over the walls and inside of everything. I closed all the doors and turned on a lamp, this is exactly the effect that I saw in real life.

 

Final output, with 50 bounces. Looks gorgeous in my opinion.


I can flip a switch on my shader to show just the lighting data, which is cool. Weird how all that soft orange light came from a pure white lightbulb shining through a wood texture lampshade.

 

Nice job with the lightmapper. Could your implementation run in a build? I've worked on a few in-game level editors and not being able to bake the lighting has always been the biggest issue.

 

@DebugLogWarning It does run in the build, that's the only way that it'll work properly with my teleporters. Here's the code: https://forum.unity.com/threads/static-lightmap-baker.919859/. The lightMagnifier could be increased by a bunch to put more light in the scene faster, though it'd still be slow. It takes about 60 seconds per bounce on a fairly simple 512pixel scene. Faster than Unity, but still not exactly real time.

 

Can't wait to check it out. Thanks for sharing!

 

Hope you find it useful, it shouldn't be too hard to convert to output something useful for the built in mapper.

Day 10
Fine tuned the controls. The player would go flying off of ramps, I added a recast below you to stick you to the ground. I also wanted to make sure that I prevented players from clipping through the walls. The physics engine is fine, but I needed a backup so I built one. If it detects that it's going through a wall, it will move back to it's previous position.

Made some final adjustments to the light mapper and realized that the teleporters don't know about the rendering camera, so I'm gonna have to rework a method or two.

 

Not adding a day since I didn't do anything today besides post for feedback. Next week, I intend to finalize the light mapper, complete the arena, and fine tune all controls for the player. That way I can have a workable demo ready before feedback Friday and can then focus on navigation. I'm still figuring out how to build a nav mesh with not only teleporters, but also wall running.

After that, AI. I need to have multiple enemies running around in order to really test the systems, and I will set them up to have a small neural network inside of a more coded AI that can fine tune parameters overnight.

 

I remember making a prototype of a mp fps with changing gravity. Looked really fun, but mp was waaay over my head at that time (still is tho)

 

Day 11
Based on feedback, I retextured some of the house, and increased the number of colors by a factor of 8. This still gives me the nice effect that I want, but the browns now have more places to go and don't get muddy. I also added a feature to the shader that will take the alpha channel and use that to multiple the distance, allowing me to put symbols on the walls that only appear at distance.




I also fixed the problem where teleporters weren’t rendering for the lightmapper, so I added a method to the teleporter to force it to render from a certain angle, which fixed the problem completely. I’m ready to do a light bake as soon as I finish the geometry.

 

Day 12
I'm going away this weekend again, so I decided to finish texturing and modeling this single arena so that I can just let the light baking run over the weekend while I'm away. I ran a test run today while I filled in some of the holes.

 

Day 13
Totally textured and closed in my first arena. I am going to let it bake lighting for a bit.

 

Day 14
Not a very exciting or long day. Just fixed some minor bugs in the lightmapper and set it up to do a 50 bounce full render while I’m away this weekend. The arena isn’t final so I’ll have to redo some it it at some point, but that shouldn’t be a big deal. Next week I plan on making projectiles and turning my damage system back on, along with fixing issues with the teleporters.

I had to take a ride to the city and during the ride I figured out how the nav system will work.

 

This is so cool! Well done so far

 

Thanks. I injured my hand so typing is problematic for a few days. I really wanna release this for Halloween so I hope it doesn’t push me back too much.

I can still design in my head which I’m doing.

 

I can't wait!

 

Day 15
This week will be devoted to navigation. I've created a nav mesh that should be very fast and allow me to have players running all over walls. I take all of the triangles in the mesh, and find all convex polygons, which get merged into groups where all nodes in the group can see every other node. Their edges link them together. For fast navigation, only the groups are considered, which makes A* very efficient. Once a suitable path has been found, a separate, more precise path will be calculated with the edge nodes.

 

I gave up on doing this in Unity for a variety of reasons. It was quite difficult and costly to do things like mirrors and portals all over the place. It's not Unity's fault, it's just how modern game engines work and I found a better way. The scope of Unity is also a little daunting, and since it's general purpose, all of the functions work perfectly. There are plenty of times where a faster approximation is what I actually want. Unity's lighting engine is also too general purposed just can't do what I want. I want old-school level design where huge chunks of the level are moving and changing, which means either all dynamic lights, or some sort of animated light map.

I'm doing the thing that no one should ever do and building a custom game engine. I'm taking several major leaps backwards in time technologically, then bringing modern sensibilities to it. I figured out that I don't need true 3D, 2.5D is plenty, which reduces a lot of math equations. I went all the way back to 1993 and decided to make a DOOM style engine, with one major change. DOOM renders entire faces at once, and a depth buffer. This actually produces about 10% overdraw on every frame. I have found a way to remove this completely, every pixel is rendered exactly once, even if there is transparency or sprites in the way. I have this theory that the reason Carmack did this instead of raycasting like his previous engine, was because he didn't have an efficient way to recast through randomly placed lines, unlike the grid of Wolfenstein. However, halfway through dev, Romero made a section that slowed the engine down anyway, which inspired Carmack to introduce the BSP tree. But with the addition of the BSP tree, I realized that now raycasting becomes almost trivial, so I decided to combine them. This is the root of all the magic I plan on doing. Reflective surfaces are difficult in true 3D when you have to occlude stuff and render a renderTexture, in a ray caster, they're free. Same thing for refraction, transparency, and teleporting.

I've generalized some of DOOMs limitations: instead of a lower, middle, and upper texture, I can have unlimited texture sections per wall. Instead of each section having a floor and ceiling, it has an unlimited number of floor/ceiling pairs. This removes a DOOM limitation and allows me to have rooms on top of other rooms.

Since I'm raycasting, I can do a lot more interesting stuff than "get darker as you get further," I can affect the darkness of the ray depending on the sector the ray is going through, allowing fog of any color and any density, and have them stack as you view through multiple sectors.

I'm building a building in-engine. From the map view (top down,) I can click and drag lines, add more, delete them, add sectors... In first person mode, I can point at any wall, floor, or ceiling and bring up the editor for that specific item, so I can see what I'm building as I build it.

Even though it's fake 3D, I can still look up and down too.

One thing that makes DOOM look crappy is sprites in the background have "pixels" smaller than screen pixels, so the engine just grabs whatever pixel matches the exact position on the screen, meaning pixels in between get lost. I use mipmaps, so textures blur properly as the go into the distance. I also produce upscaled textures using hq2x and hq4x, because I HATE the look of bilinear/cubic texture filtering. God, it looks so ugly. I load the textures as 24 bit and do all the scaling with it, but then compress them into 16 bit partial columns. 16 bit looks almost as good as full color and with all the lighting and other affects, nobody misses the color depth loss and it saves a lot of memory.
Check out the quality of the mipmaps of a doom demon, compared to the nearest neighbor version next to it.

The one in the Preview window is the 24bit original file. The lower left is the 1x version, exactly the same pixels, just reduced to 16-bit. The bottom row is then mipmaps going all the way down to a single pixel. The two above are upscaled versions, allowing me to have really nice looking monsters with very small original files.

 

I’m still going to be using Unity as a tool for this project. Primarily as a sprite baker. It’s a thousand times easier for me to sculpt and rig a 3D model and animate it than it would be for draw thousands of enemies in various states from 16 viewing angles. I considered doing what they did in Doom where they made physical models and photographed them. However, since I want my sprites to look a bit more 3D than that, I also want to know the normal of every pixel in the sprite and that’s super easy in Unity, I’ll just replace the shader. It’s also assuring me that the 16 renders are all from exactly pi/8 radians apart.

I got the rendered finalized and ran some profiling and benchmarking. It’s running nicely at 60fps and most of the rendering time is on floors, since every texture coordinate needs to be dynamically calculated. I’m sure I can find some optimizations. The doom engine actually handles wall and flat textures differently, I assume this is why.

I was shocked at the efficiency of the raycaster. Without actually drawing, the raycaster is chugging through about 800fps. Since every pixel is drawn exactly once, I can mirror the S*** out of everything. Mirrors and refraction are essentially completely free. Five mirrors each also refracting still kept it at a comfortable 200fps and add exactly zero drawing overhead.

 

My new engine is coming along nicely, and I've started making Unity scripts to prerender 3D models into flat sprites. I'm having each pose rendered from 16 directions, which is more than Doom, and I think it looks smooth.

Check out this creepy SOB's diffuse and normal textures.

 

Concept art for a bovine-humanoid abomination. Thinking about recording a broomstick hitting pavement for the sound of its footsteps as it crunches along on its boney stumps.





Some might say using sprites is a limitation, but i think having super high details models pretenders makes it look much better.

Here is an animation. Has a real "kill it with fire" feel to it.

 

I’m excited about bringing shaders into my engine. It’s one of the quality of life modernizations I wanted to be sure I brought in. I’m also binding shaders to internal texture formats to remove any extra conversion. I hope that writing these will feel a lot like writing Unity shaders.

 

I ran into an interesting dilemma when I wrote the main shader. There is code in there that turns the pixel reddish if the object is selected in edit more, but I didn’t want it to even check for them when in play mode. I thought about how I would handle that in Unity and figured that I would simply swap shaders at runtime depending on context.

This lead me to the idea of separating the shaders into a seperate library with std c headings and loading and unloading these libraries dynamically.it has the added benefit that I can release the header for the library and expose a programmable interface without giving access to the engine’s code. This allows anyone with C programming experience to mod the shaders by just replacing the dll. I want as many modder-friendly features as possible.

 

I've brought another Unity feature into my engine. The high level idea of Textures is now gone, and everything now has materials. These materials can be animated, have normals, emission... Also, instead of now calling a static function to render a texture pixel to the screen, the shader system is now functioning. Each material has a function pointer attached to it, which it calls when it wants to render: passing in information like lighting, distance... The functions themselves are loaded dynamically by a shared library loader. They are referenced by function name, so if the level data tells it to load two shader libraries, and they share some function names, the latter one will overwrite the first one, making it super moddable.

It also fixed an issue that I had where I had multiple edit modes that needed to be handled. I wanted to be able to show just lighting, sector data... independently. Now, that's as easy as just swapping out shaders, so all the if branches have disappeared.


Check it out: stairs! So what? Doom had stairs. Not floating stairs . I had this sections above sections feature already working, but hadn't built the feature into the editor yet, so I was never able to show it off until now.

 

Continuing with taking inspiration from Unity, the built-in editor that I'm building works very similarly to ProBuilder. This has allowed me to make more complex structures, which has exposed some fringe cases that I have yet to figure out. For some reason wall textures warp when starting above an offset plane and parts of the ceiling overdraw for some reason. The weird thing is that it flickers, so I thought it was some function that wasn't thread safe but if I turn the threads off it still happens. Maybe I'm using an initialized variable, but the compiler should tell me with -wall.

 

I am a bit surprised. Was using multiple cameras didn't fit for the job, of having multiple portals?
I thnk you had really good results so far. So can you elaborate again, what the issue you faced wit Unity?

Or you wanted to achieve mirror of mirror reflections effects?

 

Having multiple cameras worked up to a point, but it had some limitations that I didn’t know how to fix and I noticed the framerate really starting to drag. If even a pixel of a teleporter/mirror was visible, it had to render the whole scene from that new position. And when you could see teleporters from other teleporters, the recursive results made things even worse.

the limitation was that in order to render what you’re supposed to be seeing through the teleporter, the extra camera has to be able to be the same distance away from it on the back face. This kind of forced it so that teleporters could only face out from the main level or else extra geometry might show up in the render. I tried altering the near plane, but because of rotation, the actual distance to the teleporter isn’t a plane.

Raycasting gives me all of that for free and while it eliminates the ability to run on walls, I can still use the ceiling for that Escher-feel. Non-Euclidean loops are also free because of I wrote the partitioning system in non-Euclidean space.

 

I don't want to use UV light maps because Quake and Doom look completely different and I want to learn more into Doom. I also don't want to have to manually adjust light levels for every sector I create, so I figure a happy middle ground would be automatic creation of flat light data. I will use the strategy that I already laid out in my Unity work of setting all light values to zero, and rendering from each face to slowly add light bounces over a few iterations. This allows for uniform refraction and mirrors and the noneuclidean geometry.

 

I am super thrilled with one of my modernizations to classic tech. I wanted tho lighting to look somewhere between Doom and Quake. More advanced and realistic than doom, but not light mapped light traditional games. So cell lighting is what I'm using, which gets baked. The same strategy that I did in Unity, I did in my new engine. I turn all the lights down to zero, so that only emitters are visible, then repeatedly render from each surface and average the light coming into it, and slowly building a map. It still looks like Doom, but with way greater atmosphere possibilities. I intend to demonstrate that you don't even need light uvs to have great atmosphere.

This is the default lighting that the builder provides. Everything has a value of 128. Sort of Looks like Doom.


Now again, after baking. That blue carpet really takes over the room, and there is the consistent blue hue over everything.



From another angle, the default lighting. I replaced some of the blue carpet with wooden planks to warm up the scene a little.


My mouth dropped when I saw the bake:

 

This may be potentially something of your interest.
https://forum.unity.com/threads/sharing-a-non-euclidean-impossible-space-effect.986004/

 

I started doing later manipulation, but with up to four local players it was getting a little nuts.

The main reason was the frame rate. I want portals to be able to face other portals and not have the framerate tank. I also had plans for mirrors walls using the same technique, but the technique I used just couldn’t render that much and that far recursively.

 

Continuing to modernize based on Unity. Yesterday, lights were all one brightness, differing only by their texture. Now, emitters have scalars. This helps make more realistic lighting, allowing me to have windows that are very bright or other light sources be brighter or dimmer than their texture implies.

This has forced me to think ahead with level design. I have to consider where shadows will end up. This is a minor inconvenience, but not one that Doom models don't overcome. The baked lighting is still a major improvement.

A window to outside looks good.


I can swap out shaders and show only the lighting data

 

I found this video fascinating. Shows how much overdraw the doom engine actually has.

 

I just noticed that Doom Eternal added a classic doom rendering mode. It renders at much lower resolution and up scales with nearest pixel. Then reduces the color depth to what looks like maybe 12 bit. Looks good and reaffirms that I can make the low bit color depth look good.

 

I’d been dealing with two minor bugs plaguing the renderer. Sometimes sections failed to render and stopped raycasting leaving a black line and the texture alignment was off if something occluded it slightly. I was trying to figure out why my lighting system wasn’t quite working correctly then I realized it couldn’t work 100% unless the camera did. So I fixed the rendering bugs and the lighting engine bugs also went away.

Building my own engine made a curiosity I’ve had with Goldeneye for years suddenly make sense. So in the 20 years that people have been speedrunning Goldeneye, no one had ever managed to get out of bounds. It always confounded me how that was possible, but now I understand it. I think Goldeneye uses a sector approached rendering system like me. My own game should also be impossible to break out of. My guess is that when the character moves, it checks if it crosses a sector boundary first, then changes into the new sector. However, if there is no sector pointer on the other side, it doesn’t perform the move, so even if you could get enough speed to clip through the wall, the lack of a sector pointer on the other side will always bounce you back inbounds. This would explain why you can clip through doors in goldeneye, because they aren’t sector edges.

 

Finally, I have something that demonstrably could never work in Unity or any other modern game engine.

Any (wall) material can now be reflective. All done in real time, no reflection probes or render textures or anything, literally reflecting the recasts in real time.


It's somewhat noticeable in the previous example, but here you see the hall of mirrors effect that happens when you have two mirrors looking at each other. Even if you used render textures to fake mirrors, good luck doing it with recursion.


I included a way to determine overdraw, this tells me how many times each pixel has been reflected, and will allow me to optimize design.

 

I was watching something on how how Windwakers graphics work and it solved a problem for me. I was wondering how I could get multiple dynamic lights to effectively work in my scene. The game cubes hardware was capable of rendering 8 lights at once, but they programmed this game to only accept the closest light source. It seemed to be an artistic choice rather than a limitation, and it keeps everything crisp because it assures that half of the character is always in shadow and half is always lit. It makes everything stand out from the background more, so I may adapt this.

 

Came across Ion Fury last night. A 2019 Build Engine game. Loved it, kinda the look and feel that I’m going for. Started to look into the tech and started to get confused. How on earth is the engine running so fast? It’s running at twice the pixels as my engine, at the same frame rate, using only one core. If I just make a for loop that fills a buffer, it won’t even go that fast. They’re writing far lower but depth, but still, it’s impressive and reinforced my belief that at some point, I’m going to have to replace chunks of C++ with asm. I definately plan on rewriting the shaders in assembly, since I’ve look at what the optimizing compiler creates and wasnt happy with the number of operators.

 

Looks great, keep going! Can't wait to see the finished product in the future!

 

I got normal mapping working, on the first person weapon anyway. It made me realize that there is still a bug in my light baking since this is the first time I’m actually using the directional information. I think the way I’m determining it is flawed.

 

I had to take a break to code something for my wife. I purposefully made her GUI in GLUT so that I could reuse all of it in the engine.