Do Some1 i Rozorblade 1961 czy wy macie jakiś monopol na mówienie co jest dobre , a co nie , oraz wszystko wiecie najlepiej ?
Nie, nie wiemy wszystkiego najlepiej, nie mamy monopolu na prawdę, w ogóle to jesteśmy bardzo tolerancyjni ludzie, a Razorblade196
7 pistolet nosi nie nabity i tylko dla szpanu.
Nikt się nie czepia Twojej pomocy Flankerowi, wręcz przeciwnie. Czepiamy się natomiast Twojego stwierdzenia o przewadze trzymania tekstur jako bmp w TempTextures. Zwłaszcza, że napisałeś to w dziale z poradami dla początkujących, Sprostowanie jest zatem bardzo na miejscu. Widzę, że wiesz coś tam o grafice komputerowej natomiast nie masz pojęcia jak działa engine Lock Ona. Ja też nie mam, ale do paru wniosków doszedłem.
Flanker miał problem z teksturami , napisałem mu żeby je umieścił w katalogu TempTextures ( szybkie i wygodne rozwiązanie)
w nieskompresowanej formie z poprawnymi dla danego typu pliku rozszerzeniami , bo ten folder obsługuje poprawnie tylko taki typ plików . Jeżeli wrzucisz tam bitmapę skompresowaną do formatu dds i nadasz jej rozszerzenie bmp to gra to odczyta ale pojawią sie błędy graficzne i ogólny bajzel , na przykład po ponownym załadowaniu misji po zmianie uzbrojenia samolotu itd. W readme dodatkowym do wersji 1.02 jest napisane jak byk że folder TempTextures służy do magazynowania zedytowanych tekstur
Tu masz rację (poza tym że to rozwiązanie nie jest szybkie

). Co do poprawnego sposobu wgrywania tekstur to znam takie:
- użyć programu LoMAN (lub ModMAN, to jego nowsza wersja) i wgrać tekstury bezpośrednio do istniejącego pliku cdds. Wymaga to stworzenia wcześniej archiwum rozpoznawanego przez program (większość skinów ściąganych z sieci jest już w takim formacie) Niestety we Flaming Cliffs można wgrywać w ten sposób tylko tekstury o rozmiarze takim samym jak oryginalne, tekstury w innej rozdzielczości i tak lądują w Bazar\TempTextures jako bitmapy. Ale o ile jeszcze coś pamiętam, to w 1.02 dało się w ten sposób wgrać do pliku cdds każdy rozmiar tekstur. Ta metoda nic nie miesza w plikach konfiguracyjnych, po prostu stara tekstura jest zastępowana nową, stara jest backupowana automatycznie przez program.
- stworzyć własne archiwum (bądź archiwa) cdds i dołączyć do gry umieszczając odpowiedni wpis w pliku graphics.cfg, szczegóły jak to zrobić są w podlinkowanym przeze mnie pdf'ie.
- wrzucić nieskompresowaną teksturę do TempTextures, tak jak wcześniej napisaliśmy jest to rozwiązanie nieefektywne, ale najprostsze, więc dobre przy tworzeniu skinów i teksturach o małym rozmiarze.
A teraz pora wyjaśnić parę rzeczy, które wyjaśniałem już poprzednio, ale widać za słabo:
Gra to nie zwykły program graficzny który topornie ładuje te tekstury jak do obróbki zawalając całą pamięć RAM plus pamięć VRAM
Nie, ale przynajmniej tekstury obiektów które są widoczne na ekranie muszą zostać wczytane, prawda?
Oryginalne tekstury z paczek cdds są wczytywane w całości stąd ich małe rozmiary z ubogą jakościowo w rozdzielczości zawartością a konkretna tekstura dds np. samolotu który widzimy jest ładowana w razie potrzeby
cdds to zbiór tekstur wraz z ich mipmapami. Tak jak zauważyłeś, gra nie ładuje topornie wszystkich tekstur tylko znajduje sobie w pliku potrzebną aktualnie teksturę bądź mipmapy odpowiedniego poziomu i wczytuje właśnie je. Wiele gier ma wszystkie tekstury i modele w jednym pliku często o rozmiarze liczonym w Gigabajtach (jak w Oblivion) co wcale nie znaczy, że ten plik jest wczytywany w całości. Mały rozmiar tekstur bierze się raczej stąd, że w 2003 roku kiedy wyszedł LockOn przeciętny komputer miał 256MB RAM'u i kartę z 64MB pamięci VRAM.
musi też zostać rozpakowana do postaci którą jesteśmy w stanie zobaczyć na monitorze a nie we wzorze matematycznym i przetransportowana do pamięci . Cudów nie ma , a Kopperfild tych danych magicznie nie przesyła .
Paczki cdds na własne tekstury to też wyjście ale trzeba się bardziej wysilić. Ich zaleta to łatwy sposób ich umieszczenia na nośniku z grą jednym a nie np. dwóch czy trzech itd. Tak cdds działają też bez problemu w wersji 1.02 tak samo jak wszystkie tekstury i większość modeli dodatków itp. niby przeznaczonych dla FC to ten sam silnik ...
Proponuję poczytać na temat kompresji DXTn i jej przewag nad nieskompresowanymi, bądź skompresowanymi zwykłą metodą (np JPG) teksturami, oraz zastanowić się dlaczego w grach używa się właśnie skompresowanych tekstur (na przykład Doom 3, HalfLife 2). Ja już to napisałem w poprzednim poście i nie będę się powtarzał. Na początek może być tutaj:
http://fit.com.ru/Surveys/TextureCompression/index.htmhttp://developer.nvidia.com/attach/6585Kompresja tekstur można zarzucić, że powoduje pewien spadek jakości obrazu, ale na pewno nie to, że obniża wydajność.
pomimo tego że mam 2 GB pamięci i 512 mb na karcie graficznej nie są to jakieś kosmiczne wartości na dzień dzisiejszy
Co oznacza, że poza promilem użytkowników mających więcej niż 2GB pamięci i którąś z kart serii 8800 masz najmocniejszą obecnie konfigurację.
Co do mipmappingu i jego “darmowym” programowym czy sprzętowym zapotrzebowaniu na pamięć to nie będę się wypowiadał , ręce mi opadły .
http://pl.wikipedia.org/wiki/Mipmapping
A mi ręce opadają jak ktoś podaje linka do wikipedii nie rozumiejąc nawet o czym tam piszą. To że mipmapimg ma większe zapotrzebowanie na pamięc to zrozumiałe, ale pomyślałeś o jaką pamięć chodzi? Bo w przypadku Lock Ona chodzi tylko o pamięć dyskową, gdzieś te mipmapy trzeba przechowywać. Engine nie wczytuje naraz wszystkich mipmap do pamięci podczas grania, wybiera tylko z pliku te które są aktualnie potrzebne i tylko one są przesyłane w skompresowanej postaci do pamięci na karcie graficznej.
Za obsługę wszystkiego co związane z grafiką w grze odpowiada silnik gry , karta graficzna ( ze sprzętową obsługą Mipmappingu ..etc) , sterownik karty DX itd. To złożony proces i niema tu co podawać jakiś filozoficznych wyliczeń , wiadomo że ze wzrostem rozdzielczości tekstury czy nawet obrazka wzrasta zapotrzebowanie na pamięć
Filozofii proponuję w to nie mieszać, bo zaraz przyjdzie qrdl aka dr Boski Logos i będzie pozamiatane. Natomiast obliczenia są jak najbardziej na miejscu. LO jest tak napisany, aby robić użytek z mipmap i skompresowanych tekstur: dla każdego obiektu w grze jego tekstury są wczytywane oddzielnie nawet jeśli są takie same, co oznacza, że mając w polu widzenia 10 samolotów z 10 megowymi nieskompresowanymi teksturami bez mipmap, zajmiesz sobie 100MB pamięci RAM i odpowiednio większą ilość VRAM, choćby samoloty były widoczne jako punkty w oddali. Z mipmapami i kompresją ta wartość zredukuje się do kilku megabajtów mimo zachowania tej samej rozdzielczości tekstury...
Tekstury nie są usuwane z pamięci dopóki nie ma takiej potrzeby (dzięki temu zmniejsza się ilość powolnych pobrań z dysku twardego), więc ktoś kto nie ma 2GB ramu używając Twojej metody lecąc jakąś większą misję po prostu zapcha sobie w pewnym momencie całą pamięc operacyjną i zacznie pracować na swapie.
To co napisałem to nie tylko moje widzimisię, zresztą poparte praktyką (opisałem swoje testy w poprzednim poście ale widać mi nie wierzysz - więc popróbuj sam) ale też opinia wielu użytkowników, nie tylko z tego forum. Jesteś jedyną znaną mi osobą która upiera się że jest inaczej.