I needed a break from WinROTT and Direct3D development tonight, so I worked some on modernizing some routines in DCDFlib. I am about 50% complete with the removal of goto statements and labels. I had forgotten how painstaking the testing process is when making changes to the C++ ala FORTRAN translated code.

My hat is off to the original developers of this library. They really did a great job with this code. I am also ecstatic that it works so well in a /clr:pure or /clr:safe environment. It says a lot about the quality of the original native code. I hope to have a new release online after Christmas. (I didn't realize it had been over a month since I had looked at the library code. )

I am about to shutdown my evening work for a week and do nothing but shoot skeet with my son and help my daughter with her horse. It's time to have fun with the kids. There won't be too many years when all of my family can get together again. I already see my nieces and nephews spreading to the ends of the earth with their own new jobs and families. It's rare for the entire family to have everyone in town anymore.

I spent the evening studying the modexlib and tracing code execution paths. I need to understand how WinROTT is addressing video memory so that I can begin the translation to Direct3D 9. The learning curve is steep. I haven't looked at video memory layouts in 15 years and I have no recollection of ModeX VGA modes.

I am working on the idea that WinROTT will render to a texture which can then be bit blitted to video memory. I've got a rendering framework put together from several examples in the Direct3D 9 SDK, but the physical format WinROTT is using for video buffers is very different from the format needed for a texture.

At the moment, the task is well defined:

1. Learn Direct3D 9
2. Understand how WinROTT is addressing video memory (i.e. how is it drawing graphics?)
3. Translate the existing WinROTT video routines to something Direct3D 9 can understand

I'm also still in the process of performing code cleanup and modernization. I'm working on some aspects of the code that can utilize threading to improve performance.

I started on a project to move WinROTT to Direct 3D from DirectDraw. I soon realized I had very little idea how WinROTT was drawing it's images. (WinROTT uses DirectDraw, modexlib and rt_vid to handle update of the video buffers and image rendering.) I managed a simple upgrade to DirectDraw 7 interfaces, but I'll have to learn how WinROTT is assembling its video images. I think WinROTT is using ModeX, which will mean a fair amount of work rearranging the video buffer to work with Direct 3D.

I also started a review of WinROTT data structures, with the intention of consolidating the use of byte, short, int and long data types. I'll be limited on the types of data structures I can use for disk storage in order to be able to read old ROT game files. ROTT was written to compile with C, not C++ compilers. I doubt the authors realized how much data was being exchanged between 32 bit and 16 bit numbers and the performance hit you take when converting.

Anyway, it's an interesting problem and I am probably going to learn a lot more about Direct 3D that I wanted to know. I'll try to have a release for this weekend with the updated direct draw code.

Another update, with more code clean up and a couple of bug fixes. I've removed most of the byte ordering code. It wasn't necessary. I've also removed some "null" functions that performed no useful function. Progress is incremental, but significant in this release.

There is a new release of WinROTT. Lots of changes with data declarations. Files are fairly well lined up with a header and implementation file. I've managed to remove all extern declarations from all .cpp files. Performance is enhanced in some sections of the code.

This release will allow me to move forward with code modernization and expanded network play.