Lý do cho các tệp dữ liệu nguyên khối

Question

Chủ yếu đây có vẻ là một kỹ thuật được sử dụng bởi trò chơi, nơi chúng có tất cả các âm thanh trong một tệp, hoạ tiết trong một v.v ... Với những tệp này thường đạt kích thước GB. Lý do đằng sau việc thực hiện điều này là duy trì tất cả trong thư mục con như các tệp nhỏ - một tệp cho mỗi kết cấu mà nhiều trò chơi nhỏ sử dụng, với hệ thống nguyên khối được các công ty lớn hơn ưa thích?

Có một số chi phí hệ thống tệp với nhiều tệp nhỏ không? Họ đang cố gắng bảo vệ tài sản của họ - mặc dù hầu hết dường như chỉ là một tệp nén với phần mở rộng mới?

Answer 1

Những lý do chúng tôi sử dụng một hệ thống "archive" như thế này, nơi tôi làm việc (một công ty phát triển trò chơi):

• tra cứu tốc độ: Chúng tôi hiếm khi cần phải lặp qua các tập tin trong một thư mục; chúng tôi thường tìm kiếm chúng trực tiếp hơn bằng tên. Bằng cách sử dụng "bảng phân bổ tệp" tùy chỉnh, về cơ bản chỉ là một chuỗi hash(normalized_filename) -> [ offset, size ], chúng tôi có thể tra cứu các tệp rất nhanh chóng. Chúng tôi cũng có thể giữ chỉ mục này trong RAM, có khả năng xen kẽ chỉ mục này với các bảng chỉ mục khác, v.v.
• (Khi chúng tôi cần lặp lại, chúng tôi có thể dễ dàng lặp qua tất cả các tệp trong .arc hoặc chúng tôi có thể lưu trữ danh sách tên tệp , danh sách các tên tệp băm hoặc chỉ một danh sách các cặp [bù đắp, kích thước] ở đâu đó - thậm chí có thể là tệp trong tệp lưu trữ. Đây thường là nhanh hơn thư mục truyền trên FS.)
• siêu dữ liệu: Thật dễ dàng để chúng tôi lưu trữ bất kỳ siêu dữ liệu tệp nào mà chúng tôi muốn. Ví dụ: một bit trong trường "kích thước" cho biết tệp có được nén hay không (nếu có, nó có tiêu đề có nhiều chi tiết hơn về cách giải nén tệp đó). Chúng tôi thậm chí có thể thay đổi nén trên các mảnh của một tập tin nếu chúng ta biết đủ về cấu trúc của tập tin trước thời hạn (chúng tôi làm điều này cho lưu trữ sprite).
• kích thước: Một trong các thiết bị chúng tôi sử dụng có kích thước "tệp phải là bội số của X", trong đó X lớn so với một số tệp của chúng tôi. Ví dụ, một số kịch bản lua của chúng ta kết thúc chỉ là vài trăm byte khi được biên dịch; lấy thêm chi phí cho mỗi tập tin .luc tăng lên nhanh chóng.
• căn chỉnh: mặt khác, đôi khi chúng tôi muốn để lãng phí dung lượng. Để tận dụng luồng phát nhanh hơn (ví dụ: nền DMA) từ hệ thống tệp, một số tệp của chúng tôi do muốn tuân theo các yêu cầu về kích thước/liên kết nhất định. Chúng tôi có thể chăm sóc quyền đó trong công cụ và sắp xếp/kích thước chúng tôi chụp không nhất thiết phải xếp hàng với FS bên dưới, cho phép chúng tôi lãng phí dung lượng chỉ khi chúng tôi cần.

Nhưng đó là những lý do chính đáng. Nội dung thú vị hơn:

Mỗi .arc đăng ký trong danh sách và cố gắng mở tệp biết để tìm trong vòng cung.Chúng tôi tìm kiếm lưu trữ đã có trong RAM trước, sau đó lưu trữ trên thiết bị FS, sau đó là thiết bị FS thực tế. Điều này cho chúng ta một tấn linh hoạt:

• động bổ sung vào hệ thống tập tin: bất cứ lúc nào chúng ta có thể truyền một tập tin mới hoặc lưu trữ vào máy tính này trong câu hỏi (qua mạng hoặc tương tự) và có nó xuất hiện như một phần của hệ thống tập tin "hợp lý"; điều này thật tuyệt vời khi FS thực sự nằm trong ROM hoặc trên CD và cho phép chúng tôi lặp lại nhanh hơn nhiều so với cách khác.
• (hệ thống .wad Doom là một loại ví dụ ở trên, cho phép modders dễ dàng hơn ghi đè lên các tài sản và các kịch bản được xây dựng vào trò chơi.)
• khả năng không fs cơ bản: Có thể sử dụng bin2obj nhúng toàn bộ vòng cung trực tiếp trong tệp thực thi (.rodata) tại thời điểm liên kết, tại thời điểm đó bạn không bao giờ cần phải nhìn vào thiết bị FS - chúng tôi thực hiện việc này đối với một số bản dựng mẫu nhỏ nhất định và tương tự. Chúng tôi cũng có thể gửi các cấp trên mạng hoặc savegame-sneakernet theo cách này. =)
• tổ chức và tải/dỡ hàng: vì chúng tôi có thể tải và bỏ và ghi đè các phần "ảo" của hệ thống tệp của mình bất cứ lúc nào, chúng tôi có thể thực hiện một số thủ thuật hiệu suất với số lượng tệp trong FS tại bất kỳ thời điểm nào. Chúng tôi cũng có thể chỉ định rằng toàn bộ lưu trữ được tải vào bộ nhớ, bảng chỉ mục và dữ liệu; Mã tải tệp của chúng tôi đủ thông minh để biết rằng nếu tệp đã có trong bộ nhớ, nó không cần phải làm bất cứ điều gì để đọc nó ngoài việc di chuyển con trỏ xung quanh. Một số mã mức cao hơn có thể thực sự phát hiện rằng tệp nằm trong ram và chỉ yêu cầu trực tiếp con trỏ có lẽ-trông-như-một-struct.
• tính di động: chúng tôi chỉ cần tìm hiểu cách tải một vài tệp trên mỗi thiết bị mới mà chúng tôi sử dụng và sau đó phần còn lại của mã FS ít nhiều giống nhau. =) Chúng tôi thỉnh thoảng thay đổi công cụ ra một chút (vì lý do căn chỉnh), nhưng hầu hết quá trình xử lý vẫn giữ nguyên.
• de-duplication: với lưu trữ thông minh hơn, chẳng hạn như lưu trữ sprite của chúng tôi, chúng tôi có thể (và làm) dữ liệu trùng lặp. Nếu khung thứ năm của hoạt hình "nhảy" và khung thứ ba "đá" là như nhau, chúng ta có thể kéo ra ngoài tệp và chỉ lưu trữ một bản sao của khung đó. Chúng tôi có thể làm tương tự cho toàn bộ tệp.

Chúng tôi đã chuyển trò chơi PC sang hệ thống có quyền truy cập FS chậm hơn nhiều gần đây. Chúng tôi đã không thay đổi định dạng dữ liệu, và hóa ra việc lặp lại thông qua một thư mục trên thiết bị nguyên FS để tải một trăm tệp XML nhỏ đã hoàn toàn giết chết thời gian tải của chúng tôi. Giải pháp mà chúng tôi sử dụng là lấy từng thư mục, đặt nó vào subdir.arc của riêng nó và dán nó vào mã nén chính game.arc. Khi thư mục cần thiết (một cái gì đó như opendir đã được gọi), chúng tôi giải nén toàn bộ subdir.arc vào RAM, thêm nó vào hệ thống tập tin, sau đó lặp lại thông qua siêu nhanh.

Đó là khả năng để ném một cái gì đó như thế này với nhau trong một vài giờ, và để giảm bớt nỗi đau của porting trên hệ thống, mà làm cho những thứ như thế này đáng giá.

Answer 2

Hệ thống tệp có phí. Thông thường, một tệp có dung lượng đĩa được làm tròn lên đến một số sức mạnh của 2 (ví dụ: tối đa 4 KB), vì vậy nhiều tệp nhỏ sẽ lãng phí dung lượng. Một số hệ thống tệp hiện đại cố gắng giảm thiểu điều đó, nhưng AFAIK vẫn chưa phổ biến rộng rãi. Ngoài ra, các hệ thống tệp thường khá chậm khi truy cập nhiều tệp. Ví dụ. nó thường nhanh hơn đáng kể để sao chép một tệp 400 MB so với 4000 tệp 100 KB.

Hệ thống tệp có ích khi bạn phải sửa đổi tệp, vì chúng xử lý các kích thước tệp thay đổi tốt hơn nhiều so với bất kỳ giải pháp đơn giản nào do nhà trồng. Tuy nhiên, đó chắc chắn không phải là trường hợp cho dữ liệu trò chơi liên tục.

Answer 3

Trên hệ thống Apple, cách phổ biến nhất là sử dụng, như bạn đề xuất, thư mục. Chúng được gọi là Gói và nằm trong Trình tìm kiếm được biểu diễn dưới dạng một tệp nhưng nếu bạn khám phá chúng nhiều hơn, chúng thực sự là các thư mục. Điều này làm cho việc viết mã và bảo tồn bộ nhớ khi tải các mục riêng lẻ ra khỏi gói này rất dễ dàng. :-) Ngoài ra, điều này làm cho việc sao lưu gia tăng cơ sở dữ liệu khổng lồ dễ dàng, ví dụ như cơ sở dữ liệu iPhoto của bạn chỉ là một gói, vì vậy bạn chỉ cần sao lưu thay đổi và các tệp mới

Trên Windows, tôi tin rằng điều này khó hơn nhiều Do đó, nó sẽ giống như một thư mục "không có vấn đề gì" (Tôi chắc rằng những người thông minh đã tìm thấy một giải pháp mà sẽ làm cho Explorer thấy một số thư mục như một tập tin duy nhất, nhưng nó không phổ biến). Từ quan điểm của nhà phát triển trò chơi, bạn không xử lý các tệp nhỏ đến mức không gian đĩa trên đó là điều bạn quan tâm nhiều, vì vậy tôi nghi ngờ đề xuất của @ doublep, vì nó gây ra rắc rối như vậy, nhưng nó làm cho nó dễ dàng hơn nhiều với một tập tin duy nhất nếu người dùng là để sao chép toàn bộ trò chơi trên một nơi nào đó, sau đó nó dễ dàng để kiểm tra xem toàn bộ thiết lập là chính xác.

Và, tất nhiên, khó đọc hơn đối với những người không nên có quyền truy cập vào nó. Nhưng nó cũng khó sửa đổi hơn, có nghĩa là khó vá hơn và khó hơn để viết các phần mở rộng. Một người nào đó sử dụng các phần mở rộng rất nhiều, thích cấu trúc thư mục: The Sims.

Tôi là nhà phát triển trò chơi, tôi rất thích đi cho từng tệp. Sau đó, một lần nữa, tôi muốn được sử dụng bó như tôi muốn được viết cho Mac ;-)

Cheers

Nik

Answer 4

tôi có thể nghĩ ra nhiều lý do.

Như đề xuất kép, tệp chiếm nhiều không gian hơn trên đĩa so với yêu cầu. Vì vậy, một kho lưu trữ tiết kiệm không gian. Các tệp 10k (có kích thước bất kỳ) sẽ giúp bạn tiết kiệm 20MB khi được đóng gói vào một tệp lưu trữ. Không chính xác một lượng lớn không gian ngày nay, nhưng vẫn còn.

Lý do khác tôi có thể nghĩ là phân mảnh đĩa.Tôi nghi ngờ một đĩa bị phân mảnh nặng sẽ hoạt động tồi tệ hơn khi truy cập hàng ngàn tệp riêng biệt trên một không gian phân mảnh. Nhưng tôi không có chuyên gia trong lĩnh vực này, vì vậy tôi sẽ đánh giá cao nếu ai đó có kinh nghiệm xác minh điều này.

Cuối cùng, tôi nghĩ rằng điều này cũng có thể liên quan đến việc hạn chế quyền truy cập vào các tệp trò chơi riêng biệt. Bạn có thể có một loạt các kịch bản Lua tiếp xúc, gây rối với họ và phá vỡ một cái gì đó. Hoặc bạn có thể có âm thanh điện ảnh/âm thanh/văn bản bên ngoài/bất kỳ thứ gì bị lộ ra và bị hư hỏng bằng cách truy cập nó. Tôi cũng làm như vậy: Tôi mã hóa hình ảnh bằng khóa XOR đa, đóng gói tệp văn bản và biến cấu hình thành tệp nguyên khối (được nén để bảo mật thêm) và chỉ để nhạc được truy cập miễn phí. Bằng cách này, bí mật của trò chơi sẽ vẫn chưa được khám phá thêm một chút nữa :).

Hoặc có thể có một lý do khác mà tôi chưa bao giờ nghĩ đến: D.

Answer 5

Khi bạn biết các trò chơi, đặc biệt là với các công ty lớn hơn, hãy cố gắng thu hút nhiều hiệu suất nhất có thể. Một kỹ thuật là để có tất cả các dữ liệu trong một tập tin lớn và chỉ DMA nó vào bộ nhớ (nghĩ về nó như một memcpy từ đĩa CD sang RAM). Vì tất cả các tệp trong một tệp lớn sẽ không có đĩa tìm kiếm và bạn có thể có một số lượng tệp lớn (có thể gây ra lượng tìm kiếm lớn) tất cả được nạp nhanh vì kỹ thuật này.