Autor Wątek: Sprzedawanie gier XNA  (Przeczytany 5703 razy)

Offline quaikohc

  • Użytkownik

# Luty 05, 2012, 13:16:02
A nie chodzi aby o to, by gry niewymagające całej mocy maszyny tworzyć w języku, który pozwala na pisanie w sposób trochę bardziej 'rapid'? :)

moze nie jasno sie wyrazilem: chodzilo mi o pisanie w managed c++ skoro jest c#

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline głos

  • Użytkownik

# Luty 05, 2012, 14:48:09
C++ z nowym systemem wygląda jak manage ale manage nie jest, jest kompilowany natywnie. Skoro do WinRT mamy dostęp zarówno z kodu manage jak i z kodów natywnych nie widzę przeszkód w opracowaniu nowego wysokopoziomowego api graficznego. Oczywiście jeżeli takie api powstanie to będzie okrojone bo powinno być dostosowane do wielu platform (może właśnie coś wzorowanego na XNA 5?)

DirectX jako api systemowe pozostanie i będzie furtką dla tych którzy chcą osiągnąć maksymalną wydajność (Na Xbox 720 pewnie będzie coś na kształt obecnego XDK, na mobilach trudno zgadnąć czy coś będzie okok nowego api).

Generalnie sprzedawanie gier XNA do dobry pomysł (bo jeżeli nawet wprowadzą nowe api, co jest tylko wróżeniem z fusów :), to myślę że XNA jako platformie będzie do niego bliżej niż DirectX).

Offline ConayR

  • Użytkownik

# Luty 05, 2012, 16:33:33
W świecie Windows 8 i interfejsu metro, XNA nie będzie wspierane (oczywiście będzie w desktopie).
Bo? IIRC WinRT rysuje na tym samym surface, który można wykorzystać w XNA i SL.

Cytuj
Niby do gier ma być DirectX ale jest jedno małe ale. Nie wiem czy zauważyliście przeniesienie DirectX w Windows 8 do api systemowgo (nie będzie już samodzielną całością).
Bzdura na resorach. DirectX pozostaje tym, czym był.

Cytuj
Nie wiadomo co będzie z DirectX SDK (chyba nie będzie rozwijany przez Microsoft).
Kolejna bzdura: DX SDK zostało wciągnięte w Platform SDK, żeby ułatwić deployment całości. Samo API, narzędzia, jak i sample są dalej rozwijane (np. PIX przeszedł poważną metamorfozę).

Cytuj
Stąd wysnuwam wniosek (nie wiem czy słuszny ale prawdopodobny) że Microsoft coś przygotowuje. Stawiam na nowe wysokopoziomowe api graficzne możliwe do użycia zarówno z C++ jak i C# (w interfejsie metro).
Nic takiego nie ma miejsca.

Wydajność nie jest maksymalna jest przyzwoita. XNA mogłoby być jeszcze szybsze i to znacząco szybsze.
Gdzie i dlaczego? Na konsoli wszelkie wywołania są kosztowne, bo CLR nie jest zintegrowany w żaden sposób z systemem. Ale na PC zasadniczo nie ma żadnych poważnych powodów, które sprawiałyby, że XNA jest o niebo wolniejsze od gołego DX. Jasne, traci się wiele możliwości mikrooptymalizacji, ale w zamian dostaje się wygodne API z niezłym content pipelinem.

nie widzę przeszkód w opracowaniu nowego wysokopoziomowego api graficznego
Ja widzę.
1. Sterowniki WDDM są silnie związane z modelem programowania pod DX, a zmuszanie IHV do pisania nowych sterów nie przejdzie.
2. Wynajdowanie koła od nowa kiedy ma się miliony klientów jest biznesowym samobójstwem.
3. Zespół DX nie jest duzy, zespół XNA jest miniaturowy, a zasoby potrzebne na wynalezienie koła na nowo są ogromne.

Offline fn2000

  • Użytkownik

# Luty 05, 2012, 19:30:10
Wydajność nie jest maksymalna jest przyzwoita. XNA mogłoby być jeszcze szybsze i to znacząco szybsze.

Na podstawie jakich benchmarków to stwiedzasz?

Jak napisano wyżej, na Xboxie XNA jest wolniejsze zdecydowanie od natywnych implementacji bo .NET CLR na konsoli jest w wersji kompaktowej. W przypadku PC natomiast nie ma takiego ograniczenia i 99% informacji o słabej wydajności XNA na PC rozgłaszają ludzie, którzy nic konkretnego w XNA nie napisali.

To o czym szczegolnie nalezy pamietac tworzac pod XNA to automatyczne zarzadzanie pamiecia w postaci Garbage Collectora - tworzac gre nalezy unikac zbyt czestego wywolywania go do tablicy. Poza tym to XNA ma wiele zalet: swietna biblioteka matematyczna, content pipeline, b. przejrzyste i ustandaryzowane API, które chowa wiele niepotrzebnych i przestarzałych elementów.

XNA w Win8 jest obecne w trybie desktop co w zaden sposob nie ogranicza mozliwosci tworzenia i sprzedawania gier XNA. W obecnych wersjach systemu pomimo "oficjalnego" DirectX istnieje kilka innych frameworków, na ktore ludzie z powodzeniem tworza i sprzedają gry - najlepszy przyklad: Minecraft

Offline głos

  • Użytkownik

# Luty 05, 2012, 20:54:25
Bo? IIRC WinRT rysuje na tym samym surface, który można wykorzystać w XNA i SL.

To pytanie do Microsoft. XNA nie będzie wspierane w Metro to słowa ludzi z tej firmy i ja im wierzę :)

Bzdura na resorach. DirectX pozostaje tym, czym był.

Staje się api systemowym, jednym z wielu.

Kolejna bzdura: DX SDK zostało wciągnięte w Platform SDK, żeby ułatwić deployment całości. Samo API, narzędzia, jak i sample są dalej rozwijane (np. PIX przeszedł poważną metamorfozę).

Tutaj potwierdzasz co napisałem wcześniej DX ląduje jako api systemowe, dojrzałe którego potrzeba aktualizacji jest niewielka. Nikt nie zaryzykuje znaczących zmian w api systemowym no chyba że z nową edycją systemu :)

Nic takiego nie ma miejsca.

Tutaj są moje przypuszczenia, całkiem możliwe że błędne

Gdzie i dlaczego? Na konsoli wszelkie wywołania są kosztowne, bo CLR nie jest zintegrowany w żaden sposób z systemem. Ale na PC zasadniczo nie ma żadnych poważnych powodów, które sprawiałyby, że XNA jest o niebo wolniejsze od gołego DX. Jasne, traci się wiele możliwości mikrooptymalizacji, ale w zamian dostaje się wygodne API z niezłym content pipelinem.

XNA to nie tylko operacje na GPU. Cała reszta a szczególnie operacje matematyczne nie są optymalne. Generalnie jeżeli XNA miałoby być nie tylko do casuali to musiałoby przejść metamorfozę. Ale po co robić taką metamorfozę w starym XNA jak można za jednym zamachem upiec kilka pieczeni? Nowe api w przeciwieństwie do XNA nie miałoby łatki "casual" i mogłoby stać się tym czym nie stało się XNA. XNA jest tym czym jest, czyli dobrą platformą do casual games. DX jest natomiast za bardzo niskopoziomowe.

Ja widzę.
1. Sterowniki WDDM są silnie związane z modelem programowania pod DX, a zmuszanie IHV do pisania nowych sterów nie przejdzie.
2. Wynajdowanie koła od nowa kiedy ma się miliony klientów jest biznesowym samobójstwem.
3. Zespół DX nie jest duzy, zespół XNA jest miniaturowy, a zasoby potrzebne na wynalezienie koła na nowo są ogromne.

Pisałem o wysokopoziomowym api graficznym (z content pipeline, biblioteką matematyczną z prawdziwego zdarzenia, kreatorem shaderów i ich debuggerem dla każdego pisela, toolsami - czy wam to czegoś nie przypomina ? :-)) Api które zapełni lukę po XNA.

Offline ConayR

  • Użytkownik

# Luty 05, 2012, 23:19:33
To pytanie do Microsoft. XNA nie będzie wspierane w Metro to słowa ludzi z tej firmy i ja im wierzę :)
Używałeś w ogóle Win8? Wszystkie aplikacje, bez względu na to jak wyglądają, widoczne są na kaflowym ekranie. Te w C, te korzystające z kafli, te napisane w XNA, te w pythonie. Wszystkie można przypinać i odpinać dowolnie. Co to w ogóle Twoim zdaniem znaczy, że "XNA nie będzie wspierane w Metro"? Bo jeśli "aplikacje z Metro UI nie są pisane w XNA", to brawo, odkryłeś Amerykę: aplikacje pisane przy uzyciu API QWE nie są aplikacjami pisanymi przy użyciu API UIO. Brawo.

Cytuj
Staje się api systemowym, jednym z wielu.
Nic, absolutnie nic się nie zmienia, jeśli chodzi o DX. To API tak samo zintegrowane z systemem (czyli luźno), jak to, które było w Viście czy Win7. Nic się nie zmieniło, więc albo zawsze było API systemowym, albo wciąż nie jest. Nic, powtarzam, nic się nie zmieniło.

Cytuj
Tutaj potwierdzasz co napisałem wcześniej DX ląduje jako api systemowe, dojrzałe którego potrzeba aktualizacji jest niewielka. Nikt nie zaryzykuje znaczących zmian w api systemowym no chyba że z nową edycją systemu :)
Nie, wykazuję jedynie Twoją kompletną ignorancję w tej materii. Było sobie takie SDK od Microsoftu o nazwie VSS SDK. Któregoś dnia stwierdzono że harmonogram wydań VSS SDK współgra z harmonogramem wydań Windows SDK i wciągnięto nasze SDK do Platform SDK. Nic, absolutnie nic się nie zmieniło w procesie tworzenia VSS API, jedynie deweloperzy aplikacji bazujących na VSS nie musieli pobierać i instalować dodatkowej paczki. API VSS, tak samo jak API DirectX, rozwijane było zgodnie z tym samym harmonogramem, jaki rządził wydaniami Windowsa. Ktoś się podrapał po głowie i stwierdził, że dwa odrębne procesy weryfikowania dwóch SDK i dwa osobne .msi do utrzymania są bez sensu. Więc oba SDK połączono, bo miało to sens logistyczny. Identycznie jest z DX SDK. Nie ma to absolutnie żadnego wpływu na status danego API, jedynie na cykl wydawania narzędzi na tym API bazujących. Tłumaczę Ci, jak wyglądał ten proces od środka, doceń to i przestań pisać farmazony o czymś, o czym nie masz pojęcia, bo w tym nie uczestniczyłeś.

Cytuj
XNA to nie tylko operacje na GPU. Cała reszta a szczególnie operacje matematyczne nie są optymalne.
Proszę ładnie o jakiś powtarzalny test, albo o zaprzestanie pisania takich farmazonów. Jedyna rzecz, której XNA przy operacjach arytmetycznych nie wykorzystuje na 360 to wektoryzacja z wykorzystaniem VMX128, ale tutaj spadku wydajności nie sprawdzisz, bo nie masz devkitu. Poza tym wiara w to, że napisze się lepiej zoptymalizowany kod w stodole, niż dostarczony jest z jakimś całkiem nieźle mającym się SDK jest przejawem sporego ego.

Cytuj
Generalnie jeżeli XNA miałoby być nie tylko do casuali to musiałoby przejść metamorfozę.
Tak? Jaką? Jakieś fakty, przykłady, sugestie, a nie puste słowa. Ja też mogę sobie napisać co mi ślina na język przyniesie, ale trochę szkoda mi czasu na pchanie własnych opinii jako faktów. Jasne, XNA nie jest doskonałe. Jasne, .NET generuje pewien narzut (sporo się np. cierpi na braku dyrektywy inline), ale pisanie o poważnych problemach z wydajnością jest zwyczajnie wyssane z palca. Sporo "twitchowych" gier powstało na XNA (Dishwasher, Schizoid, Bastion) i nie cierpią na problemy z wydajnością. I mówimy tutaj o lekko upośledzonym na 360 frameworku.

Cytuj
Ale po co robić taką metamorfozę w starym XNA jak można za jednym zamachem upiec kilka pieczeni?
Może np. dlatego, że XNA już raz przeszło poważną metamorfozę wprowadzając feature levels na kształt DX11. Ale żeby o tym wiedzieć trzeba, no właśnie, coś na dany temat wiedzieć.

Cytuj
Nowe api w przeciwieństwie do XNA nie miałoby łatki "casual" i mogłoby stać się tym czym nie stało się XNA.
Jakiś przykład tego, co jest w XNA casual? Tylko jeden, nie wymagam niczego więcej.

Cytuj
XNA jest tym czym jest, czyli dobrą platformą do casual games. DX jest natomiast za bardzo niskopoziomowe.
Nie, bardzo niskopoziomowe jest libGCM.

Cytuj
Pisałem o wysokopoziomowym api graficznym (z content pipeline, biblioteką matematyczną z prawdziwego zdarzenia, kreatorem shaderów i ich debuggerem dla każdego pisela, toolsami - czy wam to czegoś nie przypomina ? :-)) Api które zapełni lukę po XNA.
To pisałeś o silniku a nie o API.
« Ostatnia zmiana: Luty 05, 2012, 23:22:57 wysłana przez ConayR »

Offline głos

  • Użytkownik

# Luty 06, 2012, 02:38:29
Używałeś w ogóle Win8? Wszystkie aplikacje, bez względu na to jak wyglądają, widoczne są na kaflowym ekranie. Te w C, te korzystające z kafli, te napisane w XNA, te w pythonie. Wszystkie można przypinać i odpinać dowolnie. Co to w ogóle Twoim zdaniem znaczy, że "XNA nie będzie wspierane w Metro"? Bo jeśli "aplikacje z Metro UI nie są pisane w XNA", to brawo, odkryłeś Amerykę: aplikacje pisane przy uzyciu API QWE nie są aplikacjami pisanymi przy użyciu API UIO. Brawo.

Używam Developer Preview. To że aplikację można podpiąć do kafla nie spowoduje że z aplikacji desktopowej stanie się ona aplikacją Metro i  nie, nie odkryłem Ameryki tylko zacytowałem słowa pracowników firmy Microsoft.

Nic, absolutnie nic się nie zmienia, jeśli chodzi o DX. To API tak samo zintegrowane z systemem (czyli luźno), jak to, które było w Viście czy Win7. Nic się nie zmieniło, więc albo zawsze było API systemowym, albo wciąż nie jest. Nic, powtarzam, nic się nie zmieniło.

DX nie będzie luźno zintegrowane z systemem tylko staje się jego bazą. Odsyłam do prezentacji firmy Microsoft gdzie wskazują że Metro UI używa DirectX 11

Nie, wykazuję jedynie Twoją kompletną ignorancję w tej materii. Było sobie takie SDK od Microsoftu o nazwie VSS SDK. Któregoś dnia stwierdzono że harmonogram wydań VSS SDK współgra z harmonogramem wydań Windows SDK i wciągnięto nasze SDK do Platform SDK. Nic, absolutnie nic się nie zmieniło w procesie tworzenia VSS API, jedynie deweloperzy aplikacji bazujących na VSS nie musieli pobierać i instalować dodatkowej paczki. API VSS, tak samo jak API DirectX, rozwijane było zgodnie z tym samym harmonogramem, jaki rządził wydaniami Windowsa. Ktoś się podrapał po głowie i stwierdził, że dwa odrębne procesy weryfikowania dwóch SDK i dwa osobne .msi do utrzymania są bez sensu. Więc oba SDK połączono, bo miało to sens logistyczny. Identycznie jest z DX SDK. Nie ma to absolutnie żadnego wpływu na status danego API, jedynie na cykl wydawania narzędzi na tym API bazujących. Tłumaczę Ci, jak wyglądał ten proces od środka, doceń to i przestań pisać farmazony o czymś, o czym nie masz pojęcia, bo w tym nie uczestniczyłeś.

Całkowita prawda, nie uczestniczyłem, ale jak czytam że cały nowy interfejs systemu zaczyna bazować na bibliotece którą przesuwa się do api systemowego to nabieram wątpliwości o których napisałem wcześniej. Być może niesłuszne i przedwcześnie, tak jak napisałem to tylko wróżenie z fusów.

Proszę ładnie o jakiś powtarzalny test, albo o zaprzestanie pisania takich farmazonów. Jedyna rzecz, której XNA przy operacjach arytmetycznych nie wykorzystuje na 360 to wektoryzacja z wykorzystaniem VMX128, ale tutaj spadku wydajności nie sprawdzisz, bo nie masz devkitu. Poza tym wiara w to, że napisze się lepiej zoptymalizowany kod w stodole, niż dostarczony jest z jakimś całkiem nieźle mającym się SDK jest przejawem sporego ego.

Chyba brak gier AAA w XNA jest najlepszym przykładem? Sugestie są na forach poświęconych XNA. Odnośnie Xbox 360 - ta jedyna rzecz powoduje ok dziesięciokrotny spadek wydajności w stosunku do PC. Pisząc o wydajniejszej (zoptymalizowanej) bibliotece matematycznej miałem na myśli twórców XNA.

Tak? Jaką? Jakieś fakty, przykłady, sugestie, a nie puste słowa. Ja też mogę sobie napisać co mi ślina na język przyniesie, ale trochę szkoda mi czasu na pchanie własnych opinii jako faktów. Jasne, XNA nie jest doskonałe. Jasne, .NET generuje pewien narzut (sporo się np. cierpi na braku dyrektywy inline), ale pisanie o poważnych problemach z wydajnością jest zwyczajnie wyssane z palca. Sporo "twitchowych" gier powstało na XNA (Dishwasher, Schizoid, Bastion) i nie cierpią na problemy z wydajnością. I mówimy tutaj o lekko upośledzonym na 360 frameworku.

Nigdzie nie pisałem o poważnych problemach z wydajnością. Wprost przeciwnie pisałem, że wydajność jest przyzwoita i że nie jest maksymalna, co jest prawdą.

Może np. dlatego, że XNA już raz przeszło poważną metamorfozę wprowadzając feature levels na kształt DX11. Ale żeby o tym wiedzieć trzeba, no właśnie, coś na dany temat wiedzieć.

Oczywiście XNA przeszło już, że tak powiem pierwszą fazę przygotowania do DX 11 stąd mogłoby stanowić bazę dla tego mojego wydumanego nowego api.

Jakiś przykład tego, co jest w XNA casual? Tylko jeden, nie wymagam niczego więcej.

Proponuję przekonać developerów, bo to oni tak mówią. Nazwa XNA nie jest w tym pomocna, zbyt wielu programistów pamięta XNA z wersji wcześniejszych gdzie jego ograniczenia ich zniechęciły.

Nie, bardzo niskopoziomowe jest libGCM.

napisałem "za bardzo", czyli brakuje mu wielu funkcjonalności które posiada XNA

To pisałeś o silniku a nie o API.

Raczej o framework-u :) takim nowym XNA

Offline ConayR

  • Użytkownik

# Luty 06, 2012, 12:59:50
Używam Developer Preview. To że aplikację można podpiąć do kafla nie spowoduje że z aplikacji desktopowej stanie się ona aplikacją Metro i  nie, nie odkryłem Ameryki tylko zacytowałem słowa pracowników firmy Microsoft.
To może cytuj w jakimś zgodnym kontekście? Napisałeś "w świecie Windows 8 i interfejsu metro, XNA nie będzie wspierane" co jest nieprawdą. W świecie Win8 XNA jest wspierane. Nadal nie zdefiniowałeś co to jest świat interfejsu metro (choć prosiłem), ale jeśli chodziło Ci o to, że Metro to nie XNA (i vice versa) to ponownie winszuje przenikliwości i zdolności obracania rzeczy oczywistych w tytuły rodem z Faktu. :]

Cytuj
DX nie będzie luźno zintegrowane z systemem tylko staje się jego bazą. Odsyłam do prezentacji firmy Microsoft gdzie wskazują że Metro UI używa DirectX 11
Co to dowodzi? Program powitalny w XP był napisany we Flashu. Czy to znaczy, że Flash stał się API systemowym? Nawet jeśli założymy, że DX staje się API systemowym, bo komponent systemowy na DX bazuje (wciąż nie zdefiniowałes co to znaczy być API systemowym, a powtarzasz to jak zdarta płyta), to wciąż nie jest prawdą stwierdzenie, że w Win8 DX staje się API systemowym, bo i Glass i Aero bazowały na DX. Więc albo stał się dawno, albo wciąż nie jest. Powtarzam: status DX się nie zmienił. Można się jedynie spierać jaki ten status jest od dawna. Pisanie o jakiejkolwiek zmianie jednakże jest bzdurą.

Cytuj
Całkowita prawda, nie uczestniczyłem, ale jak czytam że cały nowy interfejs systemu zaczyna bazować na bibliotece którą przesuwa się do api systemowego
Zdefiniuj wreszcie co to znaczy. Zresztą: komponenty Microsoftu muszą się wpasowywać w wielopoziomowy model modułów (te z Windowsa i ten spoza), a layering się nie zmienił, DX jest tam, gdzie był. Więc albo już był API systemowym, albo wciąż nie jest API systemowym. W każdym jednak razie wraz z Win8 nie stał się API systemowym.

Już nawet zignoruję to, że pierwotnie uzasadniałeś zmianę przeniesieniem narzędzi do Platform SDK, a teraz nagle twierdzisz, że bazowanie jednego komponentu na drugim definiuje, czy coś jest API systemowym, czy nie. Czuję się jakbym grał w grę, w której cel zmienia się z każdym moim ruchem. Fajna to gra, póki się człowiek nie zmęczy i nie zniechęci.

Cytuj
Chyba brak gier AAA w XNA jest najlepszym przykładem?
Strasznie naiwnym przykładem. Mówimy o wydajności, przypomnę, żebyś znowu nie zdryfował. Skoro większość deweloperów od lat rozwija technologię w C/C++, a XNA nie poprawia wydajności aplikacji, dlaczego mieliby wyrzucać cały istniejący kod do kosza i przesiadać się na XNA? Może deweloperka byłaby bardziej "rapid", ale kod nie byłby bardziej wydajny (bo, z czym się zgadzamy, XNA bardziej wydajne nie jest; jest tak samo, trochę mnie, lub sporo mniej wydajne - bez znaczenia dla tego argumentu jakie). I do tego wszystko należałoby napisać od zera. No i pozostaje kwestia PS3 (i Wii U). Zysk z przejścia żaden, a argument tak samo błędny jak "gdyby OpenGL nie było lepsze od DX, to Carmack dawno by się przesiadł!", podczas gdy różnice są w rzeczywistości nieznaczne i przesiadka między technologiami najczęściej nie ma uzasadnienia biznesowego. A że nikt jeszcze nie dogonił UE z technologią na XNA? A kto dogonił Epic w ogóle? Crytek, który też ma gigantyczną bazę kodu w C++?

Cytuj
Sugestie są na forach poświęconych XNA.
To przytocz jedną. Odwołania do autorytetów, nieistniejących źródeł i dowody przez zamazanie są rozczulające. Przykład, choć jeden. Porównanie wydajności, choć jedno. O, na przykład na to:

Cytuj
Odnośnie Xbox 360 - ta jedyna rzecz powoduje ok dziesięciokrotny spadek wydajności w stosunku do PC.
Jakieś źródło? Wyniki? Nie doczekałem się do tej pory i już nie doczekam się pewnie. :)

Cytuj
Pisząc o wydajniejszej (zoptymalizowanej) bibliotece matematycznej miałem na myśli twórców XNA.
To znaczy co miałeś na myśli?

Cytuj
Nigdzie nie pisałem o poważnych problemach z wydajnością. Wprost przeciwnie pisałem, że wydajność jest przyzwoita i że nie jest maksymalna, co jest prawdą.
Pisałeś też "XNA mogłoby być jeszcze szybsze i to znacząco szybsze" oraz o dziesięciokrotnym spadku wydajności powyżej. Jak znacząco? Pięć razy? Dwa razy? 20%? 5%? To, że nie jest "maksymalna" (cokolwiek to znaczy, mówienie o wydajności maksymalnej bez konkretnego, wąskiego kontekstu nie ma sensu - raz coś jest maksymalnie wydajne, innym razem nie, w końcu programowanie to sztuka balansowania) to kolejny truizm, jak to, że dwa różne API nie są tym samym API.

Cytuj
Proponuję przekonać developerów, bo to oni tak mówią.
Nie, nie wykręcisz się tak. To Ty tutaj twierdzisz, że tak jest i to Ciebie pytam o konkretny przykład. Przestań odsyłać do jakichś wydumanych źródeł. Albo jesteś w stanie przedstawić jakieś konkrety, albo wszystko, co piszesz, to forma, bez treści.

Sypiesz na lewo i prawo określeniami takimi jak "staje się API systemowym", "może być znacząco szybsze", "dziesięciokrotny spadek wydajności", "casual", "nie są optymalne", ale nie definiujesz żadnego podłoża dla tych opinii. Fajnie, że dajesz sobie pole do interpretowania wcześniej napisanych niejasnych stwierdzeń. To całkiem niezła metoda na gadanie dla samego gadania. Ale tak nie da się dyskutować. Tak samo jak nie da się prowadzić dyskusji z kimś, kto spytany o cokolwiek każe spytać kogoś innego. Cierpliwie próbuję wyciągnąć z Ciebie jakąkolwiek rzeczową informację, ale najwyraźniej jest to skazane na niepowodzenie. Trudno, wystarczająco dużo czasu Tobie poświęciłem. :)

-*-*-

A co do oryginalnego pytania: twórcy Indie na Xbox Live przeważnie narzekają na kiepski dostęp do ich gier. Nie zostali obłaskawieni nawet reklamą różnych gier na głównej w dashu (poprzednim), promocjami i tego typu rzeczami. Wydaje się zadem, że podstawowym problemem jest promocja stworzonych tytułów. Ale w gruncie rzeczy jest to prawdą w przypadku każdej gry. ;) Piszący w XNA gry na XBLA (a nie XBLIG) póki co nie wyrażali niezadowolenia, więc ciężko tutaj wróżyć z fusów.

Pisanie w XNA wiąże się z pewnymi ograniczeniami, np. można zapomnieć o szybkim porcie między PC/360 a PS3 czy Wii/Wii U. Pozostają praktycznie trzy platformy: PC, 360 i Windows Phone. Ale i tu nie jest różowo, bo jedna gra w trzech formatach i przy różnorodnym sterowaniu to przeważnie (nie zawsze) mrzonka. Jeśli jednak chcesz szybko mieć "coś", no XNA nie jest takim złym rozwiązaniem. Czy przyszłościowym? Ciężko powiedzieć, sporo zależy od sukcesu lub porażki Windows Phone.

I taki drobiazg jeszcze: XNA to nazwa na grupę ludzi w MS. Framework nazywa się XNA Framework a narzędzia to XNA Game Studio. Ale to i tak nikogo, wiem. ;)
« Ostatnia zmiana: Luty 06, 2012, 13:06:04 wysłana przez ConayR »

Offline quaikohc

  • Użytkownik

# Luty 06, 2012, 13:19:23
To może cytuj w jakimś zgodnym kontekście? Napisałeś "w świecie Windows 8 i interfejsu metro, XNA nie będzie wspierane" co jest nieprawdą. W świecie Win8 XNA jest wspierane. Nadal nie zdefiniowałeś co to jest świat interfejsu metro (choć prosiłem), ale jeśli chodziło Ci o to, że Metro to nie XNA (i vice versa) to ponownie winszuje przenikliwości i zdolności obracania rzeczy oczywistych w tytuły rodem z Faktu. :]

omg, nie wiem przy czym sie tu upierasz tak zawziecie:
http://elybob.wordpress.com/2012/01/16/xna-in-windows-8/
http://www.mobiletechworld.com/2011/09/19/no-xna-support-for-metro-applications-in-windows-8/

Shawn Hargreaves
"It is correct that XNA is not supported for developing the new style Metro applications in Windows 8."

mozna te aplikacje pisac w directxie, ale nie w xna i nie ma takich planow, i o to dokladnie  chodzilo  'glosowi' - nie ma tu o czym dyskutowac co usilnie probujesz robic, jeszcze dokladniej:

"WinRT is the name for the APIs and runtime. “Metro style applications” refers to the larger environment and application model around WinRT (including, but not limited to, the “Metro” UI style). As such if you write an app using WinRT you are writing a Metro style application. To be as clear as I can be, XNA Game Studio will not support WinRT or Metro style applications in Windows 8."


a co do directxa to tez gadasz glupoty:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85%29.aspx

"Because the Windows SDK is the primary developer SDK for Windows, we now ship DirectX as part of the Windows SDK. You can now use the Windows SDK to build great games for Windows."

"Starting with Windows Developer Preview, the DirectX SDK is included as part of the Windows SDK."
"The following former DirectX SDK technologies and tools are now part of the Windows SDK:"

nie no, nic zupelnie sie nie zmienilo
« Ostatnia zmiana: Luty 06, 2012, 13:24:00 wysłana przez quaikohc »

Offline fn2000

  • Użytkownik

# Luty 06, 2012, 20:29:24
(...)
mozna te aplikacje pisac w directxie, ale nie w xna i nie ma takich planow, i o to dokladnie  chodzilo  'glosowi'

To zostało wyjaśnione już wcześniej - "glos" natomiast brnie w filozoficzne wywody o słabej wydajności XNA bez podawania żadnych konkretnych przykładów, testów.

Offline głos

  • Użytkownik

# Luty 06, 2012, 21:21:29
Wracjąc do tematu wątku:

jeszcze raz napiszę: Tak, warto pisać gry w XNA

Podsumowując moje wypowiedzi:

Czy przyszłość XNA jest jasno określona? Według mnie i tak i nie. Tak, ponieważ wiadomo że XNA będzie w desktopie Win8 i nie, ponieważ nie jest znana długofalowa strategia Microsoft w odniesieniu do desktopu oraz kolejnych generacji konsol i urządzeń mobilnych MS.

Zaznaczam że poprzednie moje wypowiedzi zawierają prywatne opinie, iż być może XNA zostanie zastąpione nowym api/frameworkiem które(ry) być może jest przygotowywane(ny). Napisałem również, że zamiennikiem
XNA (ciągle w mojej opinii, nie wykluczam że błędnej) nie może to być DirectX z podanych wcześniej przyczyn. Napisałem także parę własnych przemysleń jak takie wydumane nowe api mogłoby wyglądać (połączenie cech XNA i DirectX,
ze wskazaniem na XNA jako bliższe takiemu api/frameworku).

Poruszyłem także temat zmiany statusu DirectX i jego roli w Win8, za mało być może podkreślając, że są to moje wnioski z publikowanych oficjalnie informacji. To czynię teraz :) tak to są moje wnioski (być może również błędne).
Clue akurat tych wypowiedzi był wniosek, może błędny, o spowolnieniu rozwoju DirectX.

Napisałem również, że wydajność XNA jest przyzwoita i nie jest maksymalna, sugerując że XNA może być szybsze i to znacząco szybsze. W tym przypadku, precyzując, opierałem się na moich własnych pomiarach wydajności, przede wszystkim bibliotek matematycznych, skoków do podprogramów, działań na zmiennych lokalnych, rozwijanych pętli/fragmentów kodu.
Napisałem również o wykorzystaniu SIMD i operacjach wektorowych w bibliotece matematycznej ale bynajmniej,
 nie sugerowałem, że ja taką bibliotekę napisałbym lepiej :) co to, to nie.
Zresztą problem optymalizacji pod SIMD i wektory nie jest prosty i w zasadzie chyba bardziej zahacza o .NET-a.
Zadanie wyciśnięcia maksymalnej wydajności spoczywa na autorach kodu, czyli twórcach XNA (i właśnie to miałem na myśli pisząc o twórcach XNA). Napisałem "znacząco" ponieważ nie znam granicznej wartości przyrostu wydajności na PC po wprowadzeniu optymalizacji na SIMD i wprowadzeniu ogólnej optymalizacji czasowo-krytycznych sekcji w XNA Framework. Stąd nie podaję wyssanych z palca liczb. Można polemizować czy warto wprowadzać taką optymalizację czy też nie. Ja uważam że warto, a przynajmniej warto zbadać jej wpływ.

Poruszyłem też temat "casual" w związku z XNA. Prosiłbym o zwrócenie uwagi że termin "casual" wspomniałem w dwóch kontekstach. Pierwszym metamorfozy api, a drugi obiegowej opinii (w kwestii opinii chyba napisałem jasno o co mi chodzi).
Wracam więc do metamorfozy api. XNA bazuje na DirectX 9 nawet z już wprowadzonymi zmianami pod przyszłe wsparcie dla DirectX 10/11. Zmiana tej bazy na DirectX 11 to jeden z elemetów metamorfozy api sugerowany właśnie na forach XNA.
Następna sprawa, to wsparcie dla SIMD,jednostek wektorowych i inlinowania, api dla AAA musi być maksymalnie wydajne, jak również wydajny powinien być kod gry AAA (postulaty od zawsze zgłszane na forach XNA)
Kolejna sprawa to zmiany w samym api, są zbyt częste i znaczące aby ktokolwiek zaryzykował AAA tytuł którego czas produkcji jest relatywnie długi.
Wykrystalizowana wizja api to właśnie jego metamorfoza w stabilny framework, itd.
Stąd też min. wysnułem wniosek, być może również błędny, że zamiast wprowadzać to wszystko w XNA można od razu zaprezentować nowe dojrzałe api wykorzystując doświadczenia zebrane podczas pracy nad XNA.

Wskazałem na brak AAA tytułów na XNA, myślę że tego argumentu nie można obalić tylko jednym stwierdzeniem o bazie kodów w C++ i latami rozwijanych technologiach.

Ale rzeczywiście, chyba za bardzo rozpędziłem się w przewidywaniach :-)

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Luty 06, 2012, 21:31:31
Czy przyszłość XNA jest jasno określona? Według mnie i tak i nie. Tak, ponieważ wiadomo że XNA będzie w desktopie Win8 i nie, ponieważ nie jest znana długofalowa strategia Microsoft w odniesieniu do desktopu oraz kolejnych generacji konsol i urządzeń mobilnych MS.
Skoro "i tak i nie", to znaczy, że nie. Są wątpliwości więc nie jest jasno określona, tylko, że zwolennik boi się konkretnie przyznać :P Nawet według rachunku logicznego: 1 i 0 = 0.

Offline głos

  • Użytkownik

# Luty 06, 2012, 21:41:09
Skoro "i tak i nie", to znaczy, że nie. Są wątpliwości więc nie jest jasno określona, tylko, że zwolennik boi się konkretnie przyznać :P Nawet według rachunku logicznego: 1 i 0 = 0.

Wszystko zależy co zaproponuje Microsoft. Z tego co pamiętam po porzuceniu Manage DX też był okres ok 6 miechów niepewności, aż do ogłoszenia XNA.