Long waiting times

Not sure if this is a fixable ‘bug’ but I did wonder if it was something that could be possibly improved upon. I’m not running the fastest laptop in the world (it’s a 64bit 1.4ghz AMD with 4gb ram) but I’m finding I have large waiting times when using the ‘long wait’ command (^). I assume this is because it has to calculate what happens over those hours?

Sorry if this is just my laptop, but as an ASCII based game I didn’t think it’d be too taxing on it, so that’s why I wondered.

While you’re waiting, the code is literally acting like you’re hitting ‘.’ (pause/pass) for as long as it takes for the selected duration to expire, so it’s rendering every frame and any monster activity etc exactly as if you were running around for the same amount of time. There might be some kind of speedup that can be done, like with sleeping for example where it only draws the map* once every 300 turns.

That having been said, the code is pretty unoptimized at the moment in general, especially the lighting code, which is what I’m working on right now, so there should be some major improvements soon even if we don’t end up doing a specific change for the wait code.

*Drawing the map is the single most expensive operation the game does, so making it redraw the map 5x less often will result in something like a 4x speedup.

If you haven’t already looked at it there are some very fast shadow casting algorithms that are probably at lot better than the noddy line-of-sight lighting I put in initially. Anything that reduces the number of squares checked would probably make a big difference.

The current bottleneck is caching which tiles are inside/outside of all things*, so I’m seeing what I can do to improve that, then I’ll see what the next bottleneck is, etc… The lighting algorithms themselves seem to be fine, it’s marshaling all the data that seems to be the problem. This was the same deal as the vehicle mod, the main problem was that it was re-checking each square for presence of a vehicle 100s of times per draw operation in order to determine if that square was transparent or not, simply caching the transparency data fixed the worst problem, then bigh came along and sped up vehicle lookups a great deal (also with caching) and the vehicle overhead faded into the background. Just need to do the same process with lighting, it’s quite solid overall.

*Rule #2 of caching, the bottleneck is never where you think it is.

I imagined it might be doing that. Great that you’re looking into it though and that there may be speed ups on the way as I do find it pretty sluggish at times (but unfortunately for my health - very worth it).

Great success, I was able to accelerate some of the lighting code by about 50%, which translates to something like a 30% overall speedup. The code is in my repo and ready to be pulled, it will be in the next release unless there’s a major bug in it I missed.

I bet something happens with underground lighting.

Does underground lighting not already work? should be the same as indoor at night time.

awesome! that’s really good to hear, it was getting a bit taxing at points waiting for it to load.