Friday was fun, I got to spend some time recording temp audio cues for the harvester.
[Harvester returning to Base]
The rest of the week was spent fixing bugs and getting the AI controlling the harvester to work. The good news is that harvesting is now working just like I wanted. Here is a harvester on a resource field with very few remaining resources.
[Nearly depleted double-yield resource field being harvested.]
I spent two days trying to find a bug that messed up how resource fields are handled by the collision system. Resource fields have a core crystal that I wanted vehicles to avoid, and then collectible crystals which can't have buildings placed on them. What I was getting in the collision debug display was only the collision information for the core.
[How resource fields are supposed to look in the collision debug display.]
One of the problems when programs get big is that there are so many things going on and computers are so fast that the most valuable debugging technique available - stepping through the code one line at a time - just isn't feasible anymore. You have to try to guess where the problem might be to reduce the amount of code you have to step through to a reasonable amount. I could see the resource fields putting themselves into the resource system, but when I enabled the debugging display for the collision system that data didn't display. For about a day I thought it was a rendering problem and dug pretty thoroughly through the debug rendering code to no avail. In the end I discovered that after the field was carefully placed in the collision system, some much later code came by and erased all that. All of this activity took place in about 100 milliseconds, but that's still way too much code to single-step through.
The last bug I worked on this week was tricky. Explosions and particle effects were mysteriously not working, well they were kind of working, sometimes I'd see traces of them on the screen. I did the usual things to try to find the problem, stepped through code, looked at matrices and numbers for vertices, looked through the changes a bunch of times with Mercurial (and there were a lot of them.) I couldn't find anything that would account for the behaviour I was seeing. Getting desperate, I even backed out of all of the changes I've made for harvesting and ran the old version - no problem there. The problem was in fact somewhere in the new changes.
Something that's handy for debugging rendering is when you can strip your scene back to the absolute bare minimum, get rid of the props and sky and units and terrain, reduce it to just the one thing you're trying to fix so that single stepping through your program is viable again. Since the beginning, Miranda's Lair Engine has had this little test area.
[Lair Engine Test Area]
With the test area running I fired off a particle effect, and it kind of worked, it wasn't totally right, but I saw some particles so I at least knew the rendering was working. Taking another much slower pass through the changes, focussing on the effects code, I finally spotted the problem. Every element in a scene in the Lair Engine goes into thing called a scene graph. There's the root of the scene graph, which has the camera attached to it, which then has everything to be rendered attached to it. I was attaching effects to the root of the scene graph, rather than attaching them to the camera so effects would always display relative to the global origin rather than the camera origin. They rendered fine, but in the wrong location (almost always offscreen.)
The only thing left to do for harvesting is to add a particle effect to indicate the harvester is harvesting. I should be able to put that together tomorrow, then on to The Shroud.
We were unable to retrieve our session cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.
You will not be able to post until you resolve this problem.