Skocz do zawartości
PsichiX

Testy XenonCore2

Rekomendowane odpowiedzi

Witam,

Chciałbym przetestować wciąż tworzoną nową wersję 2.0 na różnych konfiguracjach. Prosiłbym o odpalenie i wysłanie mi logu aplikacji (wygenerowany plik "xeframework2.log").

Ten test pokazuje rendering techniką Shape Poolingu, aktualnie statycznie, zaś za jakiś czas wrzucę wersję dynamiczną.

http://dl.dropbox.com/u/9759049/XeFramework2-test.zip

 

PS. Jeśli znajdą się osoby chętne, to mogę wrzucić źródła testu.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Name: 'XeFramework2'

Resolution: 1024x576

Fullscreen mode: false

OpenGL version: 3.3.0

GPU renderer: GeForce 9600 GT/PCI/SSE2/3DNOW!

GPU vendor: NVIDIA Corporation

 

AMD 64x Dual-Core 2,8 GHz

4 GB RAM

Średnia FPS: 97/120

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

ja zaś mam to samo co ediepl, 19 fps na kmpie w pracy :< no to szukam powodu tego problemu :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Tu nie ma problemu. Problem to, że ty to robisz.

Jest tyle pięknych silników, to ty musisz własny robić!

dzięki temu dostałem niezłą pracę, słuchaj. mam ambicje większe niż spędzanie dni na fapowaniu przed anime. Ale co ja będę się w jałowe dyskusje wplątywał :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
Tu nie ma problemu. Problem to, że ty to robisz.

Jest tyle pięknych silników, to ty musisz własny robić!

You are joking ? Psyhix, nie moge pobrać, brak łączności z serverem :mellow:

Dobra, dobra już jest ;)

EDIT:Oto wykaz testu:

xenon.png

Karta graficzna: ATI Mobility Radeon 9700 + Pixelshader 64mb

Procek: Intel Pentium M 1.7GHz

RAM: 512mb

Ten log zapisany w txt: http://hostuje.net/file.php?id=01b635eea8a...7e9a349f2fd9af8

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach
ja zaś mam to samo co ediepl, 19 fps na kmpie w pracy :< no to szukam powodu tego problemu

Ja mam tak mało fps bo robię na kompie który jest już stary, mogę przesłać z log lapka.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Witam ponownie, chciałbym zaprezentować nowy Xenon Framework 2.0, nad którym pracuję ostatnio. Chciałbym pokazać, co obecnie potrafi, oraz zebrać grupkę osób, która byłaby chętna wspomóc mnie poprzez tworzenie tutoriali/demek/gier na nowym silniku, generalnie chodzi o współpracę na zasadzie: daję i tworzę wymagane przez Was narzędzia, a Wy używacie ich, tworząc coś, co pozwoli na testy i wytworzenie najefektywniejszej wersji nowego silnika. Byłbym ogromnie wdzięczny takim osobom za pomoc :)

 

Link do źródeł aplikacji testowej, aby potencjalne, chętne osoby mogły obczaić kod nowego silnika:

http://dl.dropbox.com/u/9759049/XeFramework2-tut1.zip

Kolejność czytania plików: main; level; logo; player; playerbrain; crate;

 

Dodam, że nowy silnik ma w całości bazować na VBO i shaderach (skupiać się na OGL 3+), dlatego póki co nie ma fontów, które były dotychczas na displaylistach.

 

Pozdrawiam :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Yeeaaa!! Packman :D

Tak patrzyłem po kodzie w projekcie, i wydaje mi się zrozumiały.

Pytanie do ciebie, gdzie ty masz sprita packmana i paczek ?? - bo nie widze w folderach, albo jaki on ma format^^.

A jak tam z systemem kolizji, w sensie czy jest lepszy niż w GM'ie? :)

Ja ide się poduczyć o klasach i obiektach. : D

edit* Jak sam wiesz, zapisuje się do testów :)

edit2*Ta teraz patrze, to format jest *.xet, no to czytam dalej ;)

edit3*Kod da się zrozumieć, musze jeszcze popatrzeć, jak są napisane funkcje.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

1) Napisz do tego dobry edytor+skrypty. Bez tego pisanie gier na jakimkolwiek silniku to mordęga.

2) Nawet najprostsze klasy potrafią mieć po kilka rodziców i człowiek nie wie za co się złapać szczególnie, że część w ogóle jest oderwana od rzeczywistości.

Klasa MemoryManager jest tylko zwykłym holderem na info. Ktoś nie zerknie w kod tylko uzna, że to rzeczywiście mem mgr i będzie sobie z uśmiechem ładował setki intów na stertę i to w jakieś pętli czy co klatkę. Potem płacz, że gra pełza a na ekranie 2 boxy.

3)Po co dawać dziedziczenie po klasie z operatorami dla pamięci, nie prościej po prosty przeładować globalne. Ludzie będą mieli znacznie uproszczony kod.

4)Budowa klas jest myląca. Materiał zarządza teksturami ale już parametrami nie. Jak w takim razie mam sobie najlepiej posortować materiały dla batchowania jeśli nie wiem, które obiekty mają takie same dodatkowe parametry?

5) Dlaczego materiał/efekty itd muszę tworzyć sam... Tym powinien zająć się mgr. Co będzie jak do kontenera przekaże wskaźnik na lokalny obiekt stworzonego efektu? Ja nie wiem czy mgr obiekt skopiuje czy użyje gotowy pointer/albo jeśli gdzieś go tam sobie usunę bo będzie w połowie levela niepotrzebny.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

1. edytory zacznę tworzyć, mając już gotowe fonty i gui, skrypty (Intuicio) są w trakcie kodowania.

3. istnieje szansa, że niektóre liby zewnętrzne, które user mógłby sobie dodać do silnika, powodowałyby konflikty, taką opinię uzyskałem, na chwilę obecną nie mogłem sprawdzić, więc lepiej zdefiniować w ten sposób, które obiekty mają być śledzone. Poza śledzeniem będzie też właściwe zarządzanie pamięcią, nie wszystko od razu dałem radę zrobić.

4. sortowaniem zajmuje się batch wewnątrz siebie, sortuje obiekty tak, aby liczba chunków do renderingu była jak najmniejsza.

5. to załatwić może smart pointer, najpewniej dodam jego obsługę w managerach, dzięki za zwrócenie mi na to uwagi :)

 

Aktualnie tworzę zarządzanie i kompilator atlasów tekstur, które pozwolą zaoszczędzić zmiany tekstur dla chunków, następnie zajmę się fontami w VBO, obecne są na displaylistach, czego nie chcę już używać w nowym silniku. Dodatkowo będzie też klasa ładujące dane assetów, najpewniej z paczek VFS, które to już będą posiadały w sobie wszelkie dane, więc nie będzie trzeba ręcznie ładować danych w kodzie, a manager assetów się tym zajmie.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Musi on być "aż tak profesjonalny" ?

Co ci starszy xenon przeszkadzał w swojej prostocie? xd

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

1. Nie radzę tworzyć gui z własnej biblioteki. Zapier.. się jak głupi a i tak będzie problemów od cholery. Znacznie lepiej połączyć silnik z c# winforms czy wpf. Praktycznie potem do gotowego edytora wystarczy tworzyć kolejne wersje silnika, które prawie same się z nim połączą. Nawet silniki z mocnym gui jak unity są po prostu wkur.. bo ich gui rypie się przynajmniej kilka razy w tygodniu.

 

3. Kij z tym, przejrzystość jest najważniejsza. Jak jest taki problem dodać define na debuga typu DECLARE_FOR_TRACE gdzie stworzy obiekt w każdej klasie, który sam się zapiszę do śledzenia. Wielodziedziczenie to tylko problem na przyszłość. Jak doda się zarządzanie pamięcią i będzie stack/frame/pool alokator to i tak całość pójdzie w cholerę i trzeba będzie wszystko odwracać.

 

4. No tak ale chodzi o przejrzystość ze strony użytkownika. Załóżmy, że są 2 materiały wood0 i wood1. Mają te same tekstury, ten sam shader tylko różnią się przekazanym parametrem np: light_diffuse:Color. Teraz jak mam ten parametr ustawić. Normalnie zrobiłbym to z materiału ale tutaj muszę lecieć do efektu i z jego strony to układać. Na logikę all co dotyczy materiału powinienem sobie ustalić z materiału a nie babrać się z innymi klasami. Teraz wood0 i wood1 byłyby tym samym materiałem bo tex takie same.

 

5. Smart pointers są kosztowne i jeśli będzie ktoś miał w projekcie kilkaset materiałów + innych obiektów to koszt będzie duży. Nie lepiej zrobić tak:

 

Handler handler=ResMgr->addResource<Material>("material.tpp",SOURCE_FILE/SOURCE_NEW/SOURCE_VFS);

 

Teraz jako programista mam głęboko zarządzanie pamięcią, sprawdzanie błędów itd.

 

potem mogę sobie dorwać zasób:

 

Material& mat=ResMgr->getResource<Material>(handler);

 

Proste, szybkie i jest jeden mgr na większość plików. Co najważniejsze działa tak samo dla każdego zasobu czyli bardzo prosty do ogarnięcia.

 

 

 

Atlasy tekstur teraz niewiele dadzą przy różnych parametrach i tak pójdzie prawie taka sama lista drawcalli(Dla dużych projektów już co innego). Zresztą elementy tego typu można zrobić jak będą gotowe główne etapy. Ja na twoim miejscu zrobiłbym dobry edytor i wtedy na podstawie feedbacku dorzucał bardziej skomplikowane features. Dobry edytor=liczba_użytkujących*100 a tym samym znacznie lepszy feedback.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

@cekol:

jak to mówią: coś za coś.

xenon 1 był prosty w obsłudze, intuicyjny nawet bym rzekł, ale miał za dużo naleciałości z GMa, a GM, jak wiecie, nie jest najszybszy przy swej prostocie. tak samo z xenonem 1 było - chciałeś renderować masę obiektów na scenie? musiałeś brać pod uwagę, że każdy aktor musiał być przelecony w pętli i rysować w sobie tego sprajta - ogółem zły nawyk, bo mając tysiąc obiektów tego samego sprajta, wywoływało się n * 1000 drawcalli na krok pętli (gdzie n to liczba wywołań zmian tekstury i macierzy widoku modelu), przez co gra się zaczynała ciąć, w xenonie 2 wszystko jest optymalizowane tak, aby zaoszczędzić jak najwięcej czasu, pamięci i zasobów, nie marnotrawiąc tego. zresztą, muszę zarzucić jakimś testem wydajnościowym, porównującym starego i nowego xenona, sami wtedy zobaczycie.

dla czego chce, by xenon 2 byl profesjonalny? abym mógł sprzedawać jego źródła i w ten sposób zarabiać na jego dalszy, szybszy rozwój, inaczej kodzenie go zajmie mi wieki, albo kilka kolejnych lat, jak 1.

Poza tym miło byłoby usłyszeć i zobaczyć, że xenon został wykorzystany w jakiejś super grze, która odniosła światowy sukces :D

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

niestety jeszcze nie - musiałbym przekompilować na CB rdzen, czego zrobic nie moge, bo moj laptop ma martwy zasilacz i dopiero za jakiś czas kupię nowy.

 

btw. bedzie dodatkowy mechanizm i tool do niego - texture atlas arrays, dzieki czemu calosc grafik na dany level bedzie w jednej mega testurze, wiec jesli uzywamy tego samego shadera dla wszystkich sprajtow i jednej mega tekstury, to zawsze bedzie renderowal wszystkie sprajty na raz, bez podzialu na mniejsze porcje renderingu :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Update!

dodałem czcionki, popoprawiałem znalezione przez użytkowników błędy i kolejna wersja ląduje do Waszych rączek:

http://dl.dropbox.com/u/9759049/XeFramework2-tut1.2.zip

 

teraz rozszerzę implementację fontów, potem zajmę się particlesami i stworzę manager assetów, które będą zautomatyzowanie ładować niezbędne zasoby i tworzyć je w grze. na przykład: ładując asset sprajta, w nim znajduje się informacja, jakiego materiału potrzebuje i jakie są jego parametry. potem dorobię edytor assetów, póki co będą to pliki XML z informacjami dla managera.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Update!

przerobiłem ładowanie zasobów (a raczej dodałem manager assetów ładowanych z plików xml).

od teraz kod będzie dostępny na SVNie: http://subversion.assembla.com/svn/xenon-core-2

 

teraz pora zrobić jakiś mały edytor assetów na tym, co już jest :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Update!

dodałem obsługę dźwięków oraz przekodowałem co nieco frameworka, aby można było renderować scenę do canvas i używać tego potem do efektów fullscreen. w przykładowej aplikacji dodany fullscreen gray scale.

Źródła na SVNie: http://subversion.assembla.com/svn/xenon-core-2

Paczka ZIP: http://psichix.gmclan.org/download.php?fil...ore2betaSDK.zip

 

BTW. Dodałem info na stronie silnika o betatestach nowej wersji. Zapraszam do współpracy w rozwoju silnika :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

UPDATE!

Dodano klasę Skeleton do animacji szkieletowej, w drodze robi się klasa animacji, oraz asset do jej edycji.

Zmodyfikowano także nieco klasę IRenderable oraz IScene (IRenderable przy niszczeniu automatycznie detachuje się ze sceny - wcześniej brak tego wywoływał błędy).

Dodano także kilka kosmetycznych zmian.

Kod na SVNie, później wrzucę też ZIPa aktualnej wersji.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

Zgłaszam się na "projektanta" jakiegoś języka pod Intuicio :)

btw. jest jakaś możliwość kontaktu? GG/email?

@ mam nadzieję że nie odkopałem za bardzo.

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

5745342 - gg :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

fakt D:

poprawka: 5745342 :)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach


Symulacja nieba liczona całkowicie na GPU, bez użycia ani jednej tekstury ;)

Udostępnij tego posta


Odnośnik do posta
Udostępnij na innych stronach

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników, przeglądających tę stronę.

×