Deferred rendering seems to be all the rage these days. Everyone seems to be implementing it from Starcraft 2 to Uncharted 2 (actually it’s Light Prepass) to Killzone, etc. So we thought we’d dive into this and give it a whirl. The current GODZ demo now has a deferred rendering pipe. My fellow colleague, Wa Kan, hooked up the GBuffer implementation to the engine. I did the deferred lighting side (directional / point lighting). In the current demo, you’ll find that the point lights that are attached to the characters will light up all the pixels within range. I think it looks pretty cool.
Right now the deferred renderer is noticeably slower than the forward renderer (you can hit a key to switch between the two). There’s a few optimizations I can do to speed up the deferred side but I do not expect it to match the forward renderer in performance. However, what deferred rendering brings to the table is a very nice dynamic, per pixel lighting system that can handle multiple lights with fair ease. If I were to try to hookup point lights to the forward renderer, I would have to spend a lot of effort managing the lights.
Programming, Projects
godz
Been working on porting over the old godz win32 editor over to C# which has been going pretty well so far. I was basically faced with the choice of using either MFC or C# if I wanted to make the UI more current. Choose C# due it’s nice, clean interface and updated components.
The managed editor interfaces with the unmanaged DLL passing pointers back and forth via IntPtrs, etc. Unmanaged objects are wrapped by proxies on the C# side of the fence. All of the engine functions are exposed as C functions so their names do not get mangled. Levels can be put together in pieces that can be streamed / unloaded during runtime seamlessly. The goal, as always, is to never force the user to sit idle while resources load. So, if you need to load a package, etc you can start the operation and do something else as the package loads in the background
The engine can now generate a Navigationmesh based on a collision mesh that’s passed into it. Once the navmesh is constructed, it can be passed to multiple AI threads which can asynchronously access the navmesh and plan their path navigation using an A* algorithm I just cranked out last night. Currently, I have a bot that will follow me around whereever I go as a simple test
After I’m fairly sure everything is stable, etc I’ll upload a new demo.
Programming, Projects
godz
Just uploaded a new build of GODZ. In this build, I re-enabled the shadowmap quads however they must be turned on in the Default.lua file if you want to see them. Fixed an issue whereas sometimes the shadows would work and other times they would fail completely. I noticed this bug on a friend’s machine and thought that was odd so decided to track it down today. Lastly, I implemented the Animation Blending feature so we can Ease In and Ease Out of animations.
I’m pretty happy with this build seems pretty solid.
Projects
godz
So I was over a friend’s house the other day and we decided to download my GODZ demo for a look. His hardware is practically identical to mine. Everything ran smoothly however I couldn’t help but think of ways to optimize this thing further. According to my profiles at the moment GODZ is render bound rather then CPU bound which is to be expected of an app that does so little CPU side at the moment. So I’ll be looking at that over the remainder of my Christmas break along with animation blending
Projects
godz
Been playing around with NVPerfHUD lately. It’s a pretty cool tool that provides a lot of useful stats. Below is a sample pic of the tech demo running on it. It’s been tricky learning how to use this profiling tool. I’ve grown quite used to PiX for the xbox 360 in which every developer knows is beyond incredible. I’m sure this one is too- just need to learn how to make maximum use of it
Programming, Projects
This afternoon after I get in from enjoying the sunlight I started up GODZ and get a crash right off da bat. Wow. So resolved the read/write data race and uploaded a new build. This build I was in the middle of optimizing game->render thread updates. So this build is a big jump over the former. When I’m finished things should be running really smoothly.
After I’m done with the optimizations I had planned I’ll look into adding some smooth blends between animation playbacks. Right now when you switch animations I believe this occurs immediately rather then interpolating between the two animations. Animation playback should look a lot smoother when I’m done
Projects
Uploaded a new demo. This version is a significant jump over it’s predecessor in performance and runs a lot more stable. Ah, I’m feeling warm and happy inside 
Projects
Lately I’ve been thinking about playing around with integrating multicore physics. Currently, the physics system I coded occurs in the main game thread pass. You know the routine. Multicore physics or rather in my case, Multicore Collision Detection would involve the main thread passing collision volumes to a concurrent physics thread. The physics thread takes the velocities of the objects and watches for collisions. When a collision is detected, this information is propagated to the main thread
The gains for the average title might not be all that huge but for a title with hundreds of entities in the physics world the savings might be worth it. In my case though I mostly interested in leveraging more cores.
I’m a little hesitant though to go rip apart my engine yet again to introduce another layer of complexity. Actually, what I really dread is the thought of having to chase a potential read/write data race issue.
But if I do decide to pursue this my thought is that I would write this as a “Job” that runs asynchronously, running the physics simulation on its’ own Core. Essentially it would work like this:
- Loop
– Check queue for collision volume updates
— Run the physics simulation
—- Copy current state into a list of events that the main thread can query at anytime for current status of the physics world
The only bottleneck here is the last step, when the main thread queries “Physics World” for the current state. But it shouldn’t really be a bottleneck if this is handled properly.
Should be a fairly straight forward thing really unless I’m missing something. The main game thread and physics really shouldn’t be sharing much information beyond the current state of the physics world. If I do implement this will make sure to keep it all configurable so I can switch between single threaded and multi-threaded physics.
Concurrency, Projects
Yep it was a read/write data race condition that was causing the issues. The render thread was creating Game objects on the heap that represented the DirectX driver. The problem was this game object could be registered while an asynchronous read was taking place in another thread. So the threads were clashing which resulted in the occasional crash I experienced when starting up the game. The only clue I got was that I was seeing impossible memory values for these game objects sometimes.
What blew it only happened in Release. Never could get it to happen in Debug. So it kinda sucked trying to go through that call stack.
Anyway I’m just going to make sure to put some thread checks around the hot spots to insure this won’t happen again.
Happy me, feels great to resolve this issue. Will be uploading a new Demo later tonight / tomorrow
Projects
Been busy debugging the GODZ demo in my spare time. Noticed every now and then only in Release does it crash sometimes. Grr…. It could be a read/write data race condition or perhaps something else more exotic. Perhaps it could be something as basic as an uninitialized variable. When I get time I’ll try investigating into it more.
Besides that all has been well with the Demo and I’m still excited to finally upload a new build.
Projects
Recent Comments