Autor Wątek: Własny format plików  (Przeczytany 7347 razy)

Offline Esidar

  • Użytkownik

# Marzec 05, 2008, 02:28:39
wczytujac level jednym wywolaniem funkcji (np. fread) odczytuje od razu wszystkie dane (np. textury) do jednego bufora. Mamy wtedy jeden spojny blok pamieci z texturami. Taki jeden odczyt bedzie szybszy w porownaniu z odczytem i dekompresja n mniejszych plikow, tworzeniem z nich zasobow etc. No i nie mamy fragmentacji. Co Wy na to?

To się nazywa in-place-load. To z pewnością poprawia prędkość wczytywania bo pomijasz etap związany z parsowaniem pliku. Nie mniej, skompresowanie poprawia szybkość wczytywania w większości przypadków. Regedit zrobił kiedyś test z samymi tylko teksturami http://regedit.warsztat.gd/produkcje/artykuly/DxTextureLoadTest/Chart_Methods.png (oraz do całego artykułu http://regedit.warsztat.gd/produkcje/artykuly/DxTextureLoadTest.php5 ).
Zauważ, że prędkość wczytywania z dysku to ok. 20MB/s. Tymczasem za pomocą dekompresji (na obecnych komputerach), dość łatwo uzyskasz prędkość dekompresji na poziomie 50MB/s.

Offline Mr. Spam

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

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 06:54:56
zastanawiam sie czy sumy kontrolne sa jakos szczegolnie potrzebne. Zle pliki to blad usera i niech on sie tym martwi, a aplikacja niech oszczedzi na czasie.

Zastanawiam sie jeszcze nad taka opcja. Pliki nie sa skompresowane. Wiem, tracimy duzo miejsca (np. w oblivionie ok 1gb na modelach), ale jesli ktos sprytnie sobie ulozy dane to np. wczytujac level jednym wywolaniem funkcji (np. fread) odczytuje od razu wszystkie dane (np. textury) do jednego bufora. Mamy wtedy jeden spojny blok pamieci z texturami. Potem juz tylko robimy sobie wskazniki i offset na tym bloku i powinno byc cacy. Taki jeden odczyt bedzie szybszy w porownaniu z odczytem i dekompresja n mniejszych plikow, tworzeniem z nich zasobow etc. No i nie mamy fragmentacji. Co Wy na to?
Poczytaj tutaj o prędkości wczytywania danych, skompresowane zlibem ponad 40% szybciej. Poza tym zasoby takie jak np tekstury i tak musisz utworzyć, bo przecież ani DX ani OGL nie czyta bezpośrednio z pamięci systemowej.

Co do CRC to w końcowym produkcie może faktycznie nie jest za bardzo potrzebne i jezeli levele będa mi się wczytywać jak w Wiedźminie ;) to na pewno wyłączę sprawdzanie. Za to w czasie produkcji może się jednak przydać bo plik może zostać uszkodzony z różnych powodów, błedy wynikające z tego raczej trudno wykryć, a czas ładowania ma dużo mniejsze znaczenie.

Offline Esidar

  • Użytkownik

# Marzec 05, 2008, 12:16:04
Co do CRC to w końcowym produkcie może faktycznie nie jest za bardzo potrzebne i jezeli levele będa mi się wczytywać jak w Wiedźminie ;) to na pewno wyłączę sprawdzanie. Za to w czasie produkcji może się jednak przydać bo plik może zostać uszkodzony z różnych powodów, błedy wynikające z tego raczej trudno wykryć, a czas ładowania ma dużo mniejsze znaczenie.

CRC służy sprawdzeniu CZY plik jest uszkodzony. Jeśli jest uszkodzony to możesz co najwyżej zrobić to, co i tak byś zrobił nie mając CRC czyli "próbował go wczytać żeby odzyskać tyle ile się da".

Offline spax

  • Użytkownik

# Marzec 05, 2008, 12:22:00
ew. sprawdzanie CRC calego archiwum przy starcie silnika. Ale powinno sie zakladac ze pliki zawsze beda ok :)

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 12:53:54
Co do CRC to w końcowym produkcie może faktycznie nie jest za bardzo potrzebne i jezeli levele będa mi się wczytywać jak w Wiedźminie ;) to na pewno wyłączę sprawdzanie. Za to w czasie produkcji może się jednak przydać bo plik może zostać uszkodzony z różnych powodów, błedy wynikające z tego raczej trudno wykryć, a czas ładowania ma dużo mniejsze znaczenie.

CRC służy sprawdzeniu CZY plik jest uszkodzony. Jeśli jest uszkodzony to możesz co najwyżej zrobić to, co i tak byś zrobił nie mając CRC czyli "próbował go wczytać żeby odzyskać tyle ile się da".

Nie. Jeżeli wykryję uszkodzony plik to nie mam zamiaru go naprawiać. Co innego jeżeli plik nie jest uszkodzony tylko nieprawidłowo zapisany np przez edytor czy konwerter, ale z prawidłową sumą kontrolną - wtedy można próbować mimo wszystko działać dalej. Natomiast jeżeli jest ewidentnie uszkodzony np w skutek przesyłania przez internet czy grzebania hexeditem, to nie ma mowy o dalszej pracy. Jeżeli uszkodzi się exe też próbujesz dalej coś z tym robić? Albo jak dysk będzie miał bad sektory?

//Edit
Poza tym jak masz zamiar odzyskiwać uszkodzone skompresowane dane?
« Ostatnia zmiana: Marzec 05, 2008, 13:10:23 wysłana przez Ventor »

RageX

  • Gość
# Marzec 05, 2008, 14:08:09
W przypadku tekstury (nieskompresowanej, w przypadku skompresowanej zależy to od sposobu kompresji) uszkodzone bity nie będą jakieś straszne. Byle finałowy rozmiar się zgadzał  i nagłówek, np. bity które wyznaczymy jako informacje o treści.
Taka tekstura będzie miała artefakty. Ale jej uruchomienie nie będzie końcem świata.
Żródeł uszkodzenia może być tyle, co gwiazd na niebie. Po niektórych pewnie nic się nie da zrobić... ale skoro czasami przejdzie i jest to bezpieczne, to czemu nie...

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 15:03:07
W przypadku tekstury (nieskompresowanej, w przypadku skompresowanej zależy to od sposobu kompresji) uszkodzone bity nie będą jakieś straszne. Byle finałowy rozmiar się zgadzał  i nagłówek, np. bity które wyznaczymy jako informacje o treści.
Taka tekstura będzie miała artefakty. Ale jej uruchomienie nie będzie końcem świata.
Żródeł uszkodzenia może być tyle, co gwiazd na niebie. Po niektórych pewnie nic się nie da zrobić... ale skoro czasami przejdzie i jest to bezpieczne, to czemu nie...

Właśnie chodzi o to, że to nie jest zbyt bezpieczne. Jeżeli bity tekstury zostały uszkodzone to nie licz na to że reszta danych jest prawidłowa, a bez sprawdzania sumy kontrolnej nawet nie będziesz wiedział, że tekstura jest uszkodzona. Jeden nieprawidłowy bit w odpowiednim miejscu może powodować wywalanie się gry w kilku różnych miejscach, a stracisz sporo czasu zanim rozwiążesz problem.

Uszkodzenia plików nie zdarzają się na tyle często żeby warto było poświęcać im więcej czasu niż na proste sprawdzenie sumy kontrolnej. Nawet jeżeli w dużej firmie uszkodzenie pliku zatrzymałoby pracę 20 testerów, to świat się nie zawali, a ile może zająć dostarczenie nieuszkodzonego pliku czy nawet całej gry? Max jeden dzień, więc albo testerzy jeden dzień dłużej potestują starą wersję albo zrobią sobie wolne. Według mnie próba naprawiania takich błędów to przerost formy (lub ambicji programisty ;) ) nad treścią.

Offline Esidar

  • Użytkownik

# Marzec 05, 2008, 15:48:34
Nawet jeżeli w dużej firmie uszkodzenie pliku zatrzymałoby pracę 20 testerów, to świat się nie zawali, a ile może zająć dostarczenie nieuszkodzonego pliku czy nawet całej gry? Max jeden dzień, więc albo testerzy jeden dzień dłużej potestują starą wersję albo zrobią sobie wolne. Według mnie próba naprawiania takich błędów to przerost formy (lub ambicji programisty ;) ) nad treścią.

No to wyobraź sobie taką sytuację :) Do testów idzie gra z uszkodzoną teksturą. Uszkodzić można na wiele sposóbów (np. błąd w toolu do generowania asset'ów). Tekstura ma urwane kilka ostatnich linii. Gra idzie z takim plikiem do testów do zewnętrznych labów. Test round trwa 3 dni. Testy są robione przez 2 laboratoria (jedno w USA robi testy funkcjonalności, drugie w Pakistanie robi testy lingwistyczne).

I teraz gra się nie odpala bo "tekstura ma uszkodzone kilka pixeli". Cała machina staje. 2 laboratoria nic nie mogą zrobić. Przesunięcie czasowe między nami a pakistanem i USA powoduje takie opóźnienie, że np. w pakistanie Test Round się kończy zanim wyślemy nowy build. Parę tysięcy USD leci do kosza :)

A dodatkow, w połowie robienia testów nie należy wysyłać kolejnych buildów bo zanim oni zgłoszą problem, że im poprzedni build w levelu 5 nie działa to my już mamy poprawione kolejne błędy, które oni zdąrzyli w tym czasie zgłosić, że są. My możemy zrobić im build z nowymi poprawkami a w bazie QA zaczyna się w tym momencie totalny chaos bo już nie wiadomo które błędy są poprawione a które jeszcze nie. Do tego laboratorium w USA testuje nowy build a lab. w pakistanie wciąż jedzie na starym :) Mają wspólną bazę QA. Do tego dorzućmy fakt, że zrobimy im nowy build Ruski, Polski, Czeski i Brazylijski a Niemiecki i Włoski już nie mają tego błędu. Itd itp :)

Przykłady z życia wzięte :)

RageX

  • Gość
# Marzec 05, 2008, 16:04:38
Właśnie chodzi o to, że to nie jest zbyt bezpieczne. Jeżeli bity tekstury zostały uszkodzone to nie licz na to że reszta danych jest prawidłowa, a bez sprawdzania sumy kontrolnej nawet nie będziesz wiedział, że tekstura jest uszkodzona. Jeden nieprawidłowy bit w odpowiednim miejscu może powodować wywalanie się gry w kilku różnych miejscach, a stracisz sporo czasu zanim rozwiążesz problem.
Mówię o wartościach dla pikseli w jakimś formacie binarnym które są już zapisane w kolejce, przygotowane do odczytu. Gdzie nagłówek mamy osobno, wiemy że jest dobry. Wielkość pakietu się zgadza... a nasz program zakłada błąd konwersji przy odczycie kolejnych bitów (oczywiście to kosztuje), zamieniając je np. W takim wypadku program nie ma prawa się posypać z powodu kilku pikseli.
Z takimi błędami które trzeba puszczać, mamy do czynienia od dawna przecież - znamienitym przykładem będą cd i dvd.

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 16:43:34
Jak już wcześniej wspomniałem:
Co innego jeżeli plik nie jest uszkodzony tylko nieprawidłowo zapisany np przez edytor czy konwerter, ale z prawidłową sumą kontrolną - wtedy można próbować mimo wszystko działać dalej.

Jeżeli płytka jest uszkodzona to system tego nie odczyta więc i tak nic nie zrobimy, a jezeli pliki uszkodzą się podczas wysyłania przez internet to przeważnie są spakowane rarem/zipem - też nic z tego nie będzie. Nawet gdyby udało się naprawić rar-a czy odczytać dane z płyty, to i tak gry często używają własnej kompresji np zlib-a, a jeżeli taki zlib dostanie uszkodzone dane to już różnie może być. Poza tym jakie są szanse że uszkodzenie trafiło na teksturę?
Po prostu nie testuje się uszkodzonych buildów! Trudno - jakieś straty powinny być wliczone w koszty, przecież nie zdaża się to codziennie, a jeżeli zbyt często to trzeba szukać przyczyny a nie walczyć ze skutkami, bo nie jest to normalne.

Skoro już dajesz przykłady z życia, to ile miałeś przypadków, że gra działała, ale akurat uszkodziła się jedna tekstura i nieprawidłowo się wyświetlała? Ja miałem kilka przypadków uszkodzenia się plików podczas przesyłania przez internet i niestety za każdym razem wrzucałem jeszcze raz.

Tak z innej strony patrząc na ten problem - samochód bez hamulców też nie jest do końca uszkodzony i można nim jeździć, ale przetestowałbyś go?

Offline Esidar

  • Użytkownik

# Marzec 05, 2008, 17:05:52
Po prostu nie testuje się uszkodzonych buildów!
To skąd wiesz czy jest uszkodzony, jeśli nie przetestujesz ? :)

Cytuj
i niestety za każdym razem wrzucałem jeszcze raz.

I jaka jest róznica między tym czy używasz CRC czy nie ? :)

To jest dyskusja mniej więcej o tym co w jakimś innym wątku było "czy należy wykonywać validację danych w grach." (chyba przy okazji dyskuji o rzucaniu wyjątkami).

Zazwyczaj zawsze sprowadza się to do tego samego: brak pliku lub plik uszkodzony to nie jest koniec świata. Lepiej sobie napisać na kartce "kamyczek jest czarny" niż mieć dzień stracony.


RageX

  • Gość
# Marzec 05, 2008, 17:13:48
Ventor: Tak wspomniałeś o tej płycie - nie mogłem sobie podarować.

pierwsza odpowiedź na zapytanie compact disc error
http://www2.roxio.com/en/support/cdr/cderrors.html

pierwsze zdania(wstęp?):
Cytuj
All compact discs have errors on them. Some of them have a lot of errors. Even with the errors, however, you can still read a CD accurately. Why? Because CDs use Error Detection Code and Error Correction Code (EDC/ECC) to correct these errors as the CD is played (audio) or accessed (data).

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 17:49:37
Po prostu nie testuje się uszkodzonych buildów!
To skąd wiesz czy jest uszkodzony, jeśli nie przetestujesz ? :)
No gra sprawdzi CRC ;D i jeżeli okaże się, że jest uszkodzony to komunikat i koniec gry.

Cytuj
I jaka jest róznica między tym czy używasz CRC czy nie ? :)
Taka, że nie muszę już nic innego sprawdzać jeżeli mam CRC. Nie piszę nadmiarowego kodu do walidacji danych, radzenia sobie z uszkodzonymi itp.

Cytuj
To jest dyskusja mniej więcej o tym co w jakimś innym wątku było "czy należy wykonywać validację danych w grach." (chyba przy okazji dyskuji o rzucaniu wyjątkami).

Zazwyczaj zawsze sprowadza się to do tego samego: brak pliku lub plik uszkodzony to nie jest koniec świata. Lepiej sobie napisać na kartce "kamyczek jest czarny" niż mieć dzień stracony.
Dyskusja owszem, sprowadza się do tego, ale rzeczywistość raczej nie, bo jeżeli plik się uszkodzi to przeważnie nie ma czarnego kamyczka tylko czarny ekran. Sytuacja z uszkodzoną teksturą to tylko teoria, w praktyce raczej rzadko to się zdarza, a jeżeli już to nigdy nie wiadomo co jeszcze się posypie. Takie podejście żeby radzić sobie nawet z uszkodzonymi danymi jest ambitne ale, bez obrazy, zalatuje amatorszczyzną ;)


Ventor: Tak wspomniałeś o tej płycie - nie mogłem sobie podarować.

pierwsza odpowiedź na zapytanie compact disc error
http://www2.roxio.com/en/support/cdr/cderrors.html

pierwsze zdania(wstęp?):
Cytuj
All compact discs have errors on them. Some of them have a lot of errors. Even with the errors, however, you can still read a CD accurately. Why? Because CDs use Error Detection Code and Error Correction Code (EDC/ECC) to correct these errors as the CD is played (audio) or accessed (data).
Zgadza się, ale napęd czyta tak długo aż odczyta prawidłowo (wyjątkiem chyba jest CD-Audio, bo przeskakuje dalej). Dopóki nie odczyta prawidłowo nie dostaniesz tych danych, więc żadne sztuczki nie pomogą. Chyba, że całkowite pominięcie pliku.


Poza tym trochę zaśmieciliśmy wątek, a chyba nie ma szans żebyście mnie przekonali ani ja Was, więc może koniec OT.

RageX

  • Gość
# Marzec 05, 2008, 18:33:24
Spoko - nie przekonamy cię. Ale przynajmniej przeczytaj tekst który ci dałem cały... co byś wiedział co piszesz.  :) Faktem jest, że trudniej jest w jakiś sposób niektóre dane zastąpić, odzyskać. Ale to nie jest tak że czyta, aż odczyta. To przy naprawdę radykalnych błędach tak ci się płyta na próbie odczytu zatnie (poznamy to po odgłosie rzezania...).
Naprawdę - przeczytaj chociaż to.

Co do czarnego kamyczka... No właśnie czarny ekran jest jak zrobimy jak radzisz. Zauważ piszemy ciągle o zawartości, nie o kodzie - jakimś uszkodzonym "egzeku" (choć tu też może być upchana zawartość). Program jako samodzielny organizm nie powinien się łamać, bo ma problem z jakąś zawartością (co było w tamtym temacie już powiedziane).

Amatorskie podejście zakłada że dane z płyt nie mają błędów, że stream danych zawsze nadąży, że program się zamyka jak jakiś element nawala. Gry, rosną ciągle w rozmiarze i w  poziomie skomplikowania, ilość rzeczy która może powodować błędy, rośnie. To jest jakieś wyidealizowane podejście że zawsze wszystko zadziała, nie mające nic z rzeczywistością wspólnego.
« Ostatnia zmiana: Marzec 05, 2008, 18:36:15 wysłana przez RageX »

Offline Ventor

  • Użytkownik

# Marzec 05, 2008, 21:02:07
Obiecałem koniec, ale nie mogę tego tak zostawić ;)

Przeczytałem ten tekst (wcześniej faktycznie go nie czytałem :P), ale utwierdził mnie on w moich przekonaniach. Obawiam się że to Ty go nie zrozumiałeś. Kilka ważnych zdań zacytuję:
Cytuj
An audio CD does not need as much error correction as a data CD-ROM because an incorrect bit in an audio stream will not be heard, while an incorrect bit in a computer program could crash the program (or the computer).
...
E32 errors are uncorrectable, and are not acceptable on a CD-ROM disc. An uncorrectable error in a computer program can cause the program to crash, and if a disc containing such errors is used as a master for factory replication, the equipment at the mastering facility will abort when it sees the uncorrectable error. The mastering must then be redone, resulting in additional costs and delays in the replication job.

Jak mówiłem wcześniej CD Audio przeskakuje dalej jeżeli nie może odczytać danych i podobno tego nie słychać. Natomiast dane MUSZ¡ zostać odczytane prawidłowo, a że sam napęd stosuje sztuczki w postaci nadmiarowych danych do korekcji błędów to mnie nie obchodzi. Aplikacja musi dostać prawidłowe dane albo nie dostanie ich w ogóle!
W aplikacji nie stosujesz przecież takiej korekcji błędów jak napędy CD, bo nie musisz, napęd robi to za ciebie. Z HDD jest podobnie, tez ma swoje korekcje, może mieć bad sektory powstałe w czasie produkcji, tylko że z poziomu kontrolera tego nie widać, wszystkim zajmuje się elektronika. Wszystko po to żebyś dostał prawidłowe dane, więc po co jeszcze chcesz zakładać w grze że dane mogą być jednak uszkodzone? Chcesz uratować ten jeden przypadek na milion?

Jak zapewne wiesz pliki skompresowane np rar-em mają sumę kontrolną CRC32. Na pewno nieraz zdażyło Ci się ściągnąć taki plik z internetu i był uszkodzony, wywalił błąd CRC (na pewno ściągnąłeś go drugi raz zamiast naprawiać). Teraz zastanów się ile razy zdażyło Ci się skopiować taki plik z płyty CD albo drugiego dysku i w wyniku kopiowania plik został uszkodzony. Jeżeli taki błąd się pojawi to będzie to wina sprzętu, jeżeli uszkodzi się przy przesyłaniu przez internet to już trudniej znaleźć winnego, ale w obu przypadkach nie warto poświecać na to zbyt dużo czasu. Warto za to wiedzieć że dane są uszkodzone, poinformować użytkownika i zakończyć program.

Teraz już na prawdę koniec OT.