[=;182864]
Yeah zoomed all the way out it gets choppy, but zoomed in it is much better. But that is with tens of thousands of tree meshes that I am currently over producing(by say 37 times). I might have 100K meshes on a map with 20K instanced tiles.
[/]
Ok, good. Does it seem like the amount of tiles have almost no impact, as long as they are off screen, or is the effect just less pronounced? How is the framerate when zoomed all tne way out compared to having say 20*20 tiles in view?
I’m planning on making huge, procedural worlds, and these sorts of things will determine how I go about doing that. Worst case I have the world stored in arrays, and only spawn the tiles just before they enter view, deleting them as they leave. I can check this out myself, of course, but I suspect you have taken more time perfecting your tile spawning algorithm.
[=;182864]
I was talking with a friend of mine who recently took some kind of logic architecture class and he was telling me that when you search for an index in an array it starts at the beginning of the array looks at everything down the line until it finds the index you want. So in my case that could be tens of thousands of indexes in before it gets to the named index. He was basically saying that it would be better to do a few pieces of math rather than do a single array check which would have to spend time accessing memory.
I think you could test this by making a map with say 20K+ tiles(or at least that many indexes in the arrays), but then walling off a small section that would have all your actors. That way you could run the same test you have been doing but the only thing that would change would be the size of the arrays being checked.
[/]
What you are describing sounds like the difference between using the search function in an array as compared to the get function. Using search is comparable to opening every file in a file cabinet until you find the one you’re looking for, while using get is comparable to just checking a single, specific file at an index.
This is the reason why I use get functions almost exclusively, and I suspect this is the reason why my algorithm is reasonably efficient. Still, I will try to compare pathfinding on a small grid to pathfinding on a large grid in a sealed off area and report the results.
[=;182864]
This is the old default loop limit or the new one that you can set to 2 billion?
[/]
This is with the old loop limit. Increasing the loop limit is of course not that big of a problem. However, when getting close to hitting even the old loop limit, the game freezes noticeably for about a second. For generating a map at the beginning of the game, this might be unproblematic, but for something that will be called several times during the game it is quite jarring. So the loop limit isn’t really the problem here.
As it stands, I think my system is perfect for anything between the scales of King’s Bounty and XCOM, but for games lime Civ I think it is too slow at the moment. Perhaps not for player movement, but calculating all AI movement between turns is where I think my blueprint would start freezing up the game for a long time. I know of some ways to cheat by making the algorithm much quicker, but less precise, for long distances, so that’s one possible solution.
I’ll try to be as much help as I can when you get to making your own pathfinding, but I suspect you might wantto delve into C++ for something on the scale of Civ.