Can’t believe it’s already 2022. How time flies. Hope everyone has a great year!
I’m still learning Direct3D 11, It’s quite a bit different than the DirectX 9 API. Anyway, I do hope to have the new video driver working soon. I’ve been busy with other things lately, but I am finally ready to dig in again. I miss working on the game! So, stay posted, a new demo phase should start again soon.
Finally decided it was time to update the Direct3D video driver currently used by Orion Engine. It seems DirectX9 support in Windows 10 is taking a back seat. Apps no longer run exclusively in full-screen mode, they are now just a window without a border… sharing resources with everything else. There is something else going on that I can’t quite put my finger on, but it totally wrecks the performance of my game. I really hope I can get this new driver for the client up and running soon!
While working on cleaning up the avatar movement messages, I decided to move the rendering and scene updates to their own threads. This certainly smooths things out quite a lot! For one thing, input device updates don’t get starved whenever the rendering slows down. There are a few concurrency issues that I still need to work work out, however.
I’m keeping the game offline until I finally reconstruct everything that I have deconstructed!
I’ve been re-writing the game’s avatar movement code in the client and the server. I want to smooth things out once and for all! It’s finally time to retire the test code that has currently been in place for years. I’ve also been researching a bug that can cause horrible render lag while running in full screen. I hope to resume testing again soon!
Finally! Everything is coming together in the game to the point where I can finally work on the combat system. Now that the code for the friendly NPCs is progressing well, I’m starting to work out all of the details for the enemy NPC. It moves through the pipeline a little differently than the other avatars. I’ve been very pleased this week with my progress, because most of the required code is in place now! Although incomplete, I’m leaving in the proper hooks, so that I can also later add “player killer” features (i.e. un-friendly players).
Another new addition to Been There is the skill system. Experience points (XP) can now be applied towards the player’s available attributes. Skills can also be opened up (at a cost, of course) for further training.
The Orion Engine continues to live, and it sure is rocking and rolling!
Finally got around to adding some NPCs into the game. Currently you can chat with them. Soon, they will be used to start quests, and to provide rewards, etc. It’s very cool that I have this working, since enemies will derive from this code. So, this means I’m one step closer to getting the combat system up and running!
I decided to re-write the mesh load and save routines used by the engine. They were previously using a recursive algorithm, which quickly caused the stack to fill up on larger models with deep hierarchies. Running into a stack overflow situation is simply not acceptable.
I needed to write the objects to the mesh file in depth-first order, similar to the original recursive implementation. Now I see why people like recursive functions, it was very difficult to refactor this into an iterative while loop! I basically had to implement my own stack, that allocates from the heap instead of the limited call stack. Also, keeping track of the nodes that have been visited while unwinding the stack is key.
I’ve been hard at work implementing new intersection tests, and dealing with collision and response algorithms. Pretty tough stuff to make work correctly and smoothly under all circumstances!
I’m basically breaking up an area into distinct height levels, then doing 2D intersection tests between a circle (the player) and a line segment (i.e. a wall) based on your current level. In 3D this is equivalent to an intersection test between a cylinder and a plane. 2D just saves us a few CPU clock cycles, which are always very valuable!
Turns out I wasn’t extracting scaling properly in my 3ds Max exporter plug-in. For one thing, if the local transformation included any scaling, it could cause NAN problems to arise while converting the matrix rotations into quaternions for the keyframed animation system. So, I added new methods to the 3×3 and 4×4 homogeneous matrix template classes in the engine to properly decompose a matrix (without shearing) into individual translation, rotation and scaling values. This allowed me to properly export all of the animation data now.