Autor Wątek: jak to wlasciwie jest z tymi konsolami...?  (Przeczytany 14888 razy)

Offline vashpan

  • Użytkownik
    • Strona

# Luty 19, 2008, 11:03:31
Obrazy dmg to tylko najbardziej powszechny sposob dystrybuowania programow pod OSX, ale sam program znajduje sie (przewaznie) w tzw. bundle, jest to zwykly katalog z plikami wykonywalnymi, bibliotekami i wszelkimi zasobami, mozna oczywiscie dodawac wewnatrz wlasne. Wazne jest to ze jest to ustandaryzowane.

Instalacji samej w sobie przewaznie nie ma, po prostu kopiuje sie ten katalog do katalogu aplikacji i juz. Ze strony dewelopera stworzenie takiej binarki nie nastrecza zbyt wiele problemow bo trzeba ustawic tylko jedna opcje w GCC :) Trzeba jedynie pamietac zeby biblioteki rowniez byly w takiej formie.

Malo tego, wszystkie biblioteki, sterowniki etc. sa w systemie w takiej podwojnej wersji. Dzieki temu z tej samej plyty mozemy zainstalowac system zarowno na maku z PPC jak i komputerze z x86. Po instalacji rowniez to sie nie zmienia. Mozemy bez problemu przeniesc dysk z nowego do starego maka i system rowniez sie wlaczy. Bootloader jedynie wybiera odpowiednia wersje jadra.

Ze strony dewelopera moze rzeczywiscie niewiele to zmienia ( poza jednym kliknieciem mniej ) Ale za zdecydowanie ulatwia zadanie ze strony uzytkownika. Starsze aplikacje PPC uruchamiane sa w sposob calkowicie przezroczysty, nie widzimy zadnej roznicy, no moze oprocz tej ze program dziala wolniej :D Nie trzeba za kazdym razem wybierac odpowiedniego pliku wykonywalnego.

Aha - uzywam OSX na co dzien.

***

Dobra koniec offtop, jakby co to prywatna wiadomosc ;)

Offline Mr. Spam

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

Offline skoti

  • Użytkownik

# Luty 19, 2008, 15:24:52
@vashpan: na innych systemach dla developera to też to jedna opcja dla kompilatora gcc ;p
Co do instalacji to w zależności od ilości bitów uruchamiasz inną binarkę/instalkę i nie widzę żadnej różnicy - jeśli programiści by chcieli to nic nie stoi na przeciw - jaki problem zrobić taki katalog bundle i trzymać tam pliki wykonywalne razem z bibliotekami na wszystkie arch i zrobić skrypt uruchamiający dobrą binarkę? Wszystko jest po stronie programisty.
BTW właśnie tak działa mój silniczek, że mam wersję na x86, x86_64 na linux, macOS i windows razem i minus jest taki że jest 6x większy rozmiar bibliotek, ale to da się przeżyć - to nie system powinien się martwić nad bitowością programu, ale programiści - tak samo jest na MacOS, Linux i Windows, po prostu nie widziałeś tak napisanego programu na inne systemu ale to nie ich wina ;p.
PS. linux też trzyma 2 lub więcej gałęzi bibliotek i w windowsie pewnie też się da.

//editdown: Ja mówię tylko że da się to osiągnąć bez problemu to po co je stwarzać ;p skrypt uruchomieniowy na linuxa ma parę lini i dla programisty nie jest żadnym wydążeniem napisać 3 linijki (sprawdzić co zwraca "uname -i") - wystarczy napisać raz te 3 linijki i będzie wyglądać tak samo dla każdego projektu

bitowosc=`uname -i`
export LD_LIBRARY_PATH="$curdir"/lib/"$bitowosc":${LD_LIBRARY_PATH}
./SenGiNE."$bitowosc" > SenGiNE.log
« Ostatnia zmiana: Luty 19, 2008, 16:10:35 wysłana przez skoti »

Offline vashpan

  • Użytkownik
    • Strona

# Luty 19, 2008, 15:48:11
Chodzi mi po prostu o to ze programista tutaj nie musi robic ( prawie ) nic , bo tak jest standardowo... I tyle. Poza tym taka "wieloarchitekturalnosc" to cecha samego pliku wykonywalnego w formacie Mach-O ( w OSX stosuje sie taki format ) Nie ma zadnego skryptu ani nic takiego, to kwestia systemu. Cos takiego jest chyba wygodniejsze niz pisanie za kazdym razem skryptu ? Sa pewne zasady ktorych trzeba sie trzymac a nie wolna amerykanka. Swoja droga ta sama technologia byla juz wykorzystywana w bezposrednim przodku systemu OS X - systemie NeXTStep sprzed ponad 15 lat.

Wydaje mi sie ze mowimy o czyms zupelnie innym :D Mi chodzi po prostu o to ze w tak specyficznym srodowisku jakim jest obecnie Mac, dzialajacy na dwoch zupelnie roznych procesorach, potrzebna byla jakas technologia ktora pozwoli w bezbolesny sposob przejsc okres przejsciowy. A to ze daloby to sie zrobic w jakis inny sposob to zupelnie inna kwestia. Ja tylko mowie jak jest.

Juz wiecej nic nie na temat nie powiem ;)

Offline Khaine

  • Użytkownik

# Luty 19, 2008, 16:04:21
Cytuj
Jeżeli chcesz mieć najmniej problemów, to napisz silnik w XNA.
jesli chodzi o Win i DX i X360 to tak, ale z drugiej strony zauwaz, ze xna nie jest przenosne na inne systemy, a kazdy szanujacy sie silnik graficzny mozna uzyc chociazby na linuxie. Fakt, ze niewiele developerow z tego korzysta i przewaznie gra wychodzi na win32/64 i jakies konsole. XNA dodatkowo narzuca kompilator (chociaz tutaj akurat chyba nikt nie placze :)) oraz net framework, ktory jest nieco wolniejszy niz winapi + c/c++. A jesli to jeszcze nie wystarcza to zauwazmy, ze nie ma profesjonalnego silnika graficznego napisanego w xna. Z tego co mi wiadomo, to MS nie pozwolil chyba na sprzedaz produktow korzystajacych z xna, jako ze xna ma byc do celow niekomercyjnych.

Offline mi-ku

  • Użytkownik
    • miku DevBlog

# Luty 19, 2008, 16:05:45
w tej goracej dyskusji zostal przeoczony  temat ktory probowalem podjac :) cytuje tego posta:

"a jak jest z tym dev-kit'ami? bo rozumiem ze dla przecietnego zjadacza chleba nie sa one dostepne i trzeba za nie niezle wybulic. ale co wowczas dostajemy? funkcje poziomu ogl/d3d + f. do obslugi pad'ow, dzwieku, czy moze cos na wyzszym/nizszym poziomie?"

Napiszę odnośnie PS2 jako, że trochę programowałem na tę konsolkę

Z tego co wywnioskowałem z forum serwisu www.ps2dev.org (bo kilku profesjonalnych programistów tam jest), to oryginalny DevKit dostarcza podstawowych funkcji i struktur danych pod C. Czyli jest to poziom "średni"(o ilę mogę tak napisać :) ) abstrakcji. Jednak i tak trzeba znać bardzo dobrze architekturę wewnętrzną, bo np. żeby przesłać coś za pomocą DMA trzeba wszystko samemu ustawić i wypełnić odpowiednie struktury. Ale zawsze można zejść na jeszcze niższy poziom, grzebiąc w rejestrach samemu (tak jak robię to ja nie posiadając DevKitu :D ), lub też zbudować sobie samemu coś na wyższym poziomie.

Do samego zestawu jest dołączona konsola developerska (DTL-10000 lub DTL-15000). Która jest znacznie większa od normalnej, posiada więcej pamięci i co fajne ok 200 punktów pomiarowych i wyjście na oscyloskop. Ponad to jest dołączane specjalne oprogramowanie, m. in. "Performance Analyzer" który wyświetla statystyki chyba wszystkich punktów pomiarowych.

PS2 ma ciekawą architekturę i jednocześnie trudną w programowaniu. Uzyskanie bardzo złożonych (jak na tamte czasy) efektów graficznych jest bardzo trudne. Chyba nie jest możliwe napisanie uniwersalnego silnika który by udostępniał wszystkie możliwe efekty. Wynika to z ograniczeń pamięciowych (RAM: 32MB i Video RAM: 4MB). W konsolach zawsze stawiano na prędkość magistral aby pominąć ograniczenia pamięciowe poprzez ciągłe przetwarzanie małych zestawów informacji. Tutaj mamy główną magistralę 128-bitową i jeszcze kilka mniejszych pomiędzy konkretnymi układami (np. 64bit między VectorUnit 2 i GraphicSynthesizer) które odciążają główną magistralę. No i jak wspomniałem główny procesor ("Emotion Engine") posiada wbudowane dwie jednostki Vector Unit które pracują niezależnie od głównego rdzenia i uruchamiają specjalnie skompilowane dla nich programy. Jednostki te wykonują operacje typowe dla przetwarzania grafiki, m. in. iloczyn skalarny, wektorowy itp. a to wszystko w kilku cyklach :D

Czyli tak w skrócie. Jezeli ktoś ma bardzo dużo czasu i lubi grzebać na niskim poziomie aby napisać wysokopoziomowe biblioteki, to polecam homebrew na tę konsolę :D

Offline Charibo

  • Redaktor

# Luty 19, 2008, 16:14:33
Cytuj
kazdy szanujacy sie silnik graficzny mozna uzyc chociazby na linuxie
Z tego co się orientuję, to ani CryEngine2, ani Source, ani nawet id Tech5 nie rusza na linuxie - a to są chyba dosyc "szanujące się" silniki ;)

Offline skoti

  • Użytkownik

# Luty 19, 2008, 16:40:38
Cytuj
kazdy szanujacy sie silnik graficzny mozna uzyc chociazby na linuxie
Z tego co się orientuję, to ani CryEngine2, ani Source, ani nawet id Tech5 nie rusza na linuxie - a to są chyba dosyc "szanujące się" silniki ;)
Żle się orientujesz - id Tech 5, unreal engine, source (niekompletnie pliki makefile dla linuksa ale są naprawiane - tak można wywnioskować z Source SDK Release Notes) działają na linuxie - jedynie CryEngine2 nie ma wersji dla linuksa, ale zdziwiłbym się w tym wypadku gdyby miał ;p - nie wiem dlaczego ale ten silnik kojarzy mi się z reklamą dx10 i mimo że może pokazać na dx9 więcej ukrywa to - dlatego wersja na linuxa imo nie jest możliwa ;p
« Ostatnia zmiana: Luty 19, 2008, 16:43:04 wysłana przez skoti »

Offline vashpan

  • Użytkownik
    • Strona

# Luty 19, 2008, 17:14:42
IMO chociaz XNA sam w sobie jest jedynie pewnym frameworkiem to nie sadze by powazna firma w ogole zabierala sie za napisanie 'silnika' na ta platforme. Sila rzeczy taki silnik przegrywalby wydajnosciowo z rozwiazaniami natywnymi pod x360 wiec chyba nie mialoby to powaznego sensu... Mimo rozwoju .NET nadal nie wyobrazam sobie Unreal Engine 4 korzystajacego z maszyny wirtualnej i napisanego w C# ;)

RageX

  • Gość
# Luty 19, 2008, 17:45:44
Cytuj
Żle się orientujesz - id Tech 5, unreal engine, source (niekompletnie pliki makefile dla linuksa ale są naprawiane - tak można wywnioskować z Source SDK Release Notes) działają na linuxie - jedynie CryEngine2 nie ma wersji dla linuksa, ale zdziwiłbym się w tym wypadku gdyby miał ;p - nie wiem dlaczego ale ten silnik kojarzy mi się z reklamą dx10 i mimo że może pokazać na dx9 więcej ukrywa to - dlatego wersja na linuxa imo nie jest możliwa ;p
Czymze jest przepisanie renderer'a? Jedyne co to trzeba pozmieniac nazwy funkcji :D. No... moze w niektorych miejsach trzeba troche wiecej podlubac, ale generalnie jesli dx'owy renderer nie korzysta nadmiarowo z D3DX to mozna w dosc krotkim czasie przepisac go na OGL'a. Carmack w jeden weekend przepisal swoj software'owy renderer Quake'a na OGL'a ;). Wiem, ze Carmack to Carmack, a silnik Quake'a 1 nie byl pewnie tak rozbudowany jak dzisiejsze silniki, ale 2 dni jednak robia wrazenie :)

Offline skoti

  • Użytkownik

# Luty 19, 2008, 18:18:19
Cytuj
Żle się orientujesz - id Tech 5, unreal engine, source (niekompletnie pliki makefile dla linuksa ale są naprawiane - tak można wywnioskować z Source SDK Release Notes) działają na linuxie - jedynie CryEngine2 nie ma wersji dla linuksa, ale zdziwiłbym się w tym wypadku gdyby miał ;p - nie wiem dlaczego ale ten silnik kojarzy mi się z reklamą dx10 i mimo że może pokazać na dx9 więcej ukrywa to - dlatego wersja na linuxa imo nie jest możliwa ;p
Czymze jest przepisanie renderer'a? Jedyne co to trzeba pozmieniac nazwy funkcji :D. No... moze w niektorych miejsach trzeba troche wiecej podlubac, ale generalnie jesli dx'owy renderer nie korzysta nadmiarowo z D3DX to mozna w dosc krotkim czasie przepisac go na OGL'a. Carmack w jeden weekend przepisal swoj software'owy renderer Quake'a na OGL'a ;). Wiem, ze Carmack to Carmack, a silnik Quake'a 1 nie byl pewnie tak rozbudowany jak dzisiejsze silniki, ale 2 dni jednak robia wrazenie :)
Wiem to (czy ja napisałem, że jest to trudne? ;p). Mój post był tylko odpowiedzią na post Charibo (btw z xna pewnie nie było by tak łatwo przepisać - chodź ekstremalnie trudne pewnie też nie ;p). Napisałem tylko, że CryEngine2 jest za blisko z Microsoft (to taka (nie wiem czy darmowa ;p) reklamówka dx10 i visty), żeby się można było spodziewać wersji na linuksa (co nie znaczy że nie powstanie, ale to by było dla mnie zaskoczenie :))
« Ostatnia zmiana: Luty 19, 2008, 18:24:00 wysłana przez skoti »

RageX

  • Gość
# Luty 20, 2008, 17:53:13
Cytuj
Wiem to (czy ja napisałem, że jest to trudne? ;p)
No ja wiem ze wiesz :P. Moj post nie mial byc jakims kontrpostem do Twojego ale jego rozwiniecem ;)

Offline Khaine

  • Użytkownik

# Luty 20, 2008, 21:28:04
Cytuj
Mimo rozwoju .NET nadal nie wyobrazam sobie Unreal Engine 4 korzystajacego z maszyny wirtualnej i napisanego w C#
i takiego Crysisa kompilujacego sie przy pierwszym uruchomieniu... mniam :D :D

RageX

  • Gość
# Luty 21, 2008, 00:10:07
vashpan: No... a widział edytor Crisis'a w akcji? Oni musieli to ręcznie oskryptować aby można było dynamicznie tworzyć byty. A w takim .net można dynamicznie stworzyć wszystko... czy wywołać ręcznie opcode'y. Jeśli chodzi o to - twoje ukochane C jest 20 lat za całą resztą. :) Lubię C, ale nie lubię wszczynania bezsensownego flame'a. :)
Niepowodzenie C# na rynku gier komercyjnych raczej nie ma źródła w używaniu przezeń "maszyny wirtualnej".

Offline skoti

  • Użytkownik

# Luty 21, 2008, 00:29:40
vashpan: No... a widział edytor Crisis'a w akcji? Oni musieli to ręcznie oskryptować aby można było dynamicznie tworzyć byty. A w takim .net można dynamicznie stworzyć wszystko... czy wywołać ręcznie opcode'y. Jeśli chodzi o to - twoje ukochane C jest 20 lat za całą resztą. :) Lubię C, ale nie lubię wszczynania bezsensownego flame'a. :)
Niepowodzenie C# na rynku gier komercyjnych raczej nie ma źródła w używaniu przezeń "maszyny wirtualnej".
A tam gadasz w C malloc, calloc i realloc i też masz dynamicznie trwożone "byty" ;p

RageX

  • Gość
# Luty 21, 2008, 00:33:13
No właśnie, byty. Ale nowej klasy nie stworzysz (znaczy na upartego stworzysz, ale to wychodzi daleko poza zakres standardowego Cpp).