[James Ross]

disc, on 10 July 2015 - 04:46 AM, said:

Wouldn't a newer .net framework usage, and 64bit OR would hide these problems?

Newer .NET wouldn't make any difference, but 64bit OR would. It isn't a panacea or anything, though, as (at least for now) some people still use 32bit OSes and having more virtual memory doesn't mean there won't be other problems from too much memory usage. For example, we'd be able to easily use more virtual memory than physically exists in most PCs, which would create entirely different but still problematic issues (e.g. paging).

We'll certainly go 64bit when we can, but it shouldn't excuse us from using memory wisely and carefully. <_<

[ChrisD]

Just wondering. Is it not possible to gracefully deal with this SEH Exception error without crashing? Seems that You already have nailed the File I/O errors, and have taught OR how to survive these.

ChrisD

[James Ross]

ChrisD, on 10 July 2015 - 11:53 AM, said:

Just wondering. Is it not possible to gracefully deal with this SEH Exception error without crashing? Seems that You already have nailed the File I/O errors, and have taught OR how to survive these.

Oh, I guess we can. :) It hadn't occurred to me that it was not already trying, but it's terrain - which is currently not allowed to fail, but we can probably change that easily enough. Missing terrain will look way worse than the odd missing building does though.

[jbnx42]

All, I am the one who had the OutOfVideoMemoryException reported at Launchpad #1471414. At Edward's request of this morning, I tried his change to x3190 attached to post 34 on this thread. *IT WORKED*.

From the log:
Information: Allocation for 49,999 particles:

7,999,840 B RAM vertex data
1,199,976 B RAM index data (temporary)
7,999,840 B VRAM DynamicVertexBuffer
1,199,976 B VRAM IndexBuffer

Further details and the full log are at Launchpad.

Next week I will try more activities, perhaps even some that include precipitation!

Thanks for the fix!
John

[ChrisD]

James Ross, on 10 July 2015 - 01:00 PM, said:

Oh, I guess we can. :) It hadn't occurred to me that it was not already trying, but it's terrain - which is currently not allowed to fail, but we can probably change that easily enough. Missing terrain will look way worse than the odd missing building does though.

Without knowing the exact programming details, my idea is based on an assumption, so please forgive me if I am wrong. :hi:

I presume that tiles are loaded as the active train is crossing a boundy between 2 tiles. Depending on the selected visual range, new tiles that has come into view is loaded and tiles that has moved out of range is pruned

I my example with 10 Km's Visual range, I assume that the skipped assets and also (when You have made the change) the skipped terrain is located far away from the viewer and is therefore hardly ever noticed.

When we move and the terrain/assets not loaded is direct in our path, we are due to see the shortcommings in 8 Km's time. (not good)

Here is my idea to solve that.

When an I/O Out of memory Error forces OR to skip loading assets, make a note in a small table containing the Number of the Tiles that are not loaded completely. Same procedure for any terrain, not loaded.

Now when a new boundry is crossed, prune the Tiles that has moved out of range, just as You presumeably do now, but before loading new tiles that has come into view, load the tiles stored in the table.

This way missing assets/terrain will be loaded in plenty time before we reach them.

What do You think?

ChrisD

Edit: If this idea is introduced, we can also save a lot of I/O errors with resultant log entries. When the first Out of memory Error is detected, skip loading the tile, put it into the table for later load. This way each tile will generate one I/O Error only.
Suggestion, tile loading should follow the position of the camera, not the train. (If CAB view is selected, tile loading will then still actually follow the train pos.) but scenery will load better when free roaming camera view is selected.

[edwardk]

As of X3192, the ability to choose the precipitation box size has been submitted.

Edward K.