1 frame bao nhiêu ms? Đổi 60FPS / 120FPS sang mili giây cho Unity & game

Mỗi tháng lại có người hỏi: “1 frame 60FPS là bao nhiêu ms?” — câu trả lời toán học chỉ một dòng (1000 ÷ 60), nhưng trong Unity và game loop, nhầm ngân sách thiết kế với thời gian đo được, hoặc dùng số 16.67ms khi đang nhắm 120Hz, sẽ làm animation lệch và hitch khó giải thích cho producer.

Bài này tập trung đổi FPS → ms/frame cho người học Unity và team indie nhỏ (đặc biệt làm mobile / web game), kèm bảng tra, công thức ngược, lỗi VSync/deltaTime, và quy trình profiler thực tế.

Bài viết này giúp bạn

• Nhớ công thức và bảng 30 / 60 / 90 / 120 / 144
• Phân biệt budget frame vs frame time đo được
• Tránh nhầm Time.deltaTime với fixedDeltaTime
• Áp dụng cho CSS / requestAnimationFrame khi làm web game
• Dùng công cụ tính FPS ⇔ ms không cần cài app

---

Công thức cốt lõi

ms mỗi frame     = 1000 ÷ FPS
giây mỗi frame   = 1 ÷ FPS
frame → giây     = số_frame ÷ FPS
giây → frame     = giây × FPS

Ví dụ ở 60FPS:

Phép tính	Kết quả
ms/frame	16.67ms
giây/frame	0.0167s
120 frame	2 giây
0.5 giây	30 frame

Khi một frame vượt ngân sách (ví dụ logic + render > 16.67ms ở target 60), bạn drop frame — cảm giác giật, input trễ, animation “nhảy”.

Không cần nhớ hết số lẻ: mở Tính FPS & Frame Time, nhập 60 / 120 / 90 hoặc nhập ngược ms để ra FPS cần thiết.

---

Bảng tra nhanh FPS → ms

Lưu ý quan trọng: FPS cao hơn tần số quét màn hình (60Hz / 120Hz) thì mắt không “thấy thêm frame” trên panel đó. Đo 300FPS trên scene trống với VSync tắt không chứng minh game mượt trên máy khách hàng.

---

Ngân sách frame ≠ thời gian đo được

Team mới học Unity thường mắc bốn lỗi:

1. Nhầm budget với wall-clock — Có thể chỉ dành ~8ms cho game logic trong khung 16.67ms; GPU + present ăn phần còn lại.
2. Dùng math 60FPS khi target 120 — 120FPS = 8.33ms, không phải 16.67ms. Giảm một nửa ngân sách không phải tùy chọn.
3. “30 là gấp đôi 60” — Đúng hướng (≈33.33ms), đủ cho design; audio sync vẫn cần bước mẫu riêng (44100 Hz), đừng giả định frame math = DSP.
4. Bỏ qua fixed vs variable timestep — Update() + Time.deltaTime khác physics 50Hz cố định.

Quy tắc thực dụng: để headroom. Đừng thiết kế 16.0ms công việc trong khung 16.67ms — một spike GC hoặc I/O là đủ để hitch.

---

Unity: deltaTime, FixedUpdate, VSync

// Thời gian giữa hai frame render (biến thiên)
float dt = Time.deltaTime; // ~0.0167s nếu đang ~60FPS

// Bước physics cố định — thường 0.02s (50Hz), KHÔNG bằng render FPS
float fixedDt = Time.fixedDeltaTime;

Application.targetFrameRate = 60; // gợi ý; tùy nền tảng
QualitySettings.vSyncCount = 1;   // khóa theo refresh màn hình

Case học Unity phổ biến ở lab / freelance VN: animation keyframe viết theo “60FPS” (mỗi key cách 1/60s) nhưng physics chạy FixedUpdate 50Hz. Khi nhân khoảng cách bằng 1f/60f trong FixedUpdate, chuyển động lệch so với editor preview. Hãy khớp hệ thống bạn đang tune: render → deltaTime; physics → fixedDeltaTime.

VSync ON trên màn 60Hz ≈ trần ~16.67ms/frame nếu giữ được target. VSync OFF có thể đo FPS rất cao ở scene trống — hữu ích để tìm bottleneck, không phải tiêu chí ship.

Timeline / WaitForSeconds dùng giây, không phải ms. WaitForSeconds(0.5f) = nửa giây ≈ 30 frame ở 60FPS — đừng ghi WaitForSeconds(16.67f).

---

Web / canvas / CSS animation

requestAnimationFrame thường fire theo refresh (60 hoặc 120Hz). Callback cần xong trước paint kế — ngân sách xấp xỉ 1000 / refreshRate ms trừ phần browser và GPU.

Với CSS / sprite sheet: lệch một frame trong walk cycle 12 frame rất rõ ở 60FPS, gần như vô hình ở 30FPS. Đó là lý do bảng ms/frame hữu ích cả cho frontend làm game nhỏ hoặc landing có motion nặng.

---

Case study: hitch trên máy mid-range

Bối cảnh: Indie 2D Unity, target 60FPS trên điện thoại Android tầm trung (phổ biến khi playtest với bạn bè / QA thuê ngoài). Trên PC dev ổn định 120+ FPS.

Triệu chứng: Profiler trên thiết bị thật: Update + UI layout thỉnh thoảng 22–28ms → drop dưới 60.

Cách xử lý theo ngân sách:

1. Xác nhận target ship = 60 → budget 16.67ms, không phải “càng cao càng tốt”.
2. Chia: logic 6ms / physics 3ms / render+UI 5ms / headroom ~2ms (ví dụ — điều chỉnh theo game).
3. Tách việc nặng (pathfinding, spawn hàng loạt) sang nhiều frame hoặc job khi vượt budget.
4. Tra cứu nhanh “bao nhiêu frame trong 2.5s ở 60?” bằng máy tính FPS khi sync VFX với audio cue.

Bài học: Số 16.67ms chỉ hữu ích khi bạn đo trên máy mục tiêu và so với budget — không khi chỉ nhìn FPS counter trên laptop gaming.

---

Quy trình làm việc đề xuất

1. Chốt FPS ship theo máy thấp nhất (mobile 30/60, PC 60/120, VR ≥90).
2. Tính 1000 / targetFps — hoặc nhập vào công cụ FPS.
3. Phân bổ logic / physics / render / present + headroom.
4. Đặt targetFrameRate / VSync cho khớp môi trường test.
5. Validate trên thiết bị ship, ghi budget vào PR hoặc Notion team để producer hiểu “tại sao tắt effect này”.

Công cụ chạy trên trình duyệt, không cần đăng ký — tiện khi ngồi quán net / máy lab trường chỉ có Chrome.

---

Checklist trước khi ship

• Đã chọn FPS target và ghi ms/frame tương ứng
• Không dùng 16.67ms khi document nói target 120
• Animation/physics khớp Update vs FixedUpdate
• Profiler trên thiết bị thấp nhất, không chỉ Editor
• Để headroom — budget không sát 100% khung
• Audio cue không giả định sample rate = frame rate

---

Câu hỏi thường gặp (tóm tắt)

60FPS → ms? ≈16.67ms. 120? ≈8.33ms. 30? ≈33.33ms.

Có cần 120FPS không? Chỉ khi màn và genre cần (competitive, ProMotion). Mobile indie thường thắng ở ổn định 60 hơn peak 120 không ổn định.

Công cụ nào tra nhanh? Máy tính FPS & Frame Time trên Kawa — nhập FPS hoặc ms, đổi hai chiều.

---

Liên kết liên quan

• Máy tính FPS ⇔ ms (không cần cài)
• Danh sách công cụ