Finally finished working on this two-gripper robot. He is one of three in a machine that we recently programmed. I used some game AI on him, lol. He is pretty smart. The customer was pretty impressed.
Ok, so robots are fun to program. However, I’d rather be working on the Orion Engine right now! I do have some time-off coming up. I’m looking forward to digging into the engine code again!
I’ve been pretty busy at work lately, which has hindered my development on the engine some. However, I’m still pushing forward!
The plug-in system (used by the Orion Engine SDK, Orion Script, Orion Genesis, Been There Game, etc.) has been updated. The loader code is more robust now, and better handles invalid/outdated modules. There was a bug where an invalid module that was loaded would cause the application to give a warning and exit without the option to continue.
I’ve also been working on some of the tool applications. I fixed a bug in the OrionResultLookup application. Hexadecimal result strings were not always being properly converted to a signed result code. Thus, not all error codes could be successfully looked up. I also added an option where you can do a reverse lookup, i.e. select a result code such as “OE_S_OK” and the description, value, etc. will be displayed.
The monitor I use for my dev machine (a 52″ LCD Samsung T.V. LOL) started acting up the other day. It wouldn’t turn on, the standby relay just kept clicking. I can’t let this get in the way of development! It turns out, this is a common problem with my particular model of television. After a brief inspection, I found four electrolytic capacitors on the power supply board that had swollen up and leaked their electrolyte. No problem. I found suitable replacements for less than a dollar! Soldered them in and voilà! It works again, and still has a killer picture!
I spent a lot of time trying to figure out why I couldn’t export mesh files with the new 64-bit UNICODE version of the 3ds Max Orion Engine exporter. All of the vertices were coming out all zeros! I thought for sure it was a problem with the recent 64-bit conversion. So, I’ve been chasing around pointers and checking data type sizes, etc.
Well, I finally stepped through the HUGE exporter routine and discovered that the problem was with an attribute sort optimization. In fact the debugger stepped me right up to the very line of code I was working on when I had to stop working on the engine! I remember that small detail now, LOL. That’s why the exporter wasn’t working! It was just hitting some unfinished code is all. By disabling that particular optimization for now, everything seems to be working great again!
I’ve been working on a glitch in the engine that caused the root level bounding volume not to be created, if the node didn’t have any vertices. When merging the bounding volumes in a hierarchy, the top-level node should represent the entire object.
I decided to split the current game databases into two separate servers. I want to make sure we have great performance with all of the constant data that the game servers will be generating.
I’ve also been documenting the network topology that I currently have implemented. It’s a pretty interesting setup that I believe will work quite well. I like the way more servers can be easily added, as demand increases.
I’m going to continue working on the code for the servers this weekend. I want to get my multi-threading ideas in place before I actually bring the game back online. This, along with all the new re-purposed server hardware I’ve been collecting, should make the application run very smooth!
I’ve been going through my notes on the engine this week. There were many little small issues that I was able to mark off the list! The code is running pretty nice. Things are certainly headed in the right direction.
Fixed an issue with the Memory Manager when running on a 64-bit processor. I thought the problem was with some static variables being de-allocated before trying to access them on program exit. You see, this code is one of the last things to run on program exit in a debug build; that way we can report any memory leaks, etc. Turns out I spent a lot of time looking in the wrong place for the problem. The problem ended up being a string that was not initialized with a terminating character. Lol. The 32-bit string functions didn’t care, but the 64-bit versions sure did. Definitely not where I thought I would find the problem. So happy that this issue can be marked off the list now!
I also made the CPUID class in the system driver compatible with 64-bit. This code is a lot cleaner now, and the interface is more generic. I removed the inline x86 ASM code, in favor of the intrinsic __cpuid() and __cpuidex() functions.
My Team Foundation Server has been online for a few weeks now. However, I wasn’t ready to put the source code under revision control just yet. I’ve been doing a lot of restructuring and refactoring of the code base that I wanted to finish first. It could have gotten really messy, very quickly. Now that I’m finished with the changes, all of the solutions and projects have been added to source control. It was kind of a pain to get everything where I wanted it to be. There was a little bit of a learning curve. The engine has been under several different source control packages over the years, such as the old Visual SourceSafe tool. However, they just seem to keep getting more and more complicated! That’s what happens when they just keep on adding more and more functionality to the software!
Finally have everything updated and running in 64-bit. I ran into some rather interesting scenarios where what worked in 32-bit, didn’t fly at all in 64-bit. Anyway, it’s too hard and boring to explain here (lol). The good thing is, all of the fixes that I came up with actually still work with Win32/x86. So, I didn’t have to scatter a bunch of conditional compilation logic throughout the code. Actually, all in all we did a pretty good job of writing code that was ready for the 64-bit transition.
OK, so this should have been done years ago. But this was a major undertaking, because the Orion Engine codebase is huge! Heck, just Orion Script alone is a pretty large SDK itself. Orion Genesis is starting to become pretty deep too.
Oh yeah, I finally found my texture library on an old server/computer that was stored in the basement. I’m pretty stoked. Because I spent many years putting that library together, mostly from photos that I had taken over the years. I’ve got some pretty nice tiles in there!
Well, I got the engine SDK, and all of the tools and applications running again under Visual Studio 2017. Now, I’m trying to convert everything from the older Win32 (x86) architecture, over to the Win64 (x64) architecture. Actually, I’m making it so you can build either 32-bit and/or 64-bit Windows applications. All of the MDK drivers now have 64-bit versions as well. All of the codecs (jpeg, tiff, png, exr, zlib, etc.) are the latest versions and successfully build as 64-bit. The 3ds Max exporter is fully 64-bit UNICODE now, built against the 2017 Max SDK.
I spent the whole weekend updating the SDK and the MDK. Now I just need to update all of the Been There servers and applications to 64-bit. I’ll need some rest soon too, lol. All of this upgrading has my head spinning!
I have several computers ready to be servers for the game. Now I’m upgrading all of the projects that make up the Orion Engine SDK libraries and applications to Visual Studio 2017. I knew there would be some minor changes. Actually, the new C++ compiler is picking up some bugs that previous compilers didn’t even notice. It’s all good. I’m working out some DirectX issues, then all should be well. I need to give some deep thought as to which DirectX version I should create a driver for next, and how it will effect the current engine structure moving forward.