Half-Sizing > Add settings to manifest, more documentation, event

[oodavid]

The half-sizing feature is a key part of GC, however it is somewhat mysterious in it's operation. I know Jimmy has recently rewrote the halfsizing system so I thought it good timing to add this feature-request:

Manifest

I would like to see half-sizing settings added to the manifest, whereby we can choose something along the lines of:

• Memory usage that triggers half-sizing (%age)
• Resolution that triggers half-sizing (smaller than)

_NB_ - I'm not sure that these are necessarily the best settings, nor that they map to the internal logic.

Event / Callback

It would be useful to have an event we can subscribe to when halfsizing kicks in, while I can't think of a case where I would programatically react to the event, it would be useful for analytical uses, ie:

• some devices trigger halfsizing after sustained gameplay = possible memory leak
• to highlight key devices to test on (small screen+high memory, or vice-versa)

Documentation

Just the necessary documentation for the above, plus warnings about allocating too much memory on iOS

Related

https://groups.google.com/forum/#!topic/game-closure-devkit/TVCaoV8YGAE

Tag: Feature Request, Enhancement

[rogueSkib]

Updated for markdown, sorry for spamming 😅

Sorry for the late reply! I think this is a great feature request!

The new half-sizing / texture management algorithm I implemented solves a number of problems across a wide range of devices with the following goals in mind:

• Allow devkit games to keep as many textures in memory as possible to minimize time spent loading textures
  • Loading and reloading textures can cause frame skips during gameplay
• Half-size textures as a last resort to avoid texture-cycling load loops
  • We want to guarantee the best resolution possible on each device while not affecting game performance

Algorithm logic:

• Maintain an estimated (moving) memory limit
  • by default, the limit starts at 500 MB
  • on Android, the limit starts at half of the device's memory, if available
  • if we receive a memory warning on iOS or we catch a GL_OUT_OF_MEMORY error in general, we scale the limit down by a constant factor
  • if we request more memory than our current limit, scale the limit up by a constant factor
• Clearing textures
  • each tick, throw out least-recently-used textures if our estimated memory limit is exceeded
• Half-sizing
  • if the device dimensions are less than or equal to a certain number of pixels, half size on app start
  • if we throw out textures until we find a texture that was used on the same tick, then we are rendering so much to the screen in a single tick that we can't keep it all in memory, therefore we must half-size textures to avoid texture-cycling (constantly discarding and reloading textures each tick, which is very bad and ruins gameplay, performance etc)

I think that about sums it up! As time permits, we should expose some of these constants and events to JavaScript so that games can react differently.