Gierka FPP - tylko 96kB

Maxym wez wytlumacz dlaczego ta metoda plik ma tylko 96kb bo ja potrafie tylko na chlopski rozum

Tytus to wszystko nie jest W 96kb zawarte, to jakby 90kb kodu mowiacego twojemu kompowi co ma rysowac jakich kolorow itd a twoj komp tworzy textury i wszystko innne wg tych tekstowych wytycznych, a 90kb textu to BARDZO duzo, normalna gra ma te textury juz na dysku i tylko je wyswietla, dlatego zajmuja 300mb, ale za to szybkosc/wydajnosc takiej gry jak sami widzicie jest calkiem inna..

chodzi o to ze ten rozmiar nie jest nijak szokujacy a na tym sie skupiliscie..

podam inny przyklad:

w 3dmaxie mozna zbudowac scene 3d, siatki, na to textury i zrobic plik tiff 400mb jako export

to samo mozna w widoku kodu (qrde to nie 3dmax chyba tylko maya? niech fachowcy sie wypowiedza ale ktorys z wiodacych progsow 3d w kazdym razie) zapisac ta cala scene jako ciag textowy w jakims tam jezyku typu: go50color355&linesplitleft45&ksdksdjs

zajmie to ok 40 linijek teksty czyli pare bajtow, przesyla sie to do innego ludka z tym samym progrem tamten wkleja ten ciag i... generuje dokladnie taka sama scene 3d 400mb, to nie znaczy ze ten pierwszy jest super hiper cudotworca bo upchnal 400mb do 3bajtow uff jasniej nie potrafie

Richie teraz kumam , ale i tak naleza sie brawa dla autorow

MaXyM napisał:

Tytus jaki masz sprzęt? bo na moim sprzecie to chodzi ale do OK to mu daleko (jakies 10-15 fps na oko)

PIV 2,6 + radek 9500pro podkrecony... I na moje oko w tym shoterze jestok 25-30 fps

Richie napisał:

Maxym wez wytlumacz dlaczego ta metoda plik ma tylko 96kb bo ja potrafie tylko na chlopski rozum

no to moze tak ... masz pokazac na monitorze wykres funkcji sinus.

met. standardowa: wczutujemy bitmape z narysowanym sinusem. Bitmapa jest duza (bo musi miec dobra jakosc itp)

Metoda druga (w wymyslonym jezyku):
for x=0 tp 100
y=sin(x);
draw(x,y);

Tu jest podobnie .. tekstury i sample (te na 100%, bo wiekszosc to pochodna sinusa, wiec nie trzeba wczytywac wave-ow, tylko napisac wzorek) sa prawdopodobnie zapisane w jakis algorytmatmach, ktore sa tworzone w czasie trwania tego paska postepu.

oj ja za daleko poszedlem w tym przykladzie z 3d i nie wiem po co najlepszym przykladem jest przeciez wlasnie projekt 3d, sama siatka, ktora zajmuje 50kb otwieramy ja i.. program 3d renderuje ja godzinami, mozna miec siatke 30kb i generowac obrazek jak ta gierka wyzej, a mozna trzymac animacje 3giga na podstawie tej siatki w formie avikow

w sumie ciekawa mysl mi przyszla, czy w dobie rozwoju gier na 18 cdromow i przy wzroscie mocy komputerow nie powinno sie pomyslec wlasnie nad powrotem do algorytmow? gra zajmuje 50mb zamiast 10cd a mocny sprzet renderuje gre real-time?

Ale po co ? Qfa plytka kosztuje grosze, a zawsze jest to jakies zabezpieczenie przed piractwem - komu sie bedzie chcialo sciagac 10cd

Richie, Tiges mniej więcej wytlumaczył.
Ja pisałem z tego pracę inż to mogę zapodać pdf'a

Twój pomysł jest b. dobry i pewnie do tego dojdzie kiedyś. Bo tekstury proceduralne (generowane z algorytmów) mają jeszcze inną przewagę: mogą być animowane w nieskończoność (nie w pętli). Możesz sobie wyobrazić animację ognia bez wrażenia ze co 4 sek płomien jest jakiś taki sam...

Problemem niestety jest wydajność systemow komputerowych. Mimo ze karty gfx od jakiegoś czasu mają bardziej lub mniej wydajne shader'y (wbrew pozorom to jest wlasnie czesc gpu renderujaca textury ze wzorów) to tak naprawdę dopiero DX9 je wspiera. A jeszcze bardziej 'na prawde' jest fakt że są one mało wydajne. Można nimi generować małe obiekty ale pełnych textur całej sceny nie stworzysz w reatimie bo zabijesz każdą kartę gfx.