03 — Particle & VFX

Nguồn: chưng cất từ restore SOT com.Chodun.CatGunner 1.1.59 (BardCat). Mọi C# ở đây là L1 ANALYSIS, không phải source gốc.

1. Câu hỏi tài liệu này trả lời

Game idle sinh hiệu ứng liên tục: mỗi viên đạn trúng, mỗi cây đổ, mỗi cục quặng vỡ. Nếu mỗi hiệu ứng là một Instantiate thì GC sẽ giết frame-rate trên điện thoại. CatGunner ship 7 718 ParticleSystem trong một scene duy nhất và vẫn chạy — tài liệu này mô tả cách nó làm được.

2. Stable truths

3. Mô hình hành vi

3.1 Hai kiểu pool cho hai bài toán khác nhau

Đây là điểm kiến trúc quan trọng nhất, và rất dễ làm sai nếu chỉ có một loại pool.

(a) Particle_Polling — pool ở mức HẠT, không phải mức object.

// L1 ANALYSIS — RVA 0x2ABB458
public void Spawn(Vector3 Pos, int Count)
{
    ParticleSystem.EmitParams emitParams = default(ParticleSystem.EmitParams);
    emitParams.position = Pos;
    emitParams.applyShapeToPosition = true;
    for (int i = 0; i < _particleSystem.Length; i++)
        _particleSystem[i].Emit(emitParams, Count);
}

Không có GameObject nào được tạo, bật, hay tắt. Có một ParticleSystem (hoặc một nhóm nhỏ) tồn tại vĩnh viễn, và mỗi lần cần hiệu ứng ta chỉ bơm thêm hạt vào nó tại một toạ độ. Unity tự quản lý buffer hạt; chi phí mỗi lần "spawn" gần bằng 0.

applyShapeToPosition = true nghĩa là shape module của system (hình cầu, hình nón…) vẫn được áp tương đối so với Pos, nên vẫn có tán xạ ngẫu nhiên như một burst bình thường.

Ba slot static (instance, instance_dust, instance_slime) là ba "kênh" hiệu ứng khác nhau (vàng rơi / bụi đá / nhớt slime), mỗi kênh một pool riêng, đăng ký bằng Particle_index đặt trong inspector. Không có lookup theo tên, không có dictionary — chỉ là ba biến static.

(b) Polling_manager — pool ở mức GAMEOBJECT, cho thứ cần state riêng.

Chỉ hai loại: Bullet và Bullet_FX. Đây là những thứ không thể là hạt vì chúng cần collider, Rigidbody, và trạng thái riêng (_hitIds, _pierceCount). Runtime cho thấy cả Object_Polling lẫn Object_Polling_Smart chạy 207 lần — đúng bằng số lần bắn — nên mỗi phát bắn lấy một Bullet và (qua Bullet.SpawnFX) một Bullet_FX từ pool.

Quy tắc rút ra: nếu hiệu ứng không cần state hay va chạm, đừng pool GameObject — hãy pool hạt. 7 718 ParticleSystem trong scene chỉ khả thi vì phần lớn chúng là những system tồn tại sẵn được Emit() vào, chứ không phải object được sinh/huỷ.

3.2 Throttle FX — ba tầng chặn

// FXThrottle (static class) — dump.cs:596485
private static readonly Record[] _last;      // ghi nhớ lần spawn cuối theo gunNum
private const float MIN_INTERVAL = 0.05f;    // tối đa 20 FX/giây cho cùng một nguồn
private const float MIN_DIST_SQ  = 2.25f;    // = 1.5^2 — quá gần lần trước thì bỏ
private static int   _frameCount;
private static int   _spawnThisFrame;
private const int    MAX_PER_FRAME = 3;      // trần cứng mỗi frame

public static bool CanSpawn(int gunNum, Vector3 pos) { … }

Ba tiêu chí độc lập: 1. Theo thời gian — cùng một khẩu súng không sinh FX nhanh hơn 20 Hz. 2. Theo không gian — FX cách lần trước dưới 1.5 đơn vị bị bỏ (mắt người không phân biệt được, nhưng GPU vẫn phải vẽ). 3. Theo frame — dù có gì xảy ra, tối đa 3 FX mới mỗi frame.

Tiêu chí (3) là thứ cứu frame-rate ở những khoảnh khắc tệ nhất (nổ AoE trúng 20 quái cùng lúc). Hai tiêu chí đầu giảm rác trong trạng thái bình thường.

Và ở tầng gọi, Bullet còn có SpawnFX_Once — chỉ cho phép một FX cho toàn bộ vòng đời một viên đạn xuyên/laser, bất kể nó trúng bao nhiêu mục tiêu.

3.3 Tránh GetComponent trên hot path

// Bullet.SpawnFX — RVA 0x2B086A8
GameObject fxObj = Polling_manager.instance.Object_Polling(Objects_Type.Bullet_FX);
if (fxObj == null) return;
if (!_fxCache.TryGetValue(fxObj, out Bullet_FX fx))
{
    fx = fxObj.GetComponent<Bullet_FX>();
    _fxCache[fxObj] = fx;               // static Dictionary<GameObject, Bullet_FX>
}
if (fx != null) fx.Spawn(gunNum, pos);

Vì pool có số phần tử hữu hạn và cố định, dictionary này bão hoà sau vài frame đầu và sau đó không bao giờ gọi GetComponent nữa. Đây là mẫu chuẩn cho mọi pool: cache lookup theo instance đã pool, không theo prefab.

Bullet_FX.Skin_Reload áp dụng cùng ý tưởng ở tầng thấp hơn:

// RVA 0x2B096FC — .ctor đặt _lastGunNum = -1
if (_lastGunNum == GunNum) { particle?.Clear(); particle?.Play(); return; }  // đường nhanh
particle?.Stop(); particle.gameObject.SetActive(false);
particle = Skin_particles[GunNum];
particle.gameObject.SetActive(true);
particle.Clear(); particle.Play();
_lastGunNum = GunNum;

Vì người chơi hiếm khi đổi súng, nhánh nhanh chạy gần như 100 % thời gian: không SetActive, không đổi tham chiếu, chỉ Clear() + Play() — cách rẻ nhất để "phát lại" một burst.

3.4 Trả object về pool bằng thời gian, không bằng callback

// Destroy — RVA 0x2AC65A0
public void Active() { gameObject.SetActive(true); restart coroutine Disable(); }
private void OnEnable()  { restart coroutine Disable(); }
private void OnDisable() { if (cor != null) { StopCoroutine(cor); gameObject.SetActive(false); } }
private IEnumerator Disable() { yield return new WaitForSeconds(Destroy_Time); gameObject.SetActive(false); }

Và Bullet dùng Invoke("Deactivate", _deactivateDelay) (mặc định 1f) thay vì coroutine.

Cả hai đều là hẹn giờ tự trả về, không phải "hiệu ứng báo cho pool khi xong". Đơn giản hơn, và quan trọng hơn: không thể rò rỉ — kể cả khi logic gọi bị lỗi, object vẫn tự tắt.

Chi tiết đáng chú ý: Destroy.OnDisable cũng gọi SetActive(false) khi coroutine còn sống. Điều đó khiến một object bị tắt sớm vẫn ở trạng thái nhất quán khi được lấy lại từ pool.

3.5 Số lượng hiệu ứng theo ngữ cảnh

Hằng số Count truyền vào Spawn là cần gạt "độ hoành tráng":

Một dòng is_Boss ? 15 : 5 là toàn bộ sự khác biệt giữa "chết thường" và "chết boss" ở tầng hạt. Rẻ, dễ chỉnh, và không cần prefab riêng.

4. Framework takeaway

1. Hai tầng pool, phân loại theo "có state hay không". IParticleBurstPool : Emit(channel, position, count) // không GameObject, chi phí ~0 IObjectPool<T> : Rent(type) / tự trả về theo hẹn giờ // cho thứ có collider/state Đa số VFX thuộc loại thứ nhất. Nếu framework chỉ cung cấp loại thứ hai, người dùng sẽ pool GameObject cho mọi thứ và trả giá bằng hàng nghìn SetActive mỗi giây.

2. Kênh hiệu ứng là hằng số đánh chỉ số, không phải chuỗi. Particle_index 0/1/2 → instance/instance_dust/instance_slime. Không lookup theo tên, không dictionary trên hot path. Framework nên phơi ra một enum kênh.

3. Throttle là hạ tầng bắt buộc, không phải tuỳ chọn. Ba tiêu chí — thời gian, khoảng cách, trần mỗi frame — nên nằm sẵn trong IParticleBurstPool với tham số cấu hình được. Đặc biệt trần mỗi frame là thứ duy nhất cứu được kịch bản xấu nhất.

4. Cache mọi lookup theo instance đã pool. Pool có kích thước hữu hạn ⇒ cache bão hoà ⇒ chi phí lookup về 0. Áp dụng cho GetComponent, cho Bullet_FX theo gunNum, cho mọi thứ.

5. Đường nhanh "không có gì đổi" cho việc đổi skin/biến thể FX. So sánh với giá trị lần trước và thoát sớm. Người chơi đổi trang bị hiếm; đừng trả giá cho nó mỗi lần bắn.

6. Object tự trả về pool bằng hẹn giờ. Không phụ thuộc callback từ logic gameplay — nó sẽ có ngày không được gọi.

7. Độ hoành tráng là một số nguyên count, không phải một prefab khác.

5. Negative evidence & UNKNOWN

Cách khoá các UNKNOWN trên: đọc Polling_manager + FXThrottle từ ARM64 tại RVA đã ghi; và tra ngược 2 GUID kia trong [report: l1_script_identity.json] mở rộng sang các assembly plugin.

6. Raw evidence

• [reconstructed: Particle_Polling.cs] — pool hạt (disasm-proven)
• [reconstructed: Bullet_FX.cs] — FX trúng đích có pool
• [reconstructed: Bullet_Mesh.cs] — mảng ParticleSystem bật/tắt
• [reconstructed: Destroy.cs] — tự trả về pool theo hẹn giờ
• [reconstructed: Ore.cs] — call-site instance_dust
• [evidence codegen: Tree.cs] — call-site instance, count 15 vs 5
• [evidence codegen: Bullet.cs] — SpawnFX / SpawnFX_Once / _fxCache
• dump.cs:596485 (FXThrottle), :589342 + :589369 (Objects_Type, Polling_manager)
• [runtime trace: runtime_ranking.json] — tần suất thật
• [report: asset_lane.md] §3, §4a — thống kê scene

7. Đã đóng bởi FEEL lane (2026-09-05) — cập nhật cho §5