Quản lý tài nguyên - Họ có tốt không?

Tôi đã thấy nhiều lần trong mã nguồn, những thứ như thế này [tốt, đây là một ý tưởng giả C ++ của tôi]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

Tôi chỉ tự hỏi làm thế nào một lớp học như thế này hữu ích, một cái gì đó:

• Tải tập tin đa phương tiện
• Lưu trữ chúng trong bộ nhớ
• Đã làm điều này khi bắt đầu một màn hình tải cấp.
• Làm sạch

Thay vì có một hệ thống:

• Tài nguyên chỉ được tổ chức bởi các thực thể, hoặc lỏng lẻo.
• Chịu trách nhiệm tải riêng vào bộ nhớ.

Đầu tiên là một "người quản lý" như vậy; một cái gì đó tôi cảm thấy cho thấy nó sai khi sử dụng. Tuy nhiên, nó cho phép một cái gì đó giống như một vectơ tên tài nguyên được thông qua, thay vì phải tranh giành xung quanh để tìm mọi thứ cần được tải.

Một người quản lý tài nguyên tốt là chìa khóa cho mức độ - và mức độ linh hoạt - 'công cụ' trò chơi của bạn sẽ diễn ra.

Nó không chỉ giải quyết rất nhiều vấn đề với quản lý tài nguyên cấp thấp, mà còn giúp đảm bảo rằng tài nguyên chỉ được tải một lần, và sau đó được sử dụng lại nếu chúng đã được tải.

Nếu hệ thống tài nguyên được trừu tượng hóa tốt, các chi tiết cơ bản có thể cảnh giác giữa hệ thống tệp, lưu trữ Physfs, sql thậm chí ...

Bạn chỉ cần yêu cầu một tài nguyên, và nó được trao cho bạn.

Không cần phải lo lắng về ID tài nguyên và những thứ như vậy.

Xử lý xung đột tài nguyên trùng lặp, v.v.

Hãy để người quản lý tài nguyên sắp xếp nó ra.

Tùy thuộc vào cách bạn thiết kế nó - nếu C ++ thì hãy kết bạn với (các) lớp phối cảnh của bạn để đảm bảo quyền sở hữu được xử lý đúng cách.

Hồ bơi tài nguyên ?

Không vấn đề gì.

Quên giải phóng tài nguyên?

Không vấn đề gì.

Giao diện giống nhau cho các tài nguyên cho dù chúng ở đâu: bộ nhớ, đĩa, lưu trữ, mạng.

Không vấn đề gì.

Bạn có muốn phát trực tuyến?

Luồng?

Hãy để trung tâm quản lý tài nguyên của bạn chăm sóc điều đó.

Và bạn có thể yên tâm rằng nó sẽ thông báo cho bạn khi tài nguyên đã sẵn sàng để sử dụng.

Ogre 3D có một hệ thống quản lý tài nguyên rất linh hoạt, nhưng tôi chắc chắn có những cái khác 'ngoài kia'.

Gần đây tôi đã viết một trình quản lý tài nguyên hoạt động khá tốt cho trường hợp của tôi. Những đặc điểm chính:

• Tài nguyên được yêu cầu bởi ID chuỗi, ví dụ , ResourceManager::instance().getTexture("textures/player.png"). ID kết cấu hiện được ánh xạ thẳng vào một tệp trên đĩa, thuận tiện trong quá trình phát triển, nhưng điều này sau đó sẽ được thay thế bằng cách tra cứu trong một số kho lưu trữ.

• Trình quản lý tài nguyên giữ bản đồ ID cho các tài nguyên, do đó, nó sẽ không tải lại tài nguyên đã được tải.

• Cuộc gọi trên không trả về một Textuređối tượng, mà là một Resource<Texture>đối tượng; người gọi dự kiến ​​sẽ lưu trữ Resource<Texture>đối tượng chứ không phải kết cấu thực tế. Các Resource<Texture>hành vi như một con trỏ thông minh đến a Texture; nó operator*()trả về Texturechính đối tượng Ưu điểm là kết cấu thực tế có thể được tải lại hoặc tải xuống mà không cần cập nhật tất cả các máy khách.

• Trình quản lý tài nguyên kiểm tra định kỳ xem các tệp trên đĩa có thay đổi hay không và tải lại chúng nếu cần. Điều này cho phép tôi sửa đổi kết cấu hoặc đổ bóng và xem kết quả mà không cần khởi động lại trò chơi.

• Tài nguyên có thể phụ thuộc lẫn nhau. Hầu hết, nếu không phải tất cả, tài nguyên phụ thuộc vào Filetài nguyên, đó là tệp mà chúng được tải từ đó. Ví dụ, nếu một mô hình phụ thuộc vào kết cấu, mô hình sẽ được tải lại bất cứ khi nào tệp của kết cấu thay đổi trên đĩa.

• Khi không thể tìm thấy tài nguyên hoặc không tải được, tài nguyên mặc định sẽ được thay thế một cách âm thầm. Điều này cho phép tôi sử dụng các tài nguyên mà tôi chưa tạo, mà không làm hỏng trò chơi. (Tính năng đã được lên kế hoạch: cho biết các tài nguyên "thiết yếu" như trình tạo bóng GPGPU, mà không có trò chơi nào có thể chạy đúng cách cả.)

• Đếm tham chiếu và dỡ tải các tài nguyên không sử dụng, có thể được thêm dễ dàng. Vì trò chơi của tôi khá nhỏ, tôi chưa có nhu cầu này.

Tôi nghĩ rằng danh sách tính năng này cho thấy rằng, vâng, các nhà quản lý tài nguyên có thể tốt!

Một trong những lý do để có một người quản lý tài nguyên là việc chia sẻ tài nguyên. Ví dụ: khi bạn gọi resourceManager.Get("sprite.png"), nếu "sprite.png" đã được tải, trình quản lý tài nguyên có thể chỉ cần trả về một con trỏ tới tài nguyên sprite đã được tải thay vì tạo một hình ảnh mới và tải lại từ đĩa.

Trình quản lý tài nguyên cũng có thể lưu trữ tài nguyên, do đó, mặc dù tham chiếu cuối cùng đến tài nguyên đã bị hủy, trình quản lý tài nguyên có thể chọn giữ nó trong bộ nhớ trong trường hợp nó được tải lại trong tương lai gần. Trình quản lý tài nguyên sẽ được lập trình để tự động xử lý tất cả quản lý bộ nhớ với tài nguyên của bạn.

Cuối cùng, tôi nghĩ một tính năng rất hữu ích là tải lại tài nguyên trong trò chơi. Vì trình quản lý tài nguyên nắm giữ tất cả các tài nguyên trò chơi, bạn có thể xây dựng một chức năng khiến tất cả các tài nguyên được tải lại từ đĩa và cập nhật trò chơi trong thời gian thực, cực kỳ hữu ích cho các nghệ sĩ / nhà thiết kế làm việc với trò chơi của bạn .

Một lợi ích khác là, bên cạnh bộ nhớ đệm và đếm tham chiếu là nó có thể xử lý các phụ thuộc (mô hình một kết cấu cần b? Tôi sẽ lấy nó cho ya!) Và tải các vấn đề về thứ tự (mô hình cần biết shader b yêu cầu gì? Hãy để tôi tải shader b b trước khi tải mô hình!)