? Linux er framtiden for spill

[Serpentbane]

@serpentbane666:

 

Nå er det langt fra slik at de som utvikler skadelig programvare ikke har rettet sitt søkelys mot Unix/Linux. For det første kjører Unix/Linux på en svært stor andel av servere i verden. I tillegg er OSX Unix basert, samme gjelder iOS. Android er basert på Linux. Så har vi alle embedded systems osv som kjører på Linux, f.eks NAS, moderne TV-er, rutere osv., hvor mer og mer er koblet opp mot nettet. Tror nok antall enheter som kjører med Unix/Linux som kjerne i operativsystemet overgår antall enheter med Windows, faktisk svært mange ganger. Noe de faktisk har gjort en god stund. Smartphones, nettbrett, bærbare og desktop hadde i 2012 markedsandel på henholdsvis 60,1 %, 10,7 %, 16,8 % og 12,4 % (salg). Dvs i 2012 ble det solgt minst 4 ganger så mange enheter (for databehandling) med OS basert på Unix/Linux enn Windows.

 

I realiteten er det langt mer lønnsomt å få skadevare til å kjøre på servere enn på andre enheter - i realiteten kan man hente ut langt mer om de kjøres der, samt at servere er ideelle som spredere. At ikke flere servere blir kompromittert på OS-nivå forteller faktisk at det er lite å frykte på dette området, selv om Unix/Linux skulle få en markedsandel på 40 - 50 % også i desktop/bærbar markedet.

 

Newell har ellers klart sagt tidligere at hovedårsaken til satsningen på Linux er usikkerhet knyttet til Microsoft sine planer rundt distribusjonskanaler for programvare. Selv om W8 virker som før er det ingen garanti for at ikke Microsoft i Windows 9 vil kunne ta en Apple. I tillegg er Linux som OS raskest voksende på nyere typer enheter. Hvem vet om vi ikke om 2 - 4 år kan spille direkte på TV-en, som jevnt over bruker Linux som OS.

 

Klart det er et forretningsfremstøt, for Valve er det primære å sikre sine salgs-/distribusjonskanaler over tid.

 

Jeg sier ikke at de ikke har søkelyset rettet mot andre plattformer i det hele tatt, men hovedbolken av angrepene i dag er rettet mot Windows OS'et.

 

Jeg er ikke helt med på hvorfor en infisert server er bedre enn en PC, for da må man først se på formålet med infiseringen. Vi har ødeleggelse av data, datatyveri, og vi har økonomisk vinning/svindel. De to første oppnås kanskje best på server i den grad den mest aktuelle måldata stort sett ligger på server, men den siste oppnås i høyest grad på PC. Med det sakt, selv med data liggende på server, kan en klient være en lettere innfallsvinkel enn om man går på server direkte.

 

Videre vil en server ikke eksponeres mot nettet på samme måten som en vanlig klient, både når det kommer til bruk, men også med tanke på hvordan den beskyttes både når det kommer til brannmurer, nettverk og andre mekanismer, samt når det kommer til kompetansen til brukeren. At serverparken basert på Unix/Linux ikke er like utsatt er altså et resultat av flere faktorer. Tilgjengelighet, og hva man ønsker oppnå.

 

Virus angrep for å ødelegge er ikke lenger hovedformålet. Det man ønsker nå er en eller annen form for økonomisk eller strategisk gevinst, da med minst mulig investering for å nå disse målene, og med bredest mulig nedslagsfelt.

 

Det er derfor mindre hensiktsmessig å bruke resurser på å hacke embeded android Devicer etc. ganske enkelt fordi fortjenesten ikke er der.

 

Men, OSX er litt mer i vinden. Brukes av stadig flere mennesker, og da også mennesker med litt mer penger. Og denne lille økningen i markedet har gitt Apple store utfordinger med tanke på sikkerhet. Det kom etter hvert fram at OSX, i det minste fram til siste versjon, hadde store mangler på sikkerhetssiden. I realiteten er Windows som OS sikrere, og MS har kommet mye lenger på dette området.

 

Det var en sikkerhetsekspert, husker ikke hvem, som gikk ut å sa omtrent følgende.

 

OSX er som å ha en ulåst låve et sted ute på landet, og Windows er som en leilighet med stålgitter foran vinduene i byens verste strøk.

 

Dette viser at det at Linux/Unix er fundamentalt mye sikrere enn Windows i praksis er en myte.

 

Jeg ser ingen som helst tegn til at MS skal slutte som åpen plattform for standard x86 applikasjoner, til tross for at de med integrasjonen av W8 og New Gui åpner en MS store. MS har for øvrig lange, og frem til nå, levert tjenesten Games for Windows uten at dette har skremt Valve nevneverdig.

 

MS store åpner riktig nok for en viss grad av distribusjon av x86 applikasjoner også, men i hvor stor grad dette vil by på konkurranse for Valve vites ikke. Kanskje kommer de med XboX for Windows for distrubisjon av spill, hvem vet. Men like vel, Steam på PC forsvinner ikke med det første.

 

Jeg tror fremdeles dette grunner i at Valve ønsker en TV-Box. Det er der (dessverre) pengene ligger i dag. Enkle konsoller med spill for massene. En slik boks kan ikke være basert på Windows, og den må ha masse tilgjengelige spill for å lykkes.

 

Så hvordan får Valve til dette. De kan ikke operere på samme måte som MS, Sony og Nintendo på konsollmarkedet. Men de ønsker å utnytte x86 plattformen videre.

 

Kort fortalt ønsker de at utviklere skal lage spill for Linux, AKA Valves TV-Box. Og for å komme dit må de først slutte å forholde seg til D3D, og i neste omgang Windows.

Endret 20. september 2013 av serpentbane666

[Crowly]

MEN, om valve slipper en Steam Box vil denne ikke være basert på Windows

Men det er ingenting som hindrer deg fra å installere Windows på en Steam Box. Det er fremdeles en standard pc, kun med en annen formfaktor. Og Steam kommer nok til å være tilgjengelig på Windows "en god stund til".

[Del]

De har altså jobbet for å fintune motoren mot Linux, samt at de har benyttet sin tyngde i markedet for i sammen med Nvidia og AMD/ATI utvikle nye drivere for akkurat denne testen. Ikke alle utviklere er i samme posisjon som Valve.

 

Dessuten er dette lagt fram av Valv som er W8 fiendtlig, som skal slippe sin egen TV-boks basert på Linux, og som derfor er avhengig av at utviklere fokuserer på Open GL fremfor D3D.

Har du glemt hva du skrev? Selvfølgelig gjorde de en porting, men den ekstreme mengden fintuning var mot windows og directx gjennom en tiårsperiode. Her er sitatet du burde lagt merke til (og det kommer fra extremetech, ikke Valve):

 

These figures are remarkable, considering Valve has been refining the Source engine’s performance under Windows for almost 10 years, while the Valve Linux team has only been working on the Linux port of Source for a few months.

ref. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows

[efikkan]

Når det gjelder separat thread for rendring, så er dette noe som har fått fokus i det siste med patching av nvidia driver hvor det da skjer på drivernivå. SDL har støtte for tråding generelt, og skiller eksempelvis alt av lyd i egen tråd (men du hadde kanskje annen spesifikk IO i tankene?).

Jeg prøvde å gjøre poenget så kort som mulig, men la meg nå utdype. Som du sikkert vet, den tradisjonelle måten å lage et OpenGL-program på er å bygge det rundt en event-loop som tar imot events fra IO som mus, tastatur osv, i tillegg til andre typer events tilknyttet vindusbehandleren (resize, lukking, osv.). Det vanlige som mange da gjør er at de legger inn rendering i samme thread, og det kan gå bra hvis ytelse ikke er kritisk og renderingen ikke er for tung. Problemet kommer derimot når IO-events køer seg opp og skaper ujevnheter i bildeflyten eller motsatt at renderingen blir så tung at det blir forsinkelser på IO. Hvis du skal lage kabal er det kanskje ikke så farlig, men om du skal lage Battlefield 7 så er det derimot et problem.

 

Ja SDL har "generell" thread-støtte (det har også glfw), så du kan opprette threads, bruke mutexes og semaforer, men threading er som du forstår mye mer enn bare det.

 

Under f.eks. Xorg løses rendering fra separat thread på følgende måte:

Fra event-thread starter du med følgende:

- Kall XInitThreads()

- Lag et "display"

- Konfigurer events

så venter denne threaden mens du starter rendering thread som gjør følgende:

- Lag context

- Konfigurer framebuffer-objekt

- Aktivér context

Nå kan begge threads kjøre uavhengig av hverandre helt til du skal avslutte programmet.

 

Støtte for dette i Xorg har vært på plass siden slutten av 90-tallet så vidt jeg vet.

 

Var det en forklaring du var med på?

 

Biblioteket er krysspalttform, og i det ligger det naturligvis ett abstraksjonsnivå som man ikke kan unngå. Flott om du kan dokumentere at antall abstraksjonsnivåer er et kjent problem med SDL, det var ihvertfall ikke kjent for meg. Tvert imot synes jeg API'et til SDL bærer preg av å være rett på sak med greie funksjoner å forholde seg til. Det er også kodet i C, så du slipper å måtte forholde deg til abstraksjoner fra C++.

SDL har ørten abstraksjonsnivåer internt, og jeg har oppdaget at enkelte kall kan ha helt ekstrem latency, og traverserer opp og ned et stort hierarki før det faktiske kallet mot vindussystemet blir kjørt.

 

 

Hvor har du at SDL 2.0 er låst til en OpenGL versjon fra? Såvidt jeg har forstått støttes alt fra OpenGL 3.0 og oppover, i tillegg til OpenGL ES.

Det normale når noen skal bruke OpenGL er å hente header-fil fra den offisielle nettsiden som har en ferdig og oppdatert fil til enhver tid. SDL har derimot sin egen tilpassede headerfil (den heter SDL_opengl.h om du lurte) som betyr at etter hver endring i OpenGL-spesifikasjonen så må du som utvikler vente til SDL oppdaterer seg, med mindre du selv vil gjøre det. Så i stedet for at du selv kompilerer med den headerfilen du har utviklet for, så er du avhengig av den SDL valgte å kompilere med, og du linker dynamisk til et kronisk dårlig vedlikeholdt bibliotek.

 

For de som ikke bruker SDL finnes også GLEW, men det ser jeg ikke store hensikten med siden folk like gjerne kan bruke den offisielle headerfilen. Men GLEW er mye raskere til å oppdatere enn SDL.

 

 

 

Vell, strengt tatt er OpenGL et API.

Det blir bare forvirringer når folk bruker egne terminologier. OpenGL er i seg selv kun en spesifikasjon.

Endret 20. september 2013 av efikkan

[Serpentbane]

 

 

 

Det blir bare forvirringer når folk bruker egne terminologier. OpenGL er i seg selv kun en spesifikasjon.

OpenGL (Open Graphics Library)^[2] is a cross-language, multi-platform application programming interface (API) for rendering 2D and 3D computer Graphics....

 

In short, det er et bibliotek som kan benyttes for interaksjon mellom software og hardware, for å oppnå rendering av grafikk over GPU.

 

Du må gjerne kalle det en API-spesifikasjon, da biblioteket er en liste over disse API-ene, men det er og blir et API.

[Gavekort]

OpenGL er en standard, MESA 3D er et API som implementerer OpenGL-standarden på Linux.

[Serpentbane]

Har du glemt hva du skrev? Selvfølgelig gjorde de en porting, men den ekstreme mengden fintuning var mot windows og directx gjennom en tiårsperiode. Her er sitatet du burde lagt merke til (og det kommer fra extremetech, ikke Valve):

ref. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows

Jeg vet hva jeg skrev, og jeg vet hva som står. Men det der er en liten del av artikkelen, og den er for øvrig urelatert til det jeg skriver.

 

Jeg skriver ikke at de ikke oppnådde disse resultatene, men at det var svært krevende og komme dit. Og det krever mye på driversiden og på spillmotorsiden. En oppgave som ikke nødvendigvis er alle utviklere forunt å gjennomføre da det ofte er slik at de hverken har full kontroll over motoren eller driverutviklingen.

 

Dessuten har Valve en vikarierende agenda.

 

Missforstå meg rett, jeg er ikke negativ til Open GL, jeg hadde Open GL kort for mange år siden, og kjørte righteous voodoo 2 i "SLI" lenge før folk flest hadde dedikerte skjermkort. Jeg holdt på Open GL lenge.

 

Det endrer i mine øyne ikke det faktum at jeg mener D3D for bransjen i sin helhet er en bedre plattform slik de fremstår i dag.

[Serpentbane]

Men det er ingenting som hindrer deg fra å installere Windows på en Steam Box. Det er fremdeles en standard pc, kun med en annen formfaktor. Og Steam kommer nok til å være tilgjengelig på Windows "en god stund til".

Så klart kan jeg reinstallere Steamboxen, med mindre Valve finner på noe rart. Men det var ikke poenget mitt Jeg har allerede en Windows PC på stua.

[Serpentbane]

OpenGL er en standard, MESA 3D er et API som implementerer OpenGL-standarden på Linux.

Fra opengl.org

OpenGL is the industry's most widely used, supported and best documented 2D/3D graphics API...

[Lycantrophe]

OpenGL i seg selv er bare en spesfikasjon av et API.

 

API != implementasjon.

[Del]

Var det en forklaring du var med på?

Hm, la meg forsøke å oppsummere, så får du rette på meg etterpå.

 

At SDL har ørten abstraksjonsnivåer er ikke kjent. I hvertfall har du ingen dokumentasjon for hånden som bekrefter det.

 

SDL er ikke låst til en versjon av OpenGL.

 

SDL støtter IO i separat tråd.

 

SDL har blitt brukt i ytelseskritiske spill som UT2004 med hell.

 

Flott om du kan gi et eksempel på et kall fra SDL med ekstremt høy latency, enda bedre om du faktisk har noen tall på latency'en du oppdaget.

[Del]

Det endrer i mine øyne ikke det faktum at jeg mener D3D for bransjen i sin helhet er en bedre plattform slik de fremstår i dag.

D3D er en plattform kun for Microsoft. Du mener bransjen i sin helhet er tjent med at Microsoft har monopol til evig tid? Er du klar over hvor utrolig idiotisk det høres ut når noen sier slikt? Alle dine skjermkort støtter OpenGL, OpenGL er støttet på Windows, du bruker det fortsatt støtt. Enten har du kommet godt i gang med helgefylla, eller så har du noen betydelige huller i kunnskapen om OpenGL.

[Paull]

Well, that escalated quickly..

[Gjest Bruker-245639]

 

 

Jeg synes ikke det er spesielt vanskelig å se potensielt vikarierende motiver i denne saken.

Det er ingen vikarierende motiver her. Det er krystallklare opplagte motiver. Har du lyst å overleve som spillutvikler så finnes bare ett alternativ OpenGL. Den andre teknologien gjør deg til en slave og ingenting annet. Da er livet ditt 100% avhengig av slavedriverens lynne.

[efikkan]

Hm, la meg forsøke å oppsummere, så får du rette på meg etterpå.

 

At SDL har ørten abstraksjonsnivåer er ikke kjent. I hvertfall har du ingen dokumentasjon for hånden som bekrefter det.

 

SDL er ikke låst til en versjon av OpenGL.

 

SDL støtter IO i separat tråd.

 

SDL har blitt brukt i ytelseskritiske spill som UT2004 med hell.

 

Flott om du kan gi et eksempel på et kall fra SDL med ekstremt høy latency, enda bedre om du faktisk har noen tall på latency'en du oppdaget.

All dokumentasjon du trenger finner du i kildekoden, der vil du se at for svært mange funksjoner så har de først laget et generelt plattform-uavhengig hierarki, deretter et plattform-spesifikt hierarki og til slutt wrapper rundt mange kall mot vindussystemet osv. Og som sagt før så er OpenGL-spesifikasjonen kompilert inn i biblioteket. Hvis du bruker SDL og skal publisere noe for f.eks. Ubuntu, så er du da avhengig av hvilken versjon Canonical har kompilert for distribusjonen, og der er det mildt sagt lang forsinkelse. Det er kanskje ukjent for deg, men dette er kjent for de som har brukt SDL i mange år.

[Del]

Hvis du bruker SDL og skal publisere noe for f.eks. Ubuntu, så er du da avhengig av hvilken versjon Canonical har kompilert for distribusjonen, og der er det mildt sagt lang forsinkelse. Det er kanskje ukjent for deg, men dette er kjent for de som har brukt SDL i mange år.

Jeg snakker om SDL 2.0, den er ikke låst til en versjon av OpenGL. At den blir låst tili en versjon ved compile time er også nytt for meg, men denne gangen foreslår jeg at du leter opp dokumentasjon på påstanden din.

 

Kan du gi meg ett eksempel på en funksjon i SDL 2.0 med uakseptabel høy latency?

[efikkan]

Det får da være grenser til stahet da mann? Last ned SDL2 2.0.0, pakk ut og åpne include/SDL_opengl.h. Der ser du at OpenGL-headere er inkludert i SDL, så de OpenGL-versjonene du kan bruke er avgrenset til hva SDL er kompilert med. Hvis du ser nøye etter så støtter SDL2 versjon 2.0.0 bare opptil OpenGL 4.1, og har et etterslep på 3 versjoner og ligger cirka 3 år bak. Dette er bekymringsverdig siden siste versjon av SDL2 kom for 38 dager siden. Hvis du tar med tiden før pakker kommer inn i de forskjellige arkivene til Linux-distribusjoner så kan du forvente at folk ligger 4-5 år bak med mindre du selv legger med en modifisert utgave.

[Del]

Det får da være grenser til stahet da mann?

Beklager det, men du hadde et rimelig dømmende rant mot SDL. Når du da i tillegg har en rekke feilaktige påstander som applauderes her med likes, så blir det vanskelig å ikke ta til orde.

 

Last ned SDL2 2.0.0, pakk ut og åpne include/SDL_opengl.h. Der ser du at OpenGL-headere er inkludert i SDL, så de OpenGL-versjonene du kan bruke er avgrenset til hva SDL er kompilert med.

Istedet for å linke til tar-gz filen er det litt greiere med direkte link til header filen:

http://hg.libsdl.org/SDL/file/6a145dedc972/include/SDL_opengl.h

Om jeg ikke tar helt feil, så er er OpenGL utvidelsene der kun inkludert for de som ikke har OpenGL header fil tilgjengelig på systemet sitt:

    60 /**

    61  *  \file SDL_opengl.h

    62  *

    63  *  This file is included because glext.h is not available on some systems.

    64  *  If you don't want this version included, simply define ::NO_SDL_GLEXT.

    65  *

    66  *  The latest version is available from:

    67  *      http://www.opengl.org/registry/

    68  */

Når da i tillegg Ryan Gordon i august eksplisitt sier at *alle* versjoner fra og med 3.0 er støttet, så er det liten grunn til å tro noe annet.

http://phoronix.com/forums/showthread.php?83328-SDL-2-0-Has-Been-Officially-Released&p=350877#post350877

[Del]

All dokumentasjon du trenger finner du i kildekoden, der vil du se at for svært mange funksjoner så har de først laget et generelt plattform-uavhengig hierarki, deretter et plattform-spesifikt hierarki og til slutt wrapper rundt mange kall mot vindussystemet osv.

OK, nå har jeg trålet kildekoden til SDL etter hint til disse hierarkiene. Jeg valgte å se på det mest ytelsessensitive jeg kan se for meg, nemlig musbevegelse. Sjekket gjennom kildekoden i SDL_mouse.c og trålet ned til kallene for både X11 og Android (må skamfullt innrømme at jeg tok en snartur innom OSX og IOS også). Jeg så ingen spor etter hierarikene du snakker om. Utover work-arounds for å tilpasse seg særegenheter til plattformene ser det på meg ut som rett på sak, og med noen få linjer C-kode skal jeg like å se at det blir latency verdt å nevne. Foreslår at du kommer opp med noen eksempler, eller trekker tilbake påstanden din (altså den hvor du hevdet at SDL var ubrukelig til ytelseskritiske apps). Du bør tenke over hvor ødeleggende det er med poster hvor man feilaktig henger ut et prosjekt som SDL. Hvis du har noe å fare med er det greit, men så langt kan jeg ikke se det er hold i noe av det du har sagt om SDL.

[Serpentbane]

D3D er en plattform kun for Microsoft. Du mener bransjen i sin helhet er tjent med at Microsoft har monopol til evig tid? Er du klar over hvor utrolig idiotisk det høres ut når noen sier slikt? Alle dine skjermkort støtter OpenGL, OpenGL er støttet på Windows, du bruker det fortsatt støtt. Enten har du kommet godt i gang med helgefylla, eller så har du noen betydelige huller i kunnskapen om OpenGL.

Jeg skrev "per i dag", og enn så lenge er det som du sier et MS monopol, og dermed er D3D veldig gjeldende. Jeg har ikke noe i mot Open GL, ei heller ville jeg blitt lei meg om Open GL skulle erstatte D3D. Men i mine øyne er vi ikke der i dag. Jeg holdt for øvrig på Open GL veldig lenge i forhold til mange andre.

 

Jeg skjønner hva du mener, men jeg er ikke prinsipielt i mot D3D fordi det er et MS produkt.