Autor Wątek: Jeden duży plik vs kilkaset małych.  (Przeczytany 4242 razy)

Offline revo

  • Użytkownik

# Maj 16, 2007, 11:00:34
Cytuj
Pozwala to na uzycie technik adresowania duzy szybszych niz B-drzewa, dajmy na to haszowania doskonalego.
Tak, tylko po co, skoro zwykły std::map w zupełności wystarczy. :)

Po to, że słownik stały możesz zbudować na zewnątrz i go wczytać tylko, a mapę musiałbyś tworzyć od zera i tracić na to czas. Chociaż pewnie w przypadku kilku/klkunastu tysięcy plików tworzenie mapy to czas pomijalny :P

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Asmodeusz

  • Użytkownik
    • Bogumił Wiatrowski: Blog

# Maj 16, 2007, 14:56:42
Jeśli jest kilka tysięcy małych plików i koder ceni sobie swoją oraz ewentualnych ambitnych (modyfikujących) graczy wygodę i pisze docelowo pod Windows, może wykorzystać możliwość folderów kompresowanych NTFS. Wymagania: partycja z systemem plików NTFS, nagłówek windows.h, biblioteki windowsowe (bodajże user3.lib w tym rpzypadku) - jest w każdym windowsie od NT4 SP2 wzwyż. Efekt: obsługa plików od strony kodu wygląda jak dla plików luźnych; natomiast problem wyrównywania pliku do klastra nie istnieje - Windows przeznacza na plik dokładnie tyle, ile jest potrzebne i wyrównanie do klastra następuje dopiero dla całego folderu skompresowanego. Rozwiązanie prawie doskonałe, gdyby nie wady. Wady: wymaga Windows (jeśli ktoś pisze docelowo pod Windows, to nie ejst to problemem); wymaga partycji NTFS (FAT jest na tyle przestarzały, że można bezpiecznie założyć, że nikt, kto ma system Windows 2000 lub nowszy, nie używa FATa). [ KrzysiekK: a system dalej instalujesz z FDD 5.25'' ? :D ]

Offline novo

  • Użytkownik
    • my devblog

# Maj 16, 2007, 15:28:00
No chyba ze ktos ma na kompie linuxa i windowsa. Ja przez to musialem wszystkie partycje oprocz windowsowej dac na FATa zebym mial do tego normalny dostep z lina. Takich ludzi moze byc troche i wtedy nie beda mogli oni pograc w twoja gierke(bo nie maja ntfs'a. Ja bym byl raczej za pisaniem wlasnego, ew uzyc jakiegos gotowca.

Pozdr.
novo.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 16, 2007, 15:36:37
Cytuj
[ KrzysiekK: a system dalej instalujesz z FDD 5.25'' ? :D ]
Nie. :) Z FAT'a korzystam głównie dlatego, że można dostać jego pełną specyfikację i w razie padu systemu plików, czy partycji, jestem w stanie nawet sam odzyskać to, co się da odzyskać. W przypadku NTFS'u już tak łatwo nie jest.

Jeżeli chodzi o wymaganie NTFS'u w grach pod system inny niż Windows Vista, to IMHO jest to trochę jakby wymagać, żeby mysz zainstalowana w systemie była produkcji Microsoftu. Nawet pod Vistą może to sprawiać pewne trudności, bo nie wszystkie partycje muszą być przecież NTFS. :)

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 16, 2007, 16:42:25
No chyba ze ktos ma na kompie linuxa i windowsa. Ja przez to musialem wszystkie partycje oprocz windowsowej dac na FATa zebym mial do tego normalny dostep z lina. Takich ludzi moze byc troche i wtedy nie beda mogli oni pograc w twoja gierke(bo nie maja ntfs'a. Ja bym byl raczej za pisaniem wlasnego, ew uzyc jakiegos gotowca.

Pozdr.
novo.

swego czasu jest juz [po captive-ntfs] cos takiego jak ntfs-3g. Bardzo fajnie chodzi jak na OS, testowalem :)

Offline novo

  • Użytkownik
    • my devblog

# Maj 16, 2007, 17:46:51
Dzieki za info, ale jednak na razie zostane na facie(ciezko bedzie przekonwertowac 300GB z FATA na NTFS). Moze jak jakis nowy dysk dojdzie to o tym pomysle.

Offline Hadrian W.

  • Użytkownik
    • Homepage

# Maj 16, 2007, 21:40:26
Potwierdzam ntfs-3g jest już kilka wersji po 1.0 i wszystko działa należycie.
Co do VFS to jak już ktoś wspomniał to fajna rzecz dla modderów. Dzięki temu wystarczy taka jedna mała paczuszka wrzucona w odpowiednie miejsce i wszystko jest git :)
Jest ciekawy projekt open source'owego VFSa działającego w duchu Quake'a - PhysicsFS - http://icculus.org/physfs/

Offline Liosan

  • Redaktor

# Maj 17, 2007, 01:00:22
Cytuj
Pozwala to na uzycie technik adresowania duzy szybszych niz B-drzewa, dajmy na to haszowania doskonalego.
Tak, tylko po co, skoro zwykły std::map w zupełności wystarczy. :)

Po to, że słownik stały możesz zbudować na zewnątrz i go wczytać tylko, a mapę musiałbyś tworzyć od zera i tracić na to czas. Chociaż pewnie w przypadku kilku/klkunastu tysięcy plików tworzenie mapy to czas pomijalny :P

dobrze napisany slownik staly bedzie szybszy do wczytania i wyszukiwania, niezaleznie od ilosci plikow. Jak masz 100k plikow i chcesz wczytac tylko loading screen... to budowanie mapy to nie jest czas pomijalny :) a std::map pewnie bedzie wolne jak cholera i niewarte zachodu, rownie dobrze moznaby struktury dysku uzyc... przynajmniej IMHO :)

Liosan

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 17, 2007, 01:32:23
dobrze napisany slownik staly bedzie szybszy do wczytania i wyszukiwania, niezaleznie od ilosci plikow. Jak masz 100k plikow i chcesz wczytac tylko loading screen... to budowanie mapy to nie jest czas pomijalny :) a std::map pewnie bedzie wolne jak cholera i niewarte zachodu, rownie dobrze moznaby struktury dysku uzyc... przynajmniej IMHO :)
Proponuję sprawdzić ile czasu zajmuje wrzucenie 100k kluczy do std::map - nie powinno trwać to zbyt długo. Jeżeli będzie to zrobione raz przy uruchomieniu gry, to wszystko będzie OK. Poza tym komu będzie się chciało kodować własną implementację słownika dla zaoszczędzenia sekundy, czy nawet mniej wczytywania. :)

bies

  • Gość
# Maj 17, 2007, 01:46:19
dobrze napisany slownik staly bedzie szybszy do wczytania i wyszukiwania, niezaleznie od ilosci plikow. Jak masz 100k plikow i chcesz wczytac tylko loading screen... to budowanie mapy to nie jest czas pomijalny :) a std::map pewnie bedzie wolne jak cholera i niewarte zachodu, rownie dobrze moznaby struktury dysku uzyc... przynajmniej IMHO :)
Proponuję sprawdzić ile czasu zajmuje wrzucenie 100k kluczy do std::map - nie powinno trwać to zbyt długo. Jeżeli będzie to zrobione raz przy uruchomieniu gry, to wszystko będzie OK. Poza tym komu będzie się chciało kodować własną implementację słownika dla zaoszczędzenia sekundy, czy nawet mniej wczytywania. :)
W takiej sytuacji (jedno wczytanie na starcie) to proponuję użyć posortowanego std::vector<std::pair<T1, T2> > a następnie wyszukiwać std::lower_bound(). Będzie szybsze od mapy (bardziej cache-friendly, mniej wskaźników po drodze) a i wczytać z zewnętrznego źródła będzie łatwo.
« Ostatnia zmiana: Maj 17, 2007, 01:50:19 wysłana przez bies »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Maj 17, 2007, 02:21:25
bies: Ogólnie dobry pomysł, tyle że mapa ma ten plus, że jesteś w stanie po jej wczytaniu coś tam jeszcze dorzucić, np. wczytywać archiwa patchów, modów i plików wrzuconych "luzem" przez graczy robiących aktualnie mody. :)

Offline krajek

  • Użytkownik

# Maj 18, 2007, 11:11:01
Cytuj
bies: Ogólnie dobry pomysł, tyle że mapa ma ten plus, że jesteś w stanie po jej wczytaniu coś tam jeszcze dorzucić, np. wczytywać archiwa patchów, modów i plików wrzuconych "luzem" przez graczy robiących aktualnie mody.
Gwoli ścisłości  : jeśli użyjemy std::vector to także będziemy mogli dorzucać, z tym że oczywiście wydajność(w zależności od liczby kluczy) może być nawet o rzędy wielkości gorsza.

Offline Esidar

  • Użytkownik

# Maj 18, 2007, 23:37:36
VFS jest w przypadku wielu gier, raczej koniecznością. Instalowanie gry która zajmuje 2GB i ma wszystko w 100k plikach to byłby koszmar. Podczas developingu VFS się nie używa bo pliki przez cały czas się dodaje/usuwa/zmienia. Tak więc potrzebny jest system który wczytuje pliki zarówno z dysku jak i z pliku VFS.
Co do sposobu trzymania listy plików, to zależy od tego jak ktoś chce używać zasobów. Czy przy wczytywaniu tekstury podaje "textures/vehicles/car01.jpg" czy po prostu "car01.jpg". Pierwsza metoda sama z siebie narzuca właściwie użycie drzewa. Przy drugiej już przydałoby się proste hashowanie 8-12 bit:
std::vector<Resource> zasoby[4096];
int hash = hash_string( filename );
std::vector<Resource>& v = zasoby[ hash & 4095];
Resource* r = find( v, filename );
12 bit przy 100k plikach daje statystycznie 24 porównania bez specjalnie kosztownego przygotowywania listy plików.