Jak umieścić wszystkie obrazy z gry w jednym pliku?

Właśnie skończyłem podstawową grę RPG napisaną w C ++ SFML, włożyłem wiele wysiłku w tę grę i chciałbym ją rozpowszechniać, jednak natknąłem się na mały problem.

Problem w tym, że mam ponad 200 obrazów i plików map (są to pliki .txt, które przechowują kody map) wszystkie w tym samym folderze co plik wykonywalny, kiedy patrzę w folder, sprawia, że ​​chce mi się trochę płakać tak wielu zasobów, nigdy nie widziałem gry, która pokazuje wszystkie zasoby bezpośrednio, zamiast tego uważam, że pakują zasoby w określony plik.

Cóż, właśnie to staram się osiągnąć: mam nadzieję, że spakuję wszystkie obrazy w jednym pliku (być może również pliki .txt), a następnie będę mógł odczytać z tego pliku lub łatwo go dodać.

Programiści gier polegali na jednej z dwóch głównych metod przechowywania danych:

• przechowuj każdy plik danych jako osobny plik
• przechowuj każdy plik danych w niestandardowym formacie archiwum

Wadą pierwszego rozwiązania jest problem zmarnowanego miejsca na dysku, a także problem wolniejszych instalacji.

Drugie rozwiązanie zapewnia własne pułapki, po pierwsze, musisz napisać cały swój obraz / dźwięk / etc. ładowanie procedur korzystających z niestandardowego interfejsu API w celu uzyskania dostępu do zarchiwizowanych danych. Kolejną wadą jest to, że musisz napisać własne narzędzie do archiwizacji, aby zbudować archiwa.

Jeśli nie będziesz zawsze ładować wszystkich plików z archiwum, TAR / GZ może nie być dobrym pomysłem, ponieważ nie możesz wyodrębnić określonych plików, ponieważ są one potrzebne. Jest to powód, dla którego wiele gier korzysta z archiwów ZIP, które pozwalają na wyodrębnianie poszczególnych plików zgodnie z wymaganiami (dobrym przykładem jest Quake 3, którego pliki PK3 to nic innego jak pliki ZIP z innym rozszerzeniem).

• http://zpp-library.sourceforge.net/
• http://www.winimage.com/zLibDll/minizip.html

EDYCJA: „Ukryj” strukturę folderów gry i „Zachowaj” tylko pliki wykonywalne

Często stosuje się inne rozwiązanie do „ukrywania” plików gry w strukturze folderów. Zachowaj tylko pliki wykonywalne i może plik Readme w głównym katalogu i przenieś pliki gry do podfolderu o nazwie „dane” lub innego pokrewnego.

EDYCJA: Gamedev Tuts Plus ma niezły zasób

• http://gamedev.tutsplus.com/tutorials/implementation/create-custom-binary-file-formats-for-your-games-data/

EDYCJA: libarchive

Jedno potencjalne rozwiązanie libarchive, które jest biblioteką do archiwizacji, która będzie obsługiwać rozpakowywanie plików z archiwum, takiego jak plik ZIP. Pozwala nawet przypisać wyodrębniony plik do standardowego wskaźnika PLIKU, co znacznie ułatwiłoby interakcję z dowolnymi innymi bibliotekami.

• http://libarchive.github.com/

EDYCJA: Pliki w formacie ZIP z alternatywnym rozszerzeniem

Tutaj podoba mi się komentarz @Joachima Sauera

Używanie plików ZIP-format z alternatywnych rozszerzeń ma wielką tradycję poza grami, a także: Java robi to , na OpenDocument Format (aka format OpenOffice / LibreOffice) to robi , nawet Office Open XML (aka "nowego" formatu Microsoft Office) robi .

Innym rozwiązaniem często używanym do „ukrywania” plików gry jest struktura folderów. Zachowaj tylko pliki wykonywalne i może readme w głównym katalogu i przenieś pliki gry do podfolderu „data”. Nie sądzę, że jest to bardzo rzadkie. Wiele gier, które znam, przechowują swoje treści w taki sposób.

Naprawdę podoba mi się za to PhysFS . Umożliwia dostęp do folderów lub archiwów zip z tym samym kodem. Działa dobrze na wszystkich etapach życia Gry.

1. Podczas programowania : dostęp do zasobów bezpośrednio z hierarchii folderów. W ten sposób skompresowane archiwa nie przeszkadzają i można szybko iterować.
2. Wstępne wdrożenie : spakuj zasoby, aby ułatwić wdrożenie / szybkie instalacje. Nie trzeba zmieniać kodu. Po prostu skieruj PhysFS na zip zamiast na folder.
3. Aktualizacje / Modding : PhysFS może załadować wiele archiwów zip, w których zasoby jednego z nich zastępują inne. Aktualizacje mogą być tak proste, jak nowy plik zip ze tylko zmienionymi plikami. Podobnie w przypadku modowania.

aktualizacja:

Skorzystałem z samouczka dołączonego do źródła i dokumentacji doxygen, aby nauczyć się PhysFS. Interfejs API jest naprawdę dość prosty, poświęcisz więcej czasu na naukę ładowania obrazów do SFML przez bufory pamięci zamiast ścieżki pliku.

Sugerowałbym użycie pliku ZIP. Jest to wszechobecny format, a znajdziesz gotowe biblioteki, które pozwalają ładować pliki z pliku ZIP. Szybka wyszukiwarka Google ujawniła nawet program ładujący zip dla sfml .

Cóż, możesz oszukiwać tak, jak wspomniano :) Możesz zrobić arkusz sprite ze zdjęć, nie ma potrzeby, aby go teraz spakować, chyba że pozwoli to zaoszczędzić mnóstwo miejsca. Po utworzeniu arkusza duszków lub kilku arkuszy duszków z obrazów możesz po prostu zmienić ich rozszerzenia. Większość graczy nie zadaje sobie trudu, aby to sprawdzić i dlaczego nie pozostawić tej opcji Artystom, którzy mogą chcieć zmodyfikować Twoją grę w przyszłości? W ten sposób mogą też utworzyć arkusz ikon, zmienić nazwę jego rozszerzenia i zacząć się rozwijać.

W przypadku plików tekstowych pokornie sugeruję konwersję tych danych do postaci binarnej. Jestem pewien, że znajdziesz prosty sposób, aby to zrobić. Na przykład, jeśli używasz tylko AZ, az i 0-9, możesz użyć 6 bitów do reprezentowania każdej postaci, co w pewien sposób ochroni twój materiał chroniony prawem autorskim, to uniemożliwi również innym edytowanie map. Zawsze możesz dodać konwerter map, jeśli chcesz. Jednak kompresowanie tekstu jest całkowicie rozsądne.

Nie chodzi tylko o liczbę zasobów lub miejsca na dysku.
W przypadku wielu różnych plików tekstur, ponieważ używasz SFML, który renderuje w OpenGL, za każdym razem, gdy będziesz renderować teksturę, OpenGL musi powiązać następną teksturę z kartą wideo (sprawdź glBindTexture ()) i jest to naprawdę drogie zadanie.
Mając to na uwadze, możesz zrozumieć, dlaczego gry zazwyczaj umieszczają wiele duszków w tej samej teksturze, tak zwane arkusze duszków, zgodnie z menu / poziomami / mapami gry.
Rezultatem jest ogromny wzrost wydajności, ponieważ renderujesz wiele duszków z tym samym wywołaniem tekstury wiązania.

Osobiście wybrałbym w tym celu niestandardową trasę pliku binarnego. Jest to coś, co robię teraz cały czas, nie jest tak trudne, jak mogłoby się wydawać, a także zapewnia pewien poziom zaciemnienia plików zasobów gry. Niedawno napisałem mały wstępny artykuł Gamedev, jeśli jesteś zainteresowany:

http://gamedev.tutsplus.com/tutorials/implementation/create-custom-binary-file-formats-for-your-games-data/

Arkusze sprite są zupełnie innym tematem, ale są normą w większości gier :)

Inną metodą, której możesz użyć:

Darmowa wersja XnView zawiera funkcję o nazwie „ Strip of Images” (SHIFT + A), która umożliwia tworzenie sprite-collections.

Minimalizuje to dostęp do plików i jest szczególnie ważne dla aplikacji / gier internetowych, aby zminimalizować liczbę HTTP-roundtrips.

Dostęp do poszczególnych obrazów jest następnie przyznawany poprzez mapy współrzędnych (na przykład definicje css).

Najpierw musisz napisać własny obraz / dźwięk / etc. ładowanie procedur korzystających z niestandardowego interfejsu API w celu uzyskania dostępu do zarchiwizowanych danych. Kolejną wadą jest to, że musisz napisać własne narzędzie do archiwizacji, aby zbudować archiwa. Jeśli nie będziesz zawsze ładować wszystkich plików z archiwum, TAR / GZ może nie być dobrym pomysłem, ponieważ nie możesz wyodrębnić określonych plików, ponieważ są one potrzebne. Jest to powód, dla którego wiele gier korzysta z archiwów ZIP, które pozwalają na wyodrębnianie poszczególnych plików zgodnie z wymaganiami (dobrym przykładem jest Quake 3, którego pliki PK3 to nic innego jak pliki ZIP z innym rozszerzeniem). http://zpp-library.sourceforge.net/