Now the 2017.05.12 version has gone live, I can turn my attention and a large chunk of the engine to focusing on the DirectX 11 porting of the engine. Step one is to strip out the DX9 into something I can isolate, then step two is to run the engine with no graphics running at all, then the third step is to drop in the DirectX 11 functions slowly to build up the basic graphical elements again. The final step is to clean up the project and remove/replace any legacy stuff that does not sit well with the new engine.
15th May 2017
I start at the first step and my progress reports will be following my work through these four steps, but perhaps this first step is the most crucial as I need to ensure that 100% of the functionality is not affected so I can instantly switch back to DirectX 9 to continue compiles for smaller fixes and other additions as may be required in the months to come. The benefit then is that I can switch back over to DirectX 11 work on the latest build of the game engine half without maintaining two versions of the code, always a plus. The good news is that after 9 hours of slog (9am-6pm), all 28 modules have now had their DX9 code isolated, just leaving the main OBJECT module and the two projects for the Lightmapper and the Main Editor/Game. These I will tackle and likely complete on Tuesday, leaving me to then run a full battery of tests to make sure nothing broke in the process. Once we have this all compiling, the fun begins with running the game engine with no graphics engine and should afford me some time to further clean up the code and perform a little spring clean before proceeding to step three.
16th May 2017
If it was not nearly midnight and midweek I would be opening a bottle of Champaign now. Stage One is complete. All 30 modules of the engine have now been completely isolated from DirectX 9 files and can compile under its new DX11 flag. Phew! I would like to thank the song 'Chicken Attack' and their 10 Hour Army and the Japanese Yodeller Takeo Ischi who got me through a grueling number of hours to get through to this stage (yes, I have listened to Chicken Attack for over 10 hours and joined an elite club;
https://www.youtube.com/watch?v=dT9eI40RNoQ).
Stage Two begins on Wednesday when I step through a few thousand lines (slowly) and eradicate any functions from the engine that are no longer called or can be replaced with something more elegant. The objective is to be able to run the engine without graphics, get to the editor UI, then exit and gracefully leave with no memory leaks and a detailed log of failures (where the graphics calls are absent). This part is a little more fun as I will get the joy of cleaning up code that may have sat idle and unused for years, and prepare the 'site' for the introduction of the all-conquering DirectX 11 API. I did have the idea of creating additional abstractions in the engine to support multiple graphics APIs, but it would slow down development considerably, and there would be no immediate benefit. That said, the work being done now will make such a future effort MUCH easier. Now time for some supper!
17th May 2017
Spent a good deal of time stepping through and cleaning up redundancies, and have hit upon the idea of introducing 'a little' DX11 code into the process to accelerate the eventual work of porting everything. I can easily trick the engine to load 3D objects, but textures loading is pretty much tied to the graphics pipeline, so looks like Stage Two and Three are about to merge quite quickly. The objective is still to get to the main editor loop without any issues (all be it with no graphics rendering) but it also means some of the foundations will be in place when the actual rendering side starts, including a fully realized device context and DX11 image module, working. You probably won't get any nice visuals or code for some time, but hope this daily progress report will keep you in the know.
18th May 2017
First DX11 function went in today
The last time I dealt with a DirectX engine swap was when I did X10 with DirectX 10 back in 2009 and it reminded me how much the new API was simplified compared to DirectX 9 with its many separate interfaces to handle numerous functionality. I basically reduced three bulky functions into one rather simple effort, boding well for the future of this port. I dare say I will be returned to make the simple implementation more robust with the various required modes, but it's nice to benefit from an API that has had some thought given to the end user. As I finish my coding for the evening, I have now created a DirectX 11 device, swap chain and immediate context and also loaded in a texture. Small steps I agree, but significant and encouraging ones
22nd May 2017
Stage Two Complete! I have added enough DirectX 11 functionality to initialize the basics (device, context, swap chain, back-buffer views, depth buffer, loading textures, extracting raw texture data and the beginnings of creating and managing bitmap surfaces). This means I was able to run directly through to the main editor loop with no crashing or fudging of code
Naturally, the bits that make stuff you can see are missing, but it's a huge step to get to this point as it means I can start adding layers of functionality knowing that the engine compiles, runs and gets to the loop without a fuss. If any new stuff breaks that, I know which bit caused it - a pretty vital time-saving part of the process. Going to grab something to eat, maybe play a few hours of Far Cry 4, then get an early night so I can crack on with Tuesday which will probably see 'something on screen' rendered under DirectX 11. It might seem an extraordinary amount of work for 'something on screen' but it's being done in such a way that the core game engine does not need to be changed or affected, except for the graphics API swap-out. The benefit, in theory, is that nothing changes or breaks, and I don't spend the next four weeks chasing random issues caused by the shifting of core game code. Exciting times and I hope you are enjoying the daily blog of how a games/graphical engine is created (ported)
In other news, I have commissioned some work on getting FBX models imported into DirectX 11 and we now have a static untextured mesh loading and rendering. I know the current GameGuru importer does more than this, but this new code is being built with full support for animation and deep FBX features in mind so it's exciting to see this parallel development take shape for the time I can drop it into the engine overhaul progress.
23rd May 2017
Now begins the 'worse before it gets better' section of Stage Three which means making some harder decisions between remaining faithful to the DX9 architecture and cloning every line with DirectX 11 equivalents, or creating better DX11 code that fits with the best practices of the API. I plan to proceed carefully but have already made some decisions and progress in those directions. For example, instead of the game engine loading the shaders sporadically throughout the load process, they will all be loaded at the very start of the boot-up and referenced when needed. This was to accommodate the CreateInputLayout command of DirectX 11 which requires knowledge of the shader BEFORE you declare the data structure for manually created 3D objects. I could happily bore you with the technical trauma of the last ten hours, but to avoid making your eyes spin I will reduce it to the highlights. I can now load in a modified terrain shader as a Shader Model 5.0 HLSL file using the 'not included' Effects11 framework which duplicates the techniques and passes heavily used in the current engine. The next step is to create a global structure to store all my pre-emptively loaded shaders, then switch back to the original purpose which is to create what was once called a VertexDeclaration for the terrain geometry, and proceed to port each stage of the load, creation, setup and render steps to get something 'finally' on the screen. I've also had to shift around a lot of the back-end includes and libs to focus more on Windows 8.1 SDK which means more work waiting for me when I try to set the configuration back to compiling DirectX 9 version of the engine, but it makes sense to do so to give me a perfect side by side comparison for testing everything when we start to see renderings.
24th May 2017
You may know that with small companies, each person has to wear many hats, and today I wore my 'do-all-the-other-things-day' hat and although I filled up my eight-hour daily quota, finishing by writing a short 1000-word foreword for a forthcoming PDF introduction to our key game making brands, it transpired that I had about 20 minutes left from the day to actually do any DX11 code, so I spent the time going through some more emails and writing this text. I would have liked to report the event of getting something rendered to the screen, but that will have to be 'hopefully' my news for Thursday, and can only finish with a small piece of information that has been quizzed in the forums that the new FBX importer will be handling models with more than 22K polygons per mesh as we will be using 32 bit index buffers for the renderer. This news should also please those who have been wanting to import super high-resolution terrain meshes and entire levels built in a 3D modeler, though I cannot guarantee the performance of these monsters. In regards to the FBX and Characters, the models we are looking at only just exceed the 16-bit indices limit so they should not pose a performance issue. Also, Autodesk recently announced some changes to their Fuse/Maximo services, so definitely worth checking that news out too.
25th May 2017
Still no on-screen polygon, but plenty of work done today, specifically aimed at loading in all the engine shaders up-front, modifying the old shader/effects system to account for the new approach, updating the old-but-used fixed function functionality such as storing world, view and projection globals to something that can work in both DX9 and DX11 mode and finally got the InputLayout created and VertexBuffer filled, so we are inching closer to the state blocks, texture references, and the final DrawPrim calls
I now have my breakpoint at the "DrawObject" command, and ready for the last few chunks of DX11-ness, but the sun is shining and a BBQ is indicated, so I will put away my keyboard, eat some grub under the Welsh sun, and return in the evening to see if the last few steps are as simple and fun as I hope they will be. I am pleased to report the really nasty hard stuff is behind me, it's just a case of carefully bringing visual functionality on-line bit by bit, and I anticipate 'a few polygons' being rendered before the end of the week. I know a polygon doth not make a game, but the way I am doing the port means the visuals will come in thick and fast once the pipeline has been reestablished.
26th May 2017
Well, it's all in there. Every DirectX 11 function, called in order with good data, and the result, no polygons. I kind of half expected this. Partly because it's a bank holiday weekend here in the UK which means 3 days of sunshine and chilling, and my PC wants me stuck in a dark room solving digital riddles. Partly because I have been here before, and know the alarming series of steps that have to be 100% correct before anything shows up on screen. I can't use GPA as the 3D part is in a sub-executable the profiler cannot hook into, and the extra deep debug mode shows that all the commands called worked 100% successfully so no clues there. The kind of good news is that I can see the 'red' screen I cleared my back buffer with, so I know I am looking at DirectX11 back buffer, but for polygons, I am drawing a blank. Still, I am probably 98% there, so just need to figure out the one or two missing values or misquoted flags to get juicy polys to render, and then it's plain sailing! I do have a clue as I clock off for the evening though, in that I am creating my vertex buffers as dynamic so I can write to them after the creation step, but I suspect these dynamic buffers empty themselves almost immediately which might explain why no polygons have a chance to show up. With some more reading and patience, I think I can get the vertex data to stick to the buffers, and I have not entirely ruled out finding another profiler that can show me exactly what is working and what is missing, so I can make short work of this mystery. I would have liked to end the week with a polygon, but I guess the Gods of Technology have other ideas for me and my engine.
27th May 2017
Not happy with my failure to render on Friday, I had at it again today and presto, I have a polygon on the screen. It was such a relief to get the pipeline running that I stopped and posted this progress. I am going to quit while I am ahead and do some weekend jobs, but rest assured how I have one polygon I will chasing some more tomorrow, or later this evening, with a view to getting all the terrain polygons down, and with textures. I have posted a shot of my amazing new DirectX11 engine in the thread below
30th May 2017
With the bank holiday weekend out the way, I had a full Tuesday to sort out my backlog but was surprised to find it a smaller pile than usual. Given this, I was able to crack on with some good DirectX 11 work and I now have a polygon for each terrain mesh in the scene, the editor camera now works with the rendering sequence and I can get a texture through the system and onto the polygons (see shot below). The final few bits for this part involve cleaning up the code a little to remove any older commentary and get the actual terrain mesh data to replace the polygon placeholder. This will then put me in a position where I can raise and lower the terrain, rendered under DX11, but using a simplified shader. Once I am there, putting the original 'heavily modified' shader back should be a much simpler effort than if I had the other mysteries to deal with, which I have been solving slowly one by one. I say 'heavily' as I plan to do some housework on the shaders too, bringing them closer to a Shader Level 5.0 layout to make things easier to read. It's been a grind, and apart from feeling zonked, I am also pretty chuffed with the progress
31st May 2017
The terrain rendering code is now clean once more, running a more efficient DirectX11 approach and now rendering my single textured full terrain geometry, yay! Seems DirectX 11 removed the ability to present to a section of the client window so will need a new way to render nice text to the screen when in editor mode (the feature is in DirectX 11.1 but I hesitate to move off the base version from experience). The next step on Thursday will be to get the other textures in the shader, sort out the filtering and start work on porting the terrain shader over piece by piece. I have introduced the use of constant buffers in my re-implementation which means more aggressive shader modifications, but it means better performance and friendlier DirectX 11 coding, so it's definitely worth doing at this point in time. I have posted a screenshot of the latest build. Lee is happy this evening
1st June 2017
As I had plenty of terrain polygons to look at, I decided to backtrack and make sure the DirectX 9 variant still compiled, and after a few hours of putting things back where they should be, I can now run what I have in both DX9 and DX11 with no issues. This is especially important when comparing functionality side by side to ensure I don't waste hours hunting logic issues. Thanks to this approach, I was able to solve why I could not raise and lower my terrain, which now works a treat. I have also started the task of converting over the real terrain shader, and Shader Model 5.0 has enough changes to make the port a line by line affair, which means it will probably take longer but at least it will be clean and nice DirectX 11 shader code. Also managed to find some time to create a video to show a small change I have released to Steam which makes the Zombies (and any melee script users) to handle "Homing" into the player much better, so feel free to check that out on the YouTube channel. My plan on Friday is to work on a script for a new intro video for GameGuru and of course carry on with getting textures and painting working with the terrain shader, and hopefully get to the point of running around the terrain in test game
6th June 2017
This week is a meeting week, but I have managed to crack on with the terrain shader port and I now have all the textures created/loaded and bring sent to the terrain shader, and the terrain shader HLSL is now running under the LOWEST shader mode (to start with), and is just missing the highlighter cursor, grass highlighter and fog effect. Spent a good deal of time getting the back-end functionality to be able to create image textures, write to them dynamically (for terrain painting) and being temporarily baffled by the issue of RGBA vs BGRA when it comes to DirectX naming conventions (madness, but now learned). I have shared a shot below of the progress so far, and I anticipate the next one will show the terrain looking identical to the old functionality (my goal). Won't be posting a report on Wednesday but will have something tasty for you Thursday, hopefully completed terrain
8th June 2017
More foundation stuff working now, so my shader can get the traditional constant values from the engine which means I got to see my highlighter cursor for the first time, and also started bringing the various shader levels (techniques) coming online too, so really happy with the progress. I skirted the issue of shadows and depth buffers, but I want to revisit these to make sure I am doing the best approach for my new DirectX 11 pipeline. For example, this DirectX has the ability to view the render targets depth buffer resource as a 'source texture' which means I don't need to render out a separate depth buffer like the current engine does. You can imagine this means half as many draw calls, and well worth doing now, instead of blindly converting everything like for like. Shadows may also present a similar opportunity. For now, apart from the terrain vegmap texture being coloured with the wrong value (I see path instead of grass) and the lack of mipmapping, the visuals are now exactly those of DirectX 9 terrain editing
9th June 2017
I wanted to get to run around the terrain today and get 2D sprite layer rendering. I managed to get to the test game running around, but no visuals. I could hear my footfalls and jumping, but because the post process was on, and I had no 2D control panels to switch it off, all I saw was a red backdrop. So I plumbed into my next task of getting Sprites working, and of course DirectX 11 has removed the direct vertex data draw call (fixed function) so I am now writing a new one and of course, the data I have now may not be compatible with how the shader wants the data. Arg. I did, however, manage to reassemble all the stages so the sprite system could be rendering something, it's just floating about in 3D space right now, so I need to reproduce exactly how the fixed function DrawUP system worked as a shader, or update the way the data is created for a new shader transformation approach. Hopefully a little Google R&D over the weekend and I can put in the XYZRHW code for the vertex shader HLSL so I don't need to change the original sprite data sent to the sprite manager for rendering (the knock-on effects could be horrible). Despite my floating sprites, it's been a good week and I feel we'll see new things come online quite a bit next week. See end of thread for a post of my latest shot.
12th June 2017
I had a backlog of emails/support to attend, and a small script to write for the Fantasy Pack, but did have some quality hours to finish what I started on Friday which was getting the 2D sprites to render in the proper places, which they now do. It's a kind-a hack in that it does not entirely emulate the DrawPrimitiveUP call, and the lack of a Present 'rect' feature in DirectX 11 is forcing the editor view to be shrunk under the legacy system, but I now have my sprites back. I also had to switch off multi-camera rendering for now to avoid some flickering, but that's my task for Tuesday to find out 'why' the flicker was happening, and gradually introduce the camera renders as I need them (later in the pipeline). The big next step is to get the post process shader playing ball now so I can run around in test game and play with the sliders properly. The original plan was to emulate the post process effects exactly but the opportunity to make improvements would take the same time as slowly porting the old functionality to a newer DirectX 11 layer. Specifically, the opportunity is to swap in better depth of field, motion blur and shadows because of the way depth data can be read now, which all connects eventually to the post process shader(s). The biggest known gain, of course, is performance as it will no longer be necessary to render the depth layer separately, and a new shadow technique I have been introduced to would only require a single shadow map texture instead of four. Lots in the air, but it's the kind of advancements I think GameGuru needs if it's to have a place in the modern game making arena. For now, I have posted a shot of the sprites rendering in the editor on top of some painted terrain, but subsequent tests have shown the sprites need a little more coaxing before they can operate independently of the cameras, shaders and even the current depth stencil buffer.
13th June 2017
All is happy with my 2D world again. Having stripped out the 'world matrix hack', I finally figured out to use OrthoOffCenter projection for my 2D rendering, and also changed the graphics engine so it would dynamically resize the back buffer attached to the swap chain based on the editor client view size and the full screen test game, so no need for a special Present command to fit the back buffer in the editor view. The bottom line is that combined with other tweaks, all the 2D sprite renderings are back to normal, correct 1:1 pixel quality, responding to sprite alpha and diffuse color changes, rendering in exactly the right place and even the terrain cursor is now aligned correctly through putting things back as originally intended. I can now see my loading screens, tab tab views, text and numbers, sliders, pretty much anything 2D. A good day. The next step on Wednesday is post process shader as I still have a big red screen for the test game, with the initial goal to simply pipe the backbuffer as a resource through the new shader and onto the screen quad. From there I can decide how best to update my depth buffer and shadow handling. New shot posted below
14th June 2017
One step forward, half a frustrating step back. Progress has been made for sure, with more of the multi-camera system up and running, including a nice auto-fix of the camera clearing code so now I can see the normal grass texture when I start-up (thanks to the vegmap clearing with the correct color now). The current issue I find myself in, at 5PM BST, is the post process camera is not showing any polygons that my shader is attempting to write, which is currently nothing more than a glorified quad. All the right processes are in place, just no polygon quad (yet). I did, however, manage to get my terrain rendering in the test game and run around it (one of my personal milestones during the port). I am pretty sure it's something small, and silly, but my brain is too frazzled to leap on it, so it can wait until Thursday. As this little quad is also tied to the general 3D object manager, when this gets solved it will also bring with it pretty much every other standard model including sky, entities and markers so almost at the next cool milestone.
15th June 2017
And then two steps forward
I would say today is the biggest milestone to date with the main 3D object manager rendering a few polygons to the main scene, and then I went a little further and aligned it with the multiple camera system so now the main camera is being rendered to an image, which in turn is being rendered on a box, which sits happily in camera three which will eventually be used for the post process quad. By dinner time I was convinced the rest of the day would be banging my head against a wall, when suddenly a brain wave solved many things and forward I charged. The bottom line is that with the visibility of this latest batch of polygons, I now have the means to slowly restore the visual activity for post processing, entities, skies and pretty much anything else the 3D object pipeline used to handle. As it's 5PM I have decided to quit while I am ahead and go outside to what is left of the sun and do some wheelbarrowing. I have posted an unremarkable but very telling shot of my progress. Next week we should start to see all the graphics come back into the GameGuru universe, along with any ideas I might have to speed up the scene graph. It's strange to think the reward for all this will be a first version that is almost identical to the one I had before
20th June 2017
I can now load in levels and see all the entities rendered in the editor and test game
Oh yes! The object manager is happily rendering in all the major spots where stuff needs drawing, and my next task is to clean up the current code and achieve the fastest sequence of shader, resource and state changes to render everything I have so far. The shader load time is super fast, so I've already accelerated the time it takes to load GameGuru from scratch, now I need to see the performance gains in the test game itself to match it. Don't worry about any FPS scores you see for the time being, they are the worst of the worst right now, and it will only get better from here on in. I have posted my latest shot so you can see the latest progress, and I am confident to bring you reports of plenty more game performance quite soon!
21st June 2017
I gave myself the task of resolving the frame rate issue of the debug build, and ensuring a good fast path for rendering and state changes. I felt this was important to get in early so I could then keep the frame rate high as I re-introduce legacy visuals and eventually the new visuals. As you can see from my screenshot posted, I am pretty happy with 459 FPS to start the ball rolling. Of course, this will drop quite a bit when we add shadows, shader complexity and more textures to the pot, but it's a good place to start from! P.S. Another scorcher of a day here in the UK, managed not to melt!
22nd June 2017
No amazing shot today, just a monolog of grief I shall briefly share. When you get a bug that only shows up in release mode (player capsule falling through floor) but works fine in debug mode, it makes a mockery of 20+ years of coding experience. It never ceases to amaze me how often you can come across a truly original problem after so many many years doing this sort of thing. Same experience also tells me I will solve it, and feel REALLY good when I finally discover the truth, but right now it's like some kind of murder mystery and I am just moving onto Chapter Two. I have traced it to the release version not creating overlapped object in the physics engine so my player capsule can collide with it, and this is why it remains the question. It would be nice if every development question had a simple answer in this trade, but sometimes, and answer can take an undefinable amount of time to produce, to the fury of publishers and CEO's alike. The person who develops a system of coding that reveals the nature of a bug before the 'human' even determines the problem, to begin with, is going to control the universe! I resign myself to working this out the old fashioned way, but it would be nicer if I could just 'get it working' and move on. After all, physics has nothing to do with my graphics overhaul. The fates are against me today for sure! Let's hope Friday brings joy and 'a solution' to today's fruitless pursuit. NOTE: Does the guy who wrote Bullet Physics API (Erwin) still frequent our industry? I have no doubt he could debug, fix and optimize my entire physics system in about 10 minutes
Alas, such legends are forever out of the reach of us mortals.
23rd June 2017
It took me to 2AM on Saturday morning, but I managed to find and fix the issue. It was caused by my failure to convert the QuaternoinRotationAxis function, which consisted of an empty block of code that returned the garbage from a local stack variable. No wonder it worked in debug mode (which clears these to zero) and not in release (which leaves the original stack contents intact). Of course, before this simple fix, I had to basically step through the might of the Bullet Physics API from adding a collision object through to how it determines the actual collision. I must admit to being impressed with the way the various objects are organized in real-time to allow for very fast rejection of objects as they move through the physics scene. Anyhoo, despite the heavy rains today it's still pretty humid so I am going to get a cold glass of milk and retire to bed, thankful in the knowledge this horrid bug is well behind me now. Next week I can start the process of adding the remaining missing elements of markers, sky and water before bringing the real shaders back and of course tackling the changes I intend to make for the depth buffer handling and shadows.
26th June 2017
We now have markers and skies
I got widget graphics to show up briefly, but it seems there are some alignment issues to sort out before I can get entities being selected and moved about properly, but I am quickly running out of areas where rendering is not being performed properly, at which time I can start fleshing out the shaders to restore normal behavior. The good news is that performance metrics are still good with my best FPS on the first scene of the Big Escape showing 185FPS and my new engine pushing out almost double that (granted without the hassle of the extra shader commands), so I am pretty confident we have top-end speed analysis for this level before we load it up with shadows, depth buffer antics, and other concerns. I can almost sense the restlessness out there, but if Rome was not built in a day, I can pretty much guarantee the graphics engine to render it would take considerably longer
Thanks for your patience, and forward momentum is happening right now and each day we see more of the visuals coming back online so hopefully it won't be much longer before you can view a finished screenshot (admittedly almost identical to the one you saw before) but a little faster to load and a little faster to render
27th June 2017
You can add widgets, widget menus and rubber band boundboxes to the list of visible assets, plus a new constant buffer for pixel shaders to transport things like entity color and alpha override. I did notice the markers have disappeared, but I am sure it's a silly toggling of the state blocks. With the new system, you do not set individual state items per mesh draw, you need to create a common state block that represents a larger collection of stuff to be drawn, which makes sense when designing a graphics pipeline from scratch but will take some thinking to morph the current system to it. Also fixed the issue of entities being selected accurately, so it looks like I am just about ready to work on the shaders. The editor needs an entity highlighting feature so I will likely start there on Wednesday, along with expanding the functionality to move vertex and pixel shader constants over. I have posted two shots from today so you can see the progress visually.
28th June 2017
Please add entity highlighting, Easy Building Editor and Character Creator to the list of working visuals. Also managed to get markers visible again (related to the mutating state block system). My next few steps will involve getting the character shader fully animating, and ensuring the Character Creator heads and hats fit properly, as at the moment the CC characters look a little strange. Really pleased with how more of the system is coming online quickly without too much fuss. I did notice the 'thumbnail generator' for the Character Creator is a little messed up, producing some very strange BMP files indeed, but this will be another of my targets on Thursday as it also affects saving out more important files such as the water mask (which controls alpha levels along the water shorelines). I have posted a daily shot, as much to show a working head, as much to show my misaligned head to show how far I got today. Should have it on his shoulders by this time tomorrow and hopefully another fully working shader to join the terrain shader which stands at about 90% complete.
29th June 2017
Spent most of the day getting the engine to create and save a thumbnail for new characters from the character creator, and had to solve a lot of niggles along the way, but at least the engines bitmap rendering systems are working. The problem I have now is getting the DirectX 11 D3DX functions to save that texture out as a BMP. It would seem the engineers have been happily removing more functionality in D3DX (and making it obsolete in the process) so the matter is not straightforward. I am sure the right combination of texture staging format and output format will produce a saved texture but it's being decidedly stubborn right now. I am tempting to adopt the new DirectXTK methods (not obsolete) but it means something of a rewrite and an admission that I failed to get the D3DX version working, but I have my suspicions it would be the quicker option. The major work today however was good in that the other parts of the engine that rely on rendering to an offscreen bitmap are all working as expected, which means more functionality I have yet to cross paths with will work out of the box when the time comes. Who ever thought a graphics engine could be so vast
My hope is that Friday I can give D3DX another hour then switch to DirectXTK for which there are more samples out there, and a more reliable set of options.
30th June 2017
Funny now 24-hours can bing inspiration! I spent an hour looking at DirectXTK, and the grab bag of dependencies subtly designed force me away from my dependence on D3DX functions, then decided to take another peek at my current code. It was almost immediately apparent that the format conversion (which is no longer automatic in DirectX11) was to blame, so I simply created a second staged texture in the correct format and used the mapping functionality to manually convert the pixel data across. I then used the correctly formatted RGBA texture to save out. Sorted. Next on my list was character animations and limb associations, but today I was needed in an all-hands-on-deck so not much progress worth reporting was made. The good news though is that with texture handling for main backbuffer, cameras and bitmaps behaving, future progress that relies on them should go faster. This means of course the full restoration of the character shader, and a chance to see if bringing large chunks of the effect constants over will work first time (as opposed to creating whole new groups of constant buffers to emulate legacy behavior). As the last day in June, and capping off almost two months of progress updates, I am sure there are plenty of users who have no stomach for this level of waiting, and I can only hope these frequent blog posts serve to illustrate the difficulties at the lower-levels of game engine development. I am certain it will be worth the wait, and will ensure GameGuru sits on a better graphics technology moving forward.
4th July 2017
Started the week on the character animation and shader, which meant delving into the world of mesh data generation to create the tangents, binormals and bone influence data, and of course retain backwards compatibility with the old DBO model structure which expects the old DX9 vertex declaration structures as part of the mesh import/export step. It was a little fiddly, but I now have the mesh data generated and provided to the restored character shader. Not animating yet, but all the back-end pieces are in place. Upgrading of the character shader was not too difficult, and apart from some syntax tweaks and the addition of a constant buffer, it sits largely unaltered from the original one, which bodes well for the other shaders to come. I have a meeting all day Wednesday but will finish off this part of the port on Thursday and get both stock and character created enemies running around again.
6th July 2017
I now have animating characters
It was a journey getting the old and new worlds of vertex declarations to talk nicely with each other within the engine, but it looks good now, and my reward was a soldier posed for action and idling happily. The next step is to extend the FVF handling to the sky shader effect which now pops up a warning that it needs a special FVF format too, but apart from that I should be able to conduct a full release mode performance test tomorrow and run through the Escape Level and check out if I have impaired the performance. I also need to restore shader level settings in the character shader, but it went extremely well and I am confident to bring the other shaders back online in quick order.
10th July 2017
Thanks partly to my inbox backlog, I only found enough time to do some performance tests with the new animating character in the Escape Level today, the rest of the time was spent creating a small addition to GameGuru and the SciFi Pack to give those who are not particularly enjoying the wait for the new graphics engine something to play with. Last time it was the Golden Ally, this time it was the Liquid Tile. It's a simple enough creation, a tile of lava (or other liquid) that hurts on impact, but also looks good with vertex animation and texture parallax effects if used with a seamless texture. I had a few textures left over from the SciFi project so made one for free in the core product and the rest in the SciFi Pack under a new Liquid folder. A good deal of time was spent making the video for it as well, which also shows a good technique for combining creative tricks to make a good in-game visual. The good news for regular readers of this blog is that the work on shader code continues in the morning, starting with the secondary UV layer for skies and the depth-buffer textures for the shadows. The sooner I get the old legacy shaders restores, and all games working as before, the sooner I can get stuck into PBR, FBX and performance work (the good stuff).
11th July 2017
Had a good day of GameGuru development today. Had to spend a few hours backtracking through all the older non-English reviews on Steam to reply to each one, which took some time, but everything is up to date now. Managed to improve the FVF system to allow for secondary UV structure so the scrolling sky system can work again, and it should be pretty simple now to extend this further when I have to use it again for the lightmapping geometry which also requires secondary UV data per vertex. I also improved compatibility with the legacy shader approach somewhat so future shader ports are a little quicker (though I expect to rewrite them somewhat for the PBR when the time comes). The sky scrolling effect has now been restored, and more of the back-end to make this happen is also working without change too, so I am happy to move onto depth buffer textures and shadows Wednesday, which I dare say will be challenging as this will not be a straight port, but an attempt to improve performance by taking the existing depth buffer recast as a shader resource. There are other tricks to make depth rendering VERY fast, but for now I just want to get it working so I can watch for it breaking as I improve the performance of the render. I will also be doing some research on DirectX 11 depth buffer techniques for shadows as I dare say there have been some nifty tricks achieved since DX11 first launched its SDK.
12th July 2017
Completed another good day of work and also prepared a surprise for everyone for Thursday but I will keep that dark for now. I was planning to get to shadows, but the depth buffer work took me the whole day, but that's fine given the importance of it. You see before the shadows can have some depth data, the post process shaders needed it first, and it made a lot of sense to sort out great performance friendly depth buffers with the post process shaders before adding the additional complexity of shadow calculations into the mix. I also scored some good wins too. For example, I was never really satisfied with a 24bit depth buffer, so I tried a 32bit one with the new DirectX 11 techniques and it worked a charm (which of course means higher quality shadows, depth buffer and motion blur effects). I also got to directly render depth data values to the shader for the first time, instead of messing with conversions and back-flips to see the values, which was great to see and will really help me soldier on with getting this new depth buffer up and running with the current post process effects. If I have not already mentioned it, handling depth buffer data this way means I've just HALVED the number of draw calls for the main camera rendering, as I can get the depth data directly without rendering them specifically. Not so for the shadow renders of course, but I my research shows me that I can skip rendering to the render target when I do, so a speed boost there as well. A good day.
13th July 2017
Attempted a third good day, but it's gone 10PM now and this task is bigger than one day. The task was to fully restore the post process shaders, which of course meant getting the RenderColorTarget functionality to work (a way to do multiple passes to render to different targets and then combine in a final step). I have got most of it working, but the latest issue I am suspecting is that the depth buffer handling is a little off. The good news is that the entire post process shader compiles okay, and all the back-end code to support it is now in DirectX 11, I just need to give a few lines of code a little push to get it to do what it is 'supposed' to do. Right now even though I can render multiple passes in the shader, and everything reports good, I can only 'see' the first one, not the final pass, even though the first pass should be squashed to 2x2 but it's the entire main camera render. More than one issue remains I'm sure, so time to get some sleep and then finish this one off Friday.
14th July 2017
Stole a great day for Friday and got everything I wanted to do completed. With the exception of motion blur (the technique for which I will need to research as the old method no longer has the extra data I would need) and SAO (same reason), the rest of the post process shader works again. This includes the basics of correct passes within the shader, but also Bloom, Depth Of Field and FXAA. I even took the time to improve the depth of field effect so it does not take contributions from nearer pixels when calculating the final blurred pixel result (a small tip from a modern game's AAA paper). The MB and SAO both relied on an input texture representing the scenes current world XYZ positions, which we no longer have thanks to the faster depth buffer method. I think I can convert the SAO one to use the new higher resolution depth data, but the MB effect I think relies on some kind of world position data, but I can study that closer next week. I have posted a screenshot for Friday with the post process shader in effect. It's funny when I look back at a month or so ago I would be happy to see even one polygon rendered to the screen. Now I have the bitmap, camera and object management system working, sprites, entities, shaders large chunks of the graphics engine humming along nicely. I dare say it won't be long before I turn back and realize I have crossed the finish line of this port. Can't wait to start playing with PBR, but I need to show restraint and restore legacy functionality running under DirectX 11 so no stone is left unturned, and ensure that all corners of GameGuru function normally (and apart from the boost in speed, unnoticeably).
17th July 2017
I was meant to blast through SAO and Motion Blur, but the pesky issue of constant buffers (old and new) reared its nasty head and highlighted some issues with the Effects11 support compared to the proper use of constant buffers in DirectX 11. Finally had to resort to the Visual Studio graphics analyzer to discover my inverted View matrix was blank, and then a face-palm moment when I realized the post process shader sequence did not use the view matrix from the main camera zero, which explains the lack of useful data in there. Once that little drama was sorted, I was able to resume adding some HLSL to convert my new high-resolution depth data into world and camera space coordinates, and from there was able to get SAO and Motion Blur working again. I even improved the motion blur to make the effect more noticeable and fixed the issue of charging forward and backward with the effect, so now a high-speed movement with motion blur will create a cool AAA style effect from it. I was tempted to replace the SAO with something more modern from the DirectX 11 toolbox, but my primary mission remains the restoration of functionality, with fancy new toys later. With the post process shaders now fully functional again, my next target is the technique styles so I can get low, medium, high and highest back in for all in-game shaders, and further reduce the warnings my graphics backend is delighting in showing me everytime I run the engine. I am pushing shadows further away from me a little, but only because I want a few clear days where I can get it coded a better way and get those precious performance improvements when done right.
21st July 2017
I now have fully working shaders for terrain, entities, characters, vegetation in all shader level modes, and have started working on the water shader. I have also chased out most warnings inside the graphics engine side to make future debugging DirectX 11 specific issues easier too. As I suspected, once the basic background stuff was working, shader conversions came thick and fast, with some basic changes required on all of them, but the legacy functionality is mostly intact. The only chunk I commented out was all the shadow related HLSL code as this will need a different approach when I start the shadow and light ray work. This will be the focus for next week, but I have created a screenshot from the latest build to keep this post alive and offer up some minimal visuals until the fun really starts with PBR and FBX importing.
25th July 2017
We have reflections back in, which means the water shader is now also ticked off the list. As you can see I am cornering the shadow rendering which is pretty much the last main hold-out of the rendering pipeline. I regret it has taken so long to effectively reproduce what we already had, but each time I compile and run in release mode the performance improvement and loading time reduction greet me and remind me why this was a good idea. Also getting the hang of the new HLSL Shader Level 5.0 way of doing things, and once you know the 5 or 6 differences, you can pretty much spot an old piece of shader model 3.0 code right away without having to compile it to see if it will work or not. Wednesday I begin the long awaited shadow work, during which time I will be bending those depth buffers to my will and enjoying the performance benefit of not having to render to the color buffer
26th July 2017
My first glimpse of the depth-only shadow rendering (shot posted below). I spent nearly most of the day chasing a maths transform issue, but the way shadows matrices are calculated is a little long winded and working out what a projection matrix represents in the context of a perspective from the shadow camera can be a brain teaser. Still, with a little help of the old engine to show me the correct sequence of values as I calculate the shadow matrices for the cascades, offsets and other nonsense, I was able to cobble enough together to get to see a 'sort of' shadow in the editor. Plenty more to do yet to get everything lined up, and I have to decide whether to swap the 'cheap shadow' trick that the old editor used with a more direct cascade shadow mapping approach (i.e. better shadows when editing the level). The best news is that the new trick of skipping the pixel shader and rendering only depth information worked a treat, and in the latest shot below you can see that data being rendered crudely on the editor terrain. Now I have a grasp of something that renders, I can slowly work out the alignment issues and eventually expand the cascade to 8 stages and start to pull the last of the techniques into the port.
27th July 2017
My oh my, such shadow success today! Started with aligning the shadows, turns out it was the viewport in DirectX 11, nothing to do with my calculations after some exhaustive data scanning. Next I got what I call the 'cheap shadow system' working which I decided to keep as it means when you are in the editor you get lots of shadows for almost no cost which helps lower end systems (plenty of tricky things to do this including more bitmap surface pixel handling for creating texture data on the fly). I finally extended the system to run the 4 shadow cascade in the highest mode of a test game, and that did not quite work, and that's when I ran out of 'day'. This last bit should be no problems come Friday though as all the nasty stuff has been done, and I can generate my shadows again, but now at a much faster rate and opens up the possibility for me to extend the Cascades to 8 for higher quality shadows at different distances (i.e. VERY good shadows for close-up characters and smooth transition of that shadow into the far distance). Once all shadows work across different shader modes, I will turn my attention to the lightrays which I think is the last graphical 'missing bit' from the in-game render process. Hopefully next week will be a choice between more performance optimization work (plenty stuff I can try now with DirectX 11) or switch over to PBR and FBX support so we can introduce some next-gen techniques to get superior graphics in GameGuru. I dare say many users will be looking for this (especially those with high-end rigs and no FPS complaints)
Rest assured this major update will be a little of both, so everybody gets a little of what they want. Added a screenshot below showing the editor shadows restored.
28th July 2017
Shadows are done
I have noticed some artifacts I would like to take a closer look at, but the method I am using is better than the old one, which actually uses some closer sample compare linear filter math to make nice smooth edges to the shadows. I have extended the cascade shadow code now to terrain, entity and character shaders. Best of all, shadows are rendered MUCH faster and the shader are more efficient (due to some extra warnings that flashed from the latest DX11 shader compiler). These small artifacts are an opportunity to further improve the visuals of shadows, but I don't want to take my eye off the goal of finishing all legacy visual functionality. We are so close now. Did not find time to do LightRays but I suspect that would be a quick task for next Monday, and then I suspect I will be dancing around the completion of the legacy stuff and warming up the R&D on the new and exciting stuff. Just need to figure out whether to release an early beta with DX11 and no visual add-ons, or delay and reveal a beta with the PBR experiments in there. Really great to see almost all the visuals back on-line. Phew!!
1st August 2017
Apart from light rays (a little known GameGuru feature not worth its own screenshot), my main task this week is to get the whole game maker to a point where it mostly if not entirely resembles the one we started with in May. Granted it renders faster and loads quicker, but it was important that projects still underway did not look alarmingly different from the ones already being worked on. It's not guaranteed that a boost in visual quality would be welcome for projects that are relying on a careful balance of visual settings and custom artwork created over many moons. It has been a thought of mine that the new PBR+FBX infusion should have some kind of artificial threshold whereby existing projects don't suffer and new projects can 'opt in' to the new way in which the shaders will work to gain the benefit of PBR. If you think about it, a single pixel in a PBR universe would need to reference one or more 'light probe' texture sources, in addition to the existing requirement to reference normal maps, specular maps, shadow mapping texture(s), occlusion maps, optionally a lightmap, a cube reflection or illumination map, and you get the picture. It basically means more sampling, and if you are on low-end graphics hardware, you will not thank me for adding MORE to the shader, rather than less. Not entirely sure how this 'opt in' will work, but I think it will work best if existing users have this switched off so the update does not interfere with existing projects, and brand new GameGuru users get it switched on by default, so they get to see what it's like working in a PBR based universe. Naturally, the user is only one click away from toggling this if this is the way to proceed. What I do know is that we cannot take 6000MB of non-PBR assets (that in some cases could be eight years old) and convert it all to shiny new AAA PBR models and textures, so it poses the question of how these two worlds will live together. The good news is that GameGuru will be able to provide a choice, allowing those who value quantity of assets over the quality of assets to create games side by side under the same roof (and even in the same game level) should they wish.
3rd August 2017
Well, we now have light rays restored to the engine
I also forgot to mention the weapon shaders (fixed and animated) which are now ALSO done, complete with the cube mapping effect for the more reflective weapons. As you can imagine, I am rapidly running out of graphical chunks to port, and creeping up on the time when I can publish an internal beta for those who want to taste the fruit of the last few months. The first few betas will be pretty low-key so I can figure out how much I have broken, but once we're back to full legacy functionality, the fun can begin with the newer aspects that DirectX 11 brings to the party. Not quite ready for the first beta however, as I need to deal with the relatively minor graphics tweaks that remain such as getting the mipmapping working again, the alpha masking, particles, explosions, e.t.c. But the last thing I will do this evening is compile everything in release and see how my performance is doing, now more of the graphics engine is 'alive'.
4th August 2017
We now have animating unified tree shaders, mipmapping, alpha masking, decals, explosions and entity cube mapping to the list of completed graphical tweaks, plus some very minor improvements to the weapon shadow technique. I still have to try another release build to see if the performance is holding, but I am pretty much there in terms of legacy visuals. There are some areas still in need of attention such as the terrain texture customizer, Easy Building Editor texture selector, and the light mapper, no small tasks ahead, but I am pleased to report that the basics are now back and you can run the example games as though nothing has happened. I think it's a little too ropey to put out as a beta, but it's very close now and I am looking forward to seeing how this entirely new 'DirectX layer' works on systems that have until now relied on the older DirectX 9 layer to run things. On a side note, very pleased to see the 'Easy Or Not? Strapline thread' getting lots of attention and discussion, and I think we are getting some clarity on possible changes to the strapline and the product description page to ensure GameGuru messaging is clear as we move forward with our newer engine! For now, it's Friday 5PM and the sun is shining, so going to say hello to it for a while, then perhaps return later to grill the performance of the engine, see what the GPA and Visual Studio graphics profilers think of it so far
7th August 2017
Some more tweaks and major adds to the source code. The grass now aligns to the terrain properly, the alpha channels of textures are now read by the shadow casting code for better more detailed shadows and I made a start on the custom terrain texture feature. Of course, I ran into another case of missing functionality in DX11 that used to be in DX9, so format conversions are all but impossible natively. I eventually tracked my way to the DirectXTex open source library which grants this power back to DirectX 11 apps and now the happy work is to learn the various commands to create, load and convert textures so I can read in both PNG and compressed DDS textures, modify them live and then save out in the necessary format. I am pretty sure after reading this extensive port blog all the way through, most users will probably not want to write their own games and graphics engine, ever
I have a meeting day Tuesday but should be back at full coding power on Wednesday when I hope to finish the terrain/ebe custom texture system and also make a big start on the lightmapper. I had considered capping it off, but many users still depend on pre-baked scenes for the lower-end, and it would hardly be an upgrade if the latest version had a big hole in it!
14th August 2017
Almost there now with the legacy work. Custom textures for terrain and Building Editor can now be created properly, with all proper mipmap handling. It appeared that DX11 removed all the texture copy/stretch/convert stuff as well, so I've mastered the DirectXTex API to get my functionality in this regard back into the engine. I then used this knowledge to start work on the light mapper, which also requires texture loading, saving, converting, e.t.c. As tantalising as I am now to completing the FBX animation work, I really want to make sure the legacy stuff is solid, and during my tests from last week I found some small issues with SAO world position calculations, water reflection images at some angles, missing light range markers, missing normal and specular for Building Editor customised textures and a few others I am sure are lurking in there. As per my usual days, I do the rounds on Facebook, Youtube, official forums, Steam discussion board, emails and tech support system to make sure all GameGuru questions are answered. It would appear that only 40% of people like GameGuru from the last 30 days, posting a negative review and the latest overall score is down to 73% (down from 80% from about 9 months ago). Not sure if that's due to the lack of an update or the increasing old-age of the current technology, but it does not bode well for new users who will probably run a mile from our little game maker before they've had a chance to check it out
Hopefully the new overhaul will reverse this fortune over time.
15th August 2017
A great day today! Fixed the water reflections, fixed SAO from disappearing when weapons showing, weapons no longer sink into nearby geometry (using better system than wiping the depth buffer for z-disabled objects), the building editor custom textures how retain normals and specular data, and use defaults if no source is present, fixed light markers, together with the zones and waypoint geometries which now support diffuse colors in the vertex data, improved prompts so delays are less noticeable so user not waiting in an apparent freeze, improved standalone executable loader so it ONLY locks in DBO objects so no longer depends on any rogue X files a few tweaks along these lines. The two big events though was a 4-hour chase and fix to find out why a ghost character was appearing over ragdolls, which caused the second of my wins which were to get a standalone fully running so I could run the Intel GPA graphics debugger on it. It is the first time I got this to work on a LARGE level (thanks to an up to date version of GPA and DirectX 11), and was able to drill right into the pixel that was associated with the ghost, and through some basic elementary tracking was able to find the cause. Yay! This also means I now have access to a pretty cool analyzer for graphics, which of course means plenty opportunities for performance profiling! From this early look, the grass is a really heavy hitter and a perfect candidate for hardware instancing when the time comes. For now, it's time to back up my files and pat myself on the back. As an encore, I also found a GREAT article about animating FBX data so will be reading through that on Wednesday to get true mastery over the subject (I know 90% of it, I just need the missing ingredient to complete my work).
17th August 2017
Plenty more ticked off the list, including fixes for the rubber bound box alignment in the editor, progress bar restored in light mapper, character creator has textures again and can create simple characters as normal and the biggest work was a complete replacement of the SSAO system to improve the quality of the technique. Friday I will be doing a full test of the GameGuru legacy functionality, and if it looks good, I 'might' put up an internal beta to see how much mayhem I can create with my long suffering testers! It should be good though. I just did a quick test, the current Steam build loads up the editor in 40 seconds on my machine. The new DirectX 11 version I have here boots up in 16 seconds
18th August 2017
Would have been great to get a beta out today as my daily task list was done in good order, with both import model and character creator behaving normally again, and some asset loading issues tweaked to bring all functionality back online. Alas, during my full-speed complete test of the software, I started racking up some more minor issues that make sense to fix before inflicting this version on anyone. One of my other hats is being a tester for other software coming out of TGC and I am not too keen on testing a build that the developer knows has bugs in it, and my report nothing more than repeating what is already known. It's not a huge list of fixes, but I would like to deal with them before unveiling what will be the first build in over two months (good first impressions and all that). I must also highlight that the Import Model feature for FBX is still in pieces, so I will be advising my beta testers avoid that one while I continue to work on that, which of course is the next major chunk of work facing me. The good new is that both FBX and PBR have been heavily researched and I am on good footing to get those sorted quickly and part of the general mix for the early betas. I will still be using the earlier beta versions to ensure legacy functionality is completely restored and to start the process of fixing any critical issues from the 2017.May version such as the AI freeze issue and other project-impairing items that will at least allow some forward momentum for projects coming to the end of their development. The plan is to continue developing into the weekend and see if I can get something resembling a solid beta for the start of next week, and I am hoping that week will herald the posting of some brand new PBR-rendered models to give you a little faith in the future of GameGuru graphics.
21st August 2017
I had about 24 issues discovered over the weekend with my final tests before a beta, so had plenty of fun coding today. I have updated the GameGuru stand-alone splash with some proper instructions on how to replace it, character creator skin and clothing colors restored, removed mipmap artifact from terrain paint cursor, mouse pointer now perfectly aligned to character creator body and head object selection, added in debug visuals back in, and restored its ability to use colours for the different types of AI debug rendering ( you will see soon enough), added a prompt when terrain texture painter initialising to keep screen responsive, removed a number of demos and video links from the top menu bar, cleaning up the interface a little, waypoint highlighter improved and fixed lightmapping for Easy Building Editor structures.
