Day 22: My Brain is Hashed

Today will be a short post, as I have been quite busy these past couple of days and need some sleep.

Phew! What an assignment this has turned out to be. I've been implementing a hashmap and both learned some interesting things, ran into some issues, and managed partial success.

Partial? Yes, unfortunately, I've managed hash functors for all but one of the specified key values. For some odd reason, the user-defined object classes give compiler errors when I try to make hash functors out of them. Pointers, integers, characters, and strings give no issue, but dare I use a Foo? The compiler sure doesn't think so.

I've also learned that due to allocation costs, it's actually quite permissible to store an iterator inside an iterator's implementation as a data member. Who knew? Especially since it's an iterator to a linked list.

This also leads to some odd implications that I don't get in the other containers but I do in this one. For iteration, the values are unordered and not necessarily next to each other, so I have to quickly look through each and every bucket and iterate through each list to manage it. Sounds like a bit of extra busywork, but it's the only way if the data's not even contiguous, let alone ordered. Luckily enough the hashing's lightning fast by comparison.

What's next? 1200 more lines of test code...

Day 20: Magical Ball of Targeting +2

Phew! Managed to overhaul the master projectile target design for something that is at the least unique, if not more than suitable to the task. After fixing a bug that imposed too much gravity onto the projectile (the arrow acts as if it has no gravity in the beginning, as to make the shot straighter for the player), the arrow now hits where it needs to go.

However, how does one line it up with the screen space? Can one line it up with the screen space? Instead, I opted for a world space targeting reticle that snaps to the area for firing. This creates a more immersive way to look at targeting:

As for the trailing line, that helps map the exact trajectory of the arrow. Much like a smoke trail, the player can now feasibly trace the arrow to its target.

What's the catch? Well, this arrow targets a lot of things, including unnecessary things like actual arrows and gravity fields. This means a bit of work to do...

Day 19: Late Night, Come Home

As for work today, the stalactite still eludes me. Such mysteries of physics interaction! It's like I have to disable physics once the stalactite hits the ground. Luckily, the event of being caught under the stalactite successfully constantly pushes the main character out of the way. The tricky part of that one was creating an extra array to remove pieces of an array during iteration. During the process, one can only inspect (not change) parts of a container, so an extra container containing the to-be-removed pieces needed to be taken out.

As for programming work today, the stack cometh! Fortunately, the stack was only an adaptor. In that case, the vector was more than suitable to fit a stack's needs. As for unnecessary implementation, that always comes with a cost for using a complex container to mimic a simple one. Luckily, it's not too much, dealing with the already simple implementation of a vector.

What's next? Hashmaps!

Day 18: Crushing Defeat? More like Crowning Victory

Thank goodness! After looking in the same particle distribution parameter that solved the Size problem, I managed to find the issue that had been nagging at me since the Ley Blocker!

Turns out the actual Target (the beam particle system has two nodes for the start and end location of the beam, Target being the latter) location was a parameter that I could set. The actor parameter looked as if it overrode the line, but could not work with actors that weren't already in the scene. As for the particle distribution parameter, I used that instead and now have a beam that can be set with location!

As for the size parameter, I could not figure out a decent way to manage size of particles programmatically. As for Size By Life as a particle system node, I could combine that with proper timing of activation and deactivation of nodes to get a nice firing system that can be repeated and attached to actors at will:

As for the stalactites, I managed a quick and dirty implementation before I left work today, in which the stalactite consistently launches characters outside of its vicinity while they are in a set range. A bit of tweaking tomorrow should help finalize the stalactites as a threat.

Day 17: Crushing Defeat, Hidden Fix

Today was a day for a bit of a quick fix on the vector implementation. After a bit of clarification, it was necessary to only call constructors on the data that was up to the size, not the capacity. While saving a bit of time on calling constructors with reserve calls, this also meant that Push Back had to call the constructor instead, each time size was increased.

As for capstone work today, I attempted my darndest to get a procedural actor to act as an instance parameter, but no dice. It's quite the peculiar bug in that the Particle System doesn't recognize the instance location of both child actors nor dummy actors created in the scene. Scene-specific actor references will have to do.

On the bright side, the size of the particle system is an applicable instance parameter for laser expansion! The tricky part was figuring out the difference between modules that could be converted to parameters and those who took a "parameter" as a data type. Twas a bit of a jumble when I was searching today.

What next? The size increase is a bit wonky; the leftover particles still remain present after the size change, making a less-than-smooth change.

Day 16: Black Laser And That Slow Southern Style

Phew! Today marked the end of the vector implementation. The tricky part about this was that our professor required placement new when initializing a set of objects in the vector. This ensures that one can call something other than the default constructor when one allocates a new set of data.

Of course, this means directly calling destructors and calling mallocs and frees like it was C all over again. Ugh. UUUUUGH.

As for capstone progress, I looked into a few bugs surrounding the arrow and the StateChangeCube. The first wasn't anything much, as the arrow only looked as if it was directly hitting the object; a slow ricochet means that the arrow hit the ground first and already wasted its state-changing energy.

The actual bug went to the warp effect; when being pulled across the ground, the object had a chance to sweep into the ground (even though the vector may be fully horizontal), so I had to use the implementation to move the object up before warping it.

As for the next implementation, I'm still trying to figure out a good way to implement the ArmorLaser without having to create a new actor in the scene. The laser implements similarly to the LeyNode, which I couldn't get around but thankfully there are few enough nodes in the scene.

As for an entire league of pieces of armor on the boss...

Day 15: Stronger Than a Stalactite

Good news! Nearly finished up with the Vector implementation; after (1100 lines of testing code), the class is sure to work for all branches of code.

Problem is, I'm not sure what the required implementation of a certain method are. The At method, which originally throws an exception in the STL version if it's above max size, is now required by assignment to only throw if above max capacity. Does this mean we have to initialize all values past size with a default empty value? Hm.

As for capstone, the simplest thing is giving me a helluva time. The Stalactites that are just supposed to drop down and hit the player actually cannot push the character out of the way.

The way physics bodies work for the main character (any character, really) push all physics bodies out of the way with extreme force if the body lands on top of the character.

If there were any tips on depenetrating the character from this mess, I'm all ears.