Day 96: 1000 Useless Things

Phew. It seems there was plenty of clutter in our project this week; I mostly spent the day cleaning it up. Someone's got a bad habit of copying and disorganizing assets, unfortunately.

However! There was hope! I am now the "build master" as they say, so I'll be responsible for ensuring that the project can be built on a regular basis.

As for the programming project? We finally have sprites drawn to the screen! One sprite for now, but the global static ResourceManager loads shaders and textures fairly well, and the indexed drawing with the element buffer object works nicely:

What's next? Proper scaling and sprite-sheet rendering; those textures will probably come in a variety of frames.

As for neurofeedback? Not much was needed, but they did need a back-door entrance to the level, as they had forgotten to setup their menu with the proper sync channels.

Day 95: Lopsided

Today was another day for metering out tasks, but I got some fairly good progress on some high-priority requests from the producers. The first was to setup a color-fading for objects; I thought that I would have to use one of those janky Timeline objects, but I actually found out that using the elapsed time on the timer handles can do exactly the same thing (in a lerping perspective).

As for the big bug of the day?

Setting proper rotation for the player towards their levitating object was tricky and hilarious. Apparently when setting the actor rotation, the Y value of the rotator (pitch) translates to the Z rotation (yaw) of the character. Who knew?

And I also got more work done with the OpenGL sprite shading. Seems like I need to library link the SOIL modules next... for all builds and configurations...

Day 94: Sprite Renderer

Whew! Another long day. We had our big presentation today; the faculty seemed to enjoy our progress on the metrics so-far, and I fixed up a few bugs involving the fog not killing after loading the BossColosseum. After having to deal with child actors, I just attached it manually and used one instance. I also fixed the levitation shot time-out issue; it appears that when I restarted timeouts on weightless and time dilation cancellations, it also cancelled the levitation shot destroy timeout. Looks like cancelling specific timers is key.

As for Gamelab, I didn't have too much in the way of work (thankfully), just reorganizing the placement of the particle systems properly.

The big thing was beginning the OpenGL portion of the programming project. For the end of the semester, eight programmers are getting together to produce a simple game. Due to my previous knowledge with graphics APIs and my reintroduction to OpenGL, I feel most suited to the job. Stay tuned for 2D sprite rendering!

Day 93: Deadlock

Phew! Today was a tough coming back with a homework assignment that I didn't know was still going to be assigned.

Looks like asynchronous event handling was still on the schedule, though. I've already had experience with asynchronous programming with std::async and futures, but actually coming up with a solution for testing certain conditions was tougher than ever, mainly due to the fact that I'm not sure what the professor considers an applicable solution.

I decided to just go with a timeout on the event to stop thread deadlock and/or starvation. The idea is to do a try_lock_for, then continue onward with optional completion. I first went with timed_mutex objects, but a lock_guard was recommended, or an object that treats mutex locking/unlocking like a shared_ptr handles memory allocation and deletion. THEN I had to handle multiple locks of the same thread, as usual timed_mutex objects would not allow it.

The key? recursive_timed_mutex objects! They're actually a thing.

That mainly took up my time for today, but I think I get back to working on other more important things.

Day 92: Incoming Death Cube

Today wraps up capstone work for the week! Managed to fit the levitation shot cube with the enemy to fire at and damage the player. The only tricky part was that while the object was attached to the enemy, it didn't move as if it was attached to it. I had to constrain the location until the thing was ready to fire.

So far, the object keeps its state change properties and goes toward a player location until something is hit. That requires a slight vertical offset to make sure it doesn't skid the floor:

As for neurofeedback, I implemented the pause function that resolves with EEGer's pause function fairly well! I'm just discovering that yet another script doesn't obey the laws of deltaTime - the camera shake script.

And with that... I also got to brush up on some OpenGL again in preparation for advanced light shading lessons! Today was just a review on texture binding and mapping, including the use of element buffer objects for indexed vertices and texture mixing:

If you look closely, the symbols are eerily placed over the moon symbol texture.

Day 91: Levitation Shot

The title for today is fairly normal, as today was a fairly normal day.

Apart from some problems with source control today, I started working on the levitation shot for the flier. The shot is a generic state change object, but hurts the player on first contact and scales in and out of existence, much like the gravity well. The shot is ready to attach and use, so I may use it in a similar way to the scattershot that is currently implemented.

Oh yeah! The flier now has an actual art body, which I ensured a smooth transition in terms of materials for shader programming:

So far the new mesh doesn't affect the programming in any way. Fantastic!

I also did a bit of neurofeedback work today, as we'll need a similar pause functionality like I had in the original HGame demo. The tricky part was the vector grid; it doesn't update with a scale with delta time, so I had to actually not enter the loop if the time scale was 0.

Day 90: Now Loading

Phew! Today went by so quickly that it's late!

Nonetheless, I made quite the good impression with my action assignment. Seems like the only thing that I was missing was caching the actual Actions datum, so I made sure to do the same for Reactions since I was storing them in a similar manner.

As for capstone? The loading screen was definitely tricky, but I finally figured out how to disable character input and gravity (so they wouldn't fall to their doom) until the preloader Level Loader objects were finished loading. The trickiest part was to not disable these functions if there were only non-preloading Level Loaders or no Level Loaders at all.

Behold! A loading screen placeholder!

We also have some good feedback from our playtesting session that we can work on tomorrow! Like something that's broken and fixable!