Release 0.0.11

Fix loading screen crash caused by clearing with a null depth-stencil buffer.

During managed loading screen initialization, the active depth-stencil buffer is temporarily set to null after the loading render target state is changed.

EndDraw restored the saved depth-stencil buffer only after calling Clear(). This meant that, during scene transitions, Clear() could be called while GraphicsDevice.DepthStencilBuffer was still null, even though ClearOptions.DepthBuffer and ClearOptions.Stencil were requested. As a result, the game could crash when the loading screen finished.

Restore the saved depth-stencil buffer before clearing the device so the depth and stencil clear operations always have a valid buffer.

Release 0.0.10

Keep avatar animations alive during deinitialization.

Animation data is very memory-heavy, so character deinitialization was changed
to release animation controllers, clips, models and templates for deinitialized
characters. This works for NPCs because they are properly reinitialized when
they are re-added from a saved state.

Avatars are handled differently by the engine when checkpoint savegames are
loaded. They can be deinitialized when the old scene state is cleared, but they
do not go through the same reinitialization path as NPCs afterwards. As a result,
clearing their animation/model data caused missing animations when a checkpoint
restore triggered scripted avatar animations, such as the confuse animation
applied to all avatars at the start of the mind game in Grimnir's boss battle.

Move the animation cleanup from Character.Deinitialize to
NonPlayerCharacter.Deinitialize so NPCs still release their large animation data,
while avatars keep the animation resources they need throughout the active game.

Release 0.0.9

Fix rendering disable handling during restarts

Revert RestartAtCheckPoint and RestartLevel back to DisableRendering() instead of AwaitDisabledRendering().

AwaitDisabledRendering() is still useful in code paths where rendering could otherwise access assets while they are being disposed, but using it during checkpoint or level restarts could enter a path where rendering was never enabled again, leaving the game stuck in an endless loop.

Keep AwaitDisabledRendering() only where it prevents disposal-related render crashes, and use the simpler DisableRendering() path for restart flows.

Release 0.0.8

Restore PlayState-level loading for level-owned assets

Revert the previous attempts to load several level-owned assets through
Game.Content or GameScene.Content instead of PlayState.Content.

Loading these assets through Game.Content caused disposed asset instances to be
reused across levels. Some cached assets, such as character templates, are
cleared and disposed when a level ends. Since Game.Content still considered them
loaded, later levels could receive the same already-disposed instances again.

Loading them through GameScene.Content was also unsafe, because character
templates, items, and physics entity templates then only lived for the scene in
which they were first loaded. This could leave later scenes without valid asset
instances after a scene transition, especially for dropped or spawned items.
It may also have contributed to multiplayer join crashes when the joining player
first loaded the initial scene of a level, then switched to the host's current
scene after the first scene had already been unloaded.

These assets are now loaded through PlayState.Content again, so their lifetime
matches the whole level rather than the global game instance or a single scene.
This may keep more assets alive during a level, but the existing memory
optimisations should still keep overall memory usage under control while avoiding
disposed or prematurely unloaded asset instances.

Release 0.0.7

Fix avatar template lifetime during join and defer character select menu unload

Load player character templates through PlayState.Content instead of the
current scene content manager. Player avatars can be created during lobby join
or hotjoin before a GameScene is fully available, so loading through
CurrentScene.Content could fail.

This also gives player avatar templates the correct lifetime. Player avatars
persist across scene transitions, so their templates should be owned by the
PlayState rather than by a single scene.

Also defer profile texture unloading while the character select menu is still
active. This prevents avatar/profile textures from being unloaded while the menu
may still reference them during join or transition flow.

Release 0.0.6

Fix stale cached weapon items after scene content disposal

Weapons cached from scene-owned item assets could survive in the item cache even
after the SharedContentManager had disposed their graphics resources. When the
same weapon was requested later, the cache still returned the old Item instance,
but its model, textures, or other graphics assets could already be disposed,
causing crashes when the item was used or rendered.

Remove disposed weapon items from the cache instead of keeping stale references.

Also keep track of weapon asset names separately. Items that originate from
character templates are still first loaded through the scene content manager, as
before. However, if such an item is picked up and carried into a later scene, the
previous scene may unload and dispose the original asset. When the weapon is
needed again and no valid cached instance remains, reload it through the
PlayState content manager instead, so player-carried weapons can survive scene
transitions without being unloaded by the next GameScene cleanup.

Release 0.0.5

Remove PlayState finalizer and avoid creating Flash during cleanup.

The PlayState finalizer could call Dispose long after the PlayState had already
been cleaned up explicitly.

Also avoid touching Flash.Instance during PlayState cleanup. Disposing Flash did
not release anything useful, but accessing the singleton could lazily create it
for the first time during cleanup, at a point where the game may no longer be in
a valid state to load the flash effect.

Release 0.0.4

Fix shared content disposal and ability template lifetimes

Fix shared content disposal and character template lifetimes

SharedContentManager now tracks disposable objects created during asset loading
and disposes them when the owning asset is released. Disposable objects that are
the asset itself or one of its direct child assets are removed from the loose
disposable-object list so they remain managed by the reference-counted asset
graph instead of being disposed twice or too early.

This finally allows scene transitions to release GPU/content resources instead
of steadily accumulating them across scenes.

The previously disabled Dispose methods for Character, Avatar, Entity,
NonPlayableCharacter, and CharacterTemplate have been restored. This exposed a
lifetime bug in several abilities, such as Summon Spirit: some ability character
templates were loaded through Game.Content even though character templates are
disposed when a PlayState ends. Game.Content could therefore keep returning
already-disposed template instances with cleared fields or released resources.

Those ability templates are now loaded through PlayState.Content instead, so
their lifetime matches the active level and they are recreated cleanly after
scene transitions.

Release 0.0.3

Fix render re-enable timing for scene transitions and save loading

Fix render re-enable timing for scene transitions and save loading

Move Game.Instance.EnableRendering() out of the unsafe scene-unload path.

Savegame loading can temporarily load the first scene of a level, then load
the actual saved scene, and finally unload the initially loaded scene while
the loading screen is still active. Re-enabling normal game rendering during
that unload caused the loading screen and RenderManager to use incompatible
buffers, which could crash saved-game loading.

Instead, re-enable rendering from safer load-task points:

- after normal scene changes have been queued
- after PlayState exit cleanup has waited for rendering to be disabled
- after the old PlayState is no longer the active state

Release 0.0.2

• roll back stencil buffer changes that did not improve memory behaviour
• roll back render scene recreation during scene transitions