XenoN PlayGate 1.X

[Dragon]

Czworopost :D . A tak to chyba fajnie się zapowiada (po raz drugi :D), ale szkoda że ci się skasowało, a nie próbowałeś jakimiś programami przywrócić ?

[Dawidds]

Próbował.

 

Ale to w sumie dobrze, że usunął - napisanie czegoś od nowa zwykle daje pozytywne rezultaty :)

[Pieter]

a to Ty mowiles serio? :D ale przeciez jest tam projekt GM 6.1, a go powinienes dac rade otworzyc i exportowac jako exe :P

dał bym rade. Szkoda tylko, że mam viste i nie mam gma.

[lenin]

ęzyk "Intuicio" o strukturze assemblera

Szkoda, że nie jakiś prostszy język (cpp itp)

Ogólnie fajnie to się czyta ale ciekawi mnie, jak będzie to intuicyjne w użytku :)

[PsichiX]

Pieter: nie wiedziałem ;p to do następnej wersji dam też skompilowane demo.

Lenin: assembler nie ma takiej trudnej składni na jaką wygląda. Ale spokojnie, napiszę też do niego jakiś prosty język skryptowy więc nie będzie problemu z używaniem :)

a przykładowy kodzik intuicio będzie wyglądał na podobieństwo tego:

SYM sub1, E64;
FRST sub1, $SUBSTANCE;
SYM sub2, E64;
FRST sub2, $SUBSTANCE;
SYM dist, F32;
@petla;
DIS dist, sub1:position, sub2:position;
SUB dist, dist, 128.0;
CMP dist, @lacz, @lacz, @nielacz;
@lacz;
MOV sub2:position, sub1:position;
@nielacz;
NEXT sub2;
EMP sub2, @reset, @petla;
@reset;
FRST sub2, $SUBSTANCE;
NEXT sub1;
EMP sub1, 0, @petla;
END;

a w języku skryptowym:

E64 sub1;
sub1=First($SUBSTANCE);
E64 sub2;
sub2=First($SUBSTANCE);
F32 dist;
do{
do{
dist=Distance(sub1.position,sub2.position);
if(dist<=128)
sub2.position=sub1.position;
Next(sub2);
}while(!Empty(sub2));
First(sub2);
Next(sub1);
}while(!Empty(sub1));

 

Jak widzisz, nazwa jest dość ironiczna :D bo wcale nie wskazuje na intuicyjną składnię, trzeba po prostu będzie poznać pewne zasady ;p

[Kaelis]

Witam. Jestem co-developerem Battleships Forever ( http://gmc.yoyogames.com/index.php?showtopic=139677 ).

 

Jak zapewne niektórzy wiedzą, BSF cierpi na chroniczny brak wydajności. Jest to spowodowane kombinacją trzech faktów:

- Statki w BSF są budowane przez graczy z tzw. sekcji. Każda sekcja to praktycznie dwa sprite'y - jeden 'normalny' i jeden do uzyskania pewnego efektu graficznego. Bywają sytuacje, że na ekranie znajduje się kilka statków zbudowanych z setek części każdy - a już jeden statek zbudowany z kilkuset części jest problemem.

- Aby uzyskać efekt smugi/śladu, większość pocisków jest renderowana do surface'a obejmującego cały room, włączając pociski poza ekranem. Z kolei surface ten jest renderowany kilka razy (plus inne 'sztuczki') aby uzyskać efekt rozmycia.

- Gra korzysta z view'ów.

 

 

Dotąd byłem przekonany że nic się nie da poradzić na brak wydajności, ze względu na limitacje GameMakera. Ale ostatnio na oficjalnym forum GM odkryłem Xenon PlayGate i bardzo mnie to zainteresowało, narazie zapowiada się bardzo dobrze.

 

 

Niestety jedyne źródła informacji jakie znalazłem to ten thread, thread na gmc.yoyogames.com, no i oczywiście załączone sample. Dlatego chciałbym tutaj zadać parę pytań odnośnie PlayGate:

1. Zdaję sobie sprawę że rendering to nie jedyna mało wydajna część GameMakera, ale chciałbym zapytać jak dużo mogę zyskać przez wymianę renderingu na PlayGate? Czy istnieją jakieś dane lub benchmarki porównujące wydajność? Czy warto się w to w ogóle bawić?

2. Rozumiem że PlayGate posiada odpowiedniki odpowiedniki funkcji GameMakera (synonimy). Czy mogę w całości wykorzystać istniejący kod i tylko podpiąć PG, czy muszę coś zmienić? Zakładając że jedyne co chcę zmienić to rendering, jakie konkretnie modyfikacje są potrzebne? Które funkcje z GM mają swoje synonimy w PG?

3. Zakładając że zdecyduje się na użycie PlayGate do renderingu, jakie zmiany w kodzie rysowania mogę/powinienem wprowadzić aby uzyskać większą wydajność?

4. Zauważyłem że wszystkie przykłady to .gm6 . Czy to oznacza że PlayGate nie jest kompatybilny z GM7?

 

Byłbym wdzięczny za odpowiedzi na te pytania i wszelkie linki do źródeł informacji.

[PsichiX]

Witam :)

1. z racji iż dostępne przykłady i demka są sprzed około dwóch miesięcy, a w tym czasie sporo się działo w pracach nad silnikiem, w tym wydajność skoczyła gwałtownie, to nie miałem czasu przygotować publicznych testów wydajności, jednak testowałem w trakcie tworzenia i z pewnością jest on szybszy od GMa, nie mniej zbieram się do przygotowania takich testów gdy już skończę podmieniać wszystkie funkcje graficzne.

2. ideą jest używanie silnika dokładnie tak samo jak normalne funkcje, co za tym idzie Twoim jedynym zadaniem było by umieścić obiekt silnika w roomie w którym chcesz go używać, a on zrobi juz za Ciebie wszystko automatycznie - uzywanie go jest nieodczuwalne od strony kodu.

3. domyślnie PG używa tablic wierzchołków dla sprajtów i innych elementów co juz przyspiesza renderowanie. na pewno efekty które wymagają odrysowywania kilka razy lepiej umieścić w pixel shaderze który nam dany efekt uzyska szybciej. Surfacesy proponuję podpiąć bezpośrednio pod jakiegoś sprajta i do niego rysować elementy niedynamiczne raz i uzywac do woli, lub zmieniajac jego zawartosc dowolnie dla dynamicznych tekstur sprajtow (porownam to do malowania sprayem po murze ;p). PG umozliwia tez uzywanie macierzy transformacji (osobne dla wierzcholkow i osobne dla tekstur) i je polecam uzywac zamiast lengthdirow. Wszelkie modele (ksztalty) najlepiej bedzie pakowac w bufor (model; odpowiednik GMowego d3d_model_*()) i rysowac od razu funkcja renderujaca tablice zamiast rysowac to prymitywami. na razie tyle przypominam sobie (troche sporo w silniku siedzi a ciagle zmiany nie pozwalaja wszystkiego pamietac ;p).

4. gm6 dla tego aby mozna bylo uzywac go w obu wersjach 6 i 7 (w niedalekiej przyszlosci tez 8)

 

Jesli masz dalsze pytania jestem gotow udzielic Ci na nie odpowiedzi.

Ewentualnie zapraszam na GG: 5745342.

Pozdrawiam :)

[Kaelis]

Dzięki wielkie za odpowiedzi, chociaż są one trochę mało konkretne, no i oczywiście mam więcej pytań :)

 

1. Aby się upewnić - to znaczy że zmiana renderingu w BSF z GM na PG da mi co najmniej parę klatek więcej, tak?

2. Czy to oznacza że wszystkie funkcje typu draw_, surface_, d3d_ etc mają swoje synonimy w PG?

 

Na pewno efekty które wymagają odrysowywania kilka razy lepiej umieścić w pixel shaderze który nam dany efekt uzyska szybciej.

Czy istnieje przykład użycia takiego shadera, czy może ogólnie dokumentacja albo przykład używania shaderów ?

 

Surfacesy proponuję podpiąć bezpośrednio pod jakiegoś sprajta i do niego rysować elementy niedynamiczne raz i uzywac do woli, lub zmieniajac jego zawartosc dowolnie dla dynamicznych tekstur sprajtow (porownam to do malowania sprayem po murze ;p).

Co konkretnie rozumiesz przez dynamiczne/niedynamiczne? Czy mógłbyś wytłumaczyć albo dać prosty przykład?

 

Wszelkie modele (ksztalty) najlepiej bedzie pakowac w bufor (model; odpowiednik GMowego d3d_model_*()) i rysowac od razu funkcja renderujaca tablice zamiast rysowac to prymitywami.

Czy chodzi o to żeby grupować sprite'y używające tą samą teksturę/kolor/blending w batche i rysować te batche 'manulanie' jako po prostu trójkąty z tablicy? I znowu, czy istnieje jakiś przykład?

[PsichiX]

co do przykladow kodu niestety musialbys poczekac na premiere PlayGate2 po nowym roku, bo wszystkie musze pod nowa wersje przepisac.

 

1. na pewno da to przynajmniej tych kilka kaltek wiecej, pracuje tez nad automatycznym odrzucaniem niewidocznej geometrii z kolejki do renderowania oraz swego rodzaju poziom detali.

 

2. jeszcze w tej chwili nie do konca, ale do premiery beda podmienione wszystkie funkcje graficzne (w tym te ktore wspomniales).

 

Co do pixel shaderow to stara wersja uzywa shadery GPU ARB ktore sa nieco skomplikowane do pisania, w nowej wersji bedzie juz do uzytku jezyk shaderow GLSL (http://en.wikipedia.org/wiki/GLSL) ktory skladniowo przypomina c++ (i GML w pewnym stopniu) a dokumentacje postaram sie umiescic razem z SDK silnika i obszerny opis z przykladem jak je pisac oraz biblioteka kilku podstawowych efektow w tym wlasnie glow i blur ktore z tego co widze Wasza gra najprawdopodobniej uzywa (badz zamierzacie ich uzyc).

 

dynamiczne to takie ktorych wyglad zmienia sie czesto (chociaz by co klatke) a niedynamiczne to takie ktore mozna narysowac raz i dalej sie jej nie modyfikuje. surfacesy w PG sa niczym innym jak dynamicznymi teksturami - teksturą której zawartość możemy zmieniać dowolnie, tak jak to działa przy surfacesach w GM - malować po nich, tak jak po scenie (roomie), dodatkowo używać ich jako tekstur dla sprajtów (czego w GM nie ma) przez co możesz mieć jakiś obiekt któremu będziesz mógł dorysowywać dziury bądź wszelakie inne obrażenia, dosłownie cokolwiek, bez konieczności uzywania sprite_create_from_surface(), ani rysowania surfacesa zamiast sprajta - wystarczy utworzyć surfacesa, pobrać jego teksturę, przypisać ją dowolnym sprajtom i one zawsze będą rysowały to co zawiera surfaces. plusem jest też że surfacesy w PG obsługują kanał alpha bez żadnych zbędnych zabaw z blendingiem - możesz więc spokojnie rysować na nim obiekty półprzezroczyste, bądź ustalać wartosc alpha danego pixela wedle swojego uznania, i dziala to zaskakujaco szybko :)

 

co do ksztaltow: jesli uda mi sie szybko zrobic taki automat to bedzie on dzialal jak particle w PG ze automatycznie beda grupowane w kolejce renderowania wedle tekstury oraz wartosci depth takk by za jednym razem wyswietlac je pogrupowane i jeszcze szybciej, jesli zas nie zdaze to pokaze jak ta metode uzyskac przy nie duzych zmianach w kodzie (same funkcje i ich sklandia sie nie zmienia). Ale i tak postaram sie to zautomatyzowac by nie trzeba bylo sobie tym glowy zawracac.

 

Jak cos to jestem otwarty na kazde dodatkowe pytanie - wiadomo ze na raz nie da sie wszystkiego opisac dokladnie a konkretne pytania ulatwiaja sprawe, jak teraz ;)

PS. wybacz ze pol posta jest z ogonkami a reszta bez - pisanie na szybko daje takie rezultaty za co przepraszam jesli utrudnia to czytanie posta

[don_soyer]

jak to jest być geniuszem? ;] serio dobra robota. czekam na update

[Makary155]

Właśnie, a najbardziej na te twoje zajeświetnie szybkie particle

[PsichiX]

hehe, no na chwilę obecną bije GMa na głowę, 7 razy więcej cząstek (35000), dążę do 10x na CPU, oraz 100x na GPU (to już będzie ekstremalny wynik, jak się uda będę bogiem :D xD)

[Markar]

jak się uda będę bogiem

A ja myślałem że już nim jesteś xD

A na pewno to cudeńko użyję bo np. na przykład zrobić planetę(słońce) ze spritów to koniec świata by był, a tym cudeńiem zrobie to bez spadku fps'ów ;D

[I am vader]

Nie wiem czy mogę się wtrącić, ale słońce to nie planeta, a Psi i bez tego pro wyniku jest bogiem.

[Markar]

ale słońce to nie planeta

A to akurat wiem, źle napisałem, na początku chciałem powiedzieć ogólnie planety, ale powiedziałem słońce ;D

[PsichiX]

Hej, mam prośbę, moglibyście przetestować shadery z tej dllki (obecny komp nie wspiera shaderów, a chcialbym to do poludnia opublikowac i potrzebuje wiedziec co widzicie po odpaleniu)?

 

http://psichix.gmclan.org/download.php?fil...nShaderTest.zip

[Shockah]

Tyle widzę tylko. W show_message wszystko successful.

Gainward GeForce 9600 GT, 512 MB; Windows 7 Ultimate.

 

Chyba że to wina konwertowania EXE z GM6 na GM6-Vista.

[PsichiX]

heh, niechcacy dalem ladowanie default.frag, tutaj poprawiona wersja, sprawdz prosze teraz, obrazek powinien byc szary :)

http://psichix.gmclan.org/download.php?fil...nShaderTest.zip

[Shockah]

To samo :/

[Danielus]

 

ATI saphire radeon x1950 pro, windows xp prof

[PsichiX]

no to ostatnie podejscie dla tych co nie maja bledow:

http://psichix.gmclan.org/download.php?fil...nShaderTest.zip

modyfikujcie do woli parametry w create gdzie jest PhEffectSetVariable(), powiny sie miescic od 0 do 1, moze niepoprawne cos daje ;p