Ok, so the generated mazes have tons of points that are in a line on a wall. Here's some talk about the maze generator so the rest will make more sense.
The maze generator generates grid mazes. It builds a list of lists, rows and columns. In each item in the column (which is inside the row) it stores whether or not there is a wall on the bottom and whether or not there is a wall on the right. That part doesn't matter. What matters is that I converted it to build arma maps by multiplying the indexes of the arrays while iterating through them by some factor, and then setting a grid size that made len(rowItem) * sizeFactor = 500. So it's a 500x500 grid.
The factor currently used is 20, and it generates 25x25 grid. I'd like (and so would some others) to generate a 50x50 grid by changing the factor to 10. Obviously that's a pretty large grid. As a result of this scaling, there is a point at every single interval. So 0,0 has a point, 0,20; 0,40; 0,60; and so forth. Then 20,0; 20,20. And so forth. And then there are long hallways going this way and that way and the other, also short hallways. It's pretty neat. But there are definitely a lot of points that are being generated that aren't being used.
I went, in local game, from 250fps down to 7fps with the 50x50 grid. On the other hand, I only dropped to about 100fps on the 25x25 grid. On internet game, I've only put a 25x25 grid on the server, nothing larger, because of that dramatic drop in fps. It'd be nice if we didn't have such a huge drop in fps anyway.
Tzeentch, the first labyrinthine map I'm aware of (and that's arguable) runs at around 60fps for me. But it's a spiral, mostly, rather than a real maze.
So my question comes back, how much does it affect fps? More to the point, how much is it adversely affecting fps that could be recovered in such a volume to justify putting a priority on removing redundant points and joining wall segments, at least when they're in a straight line?