Inlägg

Ett API kan definitivt vara stängt, gör en sökning "closed api". I det här fallet kanske "api låst till en plattform" är ett bättre uttryck, men att haka upp sig på ordval känns lite onödigt. Om vi höll på med sånt skulle jag ifrågasätta vad en "kodplattform" är, dvs den du säger inte har ändrats på 20 år hos vissa konkurrenter.

Alla spel som är värda något är väldigt mycket mer komplicerade än en genomsnittlig app.

Absolut, men jag skiljer helst på vad som är bra för Apple och vad som är bra för mig. Att ett företag har monopol är tex jättebra för dom, men inte för oss andra. Sen är det inte sant att det alltid är bättre att ta fram något eget. Titta tex på WP8. En stor anledning till att det inte kommer särskilt många appar till det är för att du inte kan återanvända något från din IOS/Android-version. Microsoft förlorar snarare på att ha något eget i det fallet.

WWW är ett bra exempel på något som vunnit otroligt mycket på att det har varit öppet. Att kunna surfa in på sidor som kör olika servrar med alla möjliga webbläsare på olika plattformar är fantastiskt. Att det finns ett standardiserat protokoll driver i det fallet på utvecklingen eftersom du över en natt kan byta servermjukvara eller webbläsare utan att något slutar fungera. Det gör att alla måste slåss om att ligga i framkant för att inte bli nästa netscape.

OpenGL har extensions, så Apple kan ta fram vilka extensions de vill (vilket de också gör/har gjort, 1,2,3,4,5, ...). Då har du ett fast API som du vet funkar på alla plattformar som du sen kan speciala i de fall som är viktiga för dig. Om Apple skapar en ny extension kommer det ta minst ett år innan Google kan erbjuda den, så de kommer ha ett övertag rätt länge.

Jag trodde att det var det vi hade javascript till.

Jag tror du missförstod mig. Jag menar att det är dåligt att de tar fram helt egna lösningar. Apple skulle kunna gå med i Khronos (Google är redan med) och påverka så att vi kan få något som funkar bra på alla plattformar. Ingen vinner på att utvecklare behöver skriva om samma kod 2 eller 3 gånger. Den tiden är bättre att lägga på att tillföra faktiskt värde till produkten.

Vilken konkurrens? Problemet är att OpenGL ES har varit en av de största drivkrafterna för hela OpenGL tack vare Apple och Google. Om Apple går över till något annat och Google följer efter med något eget kommer OpenGL vara tillbaka där det var för 8 år sen, dvs totalt ointressant.

Absolut, precis som Microsoft gjorde med Windows under sin storhetstid (VisualBasic, Office, DirectX, ...). Om man fokuserar på spel är det dock intressant att titta på Unitys statistik för mobiler. Med tanke på att en stor del av den kommande tillväxten av nya användare kommer ske i Kina skulle det inte förvåna mig och Android ökar från sina redan starka 70%.

... och gör det ännu svårare att släppa program flera platformar. Börjar inte det kännas lite tjatigt? Jag hoppas verkligen inte Metal är något Mantle-liknande som bara funkar på iOS/OSX. Men med tanke på att det är Apple skulle jag inte bli förvånad.

Visst, man kan låta bli att använda metal och swift, men det vore bättre för alla om de fokuserade på något som man kan köra på alla platformar (c/c++ och opengl tex). Blir lätt väldigt fragmenterat annars. Eller som OpenGL vs DirectX i Windows.

Jag började med basic, gick till visual basic och sen till C++, vilket idag är det språk jag helst använder. En sak som talar emot C++ som första språk är att det är svårt att göra något riktigt program (dvs något som du faktiskt kan använda till något) utan att använda en mängd tredjepartsbibliotek, vilket är jobbigare i C++ än python, c#, java etc. Jag skulle rekommendera dig att lära dig grunderna och sen göra något enkelt spel med SDL (typ ett spelbibliotek som funkar i Windows, linux, osx, ios, android, ...), kanske den här: http://lazyfoo.net/tutorials/SDL/

Första delen där säger:

Försök göra en klon av något klassiskt spel. Det bästa sättet att lära sig är att sätta upp ett mål och försöka nå det. När man letar svar på något lär man sig alltid fyra andra saker innan man kommer fram till det du egentligen letade efter.

Både PS4 och XBONE kör vanliga x86-cores utan några större konstigheter, så CPU-mässigt är det typ identiskt med en vanlig PC, men ingen av dom kör OpenGL (här är lite mer om PS4:an). PS3:an har GCM, dvs något helt eget. Skulle man köra OpenGL på en konsoll så tappar man många stora fördelar, tex att både CPU och GPU använder samma minne och att API:erna generellt sätt är mer lågnivå (vilket AMD vill flytta över till PC genom Mantle).

Jag tror inte de nya konsollerna kommer påverka hur många spel som kommer till Linux/OSX alls, det är mer en fråga om pengar. Att se till att göra ett spel buggfritt på PC är mycket mer jobb än för konsoll eftersom du har så många fler kombinationer av hårdvara (BF4 är ett bra exempel på hur svårt det är). Linux är ännu jobbigare i den aspekten eftersom du har olika distar med olika versioner av typ allt. OSX är lättare eftersom det är en blandning mellan PC och konsoll, men än så länge är det väldigt mycket mindre marknad (95% av steamanvändarna kör windows).

Jag har jobbat på en hel del spel som släppts/ska släppas till windows, 360, XBONE, PS3 och PS4. Hur mycket tid det tar beror på vilken del du jobbar med. Om du sitter med gameplay, dvs spelmekaniker, är det ingen skillnad alls eftersom den koden skrivs mot motorn, inte OS:et. Jobbar du med grafik är det däremot jobbigare. En del av det är att olika platformar har olika API:er vilket gör att du måste skriva olika versioner av samma sak för varje platform. Målet är alltid att det ska se likadant ut, så att du inte ser någon skillnad är ett bra betyg En jobbigare del är att platformar är bra på olika saker vilket ibland kräver väldigt olika lösningar, dvs du kan inte konvertera koden rakt av. Det gäller speciellt om du vill köra spelet på pc/konsoll och mobil.

Ljud påminner lite om grafik eftersom det är olika API:er i olika operativsystem. Men det är inte alls lika mycket jobb eftersom det är mindre komplext.

Sen har du också skillnader mellan hårdvaran. I fallet Windows vs OSX är det ingen skillnad eftersom båda kör x86:or. Men om man tar PS3:an eller 360:n så kör de PowerPC vilket har rätt annorlunda prestandaegenskaper jämfört med x86. PS3:an är ännu mer speciell eftersom den till stor del består av ett par CPU:er som är otroligt snabba på att räkna matte, men har mer problem med kod som innehåller mycket logik. På den är det ofta bättre att göra alla beräkningar och sen multiplicera de man inte vill ha med 0 än att bara göra den man är intresserad av. Det gör att vissa saker (tex fysik, cullning, viss AI, ...) kräver olika versioner av den koden för att få någon fart på det.

Vad OS:et använder för radbrytningar spelar i 99% av fallen ingen roll. Filerna du läser och skriver har du full kontroll över eftersom det är du som skapat dom, så du kan välja vilka radbrytningar du vill. Oftast är en väldigt liten del av filerna du läser i textformat ändå eftersom det är så pass mycket långsammare att läsa.

Varför de flesta väljer DirectX istället för OpenGL är oftast för att de inte har några planer på att släppa spelet på Linux eller OSX och att DirectX är mognare (läs tex den här bloggposten av en på Valve). Mognare som i färre buggar och bättre tools (tex för att hitta var prestandan försvinner). Det är lite moment 22, de flesta nya spelen använder DirectX vilket innebär det att det är mer vältestat och därför ett bättre val för andra spel.

Jag kör CEC till min raspberry pi. Det gör att jag kan använda nästan alla knappar på fjärrkontrollen för att styra den (play/pause, pilar, stopp, ...). Det funkar perfekt för XBMC. Att styra en muspekare i windows är jag lite mer tveksam till.

En kompis har en Kühler H2O 620 vars fläkt har börjat låta lite spännande (dvs slitet). Kan man byta ut den mot vilken 120mm som helst? Några rekommendationer?

Nope, man var en mycket smalare mask Det gick ut på att skjuta eller tvinga in sina motståndare i en vägg.

Jag försöker hitta ett spel jag och några kompisar spelade rätt mycket när vi var mindre. Det var en variant av snake där varje spelare var en 1 pixel bred mask och kunde skjuta framåt. På spelplanen fanns det ett antal power-ups i form av blåa rutor som gav bättre vapen. Lite i stil med http://www.youtube.com/watch?v=dQkY4iMWuM4

Man behöver inte köra strcmp om du jämför en std::string med en char* ("apa"). Den operatorn finns överlagrad.

http://www.cplusplus.com/reference/string/string/operators/

bool operator== (const string& lhs, const string& rhs);
bool operator== (const char*   lhs, const string& rhs);
bool operator== (const string& lhs, const char*   rhs);

Jag har en Q9550 (http://www.cpu-world.com/Compare/354/AMD_Athlon_X4_750K_vs_In...) med ett GTX660 och 4GB minne. Jag kör inte 1080, men de flesta spelen flyter på alldeles utmärkt på high (tex bioshock, AC4, ...).

Nja, C#, Java, C++, C, Python, ... är väldigt likt, men det finns ganska många andra typer av språk än de imperativa.

Jag har inte läst den här, men den verkar bra:
http://www.gabrielgambetta.com/fast_paced_multiplayer.html

Här är några bra länkar som går igenom problem och lösningar:
* https://developer.valvesoftware.com/wiki/Source_Multiplayer_N...
* http://gafferongames.com/networking-for-game-programmers/what...

Det tråkiga med multiplayer är att det är ett olösbart problem, det enda man kan göra är att dölja artefakterna. Om du vill ha mjukare rörelser kan du interpolera positionen/orientationen för din mob mellan föregående position och den senaste du fick från servern. Dvs om du vid t0 får position p0 från servern och 30 ms senare vid tid t1 får position p1 och du vill rendera i 60 fps kan du på frame 0 rita position p0, frame 1 medelvärdet av p0 och p1, och på frame 2 använda p1.

För att minska mängden data du skickar kan du:
* Bara skicka det som ändrats (det som du föreslog).
* Packa datan tightare, tex istället för att skicka 32 bitar per komponent för en position kan du istället skicka skillnaden mot förra.
* Bara skicka data som du vet att klienten behöver (tex i ett MMO behöver du inte skicka all data för NPC:er som är för långt bort för att ritas på klienten).
* Skicka data olika ofta beroende på avstånd från spelaren. Om en mob är långt bort kommer du inte märka interpolations-glitcharna som kan uppstå om du skulle skicka data 15ggr/sekund.