Ragnarök: Vilket programmeringsspråk?

Jag vill hellst programmera i Obj-C / Obj-C++ Jag vet ju dock att det inte är någon dröm att porta och inte det snabbaste, men sånt trams lyssnar jag inte på.. Jag programmerar det hellre i basic, pascal och assembler än C++ dock..

Väljer vi Objective-C++ så låser vi ju iaf inte in oss i programmerinsspråk, då kan vi ju använda det bästa från de tre olika språken... Dock låser vi ju oss till Mac OS X - men som om det skulle göra särskilt mycket

Personligen är jag definitivt ingen fan av C++. Det är aldeles för restriktivt för min smak när det gäller tex. typer. Dessutom tycker jag att det gör många lätta saker onödigt krångliga.. Obj-C är ett helt underbart språk, lätt, dynamiskt och genomtänkt. Problemen som kan uppstå där är rent prestandamässiga eftersom alla meddelanden måste gå via en runtime, men om man använder det på ett vettigt sätt med C anrop i de kritiska bitarna tror jag att det är ett mycket bra alternativ. Tyvärr är ju CrystalSpace skriven i C++, vilket gör det svårt att använda vanlig Obj-C utan C++ extensions...

Slutsats:
Jag tycker att bästa alternativet skulle vara Obj-C (med C99 som bas), men pga. CrystalSpace så måste valet bli Obj-C++ (om nu inte någon känner för att sitta och skriva en brygga mellan C++ APIerna i CrystalSpace och C).

Jag håller fullständigt med Emil i inlägget tidigare... ett mycket bra inlägg. Obj-C++ med dom kritiska sakerna skriva i C är nog det enda vi kan tänka oss att använda. Obj-C++ för att kunna använda CS ihop med Cocoa saker... och C för prestanda. Mycket bra val tror jag.

/KentH

Ville bara säga att nu har Kenth Andersson (jag alltså) bytt synligt namn till KentH... detta uttalas KentHå eftersom detta är mitt nick på jobbet och även här i sajberspace verkar det som.

/KentH

Runtimen är snabb, men inte i närheten så snabb som ren C kod är..

När du gör ett anrop till en funktion i en Obj-C klass så istället för att bara hoppa till en adress i minnet så letas det reda på och anropas en dispatch-funktion som i sin tur anropar den riktiga funktionen..

Eller i vissa fall där det är ett objekt som inte fanns vid kompileringen eller den inte vet vad det är så skickas först en förfrågan om den har en sån funktion innan den anropas..

Så även om den är snabb för att göra vad den gör så är den långsammare. Dom fördelarna man får av det systemet är dock värda så mycket att jag inte bryr mig..

Hmm, vet inte om jag fick det där helt rätt även om det innehåller en del förenklingar.. Jag litar på att någon rättar mig om jag hade fel

Följande artiklar är intressant läsning för den som vill veta hur Obj-Cs runtime fungerar och vilken overhead som finns:

Inside the Objective-C Runtime

Inside the Objective-C Runtime, Part Two

Min väldigt komprimerade, fritt tolkade summering av de overhead problemen som nämns i artiklarna är följande:
I de flesta fall är overheaden försummbar eftersom flaskhalsen oftast sitter i andra delar av systemet, men i beräkningsintensiva (eller minnesintensiva) delar som tex. avancerade algoritmer för grafik osv. kan den skapa problem. Just därför bör vi tänka oss för var vi använder Obj-C och var vi bör ha optimerad (Obj-)C kod för att hålla prestandan uppe.

För att uppnå portbarhet så borde man använda SDL, OpenGL och OpenAL. Man behöver därmed inte använda Obj-C i någon större mån. SDL är dessutom oerhört lättanvänt jämfört med t.ex. CoreGL. Angående programmspråk så ger C störst prestanda och är att föredra iallafall för en spelmotor, andra språk kan vara användbara till användargränssnitt och dyl. Dessutom så finns det en del saker som man kan göra i assambler ca 6 ggr snabbare än i C, tex normalisering av normaler (förkortning så att en normal får längden 1.0).

Min rekommendation är så mycket i ren C som möjligt, allt som skrivs i asm bör även skrivas i C, initiering och användargränssnitt kan gärna skrivas i andra språk typ Obj-C, C++ etc.

Nej, men det är generellt sätt bra kodning att skriva portbar kod. SDL, OpenGL och OpenAL bör även användas av den anledningen att det är enkelt och skulle reducera kodskrivandet en bra bit.

Jag har ännu inte sett en 3d-motor (i realtid) skriven i ObjC. ObjC har inte särkilt mycket overhead, men det är avsevärt mycket overhead om man jämför med C. Ett metodanrop i ObjC kan i värsta fall resultera i över 20 efterföjande funktionsanrop. Om man istället hade anropat en c-funktion så hade overheaden minskat avsevärt.

ObjC kan användas till mindre prestandakritiska delar. Det är ganska vanligt att man väljer att göra just så.

Tro mig, jag har bra koll på detta ämne också. ; )

Portbar kod.... är det inte generellt dåligt att skriva portbar kod? Det är iaf min uppfattning... allt som ska funka på flera platformar blir oftast ganska långsamt eftersom man inte kan använda en massa optimeringar...

Sen att skriva vissa delar i assembler det håller jag med om att det är ganska bra.. men tjänar man så mycket på det? Nej egentligen inte eftersom det ändå optimeras av kompilatorn. Visst man kanske tjänar något.. men den stora tidsförlusten är ändå i call och return satserna (eftersom man måste tömma piplinen innan man hoppar... om man inte skriver smart kod... vilket en kompilator gör...), dom kommer man ändå inte ifrån om man inte inlinjar ALL kod...

/KentH

[ 08 Juli 2002, 15:21: Meddelandet ändrat av: KentH ]

Jag tror knappast att Obj-C(++) är språket för en 3D-motor, det förstår nog dom flesta... sen om man ska skriva i C++ eller C det är frågan... C++ har viss overhead som man inte vill ha med, men å andra sidan så är det ganska mycket lättare att skriva i.. eftersom man inte behöver att skicka med sin mega stora stuktur med variabler till varje funktion som ska arbeta på den... men men... det återstår att se... CS är skrivet i C++ inte för att jag vet om det blev lättare att använda för det...

Minst overhead och ganska bra är ju C... och det kan nog bli det som bli alternativet... jag har inte betämmt något ännu och för den delen är det knappast jag som tänkt skriva denna motor själv

Man behöver inte skicka in sin megastora struktur i en C funktion... enklast är att skicka in den ofantligt stora (32 bitar ; )) adressen till strukturen. C++ gör ju samma sak, fast det gör ju pekararitmetiken implicit om man använder referensanrop. Har personligen aldrig gillat det då man aldrig vet ifall man skickar kopior eller referenser.

Portbar kod behöver inte betyda att man skyr alla OS-specifika anrop, utan att man delar upp programmet i lager så att man ifall man nu vill det kan byta ut komponenter (tex renderingsmotorn eller audiomotorn) utan att paja hela programmet. Detta gör det lättare att fixa buggar, då man inte behöver riskera några följdfel (i större utsträckning) i andra moduler. Det skall i sådana fall (teoretiskt sett) inte vara några större problem att byta renderare från OpenGL till Direct3D (ingen anledning att göra detta) eller QuickDraw3D (RAVE). Samma sak gäller audiosystemet, det bör gå att byta ut OpenAL mot SoundSprocket utan att detta orsakar några större följdfel.

Angående assambler: ja det är sant att dagens kompilatorer genererar oerhört väloptimerad kod, detta gäller särskilt till PPC då den processorserien är designad med dagens kompilatorer i åtanke. Men en del saker gör sig bättre i assambler, som jag nämde tidigare så är detta ganska användbart vid normalisering (detta används vid ljussättning i OpenGL). En instruktion som kan användas då är frsqrte, den är ca 16 ggr snabbare än att skriva 1.0/sqrt(a), inte lika stor precision iofs, men det kan åtgärdas med lite matematisk magi (typ Newton-Rhapson). I och med att normaler behöver beräknas ganska ofta om man har animationer på 3d-modeller så kan en sådan liten optimering göra ganska mycket... Dock så bör man skriva rena C-funktioner av allt som skrivs i asm (lättare att avlusa programmet).

Eh, hoppas att jag höll mig på en förstålig nivå... ; )

Tråden finns kvar! Forumet Ragnarök fortsätter i Spelforumet tillsvidare... /Jon