Artykuł: Co z tą branżą? - Windows 8 zjednoczy Xboxa z PC

[DaeL 0]

Carmack na QuakeConie powiedział, że high-endowe pecety już w tej chwili są dziesięć razy "mocniejsze" od konsol i że konsole powinny to nadrobić, bo developerzy muszą się ograniczać (świetnie zresztą tłumaczył jakie triki wykorzystywali na ps3, żeby tekstur zbuforować przy małej ilości RAM-u). Ale o tym jaka będzie specyfikacja xbox 720 nic nie wspominał, bo i skąd by miał to wiedzieć...
Nb. ja sądzę, że nowa generacja pojawi się jednak w 2013 (ew. na początku 2014). Nowe Wii wymusi ruch ze strony Sony i Microsoftu. Kinect i Move to za mało, by przedłużyć życie konsol do 2015.

[Vojtas 0]

Dnia 10.08.2011 o 00:41, DaeL napisał:

Nb. ja sądzę, że nowa generacja pojawi się jednak w 2013 (ew. na początku 2014). Nowe
Wii wymusi ruch ze strony Sony i Microsoftu.

Też tak myślę. Obstawiam, że w na E3 2012 MS zapowie XB 720.

[Olamagato 3]

Nie wiem czemu wszyscy się tak przejmują wydajnością emulacji xklocka na pececie. Obecnie emulacja taka może byc niemal tak wydajna jak na oryginalnej maszynie. Po prostu dotychczas istniejące emulatory zawsze interpretowały rozkazy emulowanego procesora i instrukcja po instrukcji przekładały to na instrukcje bieżącego procesora. Jednak gdy rozkazy emulowanego procesora przekonwertować na natywny kod bieżącego procesora w procesie podobnym do kompilacji w locie (jak np. hotspot w Java Virtual Machine), to kod po konwersji jest praktycznie tak samo szybki w wykonaniu jak kod wyprodukowany na ten procesor. Ceną takiego rozwiązania byłoby nieco dłuższe ładowanie gry, ale zaleta możliwość składowania kodu na twardym dysku do wielokrotnego uruchomienia bez żadnego narzutu czasowego.
Dlatego nie ma podstaw do powątpiewania w uruchamianie gier z klocka na pececie pod nową Windą.

[Miszkaa 0]

Dnia 08.08.2011 o 21:44, Mejste napisał:

> Windows Phone 7 Porażka?! Ja bym jeszcze nie przesądzał póki nie ma mango...

Ja mówię o dniu dzisiejszym, a dziś jest słabo. Zerknij choćby tutaj http://bit.ly/paazWh
albo tutaj http://bit.ly/obyDHp

Tak jak dowiadywałem się w stanach po prostu jest straszny problem z promocją WP7. Ludzie którzy starali się nawet sprawdzić urządzenia u operatorów często spotykali się odrazu "ale to jest kiepski telefon i system", "ale my odradzamy, lepiej nie brać", "że nie ma aplikacji" (kłamstwo), dopiero po stanowczym poproszeniu podłączali te rozładowane telefony (sic!) i niechętnie pokazywali.

W tej chwili jest zbyt duży lobbing androida i iphona, M$ musi się wkupić w łaski operatorów w stanach. Jak tam się zacznie boom to i na świecie będzie. A multi-miliardowa kampania reklamowa szykowana jest dopiero na październik jak będzie wybór telefonów z preinstalowanym mango wraz z nokią do której mam teraz mieszane uczucia...

Korzystam w tej chwili z bety mango na wp7 (HTC Troophy), i to najlepszy telefon (system) jaki kiedykolwiek używałem, choć androida nie miałem w łapie, a iphonem się tylko bawiłem więc trudno mi nawet porówanać

[Henrar 2]

Zapominasz o licencjach.

[Olamagato 3]

Dnia 11.08.2011 o 14:19, Henrar napisał:

Zapominasz o licencjach.

Licencje są inną sprawą. Chodzi o to, że sprawne emulowanie kodu innych procesorów nie jest dzisiaj problemem technicznym. A w każdym razie nie jest to problemem blokującym emulację.

[rtyrtyrty 0]

Fajnie by było potem zagrać w Forze 4 na PC z Windowsem 8, ale coś to zbyt piękne się wydaje.

Ale to tylko plotki więc niewiadomo..

[lookastdu 0]

> Windows 8 zapowiadany jest zatem jako rewolucja o skali porównywalnej do premiery Windowsa 95

Odkąd mam net, pamiętam, że ten text powtarzają z każdą premierą kolejnego Windowsa... Vista, 7, teraz 8, a text nadal w modzie MSu.

Niestety, obawiam się, że nie zdołają się nawet zbliżyć do mistrza Win 95. Tak. Ten system był epicki. Żaden późniejszy system od Microsoftu nie był tak epicki, i tak rewolucyjny jak Windows 95. Sam na własnej skórze przetestowałem ten rewolucyjny, niepowtarzalny, epicki, nieskazitelny system Microsoftu Windows 95. Włożyłem płytę do starego PCta, wybrałem instaluj, aż tu w pewnym momencie podczas kopiowania plików na świeżo sformatowany HDD wybija PIĘKNY ERROR. To było epickie, a jednocześnie proces instalacji systemu po kilku próbach "Retry" oraz "Ignore" został zrewolucjonizowany przez JESZCZE PIĘKNIEJSZEGO BLUESCREENA.

Jak dotąd żaden z kolejnych systemów MS nie pobił tego dzieła 95. Żaden potem nie wykrzaczył się w środku instalacji systemu. Jestem szczerze zawiedziony, jak MS mógł tak zawieść, i to nie jeden raz, lecz wiele. :( Za każdym razem jest coraz gorzej, coraz mniej BSODów, o pięknych errorach podczas instalacji systemu już w ogóle nie wspominając... :(

Spoiler

Nie bierzcie mojego tekstu tak na serio... :P

[MKRaven 0]

No ale zachodzi pytanie: po co mi w takim razie konsola i PC jeśli są one po prostu różnymi terminalami dającymi dostęp do tego samego systemu?

[Arkhaor 1]

Pff...nigdy przenigdy, żaden system pecetowy MSu nie będzie wspierał grania w gry Xboxowe; to byłby dla nich strzał w stopę. Pomijając już fakt niemożności takiego wsparcia w postaci czysto sprzętowej. Także nie wiem o co halo z tym "Xboxem na PC", ale trudno mi uwierzyć że niektórzy ludzie takim pogłoskom zawierzyli.

Ale tak - wielce możliwe że zajdzie unifikacja (częściowa, oczywiście) wszystkich systemów Microsoftu. Artykuł tak trochę o niczym; takie domniemanie na podstawie skrawków informacji i plotek :S

[john_smith 0]

Dnia 10.08.2011 o 02:23, Olamagato napisał:

Nie wiem czemu wszyscy się tak przejmują wydajnością emulacji xklocka na pececie. Obecnie
emulacja taka może byc niemal tak wydajna jak na oryginalnej maszynie. Po prostu dotychczas
istniejące emulatory zawsze interpretowały rozkazy emulowanego procesora i instrukcja
po instrukcji przekładały to na instrukcje bieżącego procesora.

bo inaczej sie nie da

Dnia 10.08.2011 o 02:23, Olamagato napisał:

Jednak gdy rozkazy emulowanego
procesora przekonwertować na natywny kod bieżącego procesora w procesie podobnym do kompilacji
w locie (jak np. hotspot w Java Virtual Machine), to kod po konwersji jest praktycznie
tak samo szybki w wykonaniu jak kod wyprodukowany na ten procesor.

nie wiesz o czym piszesz, na plycie z gra na xboxa masz kod maszynowy dla hardware specyficznego dla xboxa, nikt ci nie napisze konwersji gry z plyty xboxa do postaci jaka strawi pcet, jedynie jakby to moglo zadzialac to najpierw inzynieria wsteczna zeby dostac np kod c++ w ktorym gre napisano, pozniej dopiero kompilacja na pcta, ale pierwszy krok jest awykonalny, pozostaje emulacja hardware xboxa

Dnia 10.08.2011 o 02:23, Olamagato napisał:

Ceną takiego rozwiązania
byłoby nieco dłuższe ładowanie gry, ale zaleta możliwość składowania kodu na twardym
dysku do wielokrotnego uruchomienia bez żadnego narzutu czasowego.

lol, ty naprawde myslisz, ze (nawet jakby to bylo mozliwe) kompilowanie programu skladajacego sie z wielu milionow linii kodu trwa minute, dwie lub trzy? to trwa znacznie dluzej

Dnia 10.08.2011 o 02:23, Olamagato napisał:

Dlatego nie ma podstaw do powątpiewania w uruchamianie gier z klocka na pececie pod nową
Windą.

sa podstawy zeby powatpiewac w twoja wiedze na temat programowania

[Olamagato 3]

Dnia 13.08.2011 o 02:22, john_smith napisał:

bo inaczej sie nie da

Bzdura. Nie masz pojęcia o działaniu komputerów.

Dnia 13.08.2011 o 02:22, john_smith napisał:

nie wiesz o czym piszesz, na plycie z gra na xboxa masz kod maszynowy dla hardware specyficznego dla xboxa

Gdybyś zapomniał (a pewnie nie wiesz), to żadnego softu od czasów antycznych nie pisze się bezpośrednio na hardware (ostatnie takie gry były chyba w 1985 r.). Dzięki temu możliwe są porty na różne konsole, peceta itd. Z tego też powodu potrzebny jest system operacyjny. Soft pisany bezpośrednio na sprzęt nie potrzebuje żadnego systemu.

Dnia 13.08.2011 o 02:22, john_smith napisał:

nikt ci nie napisze konwersji gry z plyty xboxa do postaci jaka strawi pcet

Nikt mi nie napisze - bo mu nie zapłacę. :).
Ale jakbyś nie wiedział to gry na xboxa oparte są o DirectX, który jakimś cudem znajduje się zarówno w klocku jak i pececie. Tak więc gra na obie maszyny używa tego samego API jeżeli chodzi o grafikę. Nie trzeba konwertować dosłownie nic. Jedyne czym się różnią obie maszyny to fakt iż klocek jest zamknięty sprzętowo i używa innego procesora, więc kody instrukcji maszynowych są inne. I to jest jedyny problem techniczny do pokonania.

Dnia 13.08.2011 o 02:22, john_smith napisał:

jedynie jakby to moglo zadzialac to najpierw inzynieria wsteczna zeby dostac np kod c++
w ktorym gre napisano, pozniej dopiero kompilacja na pcta, ale pierwszy krok jest awykonalny,
pozostaje emulacja hardware xboxa

Po kolei. reverese engineering jest dla ludzi - żeby mogli zrozumieć co kod robi i jak. Maszynie nie jest to do niczego potrzebne podobnie jak deasemblacja, czy dekompilacja. Kod maszynowy dowolnego procesora składa się z prymitywnych niezwykle prostych instrukcji (mov, add, mul itp). Główne różnice jakie są miedzy różnymi procesorami polegają na innych kodach tych instrukcji, nieco innym ich zestawie, różnej liczbie rejestrów i ich długościach. I to są jedyne różnice jakie między nimi występują. Instrukcje jednego CPU da się całkowicie przełożyć na instrukcje innego CPU - czasem nieco mniej efektywnie bo jedną instrukcję trzeba zastąpić 1-3 innymi lub całą procedurą jeżeli nie ma prostego odpowiednika itd.

Dnia 13.08.2011 o 02:22, john_smith napisał:

lol, ty naprawde myslisz, ze (nawet jakby to bylo mozliwe) kompilowanie programu skladajacego
sie z wielu milionow linii kodu trwa minute, dwie lub trzy?

Dokładnie. Np. Asemblacja miliona wierszy kodu (1 instrukcja/wiersz) trwa ok. ćwierć sekundy na moim starym pececie Athlon XP 2500+ (z RAM do RAM). Musisz mieć naprawdę małe pojęcie o komputerach jeżeli jest to dla Ciebie czymś dziwnym.
Ale dzięki temu wiadomo, że miałeś do czynienia wyłącznie z C/C++, w którym kompilacja kodu źródłowego jest niezwykle powolna i zawiła (głównie z powodu redundantnego wczytywania całych stosów nagłówków).
Krótko mówiąc - wiadomo skąd się wzięła Twoja ignorancja.

Co do szybkości, to konwersja instrukcji z jednego 32-bitowego CPU na inny powinna trwać jeszcze szybciej ponieważ parsowanie kodu binarnego jest sporo szybsze od parsowania tekstu.

Dnia 13.08.2011 o 02:22, john_smith napisał:

sa podstawy zeby powatpiewac w twoja wiedze na temat programowania

Żałosne. :)

[john_smith 0]

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Bzdura. Nie masz pojęcia o działaniu komputerów.

w czym ty programowales? chyba tylko w javie bo piszesz totalne glupoty

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Gdybyś zapomniał (a pewnie nie wiesz), to żadnego softu od czasów antycznych nie pisze
się bezpośrednio na hardware (ostatnie takie gry były chyba w 1985 r.). Dzięki temu możliwe
są porty na różne konsole, peceta itd. Z tego też powodu potrzebny jest system operacyjny.
Soft pisany bezpośrednio na sprzęt nie potrzebuje żadnego systemu.

pomerdalo ci sie troche, wiec sproboje wyjasnic, tak, nikt nie pisze gry w assemblerze power pc na xboxa360 bo trwaloby to wieki, to jest oczywiste, gre pisze sie najczesciej w c++, ale ten kod musi zostac skompilowany, tzn przetlumaczony na kod maszynowy (assembler power pc), wiec na plytce z gra na xbox360 masz kod maszynowy, moze go odczytac tylko procesor power pc, wiele innych rzeczy zwiazanych z zarzadzaniem pamieca, gpu itd tez jest charakterystyczne dla xboxa i tylko na nim zadziala, ewentualnie na emulatorze hardware xboxa

mylisz to z rozwiazaniem jakie jest np przy javie, java nie kompiluje sie do kodu maszynowego tylko do kodu posredniego, zeby moc dzialac na wielu systemach bez potrzeby ponownej kompilacji calego projektu itd, nikt nie pisze gry na konsole w takich jezykach bo docelowa jest jedna platforma, jakby tak robili to plyte z gra na xboxa moglbys wlozyc do ps3/pc i gra by dzialala

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Nikt mi nie napisze - bo mu nie zapłacę. :).
Ale jakbyś nie wiedział to gry na xboxa oparte są o DirectX, który jakimś cudem znajduje
się zarówno w klocku jak i pececie. Tak więc gra na obie maszyny używa tego samego API
jeżeli chodzi o grafikę. Nie trzeba konwertować dosłownie nic. Jedyne czym się różnią
obie maszyny to fakt iż klocek jest zamknięty sprzętowo i używa innego procesora, więc
kody instrukcji maszynowych są inne. I to jest jedyny problem techniczny do pokonania.

o procku juz pisalem, wiec pomine to
gry pisane na xboxa360 jak i ps3 nie uzywaja tylko directx, wiele z nich uzywa bezposrednio hardware zeby bylo szybciej - innymi slowy pomijaja warstwe posrednia czyli samego directxa, nikt nie wymaga zeby gra na xboxie musiala uzywac directxa do grafiki, w tym wlasnie konsole maja przewage, ze mozna robic tego typu optymalizacje bo maja tylko jedna karte graficzna i cala reszte tez, na pc to odpada bo rozne gpu maja rozne standardy np dotyczace pamieci

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Instrukcje jednego CPU da się całkowicie
przełożyć na instrukcje innego CPU - czasem nieco mniej efektywnie bo jedną instrukcję
trzeba zastąpić 1-3 innymi lub całą procedurą jeżeli nie ma prostego odpowiednika itd.

bez komentarza, nie wiesz o czym piszesz

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Dokładnie. Np. Asemblacja miliona wierszy kodu (1 instrukcja/wiersz) trwa ok. ćwierć
sekundy na moim starym pececie Athlon XP 2500+ (z RAM do RAM).

tak juz to widze jak napisales kod skladajacy sie z miliona instrukcji assemblera
zreszta gry nie sa pisane w assemblerze

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Musisz mieć naprawdę małe
pojęcie o komputerach jeżeli jest to dla Ciebie czymś dziwnym.
Ale dzięki temu wiadomo, że miałeś do czynienia wyłącznie z C/C++, w którym kompilacja
kodu źródłowego jest niezwykle powolna i zawiła (głównie z powodu redundantnego wczytywania
całych stosów nagłówków).
Krótko mówiąc - wiadomo skąd się wzięła Twoja ignorancja.

lol, przeczytaj to co wczesniej napisalem, gry nie pisze sie w javie, po drugie nie pisze sie ich tez w assemblerze, nie kompilowales duzego i skomplikowanego projektu to sie nie odzywaj

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Co do szybkości, to konwersja instrukcji z jednego 32-bitowego CPU na inny powinna trwać
jeszcze szybciej ponieważ parsowanie kodu binarnego jest sporo szybsze od parsowania
tekstu.

jak porownujesz to do parsowania tekstu to widac na jakim poziomie jestes

Dnia 13.08.2011 o 06:21, Olamagato napisał:

Żałosne. :)

zalosny jest caly twoj post, jak liznales w gimnazjum troche javy to sie nie osmieszaj

[Olamagato 3]

Dnia 13.08.2011 o 11:20, john_smith napisał:

sproboje wyjasnic

"Nie ucz ojca dzieci robić". Pisałem w większej ilości języków niż potrafiłbyś wymienić ich nazwy z głowy. W tym asemblery na wszystkie Intele od 16-bitów w górę, i większość Motoroli.

Dnia 13.08.2011 o 11:20, john_smith napisał:

na plytce z gra na xbox360 masz kod maszynowy, moze go odczytac tylko procesor power pc

Co jest oczywiście totalną bzdurą. Każde dane można wczytać do pamięci. I dane te mogą zostać zintepretowane przez CPU jako kod, ale dla innego procesora są to bez żadnej obróbki zwykłe śmiecie.

Dnia 13.08.2011 o 11:20, john_smith napisał:

wiele innych rzeczy zwiazanych z zarzadzaniem pamieca, gpu itd tez
jest charakterystyczne dla xboxa i tylko na nim zadziala, ewentualnie na emulatorze hardware xboxa

Człowieku, xbox, to jest tylko wyspecjalizowany pecet z niewielkim własnym OSem i w pewnej części innym API. Jeżeli gra będzie mazała po portach sprzętowych karty graficznej, to masz rację, ale od dawna tak się nie pisze gier w tym celu wymyślono takie interfejsy jak DirectX, który na wszystkich produktach Microsoftu jest *jedynym słusznym*. Oczywiście inne konsole mają swoje SDK i swoje reguły kontaktowania się gier ze sprzętem.

Dnia 13.08.2011 o 11:20, john_smith napisał:

mylisz to z rozwiazaniem jakie jest np przy javie, java nie kompiluje sie do kodu maszynowego
tylko do kodu posredniego, zeby moc dzialac na wielu systemach bez potrzeby ponownej
kompilacji calego projektu itd

A nie wpadło Ci to do głowy, że jest to jedną z przyczyn łatwej przenośności? Za trudne?
Napisałem jedynie, że stosując podobną technikę wydajna symulacja xboxa na peceta jest możliwa. Szczególnie jeżeli wykonać mogą to ludzie, którzy oba produkty stworzyli.

Dnia 13.08.2011 o 11:20, john_smith napisał:

nikt nie pisze gry na konsole w takich jezykach bo docelowa jest jedna platforma

Zaktualizuj swoją wiedzę. Frameworki, silniki, różne API i warstwy oprogramowania są wymyślone właśnie po to aby nie było się zmuszonym do pisania softu na jeden jedyny sprzęt i jedną konfigurację. Dzisiaj pisząc grę, która ma iść od razu na kilka konsol robi się to właśnie tak aby w warstwie logicznej nie używać odwołań do żadnego sprzętu i żadnych specyficznych cech tego sprzętu. Dla kogoś, kto liznął chociaż trochę programowania jest to oczywiste.

Dnia 13.08.2011 o 11:20, john_smith napisał:

jakby tak robili to plyte z gra na xboxa moglbys wlozyc do ps3/pc i gra by dzialala

Nie ponieważ na PS3 jest procesor, którego programuje się zupełnie inaczej, zupełnie inny jest podsystem sprzętowy grafiki itd. Wtedy rzeczywiście niezbędna jest sprzętowa emulacja bo symulacja software''owa całej maszyny byłaby koszmarnie dużym i nieefektywnym przedsięwzięciem.

Dnia 13.08.2011 o 11:20, john_smith napisał:

gry pisane na xboxa360 jak i ps3 nie uzywaja tylko directx, wiele z nich uzywa bezposrednio
hardware zeby bylo szybciej - innymi slowy pomijaja warstwe posrednia czyli samego directxa

DX jest tak zbudowany, że nie daje niemal żadnego narzutu na wykonanie. Na najniższej warstwie precyzuje tylko co i gdzie się znajduje. Gry mażącej bezpośrednio po portach sprzętowych nie dałoby się łatwo przełożyć - to prawda. Ale po pierwsze - taki soft jest niezgodny z zasadami programowania Xboxa (zasady są wyraźnie opisane w SDK - radzę przeczytać), po drugie numery portów i cały interfejs sprzętowy jest doskonale znany ekipie, która go zaprojektowała, więc nawet instrukcje mov/in/out mażące po portach są możliwe do przełożenia na dowolną inną (nowszą) kartę ATI/AMD.
Co do Nvidii nie będę się wypowiadał bo nigdy nie grzebałem i nie porównywałem sterowania w układach graficznych obu firm (od tego są ludzie piszący sterowniki).

Dnia 13.08.2011 o 11:20, john_smith napisał:

nikt nie wymaga zeby gra na xboxie musiala uzywac directxa do grafiki, w tym wlasnie
konsole maja przewage, ze mozna robic tego typu optymalizacje bo maja tylko jedna karte
graficzna i cala reszte tez, na pc to odpada bo rozne gpu maja rozne standardy np dotyczace pamieci

Racja, ale tylko do pewnego stopnia. Gdyby było zawsze tak jak piszesz, to portowanie tych samych gier na różne konsole byłoby sennym koszmarem. Taki stan istniał właśnie za czasów dominacji PS2 gdzie praktycznie 100% gier to były exclusive''y. Portowanie gry z Gamecube''a na PS2 lub odwrotnie, to byłby totalny koszmar - praktycznie niemożliwe bez pisania gry od początku.
Ale od tego czasu minęła cała epoka i właściwie wszystko się zmieniło.

Dnia 13.08.2011 o 11:20, john_smith napisał:

bez komentarza, nie wiesz o czym piszesz

Niestety wydaje mi się, że ty nie bardzo wiesz o czym piszesz. Albo bardzo dawno nie jesteś już w temacie.

Dnia 13.08.2011 o 11:20, john_smith napisał:

tak juz to widze jak napisales kod skladajacy sie z miliona instrukcji assemblera
zreszta gry nie sa pisane w assemblerze

Nie są. Ale sterowniki często są. I tak na marginesie - mam do dyspozycji milion wierszy kodu w assemblerze I386 (gdybyś chciał, to nawet w sieci znajdziesz tyle, że milion spokojnie uzbierasz). Średnio przypada 10 bajtów na wiersz, cała wielkość to mniej niż 10 MB do przeparsowania i wygenerowania kodu. Dzisiaj jest to śmieszna ilość danych do prostej obróbki. I trwa ona ułamek sekundy. Asemblera wziąłem jako przykład bo jeden wiersz przekłada się na jedną instrukcję maszynową, więc asemblowanie takiego źródła jest podobnie wydajne jak kompilacja w locie.

Dnia 13.08.2011 o 11:20, john_smith napisał:

nie kompilowales duzego i skomplikowanego projektu to sie nie odzywaj

Kompilowałem m.in. cały soft dużego oraz małego dekodera n-ki i wiem co piszę.

Dnia 13.08.2011 o 11:20, john_smith napisał:

zalosny jest caly twoj post, jak liznales w gimnazjum troche javy to sie nie osmieszaj

Jeżeli ktoś płaci Ci za pisanie softu, to moim zdaniem ta firma właśnie upada, albo ma kłopoty finansowe. Zresztą przez takich aroganckich kolesi, dla których słowo "niemożliwe" jest codziennością, wiele firm ma kłopoty.

[john_smith 0]

Dnia 13.08.2011 o 16:35, Olamagato napisał:

"Nie ucz ojca dzieci robić". Pisałem w większej ilości języków niż potrafiłbyś wymienić
ich nazwy z głowy. W tym asemblery na wszystkie Intele od 16-bitów w górę, i większość
Motoroli.

napinaj sie dalej

Dnia 13.08.2011 o 16:35, Olamagato napisał:

> na plytce z gra na xbox360 masz kod maszynowy, moze go odczytac tylko procesor power
pc
Co jest oczywiście totalną bzdurą. Każde dane można wczytać do pamięci. I dane te mogą
zostać zintepretowane przez CPU jako kod, ale dla innego procesora są to bez żadnej obróbki
zwykłe śmiecie.

dokladnie to samo napisalem wiec gdzie tu widzisz bzdure

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Człowieku, xbox, to jest tylko wyspecjalizowany pecet z niewielkim własnym OSem i w pewnej
części innym API. Jeżeli gra będzie mazała po portach sprzętowych karty graficznej, to
masz rację, ale od dawna tak się nie pisze gier w tym celu wymyślono takie interfejsy
jak DirectX, który na wszystkich produktach Microsoftu jest *jedynym słusznym*. Oczywiście
inne konsole mają swoje SDK i swoje reguły kontaktowania się gier ze sprzętem.

nie wiesz o czym piszesz, gra moze 95% rzeczy robic przy uzyciu directxa, ale 5% bedzie bezposrednio uzywac sprzetu, zobacz sobie filmik z quakecon gdzie carmack o tym mowi, kilka miesiecy temu byl tez wywiad z gosciem z amd, ze na pc directx sprawia, ze gry nie dzialaja tak szybko jakby to wynikalo z postepu technologi bo spowalnia je directx, a na konsoli tego problemu nie masz, bo optymalizujesz nie uzywajac directx, piszesz ze od dawna tak sie gier nie pisze, a to kompletna bzdura, pierwsze gry na xboxa mogly w 100% jechac na directx ale z czasem zeby wiecej wyciagnac z tego samego sprzetu zaczeli go omijac

Dnia 13.08.2011 o 16:35, Olamagato napisał:

A nie wpadło Ci to do głowy, że jest to jedną z przyczyn łatwej przenośności? Za trudne?

to dla ciebie jest za trudne, to o czym piszesz nie ma nic z tym wspolnego, piszesz gre w jezyku np c++ i kompilujesz osobno na xboxa i osobno na xboxa, gdzie ty tu widzisz przenosnosc? jej tu nie ma, to polega na czyms zupelnie innym, doucz sie to pogadamy

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Napisałem jedynie, że stosując podobną technikę wydajna symulacja xboxa na peceta jest
możliwa. Szczególnie jeżeli wykonać mogą to ludzie, którzy oba produkty stworzyli.

jak wyzej

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Zaktualizuj swoją wiedzę. Frameworki, silniki, różne API i warstwy oprogramowania są
wymyślone właśnie po to aby nie było się zmuszonym do pisania softu na jeden jedyny sprzęt
i jedną konfigurację. Dzisiaj pisząc grę, która ma iść od razu na kilka konsol robi się
to właśnie tak aby w warstwie logicznej nie używać odwołań do żadnego sprzętu i żadnych
specyficznych cech tego sprzętu. Dla kogoś, kto liznął chociaż trochę programowania jest
to oczywiste.

ty piszesz o czyms zupelnie innym, ja to wiem, ze nie zaczynasz ponownie pisac ponownie gry na xboxa i pc od nowa, ale ty mylisz generowanie kodu posredniego jak w jawie z kompilacja docelowa na tylko jedno urzadzenie, jak juz wyzej ci pisalem tu nie ma zadnej przenosnosci i nie myl pojec

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Nie ponieważ na PS3 jest procesor, którego programuje się zupełnie inaczej, zupełnie
inny jest podsystem sprzętowy grafiki itd. Wtedy rzeczywiście niezbędna jest sprzętowa
emulacja bo symulacja software''owa całej maszyny byłaby koszmarnie dużym i nieefektywnym
przedsięwzięciem.

przeciez o tym samym ciagle pisze

Dnia 13.08.2011 o 16:35, Olamagato napisał:

DX jest tak zbudowany, że nie daje niemal żadnego narzutu na wykonanie. Na najniższej
warstwie precyzuje tylko co i gdzie się znajduje. Gry mażącej bezpośrednio po portach
sprzętowych nie dałoby się łatwo przełożyć - to prawda. Ale po pierwsze - taki soft
jest niezgodny z zasadami programowania Xboxa (zasady są wyraźnie opisane w SDK - radzę
przeczytać), po drugie numery portów i cały interfejs sprzętowy jest doskonale znany
ekipie, która go zaprojektowała, więc nawet instrukcje mov/in/out mażące po portach są
możliwe do przełożenia na dowolną inną (nowszą) kartę ATI/AMD.

to powiedz to carmackowi i wielu innym, oni optymalizuja w ten sposob gry, jakby tego nie robili to by gry tak nie wygladaly na konsolach, poszukaj sobie wywiadu z gosciem z amd i jego ubolewaniem nad ograniczeniem pctow bo uzywaja tam directxa a na konsoli nie musza

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Racja, ale tylko do pewnego stopnia. Gdyby było zawsze tak jak piszesz, to portowanie
tych samych gier na różne konsole byłoby sennym koszmarem.

maja najczesciej tylko 2 platformy jak ps3 i xbox360 wiec duzego problemu nie ma

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Nie są. Ale sterowniki często są. I tak na marginesie - mam do dyspozycji milion wierszy
kodu w assemblerze I386 (gdybyś chciał, to nawet w sieci znajdziesz tyle, że milion spokojnie
uzbierasz). Średnio przypada 10 bajtów na wiersz, cała wielkość to mniej niż 10 MB do
przeparsowania i wygenerowania kodu. Dzisiaj jest to śmieszna ilość danych do prostej
obróbki. I trwa ona ułamek sekundy. Asemblera wziąłem jako przykład bo jeden wiersz przekłada
się na jedną instrukcję maszynową, więc asemblowanie takiego źródła jest podobnie wydajne
jak kompilacja w locie.

lol

Dnia 13.08.2011 o 16:35, Olamagato napisał:

Jeżeli ktoś płaci Ci za pisanie softu, to moim zdaniem ta firma właśnie upada, albo ma
kłopoty finansowe. Zresztą przez takich aroganckich kolesi, dla których słowo "niemożliwe"
jest codziennością, wiele firm ma kłopoty.

lol2

btw pojecia bladego to ty nie masz skoro piszesz takie kwiatki "DX jest tak zbudowany, że nie daje niemal żadnego narzutu na wykonanie." wiekszej glupoty napisac nie mogles

[john_smith 0]

"DX jest tak zbudowany, że nie daje niemal żadnego narzutu na wykonanie."
http://www.bit-tech.net/hardware/graphics/2011/03/16/farewell-to-directx/1
:D

[Olamagato 3]

Dnia 13.08.2011 o 17:49, john_smith napisał:

dokladnie to samo napisalem wiec gdzie tu widzisz bzdure

W tym, że z takimi danymi będącymi kodem innego procesora bieżący CPU nie jest w stanie nic zrobić. Jest oczywiste, że coś może zrobić.
Na przykład
1. Znane kody instrukcji maszynowych innego procka może przetworzyć na tak samo znane kody swojej listy rozkazów.
2. Dane instrukcji maszynowych zapisane w big-endian odwrócić na little-endian (taką operację mają nawet sprzętowo jako rozkaz wszystkie obecne CPU).
3. Wywołania API innej maszyny zamienić na wywołania API maszyny bieżącej.
4. Przesłania sprzętowe zamienić na inne przesłania sprzętowe.

Tego typu zadania może wykonać specyficzny kod ładujący pracujący na maszynie docelowej. Tak też działają wszystkie symulatory wirtualnych maszyn i część emulatorów. Różnica polega na tym, że wszystkie obecne jakie znam przekładają jednorazowo tylko jedną instrukcję maszynową oryginalnego kodu. A można zrobić to przecież w podobnym trybie jak kompilacja (znika wtedy problem z niewydajną emulacją pętli).

Dlatego uznałem, że plotki o symulacji xboxa360 mogą mieć jakieś ziarno wiarygodności. To mogłoby być możliwe. Tylko tyle i aż tyle.
Oczywiście możesz w to wątpić - masz prawo. Ale po co pokazujesz przy tym perspektywę mrówki?

Dnia 13.08.2011 o 17:49, john_smith napisał:

gra moze 95% rzeczy robic przy uzyciu directxa, ale 5% bedzie bezposrednio uzywac sprzetu

Zgadzam się z tym. I dlatego nawet większy procent gier z PS2 nie był obsługiwany na PS3 (inne maszyny, ale problem podobny). Agresywne optymalizacje (co oznacza zazwyczaj łamanie ustalonych reguł) mogą zepsuć najlepsze chęci twórcy symulatora/emulatora.

Dnia 13.08.2011 o 17:49, john_smith napisał:

zobacz sobie filmik z quakecon gdzie carmack o tym mowi,
kilka miesiecy temu byl tez wywiad z gosciem z amd, ze na pc directx sprawia, ze gry
nie dzialaja tak szybko jakby to wynikalo z postepu technologi bo spowalnia je directx

Wypowiedź ta dotyczyła PC. Na xklocku nie ma "postępu technologii" bo układ graficzny od momentu premiery nie zmienił się, a nawet gdyby się zmienił, to musi być maksymalnie zgodny w dół z oryginalnym układem dla tej konsoli. Natomiast to, że każda standaryzacja ogranicza postęp to jest oczywiste. Kolejne wydania i poprawki do dowolnego API zawsze idą w tyle za zmianami sprzętowymi. Tyle, że nie ma to nic wspólnego z tematem.

Dnia 13.08.2011 o 17:49, john_smith napisał:

a na konsoli tego problemu nie masz, bo optymalizujesz nie uzywajac directx, piszesz
ze od dawna tak sie gier nie pisze, a to kompletna bzdura

Skoro tak uważasz... :)
Zauważ tylko, że jeżeli projekt gry przewiduje łatwą przenośność, to wszelkie optymalizacje sprzętowe są zawsze zawarte w ostatniej najniższej warstwie softu. Nie ma znaczenia jaki framework, jaki silnik, jakie API. Tak się po prostu projektuje oprogramowanie bo jest to skuteczne.

Wymagania wydajności i przenośności zawsze są sprzeczne. Powstający soft, to jest kompromis. Oczywiście takiego kompromisu nie muszą podejmować Ci, którzy z założenia piszą tylko exclusive''y. Ale zobacz ile dzisiaj gier, to soft przeznaczony wyłącznie na jedną maszynę? Kiedyś było to 100%, dzisiaj prawdopodobnie mniej niż 10%.

Dnia 13.08.2011 o 17:49, john_smith napisał:

piszesz gre w jezyku np c++ i kompilujesz osobno na xboxa i osobno na xboxa, gdzie ty tu widzisz przenosnosc?

Po pierwsze. Nie ma kompletnie żadnego znaczenia w jakim języku piszesz, o ile jest on kompilowany natywnie na określony procesor. Tak czy inaczej produktem końcowym jest kod maszynowy konkretnego CPU oraz dane jakie które obrabia. Pisząc dzisiaj grę (a przynajmniej jej logikę), nie dotyka się prawie w ogóle właściwości docelowej maszyny.
Dlatego wiele gier mimo, iż najwydajniejsze części są napisane w C/C++ (który, dzisiaj coraz częściej pełni rolę dawnych wstawek asemblerowych) mogą mieć logikę pisaną w innych, lepiej przystosowanych do takiego celu tego językach. Np. logika Cywilization 4 jest napisana w Pythonie, a Star Wars: Galaxies w Javie; IL-2 Sturmovik oraz Forgotten Battles, Runescape i Chrome naszego Techlanda są napisane całkowicie w Javie.

Po drugie dlaczego zakładasz, że gra jest kompilowana na xboxa? Ten sam projekt może być warunkowo kompilowany na xboxa, xboxa360, Windows, Wii, a nawet na PS3. Wynikowo dostaniesz inny kod binarny, inne najniższe warstwy softu itd. To jest właśnie przenośność.
Można źródła zbić w jednym wielkim projekcie, a można też je podzielić na osobne, osobno kompilowane odwołujące się do wspólnych bibliotek gry. Chyba każdy sposób na przenośność był już użyty i zadziałał.
A że być może gra mająca interaktywne filmy zbudowane na silniku gry będzie musiała na PSP mieć filmy prerenderowane i zapisane jako osobne pliki (jak multiplatformowy Tomb Raider Underworld), to jest to normalne.
Twoje założenia nie istnieją.

Dnia 13.08.2011 o 17:49, john_smith napisał:

mylisz generowanie kodu posredniego jak w jawie z kompilacja docelowa na tylko jedno urzadzenie

Kod pośredni nie różni się *funkcjonalnie* niczym od kodu natywnego napisanego na inny procesor. Jeden i drugi jest dla docelowego CPU kompletnie niezrozumiały.
JVM tłumaczy ten kod albo w trybie interpretacji (wtedy jest ona po prostu emulatorem nieistniejącej maszyny wirtualnej na bieżącym komputerze), albo w trybie kompilacji (wtedy docelowy CPU wykonuje wygenerowany kod zrozumiały dla niego). Tak samo może działać dowolny inny emulator/VM.

Nie napisałem nic o generowaniu kodu maszynowego z kodu źródłowego z C++, ani o generowaniu bytecodu lub kodu maszynowego ze źródeł Javy czy np. Scali. To nie ma związku.

Dnia 13.08.2011 o 17:49, john_smith napisał:

jak juz wyzej ci pisalem tu nie ma zadnej przenosnosci i nie myl pojec

Jeżeli ktoś tu myli jakieś pojęcia, to nie jestem to ja. :)

Dnia 13.08.2011 o 17:49, john_smith napisał:

przeciez o tym samym ciagle pisze

Piszesz, że niemożliwe jest napisanie emulatora konsoli na peceta. A dla mnie jest to po prostu herezja. Obecnie istnieją software''owe emulatory starych komputerów i kilku konsol przenośnych na peceta, więc po prostu mijasz się z faktami. Nikt nie pisze emulatorów nowszych maszyn, dopóki nie ma takiej potrzeby (kasa, kasa, kasa). Kiedy potrzeba się pojawia, to takie softy są tworzone.

Dnia 13.08.2011 o 17:49, john_smith napisał:

to powiedz to carmackowi i wielu innym, oni optymalizuja w ten sposob gry, jakby tego
nie robili to by gry tak nie wygladaly na konsolach

No i fajnie. Jeśli emulator xboxa360 na peceta jednak powstanie, to najwyżej niektóre gry firmowane przez gościa nie będą działać. I tyle. :)

Weź jednak pod uwagę, że obecnie przeciętny pecet ma od 8 do 16 razy więcej pamięci i od 2 razy więcej procesorów (np. 6 w stosunku do 3 na klocku) i jakieś 16 razy większą wydajność obliczeniową.
Nawet gdyby emulator/VM powodował, że każda instrukcja będzie się wykonywała osiem razy wolniej, a gra powodowała 4 razy większe zużycie pamięci, to i tak dla dobrze napisanego softu uruchamiającego takie gry, to byłaby pestka.

A ponieważ techniki takie jak hotSpot (używane również w .NET) mogą spowodować zmniejszenie spadku wydajnościowego do zaledwie 2:1, to sądzę, że jeżeli Win8 mógłby mieć wymagania minimalne do uruchomienia gry z xklocka na poziomie minimalnych wymagań systemu. Czyli prawdopodobnie (moim zdaniem) 1GB RAM, 2-3 rdzenie dowolnego CPU i sprzętowa obsługa DX11 w układzie graficznym.

Ta rozmowa już stała się niezrozumiała dla większości graczy, więc nie będę tego ciągnął.
Sprowadza się do tego, że Tobie się wydaje - że coś jest niemożliwe, a mi - że może być prawdopodobne.
Jeżeli jednak w Win8 "jakimś cudem" naprawdę pojawi się wirtualna maszyna xboxa360, to będziesz musiał zwyczajnie pogodzić się z rzeczywistością. :)

ps. Tak na marginesie C++ jest staje się powoli przestarzałym i wkrótce martwym językiem. Win8 jest pisany w C#, niemal identycznym jak Java i mającym te same założenia działania. Z tym też będziesz musiał się pogodzić. Tak jak ja musiałem się pogodzić z faktem, że pisanie w Moduli, Pascalu czy Fortranie było już 20 lat temu anachronizmem.

[john_smith 0]

Dnia 14.08.2011 o 16:24, Olamagato napisał:

W tym, że z takimi danymi będącymi kodem innego procesora bieżący CPU nie jest w stanie
nic zrobić. Jest oczywiste, że coś może zrobić.
Na przykład
1. Znane kody instrukcji maszynowych innego procka może przetworzyć na tak samo znane
kody swojej listy rozkazów.
2. Dane instrukcji maszynowych zapisane w big-endian odwrócić na little-endian (taką
operację mają nawet sprzętowo jako rozkaz wszystkie obecne CPU).
3. Wywołania API innej maszyny zamienić na wywołania API maszyny bieżącej.
4. Przesłania sprzętowe zamienić na inne przesłania sprzętowe.

mylisz sie, procesor sam tego nie zrobi, musi mu pomoc software, software =/= hardware

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Tego typu zadania może wykonać specyficzny kod ładujący pracujący na maszynie docelowej.
Tak też działają wszystkie symulatory wirtualnych maszyn i część emulatorów. Różnica
polega na tym, że wszystkie obecne jakie znam przekładają jednorazowo tylko jedną instrukcję
maszynową oryginalnego kodu. A można zrobić to przecież w podobnym trybie jak kompilacja
(znika wtedy problem z niewydajną emulacją pętli).

to ja wiem, ze trzeba uzyc softwareowego emulatora

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Dlatego uznałem, że plotki o symulacji xboxa360 mogą mieć jakieś ziarno wiarygodności.
To mogłoby być możliwe. Tylko tyle i aż tyle.
Oczywiście możesz w to wątpić - masz prawo. Ale po co pokazujesz przy tym perspektywę
mrówki?

a po co ty pokazujesz swoja perspektywe bakterii?

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Wypowiedź ta dotyczyła PC.

doucz sie angielskiego, chodzilo o obie platformy

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Na xklocku nie ma "postępu technologii" bo układ graficzny
od momentu premiery nie zmienił się, a nawet gdyby się zmienił, to musi być maksymalnie
zgodny w dół z oryginalnym układem dla tej konsoli. Natomiast to, że każda standaryzacja
ogranicza postęp to jest oczywiste. Kolejne wydania i poprawki do dowolnego API zawsze
idą w tyle za zmianami sprzętowymi. Tyle, że nie ma to nic wspólnego z tematem.

o czym ty piszesz? chodzi o sam fakt spowalnainia pctow przez directx, konsole omijaja directx i dlatego sa szybsze niz taki sam/podobny sprzet na pc

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Skoro tak uważasz... :)

ja tak nie uwazam, tylko carmack i ludzie ktorzy gry pisza

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Zauważ tylko, że jeżeli projekt gry przewiduje łatwą przenośność, to wszelkie optymalizacje
sprzętowe są zawsze zawarte w ostatniej najniższej warstwie softu. Nie ma znaczenia jaki
framework, jaki silnik, jakie API. Tak się po prostu projektuje oprogramowanie bo jest
to skuteczne.

piszesz o czyms innym

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Wymagania wydajności i przenośności zawsze są sprzeczne. Powstający soft, to jest kompromis.
Oczywiście takiego kompromisu nie muszą podejmować Ci, którzy z założenia piszą tylko
exclusive''y. Ale zobacz ile dzisiaj gier, to soft przeznaczony wyłącznie na jedną maszynę?
Kiedyś było to 100%, dzisiaj prawdopodobnie mniej niż 10%.

jak wyzej

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Po pierwsze. Nie ma kompletnie żadnego znaczenia w jakim języku piszesz, o ile jest on
kompilowany natywnie na określony procesor. Tak czy inaczej produktem końcowym jest kod
maszynowy konkretnego CPU oraz dane jakie które obrabia. Pisząc dzisiaj grę (a przynajmniej
jej logikę), nie dotyka się prawie w ogóle właściwości docelowej maszyny.
Dlatego wiele gier mimo, iż najwydajniejsze części są napisane w C/C++ (który, dzisiaj
coraz częściej pełni rolę dawnych wstawek asemblerowych) mogą mieć logikę pisaną w innych,
lepiej przystosowanych do takiego celu tego językach. Np. logika Cywilization 4 jest
napisana w Pythonie, a Star Wars: Galaxies w Javie; IL-2 Sturmovik oraz Forgotten Battles,
Runescape i Chrome naszego Techlanda są napisane całkowicie w Javie.

Po drugie dlaczego zakładasz, że gra jest kompilowana na xboxa? Ten sam projekt może
być warunkowo kompilowany na xboxa, xboxa360, Windows, Wii, a nawet na PS3. Wynikowo
dostaniesz inny kod binarny, inne najniższe warstwy softu itd. To jest właśnie przenośność.
Można źródła zbić w jednym wielkim projekcie, a można też je podzielić na osobne, osobno
kompilowane odwołujące się do wspólnych bibliotek gry. Chyba każdy sposób na przenośność
był już użyty i zadziałał.

mylisz podstawowe pojecia, piszesz o czyms zupelnie innym, przenosnosc masz np. w javie, ten sam exe odpalasz na linuxie i windowsie, program skompilowany na xboxa nie uruchomisz na pc, playstation itd wiec nei jest przenosny

Dnia 14.08.2011 o 16:24, Olamagato napisał:

A że być może gra mająca interaktywne filmy zbudowane na silniku gry będzie musiała na
PSP mieć filmy prerenderowane i zapisane jako osobne pliki (jak multiplatformowy Tomb
Raider Underworld), to jest to normalne.
Twoje założenia nie istnieją.

o czym ty piszesz

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Kod pośredni nie różni się *funkcjonalnie* niczym od kodu natywnego napisanego na inny
procesor.

no coz, nigdzie czegos takiego nie twierdzilem, nie zrozumiales po prostu, ja pisalem o kodzie maszynowym vs kod posredni

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Nie napisałem nic o generowaniu kodu maszynowego z kodu źródłowego z C++, ani o generowaniu
bytecodu lub kodu maszynowego ze źródeł Javy czy np. Scali. To nie ma związku.

jak wyzej, mylisz pojecia

Dnia 14.08.2011 o 16:24, Olamagato napisał:

> jak juz wyzej ci pisalem tu nie ma zadnej przenosnosci i nie myl pojec
Jeżeli ktoś tu myli jakieś pojęcia, to nie jestem to ja. :)

przeczytaj wyzej

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Piszesz, że niemożliwe jest napisanie emulatora konsoli na peceta. A dla mnie jest to
po prostu herezja.

nigdzie nic takiego nie napisalem, napisalem ze niemozliwe jest zrobienie tak jak ty sobie wymysliles kilka postow wyzej, tzn przepisanie kodu maszynowego xboxa na pc i odpalenie gry lub robienie tego po kawalku w czasie dzialania gry, to sa herezje

Dnia 14.08.2011 o 16:24, Olamagato napisał:

No i fajnie. Jeśli emulator xboxa360 na peceta jednak powstanie, to najwyżej niektóre
gry firmowane przez gościa nie będą działać. I tyle. :)

takie optymalizacje robi wiekszosc, tylko kilka pierwszych gier na xboxa moglo ich nie miec, ewentualnie wiecej tytulow indie

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Weź jednak pod uwagę, że obecnie przeciętny pecet ma od 8 do 16 razy więcej pamięci i
od 2 razy więcej procesorów (np. 6 w stosunku do 3 na klocku) i jakieś 16 razy większą
wydajność obliczeniową.
Nawet gdyby emulator/VM powodował, że każda instrukcja będzie się wykonywała osiem razy
wolniej, a gra powodowała 4 razy większe zużycie pamięci, to i tak dla dobrze napisanego
softu uruchamiającego takie gry, to byłaby pestka.

ta, ale kto by chcial grac na kompie za 5000zlotych zeby odpalic gre z xboxa w 600p z teksturami, lod itd jak na konsoli, bez myszy, bez klawiatury itd z limitem 30fps

Dnia 14.08.2011 o 16:24, Olamagato napisał:

Jeżeli jednak w Win8 "jakimś cudem" naprawdę pojawi się wirtualna maszyna xboxa360, to
będziesz musiał zwyczajnie pogodzić się z rzeczywistością. :)

dla dobra gier na pc wolalbym, zeby do tego nie doszlo, bo wg mnie istnieje ryzyko ze zostaniemy z graniem na kompach za 5k zl z ustawieniami z konsol: 600p itd

Dnia 14.08.2011 o 16:24, Olamagato napisał:

ps. Tak na marginesie C++ jest staje się powoli przestarzałym i wkrótce martwym językiem.
Win8 jest pisany w C#, niemal identycznym jak Java i mającym te same założenia działania.
Z tym też będziesz musiał się pogodzić. Tak jak ja musiałem się pogodzić z faktem, że
pisanie w Moduli, Pascalu czy Fortranie było już 20 lat temu anachronizmem.

pisanie jakichs aplikacji biurowych to co innego niz gry, tam nie musza sie tak przejmowac wydajnoscia i pamiecia wiec moga sobie pozwolic na jave i c# (zreszta czesto chodzi tez o ukonczenie projektu w bardzo krotkim czasie), przy grach i urzadzeniach typu smartphony nadal bedzie sie uzywac jezykow takich jak c/c++ gdzie masz wieksza kontroche chocby nad zarzadzaniem pamiecia

jakbys nie wiedzial to np. unreal engine 3 jest napisany w c++, tak samo z innymi wydajnymi engiene'ami, nie sadze zeby przy ue4 przerzucili sie na c# czy jave
http://en.wikipedia.org/wiki/Unreal_Engine_3

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
java traci popularnosc od 2002 roku wiec pewnie tez wymrze jak c++ :)
troche to dziwnie wyglada bo chociazby programowanie na androida powinno podciagnac statystyki javy ale to sie nie stalo, za to objective c (rozszerzenie jezyka c o elementy programowania obiektowego) coraz bardziej popularny...

[Olamagato 3]

Dnia 15.08.2011 o 14:02, john_smith napisał:

mylisz sie, procesor sam tego nie zrobi, musi mu pomoc software, software =/= hardware

Oczywiście, że nie. Po co się czepiasz o rzeczy oczywiste?

No cóż. Weź się chłopie nie kompromituj bo Twoja wiedza jest na poziomie chłoptasia z gimnazjum, który coś tam poczytał, tylko niewiele rozumie. To co pchniesz do internetu zostaje już na zawsze.

Dnia 15.08.2011 o 14:02, john_smith napisał:

o czym ty piszesz? chodzi o sam fakt spowalnainia pctow przez directx, konsole omijaja
directx i dlatego sa szybsze niz taki sam/podobny sprzet na pc

O ile szybsze - o 5%, może o 10%?
Więcej uzyskać się nie da. Jak sprzęt jest zbyt wolny, to nie zrobisz z niego rakiety.

Dnia 15.08.2011 o 14:02, john_smith napisał:

piszesz o czyms innym

Nie. Po prostu nie rozumiesz tego co napisałem lub przyjęcie tego do wiadomości zawaliłoby Twój urojony świat. :)

Dnia 15.08.2011 o 14:02, john_smith napisał:

mylisz podstawowe pojecia

Jakie? To podstawowa wiedza każdego, kto chce napisać choćby "Hello World". Jeżeli tej wiedzy nie znasz, to nie masz pojęcia dosłownie o niczym w tej dziedzinie.

Dnia 15.08.2011 o 14:02, john_smith napisał:

no coz, nigdzie czegos takiego nie twierdzilem, nie zrozumiales po prostu

Nie. To ty niczego nie zrozumiałeś, albo właśnie dostajesz przebłysków.

Dnia 15.08.2011 o 14:02, john_smith napisał:

jak wyzej, mylisz pojecia

Jakie pojęcia? To podstawowa wiedza.

Dnia 15.08.2011 o 14:02, john_smith napisał:

nigdzie nic takiego nie napisalem, napisalem ze niemozliwe jest zrobienie tak jak ty
sobie wymysliles kilka postow wyzej, tzn przepisanie kodu maszynowego xboxa na pc

Akurat to jest możliwe tak jak każde przetwarzanie danych.

Dnia 15.08.2011 o 14:02, john_smith napisał:

i odpalenie gry lub robienie tego po kawalku w czasie dzialania gry

Tak właśnie działa kompilacja w locie, więc to też jest możliwe bo soft taki istnieje i działa.

Dnia 15.08.2011 o 14:02, john_smith napisał:

takie optymalizacje robi wiekszosc

Jak będę miał kody źródłowe tej większości, to może się z Tobą zgodzę. :)
W każdym komputerze jest kilka procent kodu, który odwołuje się bezpośrednio do sprzętu. W większości maszyn nazywa się to (co za zaskoczenie) warstwą sterowników. Pisanie softu bez wydzielenie przynajmniej takiej warstwy, to koszmar bo wszelkie przeróbki takiego kodu są bardzo kosztowne. Ale co ja Ci będę pisał. Masz bardzo dużo podstawowych podręczników do przeczytania. Np. "Informatyka dla Opornych". :)

Dnia 15.08.2011 o 14:02, john_smith napisał:

ta, ale kto by chcial grac na kompie za 5000zlotych zeby odpalic gre z xboxa w 600p z teksturami

A to "kto by chciał?" to jedyne sensowne pytanie jakie zadałeś w tej serii bezsensownych postów.

Dnia 15.08.2011 o 14:02, john_smith napisał:

dla dobra gier na pc wolalbym, zeby do tego nie doszlo

A mi to wisi. :) Czy jakiś manager uzna, że warto wydać te kilkadziesiąt tysięcy bugsów na to, żeby można było zwolnić kupę pudełek z dvd na klocka z półek sklepowych, zamiast je mielić w ramach zwrotów - to jego problem. :)

Dnia 15.08.2011 o 14:02, john_smith napisał:

(zreszta czesto chodzi tez o ukonczenie projektu w bardzo krotkim czasie)

Dokładnie ten sam wymóg dotyczy rynku gier.

Dnia 15.08.2011 o 14:02, john_smith napisał:

przy grach i urzadzeniach typu smartphony nadal bedzie sie uzywac jezykow takich jak c/c++ gdzie masz wieksza kontroche chocby nad zarzadzaniem pamiecia

Moim zdaniem będzie dokładnie odwrotnie. Trend jest dokładnie odwrotny. Jednoplatformowość ginie. Nawet na tym zdawałoby się odpornym rynku konsolowym. A jak ginie jednoplatformowość, to zginą też wszystkie języki, które nie oferują łatwej przenośności. C++ nie ma nawet przenośnych typów danych, nie ma zarządzania pamięcią (prymitywny malloc/calloc/new to dzisiaj o wiele za mało). Kompilacja idzie jak krew z nosa. Ludzie muszą się męczyć z takim zasyfionym językiem tylko z jednego powodu - bo kupili stare dzisiaj silniki napisane w tych językach i muszą z braku czasu używać już napisanych bibliotek. To jest dzisiaj jedyny powód używania C++. Kompilacja do natywnego kodu maszynowego nie jest już dzisiaj żadnym atutem.

Dnia 15.08.2011 o 14:02, john_smith napisał:

jakbys nie wiedzial to np. unreal engine 3 jest napisany w c++, tak samo z innymi wydajnymi
engiene''ami, nie sadze zeby przy ue4 przerzucili sie na c# czy jave

Jest napisany w C++ tylko z jednego powodu - bo unreal engine 2 też był w nim napisany, a ten bo unreal engine napisano w C++. :)

Dnia 15.08.2011 o 14:02, john_smith napisał:

java traci popularnosc od 2002 roku wiec pewnie tez wymrze jak c++ :)

Nie śledzisz zbytnio aktualnych informacji. Java po wojnie z Microsoftem wraca do gry, a w ogóle języki dynamiczne coraz szybciej się rozwijają. Kosztem języków statycznych.

Dnia 15.08.2011 o 14:02, john_smith napisał:

troche to dziwnie wyglada bo chociazby programowanie na androida powinno podciagnac statystyki
javy ale to sie nie stalo, za to objective c (rozszerzenie jezyka c o elementy programowania
obiektowego) coraz bardziej popularny...

Do niedawna objective c, to był język jednego projektu. Na pewno nadaje się lepiej jako wstawka wydajnościowa od zabagnionego C++. Ale ma jeden podstawowy problem. Brak bibliotek. C++ ma setki milionów (jak nie miliardy) wierszy już napisanego kodu.

ps. Dalej tego wątku nie kontynuuję bo nie ma już o czym pisać.

[john_smith 0]

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Oczywiście, że nie. Po co się czepiasz o rzeczy oczywiste?

sam piszesz oczywistosci w swoich postach

Dnia 15.08.2011 o 17:50, Olamagato napisał:

No cóż. Weź się chłopie nie kompromituj bo Twoja wiedza jest na poziomie chłoptasia z
gimnazjum, który coś tam poczytał, tylko niewiele rozumie. To co pchniesz do internetu
zostaje już na zawsze.

lol, takie samo wrazenie mam na temat twojej wiedzy, jeszcze nie odpowiedziales na "DX jest tak zbudowany, że nie daje niemal żadnego narzutu na wykonanie." - jeden z przykladow twojej wiedzy gimnazjalnej

Dnia 15.08.2011 o 17:50, Olamagato napisał:

O ile szybsze - o 5%, może o 10%?

nie wiem dokladnie ale pewnie duzo, czytales ten link ktory wczesniej podalem?
"On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can''t typically draw more than 2-3,000 without getting into trouble with performance, and that''s quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call. "

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Więcej uzyskać się nie da. Jak sprzęt jest zbyt wolny, to nie zrobisz z niego rakiety.

roznice sa raczej znacznie wieksze, cytat powyzej

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Nie. Po prostu nie rozumiesz tego co napisałem lub przyjęcie tego do wiadomości zawaliłoby
Twój urojony świat. :)

rozumiem, to ty nie rozumiesz, przenosnosc to cos zupelnie innego

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Jakie? To podstawowa wiedza każdego, kto chce napisać choćby "Hello World". Jeżeli tej
wiedzy nie znasz, to nie masz pojęcia dosłownie o niczym w tej dziedzinie.

nie wiesz co to przenosnosc

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Nie. To ty niczego nie zrozumiałeś, albo właśnie dostajesz przebłysków.

twoje odpowiedzi sa nie na temat, pisalem pisalem o kodzie maszynowym vs kod posredni, a ty wyskakujesz z kodem nieskompilowanym vs kod posredni

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Jakie pojęcia? To podstawowa wiedza.

odpowiadasz nie na temat

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Akurat to jest możliwe tak jak każde przetwarzanie danych.

to twoje bledne zdanie

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Tak właśnie działa kompilacja w locie, więc to też jest możliwe bo soft taki istnieje
i działa.

dziala np w przypadku javy, bo masz kod posredni, a gra jest w kodzie maszynowym, widzisz roznice? to podstawowa wiedza :)

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Jak będę miał kody źródłowe tej większości, to może się z Tobą zgodzę. :)
W każdym komputerze jest kilka procent kodu, który odwołuje się bezpośrednio do sprzętu.
W większości maszyn nazywa się to (co za zaskoczenie) warstwą sterowników. Pisanie softu
bez wydzielenie przynajmniej takiej warstwy, to koszmar bo wszelkie przeróbki takiego
kodu są bardzo kosztowne. Ale co ja Ci będę pisał. Masz bardzo dużo podstawowych podręczników
do przeczytania. Np. "Informatyka dla Opornych". :)

mowimy o grach a ty mylisz to z innymi programami, podwazasz to co mowia ludzie ktorzy pracuja nad grami, a to sa fakty

Dnia 15.08.2011 o 17:50, Olamagato napisał:

A to "kto by chciał?" to jedyne sensowne pytanie jakie zadałeś w tej serii bezsensownych
postów.

nie grzeszysz intelektem

Dnia 15.08.2011 o 17:50, Olamagato napisał:

> (zreszta czesto chodzi tez o ukonczenie projektu w bardzo krotkim czasie)
Dokładnie ten sam wymóg dotyczy rynku gier.

tak, ale jednak nacisk na wydajnosc i ograniczenia sa znacznie wieksze, tak ze np. carmack wraz z duzym teamem siedzial 6 lat i pisal id tech5

doskonaly przyklad twojej wiedzy na poziomie gimnazjum to ponizszy dlugi akapit :) :

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Moim zdaniem będzie dokładnie odwrotnie. Trend jest dokładnie odwrotny. Jednoplatformowość
ginie. Nawet na tym zdawałoby się odpornym rynku konsolowym. A jak ginie jednoplatformowość,
to zginą też wszystkie języki, które nie oferują łatwej przenośności.

powiedz to appleowi, objective c w ciagu ostatnich 2 lat uzyskal 5% popularnosci, glownie przez pisanie gier/softu na iphone/ipad itd, w objective c mozesz uzywac garbage collectora jak w np java/c#, ale ze wzgledu na ograniczenie pamieci czesciej stosuje sie "reczna" obsluge pamieci oparta na zliczaniu referencji

Dnia 15.08.2011 o 17:50, Olamagato napisał:

C++ nie ma nawet
przenośnych typów danych, nie ma zarządzania pamięcią (prymitywny malloc/calloc/new to
dzisiaj o wiele za mało). Kompilacja idzie jak krew z nosa. Ludzie muszą się męczyć z
takim zasyfionym językiem tylko z jednego powodu - bo kupili stare dzisiaj silniki napisane
w tych językach i muszą z braku czasu używać już napisanych bibliotek.

Unreal Engine 3 jest starym silnikiem? myslisz, ze jakby go przepisali na jave czy c# to dzisiejszy sprzet dalby rade? znasz jakies enginey nie napisane w c++ ktore maja sensowna wydajnosc? cryengine1-3 tez sa pewnie w c++ i wiele innych, jakies mniejsze dla gier indie sa pewnie pisane w jezykach typu java/c# ale tez wiele nie oferuja wizualnie itd

Dnia 15.08.2011 o 17:50, Olamagato napisał:

To jest dzisiaj
jedyny powód używania C++. Kompilacja do natywnego kodu maszynowego nie jest już dzisiaj
żadnym atutem.

nie ma znaczenia? sa gry ktore nie kompiluja do kodu maszynowego? moze jakies gry indie ale to margines...

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Jest napisany w C++ tylko z jednego powodu - bo unreal engine 2 też był w nim napisany,
a ten bo unreal engine napisano w C++. :)

nie dlatego, jest w c++ zebys nie musial miec 16gb pamieci tylko 4gb, podobnie z prockiem itd, nie mowiac juz o konsolach, jakby chcieli to by napisali nowy engine w innym jezyku, ale tego nie zrobili, myslisz, ze unreal engine 4 nie bedzie juz w c++?

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Nie śledzisz zbytnio aktualnych informacji. Java po wojnie z Microsoftem wraca do gry,
a w ogóle języki dynamiczne coraz szybciej się rozwijają. Kosztem języków statycznych.

jakos tego nie widac po wykresach tiobe ale ok, zreszta rozmawiamy o grach a nie o ogolnych tendencjach, jak ue4 czy cryengine4 napisza w c#/javie to.... bedzie koniec swiata

Dnia 15.08.2011 o 17:50, Olamagato napisał:

Do niedawna objective c, to był język jednego projektu. Na pewno nadaje się lepiej jako
wstawka wydajnościowa od zabagnionego C++. Ale ma jeden podstawowy problem. Brak bibliotek.
C++ ma setki milionów (jak nie miliardy) wierszy już napisanego kodu.

coz, objective c uzywa sie glownie do programowania na ios (iphone/ipad) oraz mac os, a tam biblioteki sa napisane w objective c... wiec nie wiem do czego bijesz :)