Dạo gần đây tôi có tham gia vào một dự án phát triển engine 3D mới cùng một đồng nghiệp vừa gia nhập công ty. Hiện tại chúng tôi vẫn đang xây dựng những nền tảng cơ bản nhất. Tính từ commit đầu tiên đến nay đã tròn 24 ngày với tổng cộng 129 lần cập nhật. Dự án tạm thời chưa có kế hoạch open source trong thời gian tới (dù có mở kho mã nguồn thì khả năng cao cũng chẳng mấy ai biết cách build thành phẩm). Tôi chỉ muốn nhấn mạnh rằng đây là một dự án đang trong quá trình phát triển sôi nổi.

Gần đây tôi vừa hoàn thành một thư viện toán học 3D được các đồng nghiệp sử dụng và nhận được nhiều góp ý quý giá. Những phản hồi này đã thúc đẩy quá trình hoàn thiện hệ thống trong suốt thời gian qua.

Ban đầu, việc áp dụng ký pháp nghịch Ba Lan (Reverse Polish Notation) trong các phép toán vector khiến nhiều người thấy không quen. Có ý kiến đề xuất xây dựng một trình biên dịch biểu thức để thuận tiện hơn. Tuy nhiên sau vài ngày sử dụng, chúng tôi nhận thấy rằng việc này không thật sự cần thiết nếu đã quen với tư duy ngược. Nhưng có một điểm gây nhiều khó khăn hơn: quy ước dấu của ID để quản lý vòng đời đối tượng.

Dự án dịch thuật tiếng Trung cho “Stellar 2.0”

Dự án dịch ngôn ngữ cho Stellar 2.0

Dự án bản địa hóa Stellaris 2.0

Từ trước Tết tôi đã để ý thông tin Stellaris sẽ phát hành phiên bản 2.0 sau Tết, và liên tục theo sát quá trình cập nhật để duy trì bản dịch tiếng Việt. Với bản cập nhật lớn như lần này, lượng văn bản cần hiệu đính chắc chắn rất đồ sộ, tôi đã chuẩn bị tâm lý cho khối lượng công việc khổng lồ này.

Từ phiên bản 5.2, Lua đã đơn giản hóa cơ chế quản lý mô-đun so với phiên bản 5.1 và duy trì cách tiếp cận này cho đến nay. Khi tải mô-đun bằng hàm require, mỗi mô-đun cùng tên chỉ được tải duy nhất một lần trong một máy ảo (VM). Các lần gọi tiếp theo sẽ trả về kết quả đã tải trước đó. Quá trình tải mô-đun sử dụng các mẫu chuỗi được định nghĩa trong package.path hoặc package.cpath để chuyển đổi tên mô-đun thành đường dẫn tệp tin tương ứng và lần lượt thử mở các tệp tin này.

Khi thực hiện các phép toán vector/matrix thuần túy bằng Lua trong các tình huống đòi hỏi hiệu năng cao thường không thể đáp ứng yêu cầu. Ngay cả khi đóng gói thành thư viện C, phương pháp truyền thống vẫn còn nhiều bất cập. Nếu mỗi đối tượng vector đều được bao bọc dưới dạng userdata, tỷ lệ dữ liệu hữu ích so với chi phí quản lý rất thấp. Một vector float 4 chiều chỉ chiếm 16 byte bộ nhớ, trong khi userdata lại yêu cầu thêm 40 byte phụ trợ. Đối với ma trận float 4x4 cũng chỉ lớn hơn chút đỉnh với 64 byte. Chưa kể gánh nặng GC do hàng loạt đối tượng tạm thời sinh ra trong quá trình tính toán.

Trong ngành công nghiệp game 2D hiện đại, tầng đồ họa hầu hết đều được xây dựng dựa trên nền tảng các API 3D. Để tối ưu hiệu suất rendering, các yếu tố đồ họa (sprite) thường được đóng gói vào cùng một texture atlas. Quy trình này có thể thực hiện thủ công ngoại tuyến hoặc tự động hóa theo thời gian chạy.

TexturePacker là một công cụ thương mại xuất sắc trong lĩnh vực này, nhưng theo quan điểm của tôi, việc tích hợp nó vào chuỗi công cụ phát triển vẫn tồn tại một số điểm cần hoàn thiện. Quá trình đóng gói sprite và tổng hợp texture atlas từ kết quả nên được tách biệt thay vì kết hợp. Trong quy trình phát triển lặp, khi chỉ sửa đổi một số lượng nhỏ sprite và kích thước chúng không thay đổi, việc tránh chạy lại thuật toán đóng gói sẽ tiết kiệm tài nguyên đáng kể.