D3D and Access Issues with Enhanced Images Extension

[HoloGnome]

If using the layers extension, you should try to keep your maps to 500K or smaller (and more like 1-200K, if possible - the smaller the better to limit memory management issues in FG). Use .jpg compression when ripping maps and go as low as you can on quality. Even at relatively high compression factors, most .jpg maps for RPG still look OK.

The layers extensions is going to triple the transfer to the clients, since it has 3 layers. So, if you are trying to use a 7mb map, you could be out of luck. The smaller the size of your map, the faster the transfer to clients and the less likely you will be to run afoul of memory management issues in FG.

Also, note that if you pre-apply a number of tokens on various layers and rotate them in different positions, the clients will not necessarily have the correct token orientation until you touch or re-rotate the ones on your master map.

[Trenloe]

The one that has the issue is 7.21MB and 5455 x 7500 pixels. Maybe thats why is producing trouble?

I've just done some testing with an image of this resolution (dimensions: 5455 x 7500) and it takes the following amount of memory when opened: 1 layer - 314MB (extension disabled), 3 layers (extension enabled) - 960MB. This is a lot of memory in a 32-bit application. Recommendation: reduce the resolution (pixel dimensions) significantly.

[Salva]

@Salva - when you are testing have Windows task manager open and see how much memory fantasygrounds.exe is using when you start to have issues. I'd recommend trying to reduce the size of the image file if you're using a lot of memory. FG is a 32-bit application so can't use all of your computer memory, it is limited.
Are you using 32-bit or 64-bit Windows? If you're using 32-bit you will have issues when memory use for fantasygrounds.exe gets above 1.6-1.7GB, if running 64-bit Windows you'll have issues above 3.5GB.

When loading FG it uses around 2,500 MB for the host or client (not sure which is one o another) and around 3,000 MB for the client or host. No changes when the issues appears only a mensage: "Runtime Error: Exception: bad allocation" on the host.
I have to say that yesterday when i disabled the extension i was able to load the original image of about 7.21 MB with no great issues, only that players couldnt rotate their tokens. The image takes some time to upload to my players but finally it did and we played normally.

They are large images. I rarely use an image over 1mb
I am curious - is your campaign called Temp? or Campaign?
Ive never seen a Temp subfolder or images created/stored in the campaign root...

The name of my campaign is “Coppernight Hold Delve” and is located in “C:\ProgramData\Fantasy Grounds\campaigns\Coppernight Hold Delve” and has the next archives: Attachment 15846
The images are inside “images” folder.
Is there any difference in loading FG with the integrated grafics card or with an NVidia Proceesor in an laptop?

-Finally i saved the image for web and reduce it to 2.52 MB
-Open host and client on mi lap.
-Open the image in the host and get “Runtime Error: D3DXCreateTexture failed - D3DPOOL_MANAGED” Close the console (GM) and was unable to rezise the image (can only see the upper left corner.
-I Close and reopen the image a couple of times and sometimes it opens normally but other times i got this message:

Runtime Error: Exception: bad allocation
Network Warning: Unable to locate requested file 'campaign/temp/drawing_snapshot_Oswald_1477334794'
Network Warning: Unable to locate requested file 'campaign/temp/drawing_snapshot_Oswald_1477334795'
Script Warning: onZoom: Recursive control event or call terminated (imagecontrol:image)
Ruleset Warning: imagecontrol: Could not find zoom status icon () for control (features_image) in windowclass (imagewindow)
Ruleset Warning: imagecontrol: Could not find zoom status icon () for control (play_image) in windowclass (imagewindow)
Runtime Error: D3DXCreateTexture failed - D3DPOOL_MANAGED
Runtime Error: D3DXCreateTexture failed - D3DPOOL_MANAGED
Runtime Error: Exception: bad allocation

-I close host and client and reopen them and in client got this message:

Network Notice: Client ruleset download complete
Runtime Error: Unable to create directory: C:/ProgramData/Fantasy Grounds/cache/Coppernight Hold Delve/usersettings
Runtime Error: Unable to save file (C:/ProgramData/Fantasy Grounds/cache/Coppernight Hold Delve/usersettings/hotkeys.xml) - Error (13): Permission denied

-Close the message.
-On host i open the image: no issues. Then share to client: gray image. Sync image but no luck. Reshare image: no luck. Close image on client and reshare from host and client crashed (no change in memory ussage).

I found this: When i open the images only with the host active no issue nor menssages appear, so it seems the problem is when the client is active.
Then i change the image to the "5E sample campaign" image folder and found no issues nor messages in open or sharing it. This makes me wonder that the problem has something to do with the campaing folder?


I will make more test with the image on the new campaign and try to delete files from the "problematic" campaign to see if that solves the problem.
Thank you very much.

PD: Same problem with the new campaign

[Salva]

I rezised the image: Monster dead so far.....
So it seems the issue has direct relation with the image size and the file size? o just the image size?
In that case which will be the max image size and the max file size?
Thank you very much.

[LordEntrails]

I rezised the image: Monster dead so far.....
So it seems the issue has direct relation with the image size and the file size? o just the image size?
In that case which will be the max image size and the max file size?
Thank you very much.

Image size.

File size impacts how long it takes to share and to store. Image size is how much RAM is required to have the image open and usable.

[Trenloe]

So it seems the issue has direct relation with the image size and the file size? o just the image size?

Please refer to details here: https://www.fantasygrounds.com/forum...l=1#post296075

Memory issues are related purely to the image dimension, not the file size.

FG is a 32-bit application and has only a limited amount of memory that it can use - it doesn't matter how much memory your computer has. As such, if you're using a lot of resources, then you will need to be aware of this and adjust as necessary. If you are going to open a lot of maps/images at the same time, these will all use computer memory. So, if you want to open a large sized map, then you will have to close the other maps/images currently open, and so will the players.

The smaller size (width x height) you make your maps and images and better. If you're using a map, use 50 pixels per 5 foot square. If you have a huge map, split it into smaller maps.

Don't load lots of tokens in your \tokens directory - these are all loaded into memory when FG starts.

[Trenloe]

Moved the posts to do with this issue to it's own thread. This issue seems very specific to Salva's system.

@Salva - please provide some details of your system:

1. Operating system - type, version and if 32- or 64-bit.
2. Version of Fantasy Grounds. Get this from the top right of the first page.
3. Which ruleset are you using and what version are they? Get this from the chat window after you've loaded Fantasy Grounds.
4. What extensions are you loading and what are their versions? Most of this will come from the FG chat window after loading.
5. How many tokens (number and total size) do you have in <FG app data>\tokens (and the sub directories).
6. What modules are you activating? Which are you sharing with the players?
7. Are you using any cloud backup applications on your FG data? (Box, DropBox, Google Drive, Drive, etc.).

I'd recommend you do testing in a CoreRPG campaign - v3.1.7 live, with only the enhanced images extension enabled. Keep checking on the memory used by Fantasy Grounds.

[Salva]

If you have a huge map, split it into smaller maps.

A great solution for not having to loose quality on image, thanks!!!!!

Don't load lots of tokens in your \tokens directory - these are all loaded into memory when FG starts.

Good to know, i will clean some of these that im currently wont use.

@Salva - please provide some details of your system:

1. Operating system - type, version and if 32- or 64-bit: 64-bit
2. Version of Fantasy Grounds. Get this from the top right of the first page:
3. Which ruleset are you using and what version are they? Get this from the chat window after you've loaded Fantasy Grounds.: -5E ruleset v3.1.7 for Fantasy Grounds
   Copyright 2015 Smiteworks USA, LLC and CoreRPG ruleset v3.1.7 for Fantasy Grounds
   Copyright 2015 Smiteworks USA, LLC
4. What extensions are you loading and what are their versions? Most of this will come from the FG chat window after loading.
   -Effect Targeting Enhancement v0.5 for FG v3.1.5 5E ruleset.
   Designed and Implemented by TASagent.
   Copyright 2016 Smiteworks.
   -Enhanced Images (layers) v1.0.8 for FG V3.1.3 CoreRPG ruleset and rulesets layered on top of CoreRPG. Copyright 2015 Smiteworks.
   Converted from the DrZeuss's 4E extension by Trenloe.
   -DOE Base Extension v1.2
   The Base Extension for all Dulux-Oz Extensions (DOEs). Includes an Alternate ColourGizmo allowing the use of Hexadecimal Colour Codes to set a User's Dice Colours.
   For Fantasy Grounds v3.1.7+, the CoreRPG Ruleset and selected child Rulesets.
   Copyright ©2004-2016 Peregrine I.T. Pty Ltd.
   -DOE Sound Extension v1.0
   An Extension that intergrates and automates sounds using Syrinscape.
   For Fantasy Grounds v3.1.7+, the CoreRPG Ruleset and selected child Rulesets.
   Copyright ©2004-2016 Peregrine I.T. Pty Ltd.
5. How many tokens (number and total size) do you have in <FG app data>\tokens (and the sub directories).: 2844 files, 61 folders, 297 MB, but going to clean them
6. What modules are you activating? Which are you sharing with the players?:
   I had a lot open. Actually only have “La Casa de La Muerte by TelArin” not shared, “Doe Sound Manual” not shared and Core rules (player one shared).
7. Are you using any cloud backup applications on your FG data? (Box, DropBox, Google Drive, Drive, etc.).: Nope

Thank you very much

[Trenloe]

Hi Salva - this is very much looking like FG was getting overloaded on your system.

1. Reduce the number of tokens you have in your tokens directory. Copy them to another location to allow you to do some testing with much less tokens - in the long run make them into FG token modules you can activate just when you need them.
2. Only share player modules with the players. Do not share scenario modules with the players - this has a big impact on player side resource use. The GM should share individual scenario records when needed - and clear up sharing (remove the (p) or (s) icons) when no longer needed. As the GM don't keep modules you don't currently need open in the library.
3. Reduce the resolution of your main maps/image that you plan to keep open.

After you've done all this, clear the player cache again before doing testing with a player instance connected.

Hopefully this will make a difference.

[Salva]

I'd recommend you do testing in a CoreRPG campaign - v3.1.7 live,

I Forget to say that Im not sure if i understand this or how to do it.

Hi Salva - this is very much looking like FG was getting overloaded on your system.

1. Reduce the number of tokens you have in your tokens directory. Copy them to another location to allow you to do some testing with much less tokens - in the long run make them into FG token modules you can activate just when you need them.
2. Only share player modules with the players. Do not share scenario modules with the players - this has a big impact on player side resource use. The GM should share individual scenario records when needed - and clear up sharing (remove the (p) or (s) icons) when no longer needed. As the GM don't keep modules you don't currently need open in the library.
3. Reduce the resolution of your main maps/image that you plan to keep open.

After you've done all this, clear the player cache again before doing testing with a player instance connected.

Hopefully this will make a difference.

Memory has passed from 2,500 MB and 3,000 MB to 1,941 MB and 1,583 MB.
First test with the rezised image: OK
Second test with the unrezised imaged but optimized in file size 2.52 MB: OK (takes longer to load)
Third test with the original image (the huge one in file and image size): OK (takes much longer to load).
Its pending the test with real players and anyway im planning to use, like you suggested, a smaller map (gonna Split the actual one).
Thank you very much

PD: Is there a max or recommended image size or just i have to try the smalller posible?