Skip to content

Game.EndFrameBarrier

Assembly:
Assembly-CSharp (typical for game code / mods; adjust if the project uses a different assembly)

Namespace:
Game.Simulation

Type:
struct — actually the provided source defines Game.Simulation.WatercraftLaneSelectBuffer (a value type wrapper around a NativeArray)

Base:
System.ValueType

Summary:
The provided source defines WatercraftLaneSelectBuffer, a small utility struct that lazily ensures a NativeArray buffer exists and exposes it via Ensure(). The buffer is created with a fixed length of 64 and Allocator.Temp. The struct also exposes Dispose(), but in the supplied implementation Dispose is empty — this is likely an oversight and can lead to leaked native memory if the buffer is created and never disposed. The buffer is suitable only for extremely short-lived use because it uses Allocator.Temp; consider using TempJob or Persistent depending on lifetime requirements.


Fields

  • private Unity.Collections.NativeArray<float> m_Buffer
    Holds the underlying native float array used for lane selection data. Created on first call to Ensure() with a length of 64 and Allocator.Temp; until Ensure() is called m_Buffer.IsCreated will be false. Because this is a NativeArray (native memory), it must be disposed when no longer needed to avoid native memory leaks. Note: Allocator.Temp is intended for very short-lived allocations (within the same frame). If you need the buffer across frames, use Allocator.TempJob or Allocator.Persistent instead.

Properties

  • (none)
    This struct exposes no properties in the provided source — only methods Ensure() and Dispose().

Constructors

  • (implicit) default constructor
    The struct uses the implicit default constructor. m_Buffer is initially an uninitialized NativeArray (IsCreated == false).

Methods

  • public Unity.Collections.NativeArray<float> Ensure()
    Lazily creates the m_Buffer if it is not already created and returns it. Implementation details from the source:
  • If m_Buffer.IsCreated is false, it assigns: m_Buffer = new NativeArray(64, Allocator.Temp, NativeArrayOptions.UninitializedMemory);
  • Returns m_Buffer.
  • Notes and caveats:

    • The array length is hard-coded to 64.
    • Allocator.Temp is used — suitable only for single-frame usage.
    • NativeArrayOptions.UninitializedMemory is used, so contents are not zeroed when created.
    • Callers should not assume memory has been cleared.
    • Because the buffer can be created, callers (or the struct) should dispose it when finished.
  • public void Dispose()
    Currently a no-op in the provided source. This should be implemented to dispose the native array safely:

  • Recommended implementation: if (m_Buffer.IsCreated) m_Buffer.Dispose();
  • Additional recommended habit: after disposing, you could reset m_Buffer to default to avoid accidental use.
  • Because the original uses Allocator.Temp, ensure Dispose is called within the same frame that Ensure() is called, or switch to a different allocator if the buffer must survive longer.

Usage Example

// Example using the provided struct, with a safer Dispose implementation:
public struct WatercraftLaneSelectBuffer
{
    private NativeArray<float> m_Buffer;

    public NativeArray<float> Ensure()
    {
        if (!m_Buffer.IsCreated)
        {
            m_Buffer = new NativeArray<float>(64, Allocator.Temp, NativeArrayOptions.UninitializedMemory);
        }
        return m_Buffer;
    }

    public void Dispose()
    {
        if (m_Buffer.IsCreated)
        {
            m_Buffer.Dispose();
            m_Buffer = default; // avoid accidental reuse
        }
    }
}

// Example usage in code:
var buf = new WatercraftLaneSelectBuffer();
var arr = buf.Ensure();
// fill arr[0..N] or read values...
// When finished (same frame if using Allocator.Temp), dispose:
buf.Dispose();

Additional recommendations: - If the buffer is intended to be used across frames or by jobs, prefer Allocator.TempJob (for short-lived job use) or Allocator.Persistent (for long-lived). Adjust the lifetime and Dispose timing accordingly. - Consider exposing length or making the capacity configurable instead of hard-coding 64. - Consider zero-initializing the array (or explicitly setting values) if callers assume cleared memory.