ISTM that the railway tracks might have been better generated *before* the rest of the map. Lay the tracks, then map/build a city around them.

But with all the work already done, that's probably not such a practical approach now.

That might have been a more sensible idea, yes. There's still some tweaking I need to do to make the tracks look 'right' - things like discouraging it from producing tight loops or snaking sections just to get the shortest path, and discouraging it from building over road so that when the track supports are put in they can be placed with reasonable spacing (All the train tracks are elevated - something I haven't mentioned before, I think.

1. General terrain for the area - you could pre-specify minimum percentages of certain types of terrain, to ensure enough flat, solid ground for the main city to be bult on, and so on.


2. With that in place, plot a railway - doing it at this stage means you could cut suitable trenches (what *are* the cutaway slices of land that railways are built through called?) through slightly higher ground (and later put bridges over it if the roads cross) and even make the lines as tunnels through hills.


3. Add an initial smattering of roads and buildings (including railway stations, obviously)


4. Add the main mission buildings as needed, with roads as necessary to access them from what's already there


5. Finally, build the remaining city - roads and buildings - around what's already been done.

Thinking further... is the map generator building any kind of terrain into its results?

(b) give the railway somewhere concrete to go (How can you put a railway between two stations if you don't know where the stations are?).

Although, you could develop the map generator in such a way that it takes hundreds of years to run, for added realism...

what *are* the cutaway slices of land that railways are built through called?) through slightly higher ground

Sounds "good enough."

Ship it!

Yeah. He should look for jobs with Microsoft.

Except that I can't seem to throw stones very well, because an optimisation I just tried ended up making things slower.

And when I removed the optimisation things got even slower still

Are you certain there was nothing running in the background hogging any CPU time?

Or did you perhaps make another change at the same time as that optimisation, with that change slowing down the speed up, and slowing it down even more without it again?

And when I removed the optimisation things got even slower still, so now I've got no idea whether I didn't revert the code properly or I've changed something else without making a note of it

It's probably just wear and tear on the processor. It's a little known fact that the more cycles a CPU executes, the slower it becomes. This is the explanation for the fact that Windows boxes become slower over time, it's nothing to do with the software being crap.

Despite my best efforts over the weekend the RiscPC is still slightly shy of the mark (40.7msec/frame IIRC). I've also realised that I've been running it without any music playing, so at some point I'm going to have to try it with music and discover how much time MP3 decoding takes.

But last night I did have an idea for how to optimise the map rendering to make better use of the d-cache, which is to draw tiles which have the same texture all at once so that new textures don't have to be loaded into the d-cache all the time. I'm not sure of the exact numbers, but I'd hope that this has the potential for a 10-20% speed boost on the RiscPC - assuming the code to calculate the rendering order doesn't take longer to run than the stuff it's meant to be replacing.

Oh well - when I first started I said I suspected that MP3 playback could be too slow, so I guess it's not really an issue if there isn't enough horsepower to support it on a regular StrongARM RiscPC. Unless people want me to try making a version of the game that runs in a 256 colour mode instead of 16bpp - that has the potential to save the 11msec needed to get the game running at 25fps with MP3 music (or in higher resolutions without MP3 music). But it seems a bit of a cop out, and might be a bit fiddly to add support for.

Perhaps a much simpler solution would be to use lower quality MP3s (which might still be too processor intensive) or a different - simpler - music format on RPCs?

Possibly. I'll probably have a play around with different encoding options, and maybe try AC3/OggVorbis to see how they fare (specifically Vorbis since it's allegedly the best quality at low bitrates)

and lower bit rates are attained at the expense of greater computation generally.

I'd have thought you should be heading in the other direction - (AD)PCM - to increase performance.

Perhaps another pair of eyes would help on the optimisation front... I'm willing to take a look at the source if you'd like and make any suggestions that occur.

Perhaps another pair of eyes would help on the optimisation front... I'm willing to take a look at the source if you'd like and make any suggestions that occur.