One thing that I'm excited about is that in the week just past I finally made gains in improving the performance of the first level!
I remembered a very neat tool that Panda3D provides, "DirectTools", which provides amongst other things a tree-visualisation of the scene graph. In addition, it turns out, it allows the user to delete nodes at run-time. Thus I could experimentally delete various nodes, and observe their effect on the game's frame-rate.
And one object in particular turned out to be problematic: the ring of trees at the edge of the level, being the highest-resolution parts of the surrounding woods. I had this ring as a single object--and as it turns out, it was a massive one.
I asked for advice on the Panda3D forum, and one suggestion was to chop it up into several objects, thus allowing the engine to cull away some of it. I tried this, and it worked!
On top of that, I made a minor gain by enforcing simplicity on the rendering of the light-cameras: they don't require things like materials, textures, transparency, or multiple culling-bins, I believe, and so I've set flags on them to ensure that the engine acts accordingly.
Overall, the performance gain isn't huge--from about 62-63fps to about 67fps, I believe--but it's one that I'm happy to have. ^_^
As to the demo, work continues on that--and indeed, I think that there are only a few outstanding issues before it's ready!
As before, working towards the demo involved dealing with a few problems. One in particular proved to be a bit of a nuisance: file-paths.
In testing under Windows, I discovered that while the game was successfully writing save-files, it wasn't writing out the associated screenshots. Once again I sought help on the Panda3D forum, and one thing that it was suggested that I check was the file-paths.
Doing so, I found that I had an awkward mishmash in place: some elements used Unix-style paths (which I gather is what Panda's file-handling likes to work with), while others used OS-specific paths--which would be Windows-style under Windows. In some cases they could even be mixed in a single path!
Finding a good solution was a little tricky, but I believe that I have this fixed now. As I recall, the general idea now is to use Unix-style paths for the most part, only converting to OS-specific paths when called for (such as when passing a file-name to my save-game system).
On the gameplay side of things, I made some tweaks to the detection of surfaces to climb onto. Specifically, I found that narrow ledges could be a problem, especially when very near to the player. To solve this, I've simply had the ray-testing start closer to the player, and reduced the distance between testing-rays. It does slightly reduce the distance at which surfaces may be detected--but this distance was fairly large anyway, I feel.
I also made a few changes to sound-related matters. One that might be worth mentioning is the re-introduction of footstep-sounds when crouched. I had previously removed (or rather muted) these--but I felt that this left such movement a little too quiet. However, I didn't want crouching to be accompanied by the normal footstep sounds--I don't think that those really match crouched movement.
So what I've done is re-instate those sounds, but played more slowly (at about half-speed, I think it was). This produces something a little different to the usual noises, but still recognisably similar. I'm not sure that it's quite right, but at the least it does for now--and is better than near-silence--I feel.
And a number of other things were done--fixes to bugs and oversights, changes, work on the second-level draft and notes, etc.--that don't seem worth detailing here.
That then is all for this week--stay well, and thank you for reading! ^_^
