Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Ventor

Strony: 1 [2] 3 4
16
C++ / Odp: Wyrównywanie elementów struktury/klasy.
« dnia: Marzec 23, 2008, 01:28:41 »
Jejku panowie, windows np. już od dawna to robi  :). Pod właściwościami mamy 2 rozmiary. Właściwy i ten systemowy.
Rozmiar klastra, czy jakiekolwiek tam jednostki logicznej systemu plików, to jedna sprawa, a wymóg dostosowania się do teog to druga sprawa.
Windows alokuje na dysku faktycznie nadmiarowo, ale jest to przezroczyste dla osoby czytającej plik - plik leży w dwóch 20kB klastrach, ale czytasz dokłądnie tyle ile chcesz czyli 32kB i tyle.
Esidar pokazuje coś innego - na Wii nie da się tak zrobić!! Po prostu musisz mieć bufor zalignowany do 32bajtów i tyle Ci przeczyta.

To tylko kwestia api, windows umożliwia odczyt z pominięciem systemowego cache (CreateFile z flagą FILE_FLAG_NO_BUFFERING) i wtedy też można czytać tylko dane wyrównane do wielkości sektora, adres bufora w pamięci też musi być wyrównany. Nie jest to podyktowane systemem plików tylko samym sprzętem bo wyrównuje się do wielkości fizycznego sektora a nie klastra.

17
C# / Odp: Własny format plików
« dnia: 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.

18
C# / Odp: Własny format plików
« dnia: 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.

19
C# / Odp: Własny format plików
« dnia: 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?

20
C# / Odp: Własny format plików
« dnia: 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ą.

21
C# / Odp: Własny format plików
« dnia: 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?

22
C# / Odp: Własny format plików
« dnia: 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.

23
C# / Odp: Własny format plików
« dnia: Marzec 04, 2008, 23:06:01 »
Można by też wszystkie 'nagłówki' plików wpakować na sam początek. Przyspieszyło by to nam wyliczanie plików (wszystkie nagłówki za jednym odczytem). A potem mając taką listę tych  nagłówków (+ informacja z jakiej paczki pochodzi dany nagłówek) można łatwo podmieniać dodawać nowe, po prostu dodając nową paczkę do katalogu z grą (łatwość aktualizacji gry).

http://www.spax.top100.net.pl/wp_blog/index.php/2007/09/22/jak-mozna-zbudowac-vfs/
Można i wcześniejsza wersja mojego formatu miała taką możliwość bo każdy nagłówek miał offset do danych. Teraz dane mam bezpośrednio za nagłówkiem, dlatego, ze mogę w ten sposób łatwo wyciągnąć z całago archiwum i zapisać pojedyncze pliki w formacie 16 bajtowy nagłówek + dane. Rozszerzenie takiego pliku to skrót określający typ danch np tekstura, siatka itp.

Dane w takich pojedynczych plikach i tak nie są bezpośrednio wyciągane np z jpg-ów tylko mają mój format, więc w efekcie każdy zasób ma swój własny format, rozszerzenie i może kiedyś ikonkę ;) Nie ma dzięki temu problemów wynikających z ograniczeń poszczególnych formatów typu bmp czy 3ds, takimi sprawami zajmują się konwertery, a sam silnik dostaje praktycznie 100% pewne dane potwierdzone sumą kontrolną CRC32, więc nie musi już nic kontrolować, liczyć czy konwertować, od razu działa.

24
C# / Odp: Własny format plików
« dnia: Marzec 04, 2008, 12:10:10 »
Odczytywanie skompresowanych danych i dekompresja w locie często jest szybsza od odczytywania zdekompresowanych danych. Zdekompresowane więcej zajmują a jak wiadomo odcztywanie z dysku za szybkie nie jest. Co do zależności prędkości dekompresji od długości pliku to chyba jest dosyć liniowa - 10 plików po 1MB rozpakuje się praktycznie w takim samym czasie co jeden 10MB.

Ja uważam, że jest to dobry sposób, a na pewno lepszy od wrzucania wszystkiego do jednego wora i kompresowania. Nie zawsze potrzebne jest wszystko z pliku, więc nie warto całego dekompresować, a wyszukiwanie offsetu w skompresowanych danych (o ile w ogóle zlib ma taką możliwość) na pewno będzie wolniejsze.

25
C# / Odp: Własny format plików
« dnia: Marzec 04, 2008, 07:41:37 »
Cytuj
Ja korzystam ze zliba i robię to w ten sposób że plik składa się z nagłówków i danych spakowanych zlibem, np każda tekstura ma swój nagłówek opisujący ją, m.in. offset do danych. Nie ma wtedy problemu o którym piszesz, bo z nagłówków wiem gdzie są dane i odczytuję to co potrzebne i rozpakowuję.
Ja robie podobnie, tylko ze kazdy plik w tym archiwum mam osobno spakowany. A Ty masz to archiwum spakowane? Bo jesli tak to jak wyciagasz tylko konkretny plik nie rozpakowujac calosci?
Może nieprecyzyjnie się wyraziłem, ale robię dokładnie tak jak Ty. Na początku pliku jest nagłówek zawierający m.in. typy i offsety do wszystkich zasobów (nie używam nazw plików, ale gdybym używał to tu też bym je zapisał). Każdy zasób opisany jest swoim 16 bajtowym nagłówkiem zawierającym rozmiar spakowany, rozpakowany, flagi i sumę kontrolną, a bezpośrednio za tym nagłówkiem są dane (we wcześniejszej wersji był jeszcze offset do danych, ale zrezygnowałem z tego). Flagi określają czy dane są spakowane, zaszyfrowane i czy sprawdzać sumę kontrolną.

Chcąc dostać się np do konkretnej tekstury odczytuję offset z pierwszego nagłówka, później odczytuję ten drugi 16 bajtowy nagłówek i dane. Zależnie od flag sprawdzam sumę kontrolną, odszyfrowuję i rozpakowuję.

27
C# / Odp: Własny format plików
« dnia: Marzec 03, 2008, 22:24:41 »
a jak zlibem rozpakowac plik i wyciagnac n-ty plik? Troszke korzystalem z zliba i tam jest funkcja rozpakowujaca archiwum, ale do bufora, wiec jesli mamy plik 2gb danych to zeby wyciagnac jedna texture z niego musimy stworzyc bufor 2gb w pamieci?!?!? :o Domyslam sie, ze jest inny sposob. Jaki?
Ja korzystam ze zliba i robię to w ten sposób że plik składa się z nagłówków i danych spakowanych zlibem, np każda tekstura ma swój nagłówek opisujący ją, m.in. offset do danych. Nie ma wtedy problemu o którym piszesz, bo z nagłówków wiem gdzie są dane i odczytuję to co potrzebne i rozpakowuję.

Trochę dziwnie. Jak dla mnie projektowanie własnych typów plików to najprzyjemniejsza robota :)
Mój sposób należy do przyjemnych, bo format jest wymyślony przeze mnie, tylko same dane kompresuję.

28
DirectX / Odp: Zmiana rozmiaru okna
« dnia: Marzec 03, 2008, 21:51:35 »
... albo spróbuj pobawić się dwoma pierwszymi parametrami IDirect3DDevice9::Present (tylko pamiętaj o D3DSWAPEFFECT_COPY).

29
SDL / Odp: SDL, opengl i brak przysp. sprzetowego
« dnia: Marzec 03, 2008, 21:17:02 »
WinXP

fps: 60.0253
GL_RENDERER: GeForce 6600/PCI/SSE2
GL_VERSION: 2.1.1
GL_VENDOR: NVIDIA Corporation

30
DirectX / Odp: Wydajność statycznych buforów.
« dnia: Marzec 03, 2008, 16:05:56 »
Testowałem na trzech różnych komputerach, renderowałem pojedyncze siatki, wielokrotnie w jednym przebiegu tą samą siatkę i duże ilości różnych siatek. Ilość trójkątów od kilkudziesięciu do 2 mln. Zawsze ta sama sytuacja - pojednczy VB/IB jest wolniejszy, różnice zależą od tego co jest renderowane i od sprzętu, a sięgają nawet 25%  :o

Ciekawe jest to, że na szybszym sprzęcie różnice procentowe są większe niż na wolniejszym. Odpowiedziałem sobie tym samym na pytanie - nie warto "optymalizować" i nie zawsze warto wierzyć w to co pisze MS:
Cytat: MSDN
As of DirectX 8, the cost of changing vertex buffer is no longer as expensive as it was with previous versions, but it is still good practice to avoid vertex buffer changes where possible.
Cytat: MSDN
Minimize vertex buffer switches

//Edit
Zapomniałem jeszcze dopisać, że próbowałem też wspólny VB, a IB oddzielny dla każdego mesha - wydajność taka sama jak przy wspólnym VB i IB.

Strony: 1 [2] 3 4