Link

1. Multi-threading from ground up

A multi-threading Shark 3D core

The whole Shark 3D uses a multi-threading architecture from ground up. As one benefit, you can easily load levels and world parts in a separate thread while Shark 3D is running in the foreground.

Optimized for performance

The whole multi-threading design is optimized for performance. It avoids synchronization overhead as far as possible, and avoids that multiple thread access shared data.

Link

2. Loading in the background

Easy to use

Loading level and world parts in the backgroud is very easy for the game scripter: With one script command, you can load a level or world part. If loading has finished, you get a notification you can again handle via scripting.

Smart resource management

If world parts re-use the same resources, it is not necessary to duplicate these resources. Due to the integrated multi-threading architecture of the Shark 3D core, world parts which share resources like objects, textures, and shaders can be accessed by multiple threads. This can safe memory siginifcantly.

For example, when loading a new world part in the background, the world part may use a texture which is already in usage by the renderer in the foreground thread. The resource manager handles this situation smartly without allocating the texture a second time.

Link

3. Huge persistent worlds

Swapping world parts in the background

You can not only load but also also save world parts in the background.

Effectively you can swap in and out level parts of an unlimited large world. When swapping out a level part, the whole state of each level part can be written to disk and can be loaded again.

Huge persistant worlds without loading screen

As result, you can create arbitrary large persitent worlds. The player can expore these worlds without loading screen.

Link

4. Roubustness

Background loading, multithreading is protected against multi-threading bugs and crashes.

For example, when loading or storing a level in the background. this level part is frozen automatically and disconnected from other scripts which are not thread-safe. This avoids that a script accidentially accesses objects which are currently loaded or saved in another thread.