PDA

View Full Version : The collapse of the program on large maps.



Optimist
April 3rd, 2024, 08:36
I'm creating a map of the city. In normal mode, the grid pitch is 10-20 yards. When you need to fight in the city, I reduce the grid so that the hex of the grid corresponds to 1 yard. And when a grid with a step of 1 yard is put on the city map, then when you try to change the window size, the FG program breaks. I understand that this is due to the load of the grid calculation. But is it possible to make the program slow down rather than crash? And the grid calculation itself, well, is it such a terrible task that it should create a program crash on modern PCs?
Why does graphics work normally in modern games, where three-dimensional polygons are calculated with textures superimposed on them, and then the program crashes due to the calculation of superimposing a two-dimensional grid on a two-dimensional image. Why not make sure that while resizing the window, the program does all the calculations for what gets into the window, and then for the rest and does not crash.

Trenloe
April 3rd, 2024, 14:14
Welcome to the FG forums. Sorry you're having issues.

Can you please provide more information:
1) What exactly do you mean by the program crashes? Does it just disappear? Does it hang for a while? Are there any error messages?
2) What ruleset are you using?
3) What extensions are you using?
4) How large is the map in pixels (width x height)?
5) What are the exact steps you follow to recreate the issue? This will help the devs try to recreate your issue.
6) If you try with a small, basic map, do you get the same issue?
7) If you try in a brand new campaign with no extensions (even no theme) does the issue still occcur?

pindercarl
April 3rd, 2024, 14:17
I'm creating a map of the city. In normal mode, the grid pitch is 10-20 yards. When you need to fight in the city, I reduce the grid so that the hex of the grid corresponds to 1 yard. And when a grid with a step of 1 yard is put on the city map, then when you try to change the window size, the FG program breaks. I understand that this is due to the load of the grid calculation. But is it possible to make the program slow down rather than crash? And the grid calculation itself, well, is it such a terrible task that it should create a program crash on modern PCs?
Why does graphics work normally in modern games, where three-dimensional polygons are calculated with textures superimposed on them, and then the program crashes due to the calculation of superimposing a two-dimensional grid on a two-dimensional image. Why not make sure that while resizing the window, the program does all the calculations for what gets into the window, and then for the rest and does not crash.

Some of the token functions, such as determining token visibility, are dependent on the grid. For example, when you decrease the grid from 10 to 1 you are increasing the number of grid cells by a factor of 100 for a square map. This is likely the cause of the crash that you are experiencing. I'll look into some additional measures to reduce the GPU cost for maps with a lot of grid cells on them, but there is always going to be some limit.

Optimist
April 3rd, 2024, 17:13
Welcome to the FG forums. Sorry you're having issues.

Can you please provide more information:
1) What exactly do you mean by the program crashes? Does it just disappear? Does it hang for a while? Are there any error messages?
2) What ruleset are you using?
3) What extensions are you using?
4) How large is the map in pixels (width x height)?
5) What are the exact steps you follow to recreate the issue? This will help the devs try to recreate your issue.
6) If you try with a small, basic map, do you get the same issue?
7) If you try in a brand new campaign with no extensions (even no theme) does the issue still occcur?

1. The program crashes while resizing the image window. It doesn't matter if I do it with the mouse along the edge of the picture window, or use ctrl + left mouse click.
The program slows down before crash. If not change the size of the window, everything works stably.

2. GURPS.
But I don't think Rulset has anything to do with it.

3. Extensions also do not matter, what is with them, what is without them - the program crashes under the same conditions.

4. The size of the map in pixels does not matter either. If there are few hexes in the grid, everything is stable, there are a lot of hexes - the program crashes if you pull the edge of the picture window.

5. To provoke a crash, simply insert any picture, and apply a grid of hexes so that the picture has a radius of 200 + hexes. And try to resize the picture window by dragging the mouse over the edge of the window. The program will slow down. If you pull a little faster, the program crashes.

6. The size of the picture does not matter.

7. I tried a new campaign in D&D5. It's all the same.

Optimist
April 3rd, 2024, 17:15
Some of the token functions, such as determining token visibility, are dependent on the grid. For example, when you decrease the grid from 10 to 1 you are increasing the number of grid cells by a factor of 100 for a square map. This is likely the cause of the crash that you are experiencing. I'll look into some additional measures to reduce the GPU cost for maps with a lot of grid cells on them, but there is always going to be some limit.

If there are no tokens on the map, the program crashes anyway.

Trenloe
April 3rd, 2024, 17:28
What operating system are you using?
"The program slows down before crash." - exactly what happens? Sorry to keep asking this, we've had many support cases when people say "crash" and it means different things to different people. Please describe exactly what happens...

Trenloe
April 3rd, 2024, 17:30
And does this occur only with a hex grid, or with a square grid as well?

Zacchaeus
April 3rd, 2024, 17:33
Do you have any other information such as the size and format of the map. I can't reproduce this with a 2750x2000px .jpg image with a grid size of 5.

Trenloe
April 3rd, 2024, 17:43
I can recreate by making a very small grid size - for larger maps I could induce the Unity crash handler appearing with a grid size of 2 or 3. For a smaller map, e.g. BattleMap01 from the FG Battle Maps module, I had to set a grid size of 1 and resize the window a few times to get the Unity crash handler appear and then FG exits.

See this video for an example:
https://www.dropbox.com/scl/fi/rdqnm3g65w348tuy7nx32/Small-grid-Unity-crash.mp4?rlkey=ebz79f45t8rp7j9vtvj7mzyqq&dl=0

Optimist
April 3rd, 2024, 18:00
What operating system are you using?
"The program slows down before crash." - exactly what happens? Sorry to keep asking this, we've had many support cases when people say "crash" and it means different things to different people. Please describe exactly what happens...

Windows 10.
https://youtu.be/TWB7EsaknsQ

Optimist
April 3rd, 2024, 18:01
I can recreate by making a very small grid size - for larger maps I could induce the Unity crash handler appearing with a grid size of 2 or 3. For a smaller map, e.g. BattleMap01 from the FG Battle Maps module, I had to set a grid size of 1 and resize the window a few times to get the Unity crash handler appear and then FG exits.

See this video for an example:
https://www.dropbox.com/scl/fi/rdqnm3g65w348tuy7nx32/Small-grid-Unity-crash.mp4?rlkey=ebz79f45t8rp7j9vtvj7mzyqq&dl=0

https://youtu.be/TWB7EsaknsQ