Just about have the new Orion Engine D3D11 driver module finished. Testing should begin soon. I still want to emulate some of the legacy Fixed-Function Pipeline using shaders. I think the generic lighting routines are still useful. Also, FFP processing lends itself to being easily scripted.
Once all of this is working and ready to release, I’ll likely begin work on a D3D12 driver module. Note that the D3D9 driver still works with the engine and can be used to target older operating systems. There will probably never be a D3D10 driver, as it never gained much traction anyway.
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!