Phiên bản Lua 5.1 rc4 vừa chính thức được phát hành hôm nay. Qua kiểm tra, so với rc3 chỉ có hai thay đổi nhỏ: một là điều chỉnh macro lua_popen trong tập tin luaconf.h, hai là bổ sung tính năng hỗ trợ số thập lục phân.

Trước đó vài ngày, chủ đề này đã được thảo luận sôi nổi trên danh sách email của cộng đồng Lua. Thực tế, yêu cầu hỗ trợ số hex đã xuất hiện từ lâu. Cá nhân tôi cũng từng tự viết bản vá để thêm tính năng này. Trong cuộc thảo luận, Roberto - một thành viên cốt lõi của dự án - đã đề xuất giải pháp chỉ cần sửa đổi macro #define lua_str2number(s,p) trong luaconf.h. Tôi đã thử nghiệm và thấy phương pháp này vô cùng tinh tế, đồng thời đã đóng góp thêm vài ý kiến bổ sung.

Từ phiên bản 5.1, Lua đã chính thức giới thiệu một chuẩn mực thống nhất cho việc triển khai module - đây là một bước tiến đáng ghi nhận. Trong quá trình tìm hiểu tài liệu và mã nguồn liên quan gần đây, tôi nhận thấy cơ chế này được thiết kế rất tinh tế. Nếu xét về yếu tố đơn giản, nó thậm chí còn vượt trội hơn cả Python :)

Một ván cờ kinh điển

Hồi còn đi học, tôi say mê cờ vây đến mức gần như lấn át cả niềm đam mê lập trình. Nhưng có lẽ trời sinh không cho tôi tố chất kỳ thủ, dù chăm chỉ nhưng trình độ cứ dậm chân tại chỗ. Sau khi đi làm, nhịp sống hối hả khiến tôi dần chuyển hướng hứng thú, thỉnh thoảng chỉ còn tranh thủ đánh vài ván cờ chớp trên mạng. Mà càng đánh lại càng tệ, bởi bản chất tôi là kiểu người thích suy nghĩ kỹ lưỡng, thích những cuộc chiến long trời lở đất, ưa thích lối tư duy sáng tạo. Khi thời gian suy nghĩ bị rút ngắn, tự nhiên không thể theo kịp đối thủ. Tuy nhiên, sự phát triển của internet cũng mang lại nhiều tiện ích cho giới cờ vây, như việc nghiên cứu phổ cờ (game record) giờ đây dễ dàng hơn xưa rất nhiều.

Trong các cảnh quan 3D của game, bản đồ độ cao (heightmap) thường được sử dụng để biểu diễn địa hình ngoài trời. Cấu trúc này dùng mảng hai chiều để lưu trữ thông tin độ cao tương ứng với từng tọa độ mặt phẳng. Việc lựa chọn độ phân giải cho mỗi giá trị độ cao ảnh hưởng trực tiếp đến chất lượng và hiệu suất xử lý.

Vấn đề về dung lượng lưu trữ

Nếu dùng 1 byte để biểu diễn mỗi giá trị độ cao, không gian 256 mức độ cao thường không đủ đáp ứng cho các địa hình phức tạp. Do đó, các nhà phát triển thường chọn kiểu dữ liệu word (2 byte) hoặc float (4 byte) để đạt độ chính xác cao hơn. Trong đó, kiểu float mang lại nhiều lợi thế vì không cần xử lý hệ số tỷ lệ (scale factor), nhưng lại tiêu tốn gấp 4 lần dung lượng so với byte.

Ngày hôm nay đã đến - ngày mà thông báo mong đợi cuối cùng cũng xuất hiện: Lua 5.1 (final) đã chính thức được phát hành tại địa chỉ Chúng tôi xin chân thành cảm ơn sự kiên nhẫn của tất cả mọi người trong suốt quá trình phát triển đầy thử thách này. Đặc biệt cảm ơn những đóng góp quý báu từ cộng đồng - những ý kiến đó đã giúp Lua ngày càng hoàn thiện hơn. Hãy cùng trải nghiệm phiên bản mới! Và bây giờ chúng tôi sẽ tập trung vào việc phát triển phiên bản 5.2 :-) –lhf

Vài hôm trước, tôi viết một bài blog về phép chuyển đổi qua lại giữa số nguyên và số thực dấu phẩy động. Những con số thật sự rất kỳ diệu! Lúc đó tôi nghĩ nguyên lý hẳn không quá phức tạp nên lười tìm hiểu kỹ.

Hôm nay, trong lúc chạy chương trình, tôi bất ngờ phát hiện một lỗi nghiêm trọng do kỹ thuật này gây ra. Có chỗ hoạt động đúng, có chỗ lại sai lệch hoàn toàn - kết quả chuyển đổi ra toàn số 0. Dù suy nghĩ rất nhiều cách giải thích nhưng vẫn không tài nào hiểu nổi. Cuối cùng đành phải ngồi nghiên cứu lại từ đầu cách thức kỹ thuật này vận hành. Đến lúc đó mới vỡ lẽ đây là vấn đề liên quan đến độ chính xác của phép toán dấu phẩy động. Dự án của chúng tôi sử dụng client d3d, và sau khi khởi tạo thiết bị d3d, độ chính xác trong các phép tính với kiểu double đã bị thay đổi mà không báo trước.