Skip to main content

TpLibInit and TpLib Memory allocation

The static library TpLib.cs has several Dictionaries that keep track of all TPT tiles.

The initial size of these dictionaries is set by constants in the TpLib.cs file. Similarly, pooled Dictionaries and Lists have a constant size when new pooled instances are created.

These constant size values are small. It is possible to change these allocations during App startup with the TpLib.Resize method. An instance of the TpLibMemAlloc class is passed to Resize.

One could change the constants themselves, however, updating the Plugin will naturally revert these values. Hence, Resize is a better choice.

There’s no reason to use this feature in an editor session. At runtime, use Resize immediately/soon after startup.

Internally, Resize releases all pooled items and resets MaxNumClonesPerUpdate and MaxNumDeferredCallbacksPerUpdate to their initial values.

The TpLibMemalloc values for pooled Dictionaries and Lists affect the size of new pooled instances of

  • Dictionary<Vector3Int,TilePlusBase>
  • List<TilePlusBase>

These are created and pooled frequently and optimizing this size can have a significant effect on performance.

TpLibInit

This is a scriptable object in a resources folder that you can use to set up memory allocations and certain optional features. It's in TilePlus/Runtime/Resources/Tp. TpLib startup code examines this asset and uses the following fields:

  • Active: the asset is ignored if this is false.
  • RefreshRequestsPerUpdate: Maximum number of Tile Refresh Requests per-internalUpdate
  • TargetFrameRate: useful for diagnostics. Shown in System Info editor window.
    • If zero, adaptive features are disabled (not discussed herein)
  • UsePlayerLoop: if true, TpLib modifies the PlayerLoop, if false, uses an Awaitables-based updater.
  • ResizeMemory: if true, use the following info to resize memory.
    • MemAlloc: various fields for memory allocations. Read up before changing these.
  • InhibitTilemapCallbacks. Normally false. Useful for debugging. Bad for production.
  • RecloneCachedTiles: Normally true. See below.

PlayerLoop

Using the PlayerLoop timing is the best choice unless it inteferes with your project code somehow. When TpLib shuts down (app closes) or (Unity state change Play->Edit) it terminates the Awaitables-based updater OR restores the default Player loop.

If you are using PlayerLoop in your app and this doesn't work for you, subscribe to the OnResetPlayerLoop callback (it's not an Event, only one subscriber allowed.). Before restoring the default Player Loop, this callback is invoked.

If the callback exists and returns false then the default Player Loop is restored. If the callback returns true then it's assumed that you handled this situation yourself and no further action is taken.

RecloneCachedTiles

This is used by the Layout/Chunking system. When the Layout system is used it internally creates a cache of data in each TileBundle for rapid loading or re-loading of tiles.

For TPT tiles, these are clones of the archived, Locked, TPT tile assets which are sub-objects of the Bundle asset.

If the tile has any state variables (fields) which are modified during the time that a TPT tile is actually loaded onto the Tilemap, what's actually affected are the cached, cloned tiles.

If these were unloaded and re-loaded later then the modified fields will still be modified. But what's usually desirable is a 'fresh' TPT tiles. So one should usually leave RecloneCachedTiles true.

However, this has a small performance penalty. If you want to set this value to false, please read this first.

Back to top