Slow supply Hub response and map scroll using 5 key

[littleike]

Depending of the base hex selected with the 5 key to display flow supply the game goes from normal to very slow performance at the point that with some bases (es. Perth or Melbourne) game seems to freeze before showing numbers after many seconds. Moreover scroll of the map consequently freezes taking many seconds to do a step till a new press of the 5 key let numbers disappear and map scroll return very fast.

Using -dd_sw switch made things goes better (at least playable) but slowness is always present depending from the base choosen and scroll of the map consequently remain extremely slow.

Note that with or without -dd_sw and/or –cpu1 combinations things don’t change. Game is always very fast with scroll of the map and response to mouse selections everywhere; so i think there is something related to key 5 usage that slow the system as soon as the terrain distance from the base hub increase.

[Yaab]

Interesting. I have had slow scrolling when pressing Y or R key. The -dd_sw switch fixed it. Thought it would work the same for 5 key.

[chemkid]

.

[Oberst_Klink]

Try -SingleCpuOrders instead of -CPU1.

Klink, Oberst

[littleike]

Maybe it is as you think chemkid.

Seems that scrolling the map with numbers displayed every step of scroll system will do some sort of deep calculation but if it was a cpu bound trouble the -dd_sw switch should have had no influence on the time of calculus beeing more related to some graphic management where instead time to show numbers decrease using this switch but the scroll trouble remain.

I supposed that system will recalculate everything when scroll let appear or disappear on the screen hexes interested in the calculus but neither this is the case because I tried with a base in alaska where all hexes calculated are visible on screen and scroll is also affected.

Not a big deal anyway when I saw that game don't freeze.

For Oberst_Klink

Thanks for the suggestion. Tried but don't resolved.

[BBfanboy]

ORIGINAL: littleike

Maybe it is as you think chemkid.

Seems that scrolling the map with numbers displayed every step of scroll system will do some sort of deep calculation but if it was a cpu bound trouble the -dd_sw switch should have had no influence on the time of calculus beeing more related to some graphic management where instead time to show numbers decrease using this switch but the scroll trouble remain.

I supposed that system will recalculate everything when scroll let appear or disappear on the screen hexes interested in the calculus but neither this is the case because I tried with a base in alaska where all hexes calculated are visible on screen and scroll is also affected.

Not a big deal anyway when I saw that game don't freeze.

For Oberst_Klink

Thanks for the suggestion. Tried but don't resolved.

If the game is programmed to draw the base map view before calculating the supply flow and presenting it, moving the map will result in recalculation, and a long delay.
Graphic speed always suffers when you add more layers of detail to present. Try enabling patrol zone highlighting with the 6 key, then add hex side ownership with the W key and Roads and Rails with the R key. Now try scrolling ....

[Bullwinkle58]

ORIGINAL: BBfanboy

If the game is programmed to draw the base map view before calculating the supply flow and presenting it, moving the map will result in recalculation, and a long delay.
Graphic speed always suffers when you add more layers of detail to present. Try enabling patrol zone highlighting with the 6 key, then add hex side ownership with the W key and Roads and Rails with the R key. Now try scrolling ....

Not going to search, but I believe Michael did make comments on CPU load when this feature was added. Given that supply can trace 360 and has to check terrain, enemy presence for each hex in the path, etc. for every iteration I can see how it would bog down.

[littleike]

Hi BBfanboy

I don't have patrol zones because I made a new install from scratch after windows 10 installation.
With every combined option with whom I toggle the map (W/R 3 4 6) map scroll is beyond the standards.

The issue I wrote about can be easily replayable.( If not it would be that it is a trouble related to my configuration and I would be happy to hear this).

Try to set key 5 to a mayor Australia city hex and look both to time to see numbers and time to scroll.

I think there is something related to supply display path (at least maybe there are no limitations to how far an hex could be to enter it in the computing path) but I assure you that before I accounted for a long program response time I was sure that the game was freezing.

Bullwinkle58

Surely things are as you remember. Calculations are really impressing. As I said before no big issue when I know that game function well.

[BBfanboy]

ORIGINAL: littleike

Hi BBfanboy

I don't have patrol zones because I made a new install from scratch after windows 10 installation.
With every combined option with whom I toggle the map (W/R 3 4 6) map scroll is beyond the standards.

The issue I wrote about can be easily replayable.( If not it would be that it is a trouble related to my configuration and I would be happy to hear this).

Try to set key 5 to a mayor Australia city hex and look both to time to see numbers and time to scroll.

I think there is something related to supply display path (at least maybe there are no limitations to how far an hex could be to enter it in the computing path) but I assure you that before I accounted for a long program response time I was sure that the game was freezing.

Bullwinkle58

Surely things are as you remember. Calculations are really impressing. As I said before no big issue when I know that game function well.

Yes - I have said in some recent posts about supply movement that it can take as much as two minutes for the calculation of all the supply paths from a given hex. There is no way to shorten this part of the function. My point was that there could be a recalculation with scrolling, rather than just a re-presentation of the results already calculated in the first instance.

[Korvar]

I believe the slowness is related to the graphics processing - not the computation of the supply flow.

All the hex numbers generated have to be rendered in realtime; therefore, they have to be constantly redrawn as you scroll the map - as opposed to the map itself which is loaded once into memory when the game is first started and accessed as needed.

The realtime graphics is vector art (i.e. math/formula based) and the other graphics assets like the map, icons, ship art, etc. are raster art (i.e. pixel based).

[witpqs]

ORIGINAL: Korvar

I believe the slowness is related to the graphics processing - not the computation of the supply flow.

All the hex numbers generated have to be rendered in realtime; therefore, they have to be constantly redrawn as you scroll the map - as opposed to the map itself which is loaded once into memory when the game is first started and accessed as needed.

The realtime graphics is vector art (i.e. math/formula based) and the other graphics assets like the map, icons, ship art, etc. are raster art (i.e. pixel based).

That has been my working assumption for years with the various display options. I just work around it by pressing the toggle key to undo whatever it is (weather, search arcs, patrol zones, *anything*) and then press the toggle again after I have scrolled to where I want.

[michaelm75au]

Correct. It is the graphic rendering that is intensive, more than the calculation[:D].
The option was expected to be turned on/off as needed, not left on.[;)]

[Korvar]

Edit: false alarm - I thought I run across a way to correct the slow scolling while supply flow is displayed... I was in the wrong mode; I haven't had my coffee yet. [:D]