Wolfenstein - co z wersją na PC?

Dnia 23.03.2009 o 20:52, hans olo napisał:

(..)

Do wygenerowania takich problemów wystarczy głupia zmiana wersji kompilatora:( A potem szukaj błędu w kodzie którego wcześniej nie było.Valve ma rację napisanie biblotek "cellowych" to robota na miesiące. Te wzorce o których mówiłem dają tylko/aż tyle, że wiemy w jakich klasach mamy szukać funkcji do przepisania. Jak program był pisany tylko pod jedną platformę bez ich uwzględnienia to lepiej tak jak to napisałeś zacząć wszystko od zera. Tylko najpierw szefostwo musi się na to zgodzić:(

Proste pętelki i matematyka (wspomniane wykrywanie krawędzi) to zawsze będzie przenaszalna. Gorzej już z charakterystycznymi dla danego systemu funkcjami. Nie jestem jakimś mistrzem i bardziej obeznany programista zrobiłby to lepiej i szybciej, ale sam ostatnio przenosiłem program do komunikacji po Bluetooth z projektu dla PC na projekt dla PDA. To co się tam działo, przechodziło najśmielsze moje oczekiwania. Rzeczy dotąd oczywiste okazywały się być całkowicie nieprawidłowe. Już nie wspominając jak trudno było znaleźć jakiekolwiek źródła wiedzy na temat programowania dla Win CE. Ja zatem idąc za doświadczeniem wierzę w słowa programistów Valve - PS3 to kawał grubego orzecha ;].

Dnia 22.03.2009 o 23:24, hans olo napisał:

http://www.blachford.info/computer/articles/CellProgramming1.html

Dzięki za linka do artykułu. Po jego przeczytaniu doszedłem to trochę innych wniosków niż Ty.

Dnia 22.03.2009 o 23:24, hans olo napisał:

Intel to CISC maskowany udawanym RISC, tymczasem Cell to pure RISC. Z pewnością różnice są spore

Z artykułu wynika, że kod napisany w języku wysokiego poziomu (np C++, Java, Python) jest przenaszalny.Wystarczy go przekompilować. W sumie to mnie to nie dziwi. Sorry ale nie wolno mi powiedzieć dlaczego:(

Dnia 22.03.2009 o 23:24, hans olo napisał:

z tego co wiem zazwyczaj gry na Xa i PS3 programuje się oddzielnie, bo latwiej napisać od zera niż przebudowywać.

Z tym łatwiej ostro bym polemizował. Odpowiednie wzorce projektowe pozwalają na płynne przejście pomiędzy platformami. Spore kawałki kodu można bezproblemowo przenosić. Nie widzę sensu w pisaniu od nowa np. testów wykrywania krawędzi, SI, czy oskryptowania obiektów. Co prawda stracimy całkiem sporo mocy cella (Vector Programming wygląda ciekawie), ale zyskujemy całkiem sporo czasu na kodowaniu oraz łataniu baboli. Jeden team zamiast 2 czy trzech to spory zysk na kasie. Jak znam życie to w takich molochach jak EA czy Ubi 60% kodu jest mutiplatformowe.

Dnia 22.03.2009 o 23:24, hans olo napisał:

A tu już nieco o wyższym poziomie programowania Cella z uwzględnieniem wielu rdzeni, jak widać trzeba mieć wiele rzeczy na uwadze i raczej różnice są spore

Ten kawałek nie tyle dotyczy programowania wielu rdzeni ale wielowątkowości. 80% tekstu dotyczy problemów niezależnych od architektury procesora (dostęp do danych, semafory, zagładzanie, itp). Pozostałe 20% to podział na PPE i SPE i ograniczenia tym spowodowane.Swoją drogą zlanie nadprogramowych SPE (w stosunku do Xa) i potraktowanie ich jak wolniejszych PPE dość ostro zmniejsza liczbę problemów przy tworzeniu gier multipatformowych. Można sobie wątki rozpisać np. na kartce i przemyśleć czy się nie pozagładzają. Oczywiście dobrze zaprojektowany kod wraz z odpowiednimi bibliotekami i kompilatorem sam sobie powinien poradzić z zagospodarowaniem nadmiarowych SPE. Z optymalizacją już sobie niestety nie poradzi:( Złośliwie mógłbym napisać, że to by tłumaczyło reklamy Sony: 100% mocy x360 to 40-60% mocy PS3.Oczywiście dalej pozostaje te 40%. Większość tych 40% to grafika. Co z tego, że model jest ten sam skoro DirectX (czy jak się to tam zwie na x360) i OpenGL inaczej go wyświetlają:( Do tego dochodzi możliwość przerzucenia części obliczeń z grafy na SPE.Swoją drogą po napisaniu tego tekstu doszedłem do wniosku, że już wiem czemu Sony wszystko tłumaczy lenistwem programistów i brakiem ich chęci do nauki:)Oczywiście to tylko teoria. Praktyką się nie zajmowałem ani na x360 ani na PS3. A szkoda bo to by mogło być całkiem ciekawe.