Allocating the Right Way

When picking out a good set of code examples to model a custom memory manager after, one must consider what one is looking for in objectives.

For example, what use would it be to have a custom memory manager that still uses the new/delete with the OS malloc if the custom memory manager was to be built around that purpose? I almost fell into that one, but that example I came across still called new and delete on char* groups to model bytes.

Instead, I found a much better example that suggests using a customized malloc (just grabbing the data instead of using OS malloc) then applying a placement new using a templated new/delete (array included). So far I'm liking this method!

I'm also learning about byte alignment; apparently if one masks off the log2(n) least significant bits from an address, one can get the n-byte aligned address from that address. Neat!

I'm also thinking of dabbling in a variety of allocators; that way I can use the one that best fits what I'm looking for.

Just Done

Today and yesterday marked a nearly endless amount of time spent in capstone. It is done now; I may rest.

All subtitles and credits added, all missing meshes and doors fixed.

Sure, there's more to be done, but in an academic sense, I am done.

...What to do? Start up a custom memory manager!

Day 73: Nothing Special

Well! Tomorrow's going to be the final day for official capstone work. Oddly enough, all sorts of fixes needed put in between. Rocks were off or not fully connected, crystals were back-face culled, and the cube generator (falling blocks in the Time area) weren't using the original material. Heck, the cube generator needed some fixing since it wasn't using the original dissolve material well as is.

Unfortunately I did run into some walls, as said dissolving material doesn't apply to materials involving the character. Ah well.

Due to the final exam today, terrain work may be concluded, settling for next week's presentation. I'll have to get working on something else soon...

Day 72: Dreamy

Phew, through all this mesh fixing and level loading and studying, I've been fairly busy. I did manage a shader that adds on extra samples for a dreamy faze out:

I am reaching the limit, at least for quick and cheap post-processing shaders that don't require anything other than a single render target switch.

As for studying, I made sure to run through AI pathfinding techniques, perfect forwarding, memory management, saving disk space and loading, and the basic graphics techniques I've implemented in my project. I'm ready for tomorrow!

Day 71: Ew, Studying

I've finally hit the point in capstone where I will no longer be adding new features! Woo!

I will be fixing things, especially the aftermath of instancing. On the bright side, it allows me to remesh some areas that I did not consider; previous passes of these levels involved nearly 30+ rocks for a single ceiling (!!!) instead of a single or multiple ceiling tiles, in the case of an a aperture.

I also managed to solve that pesky problem (eh) of people seeing through the character with the camera; when the camera gets too close, she turns invisible! It required an extra line trace instead of simple distance calculation due to the span of her capsule.

As for terrain, I will be adding new effects when I can; however, a large exam is approaching and I'm preparing the presentation of said terrain. So many things to cover! Hopefully I can give a simple enough explanation of Simplex Noise.

Day 70: A Variety of Pretty Things

Seems like instancing meshes led to some strange complications. Some of the meshes became transparent, oh no! Or back-face culled. I just replaced it with a working mesh and it worked fine; it also allowed me to reduce the amount of meshes in the scene, replacing a rock where 15 or so filled up a small hole.

As for the terrain, post-processing filters are in the work!

Pixelation allows people to sample colors divided across an image, much like point filtering:

We can also split the image into color tones for a posterized effect:

By also reducing the colors and crosshatching where luminosity is darkest, we get a strange but cool cross-hatching:

By experimenting with cross sampling using kernel matrices, we can also use edge detection and even blurring with small enough values:

I sure do like post-processing!

Day 69: Swirly

Aha! So it is possible to switch between shaders on the fly! After redoing a bit of code to allow pixel shader re-compilation, I managed to be able to switch between shaders by the hit of a key.

As for more shader research, I managed to figure out a neat swirling effect. If one takes the percent that the texture is from a set radius (within, for example), turns it into an angle and computes a new texture coordinate based on the dot product of the texture coordinate and the sine and cosine of the that angle, one gets a swirling effect:

The tricky part about this shader research is figuring out what takes no real parameters in the calculation; it would be tricky to add other textures and parameters without using them in the other shader functions.

Day 68: For Instance

Phew! Looks as if I found a stroke of luck with Unreal plugins. Thanks to the use of a Instanced Static Mesh editor, I can take the myriad of different meshes in the scene and transform them into a single instanced mesh. I expect some frame rate improvements, but not by much.

As for the terrain application, I managed to get a few more effects from post-processing.

First off, managing brightness by way of a simple multiplier:

Why did the text get dark? I learned that UI does not apply to post-processing the scene, so I placed the rendering of the UI after the post-processing quad.

Second, some color shifting, including a grayscale smudge and a more vibrant shifting effect:

What's next? Definitely more post-processing, though I should find a way to swap out shaders to make the application more data-driven.

Day 67: Solutions Galore

Today wasn't too much of a day for capstone work due to meetings and playtests, but we've come across an answer to one of our big issues! Seems as if the cinematic bridge formation near the end of our game wasn't forming because it was in the middle of creating an old bridge from a leftover piece and making a starting bridge point. Tomorrow we fix the big problem!

As for rendering to texture, I did manage to finally get rendering to texture to work. Oddly enough, the screen width and height actually made the quad close up so much as to blur it beyond distinction:

Once the width/height was set down to 2 (?!?), the quad appeared appropriately and allowed me to calculate a simple dot product for some grayscaling:

Now we get to some interesting effects!

Day 66: Crushing Failure

Today didn't work out so well for the water texture. What I thought would be a simple addition turned into a myriad set of complex steps that led me astray. I'll be pulling back a bit and focusing directly on render-to-texture in DirectX; hopefully I can get some post-processing effects up and running.

As for capstone, the new bridge effect is in! I had to tweak some things such as which specific world coordinate (Y, not X) to pan, but it works all well now. I also had to increase the speed of panning, which I used by multiplying the time value and the texture for panning by a set number for speed. Changing the period of the time input changed how long it would take the function to repeat, but this would only interrupt the pan at small periods. With the new multiplication, one can quickly pan the function across independently of the period.

Day 65: Rabbit Watering Hole

Phew, this water code is definitely more in-depth and myriad than a small add-in. Seems as if there has to be a separate shader created for reflection/refractions when rendering to texture, which takes into account a clipping plane.

Other than that busy work, capstone was mainly integration of things such as a totem pole for large state change cube pillars (taking the cube, making it invisible, and making a stand-in mesh around the pieces) and matinee skipping that requires a held input. It required some level blueprinting, but I got a similar thing to work for the cinematic.

Man, busy-work can definitely be unrewarding in terms of visuals. Here's a totem pole for your thoughts!

Day 64: Refractory

Phew, today's taken a lot out of me. I'm not sure, but I'm quite tired from the day. Regardless, I managed some more fixes, including segments where cinematic bridges wouldn't form (not setting a self destruct timer instead of setting the time to zero) and properly setting the fullscreen on the build to not become windowed (resolution setting function instead of fullscreen toggle).

As for the water, I'm managing. I created the render texture class to capture a render target, but the setup along with the water shading and texture is going to be awhile.

Day 63: Cinematory

Today was another big build day, but I did manage to add some more content! This came in the form of cinematics; I took an animation sequence (think of a motion graphic) and added it to the game in the form of cinematic levels. Some things got tricky, like setting specularity to zero on textures since the default wasn't zero and making sure the full-screen command was only called once, but it managed to go through well:

As for terrain work, I've decided to tackle water for something big enough to wrap it up. Hopefully just calculating refraction won't be too expensive!

Day 62: Jumpin' Jumpin'

What does one do with the terrain project when there's nothing better to do? Jump!

I also managed some more optimizations; since I realized a lot of the data in some of the constant buffers is constant across all applications, I could essentially save the cost of mapping/unmapping data buffers with data every frame in the Skydome and Terrain values.

But honestly, what is left to do? Water? Water perhaps!

I also worked on some design fixes and preventing crashes in the capstone project, namely that the Warp room had some very strange crashing based on dissolving cubes in and out of view. I managed to stick respawning and dissolving properly based on volumes and making sure to destroy objects and remove them if they were really dissolving; that was something that the original component did not have.

Day 61: Fifteen Builds

Phew! Today was a busy day in preparing the builds for tomorrow's playtest. Turns out a whole lot of things like looping audio, flipping platforms, and glass that wasn't orange enough were fixed just in time.

As for the terrain, I managed some loading files for sky and texture data. Oddly enough, std::getline was a choice over fstream, but I had to be very careful not to leave any space from the colon to the texture file.

Now I can control plenty! I may even put in a jump when I get the chance. Basic physics might be something manageable.

For now, skies and clouds can be a variety of values!

Day 60: The Terrifying Shipping Build

There are some things unexplained by science and human reason...and those things are crashes in the Shipping Build.

Oddly enough, this expanded far enough out to the Development Build. During the spawning of enemies in the project, there was no specific check for whether the class was available (i.e. existed at that point) for spawning, leading to a crash when the spawner was activated. Oddly enough, the editor also claimed some odd ownership over the build even after it was packaged; closing the editor and then running fixed the issue.

The build also doesn't allow a full-screen settings style file like in DefaultGame.ini or DefaultEngine.ini; the system requires I set console commands in the GameModes upon beginning play, or setting the user settings through code. Also weird.

As for not weird things, I did a little more progress on the terrain project; turns out that by loading data once in the constant buffers, I had no need to set their parameters frame-by-frame like in the LightBuffer. Yet another optimization!

Next up? The sky could use some data driving, which may lead to further optimization.

Day 59: Constantly Buffer

Today was a day to kickstart more data-driving. I learned some interesting rules about HLSL constant buffer structure, mainly the fact that it defaults to 16-byte aligned. That way, I couldn't do a struct with one XMFLOAT2 value and four floats without some padding.

However, we can now control some more in depth parts of the terrain, including heights and levels of depth:

As for capstone, I noted an odd thing during the Shipping build - setting a Material Instance Dynamic as a parameter for calculating during program begins actually doesn't register during the build, resulting in some nasty crashes. Setting the parameter to an editable UMaterial value fixed it up, but it still reminds me how things can work in the editor and Dev builds but not work at all in Shipping.

Day 58: Pressing Buttons

Welp, with most of the terrain work being more than complete, I've gotten back to data-driven and input application. Now we can turn things such as outlining, wireframing, and height locking on and off at will and designate slope values for the tiled noise:

As for capstone, the build functions alright; I noticed, however, that the Shipping build crashes with debug text. Very odd observation.

Day 57: The Trees Move With Us

Managed a bit more work, even as the ideas are rolling thin for the terrain. Turns out the billboards didn't actually move with the terrain as it streamed in, so I figured out a way for the billboards to quickly shift over. Whenever the terrain shifts to another central terrain, I do a quick check on all the billboard instances. If the billboard instances are not on any terrain, it shifts toward the direction that the central terrain moved to.

I also found that with the slight gap of terrain that is covered up but still shows up when moving quads, I had to add a slight additional tolerance so the trees would still remain in the ground. Otherwise, it would've been expensive height checking and re-adjustment. I am quite thankful for tiled terrain:

As for capstone work, it was mainly composed of refactoring; there's a lot of old classes we aren't using anymore. I'm also doing some investigative work on why metrics are picking up low times for area completion in specific areas. Seems as if there are moments where the data picks up sessions with absolutely no time spent in them, so I'll leave those out of the equation.

Day 56: Spreading a Little Thin

Today was mainly a day to..well...not sure. I'm fairly certain I'm hitting the limits of technical coolness for this terrain here. I managed to do a pretty nice optimization; it seems that by only checking if the player is in a certain terrain (instead of checking a bunch of cells, treating the terrain as a single cell), I could get the frame rate up to snuff with a 3x3 of cells continuously tiling into the horizon:

I also spread out the clusters of billboards so they'd cover the whole 3x3 set instead, but nothing yet on them following the player.

As for capstone, I did manage to do some bits and pieces for fixes. I feel like I'm doing plenty of design (or correcting design) work instead of programming, but somebody's gotta do em'.

Day 55: Feel the Infinite

For capstone, today was mainly just a set of content fixes. It's almost terrifying to look away for a few days and come back to a multitude of lighting, build, and import errors. All fixed up, though!

The exciting part was the terrain; by hooking up a temporary vector swap and height check, I can effectively "load" in pieces of terrain by consistently centralizing the surrounding terrain over a current central terrain that the player is on:

Frame rate's a bit chuggy with all 9 terrain pieces, but it goes on infinitely! Now I just gotta figure out a good way to optimize all this...

Day 54: The Answer

Woo! It looks like the issue with the terrain was due to the cells cutting off the last parts of the vertices of the model data. Problem is, even the terrain calculations cut off the last bit. What to do? Even with the exact coordinates, the data always misses one quad of terrain.

However! What if the original sampling of positions goes one quad over, using the first quad as a terrain wrap?

Now we can render gigantic, if not infinite sections!

Well, the idea is to take a section of terrain and place it in front of the other section for a so-called infiniscape. Let's see how that goes!

Day 53: The Problem

Blargh, I'm so hungry. I've been trying to crack this here nut, but the bug's deeper than I thought.

When I was using regular noise with turbulence, I didn't notice that the cells weren't actually covering the entire terrain. Gasp! Where are these extra bits leaving off?

Seems as if my cell calculation process actually doesn't handle the last parts at the end, meaning that I must figure out how to get the vertices exactly on spot to cover the entire mesh.

There's no way to tile terrain at this rate!

Day 52: The Fourth Dimension

Whoooo! Turns out that I needed to completely rethink (i.e. redo) the noise that I did; turns out that only a special type of noise can be tiled in order to create what I seek.

4D Simplex Noise! Turns out that Perlin noise has a much higher computational complexity (2^n?!?!) at higher dimensions compared to Simplex (n^2). By skewing the coordinates (4 of them!), finding the specific simplex (a sequence of mutually orthogonal edges), and hashed in a pseudo-random gradient direction.

Did that sound ridiculously complex? Yes, yes it was.

But now we have noise that can be tiled (using the power of two circles orthogonal in 4D space):

Man, don't that just look simple. It tiles, so that's important; I'll be working on seeing if I can use turbulence or something to get it looking more natural.

As for capstone, we've got more pretty things integrated in! The podiums needed a bit of work, including a set of pieces that get moved by gravity in the podium without actually falling to the ground and bridges spawning in the correct place, but it all ended up alright! We also have a new platform that required fortunately little material work.

Let's get that simplex noise less simple!

Day 51: Expansion Pack

Time for some more data-driven evidence! Now we can easily switch out algorithms and values on the fly, allowing no compilation to go from this:

To this:

What's the real aim today, though? Making more than one terrain. If you thought this terrain took several weeks to manage, this one'll be a doozy. I'm making it so that multiple terrain object can be created as we speak. Right now the terrain will share one neighbor, but if I can blend both to look natural then we have an advantage:

Note - the displaced terrain can only be shown one at a time. Working on getting both versions!

Day 50: Data-Driven

Today was a fairly successful build for the capstone project, save for an awful crash that appeared during the podium trying to respawn gravity wells when the podiums were being unloaded. The fix? Disable their timers for a few seconds and restart when the old ones were destroyed. Otherwise we're all set!

As for the big stuff, the programming project now has an initialization file! A .ini file, to be specific. Now the terrain can be fully controllable from a text file. Won't we want something a little more responsive? For visual effects that don't require a terrain rebuild, that would definitely help with some UI. The next step?

We'll see!

Day 49: Profiling

It's quite odd to keep looking for optimizations after the big ones roll through. Cell culling and dynamic levels of detail (distance mapping and tessellation) are big ones, but how about the code that lies in between? Why not break when detecting cells for heightmap movement? Why are there still post-increments?

One of the bigger optimizations, though, is the setting of texture resources. Since most shaders only use two textures at a time, the larger terrain shader would only have to set its textures once (3-9, to be exact).

As for capstone? Just some bugfixing here and there; oddly enough, multiple bridges could be used on an insect and that character could aim while in a gravity well. Fixed those up!

What next? I can still see if I can optimize more...

Day 48: Perturbing

From the previous post, I managed translation with two bitmap textures to give the impression of a cloudy environment. Did these look nice? Kinda, but what about SPECTACULAR?

In the next attempt, I used a cloud texture and a noise texture to perturb the cloud's texture coordinates. Essentially one would sample the perturbing texture, multiply it by a scale value and add the current texture translation. The effect is much more interesting than two bitmap cloud textures.

However, why was a large dome of colored sky blocking off the cloud sheet? It may be risky, but I extended the far plane to get some pretty good cloudiness:

After this lovely sidetrack, I should be able to get back to profiling. It'll be a lot more convincing if I don't have my computer plugged in. 

Day 47: Cloudy Skies

For capstone, I mainly worked on getting bugs fixed up (the big ones). Enemies not spawning when they should? Fixed it! Trick Elevator disrupting warp recalls? No problem! Files too long to build? Got it!

What's the interesting part? Cloud rendering! For this application, I took a regular plane (no .obj file required) and procedurally pulled down the corners for a curved plane. After applying two translating textures to the scene (additively blended to the skydome), we've got cloudy skies!

Whoa, what? Looks like I needed to stretch out the plane a bit.

There we go! Now to perturb those textures.