Ragnarök: Vilket programmeringsspråk?

Tråden skapades och har fått 22 svar. Det senaste inlägget skrevs .
1

Vilket programmeringsspråk skall vi använda oss av? Jag har hört av KentH att CS är skrivet i C++. Det här är första gången jag ger mig på något dylikt projekt så jag vet verkligen inte vilket som skulle vara bäst.

Jag kan C++, Obj-C (Cocoa) och har kollat en del på Obj-C++ (som inte är så märkvärdigt, men väldigt användbart).

Vad säger ni som kan det här?

/Jont Olof

[ 26 September 2002, 12:45: Meddelandet ändrat av: Jon Adolfsson ]

  • Medlem
  • International user
  • 2002-07-04 19:08

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

Jag proggar också helst i Obj-C++! För min del tycker jag även det vore lite kul att programmera ett spel bara för Mac OS X. Jag har bara utforskat en bråkdel av vad Cocoa har att erbjuda, men det känns som en kompetent grund att stå på, speciellt om vi kombinerar det med C++!

  • Medlem
  • Järfälla
  • 2002-07-04 19:34

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).

Citat:

quote:Skapades ursprungligen av: emil:
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.

Bra inlägg emil. Måste dock frågra en sak angående det här med prestandan som en följd av Obj-C Runtime. Som jag har förstått det är runtimen i Objective-C extremt snabb och att dålig prestanda snarare beror på lamt skriven kod. Hur är det med detta egentligen? I all dokumentation jag har läst uppmanas man till att inte försöka komma runt Obj-C runtimen med C anrop.
Själv vet jag inte riktigt hur beroende prestandan är i ett dataspel, men är det verkligen värt att försöka skriva om anropen till C-anrop för prestandans skull?

/Jont Olof

  • Medlem
  • 2002-07-04 22:52

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

  • Medlem
  • 2002-07-04 22:57

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

  • Medlem
  • International user
  • 2002-07-04 22:58

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

Fick visst svar på frågan! Tack Kent!!

[ 04 Juli 2002, 22:59: Meddelandet ändrat av: Jont Olof ]

  • Medlem
  • Järfälla
  • 2002-07-05 09:20

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.

Någon som testat betan av gcc 3.0? Den sägs ju öka prestandan med en massa...

Någon som har erfarenheter?

/JO

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.

Snackade med en polare igår angående val av programmeringsspråk för projektet. Han ansåg att om man skall använda Obj-C så skulle man köra det fullt ut (han ansåg inte att runtimen var något problem), om man ens lekte med tanken att försöka optimera Obj-C koden så tyckte han att man skulle slopa det helt och bara köra C istället. Han menade dock att prestandaskillnaden för ett sådant här program knappast var något att hänga sig för och att om folk föredrog Obj-C som programmeringsspråk kunde man gott köra det...

Den här snubben har tvärkoll på allt vad datorer och programmering heter, därför tänkte jag bara slänga in en liten blänkare om det han sa här, ifall någon kan tänkas hålla med... Själv vet jag inte!

/Jont Olof

[ 06 Juli 2002, 13:42: Meddelandet ändrat av: Jont Olof ]

Citat:

quote:Skapades ursprungligen av: Kinslayer:
För att uppnå portbarhet så borde man använda SDL, OpenGL och OpenAL.

Få se nu, ville vi verkligen uppnå portbarhet?

/JO

Citat:

quote:Skapades ursprungligen av: Jont Olof:
Få se nu, ville vi verkligen uppnå portbarhet?

/JO

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å. ; )

[quote]quote:Skapades ursprungligen av: Kinslayer:
[QUOTE]
Tro mig, jag har bra koll på detta ämne också. ; )
[/quote]Jag tror dig! Själv är jag helgrön på det här så jag försöker bara skaffa mig lite kött på benen. Jag hänger med oavsett vad vi kommer fram till...

/Jont Olof

  • Medlem
  • 2002-07-08 15:08

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 ]

KentH:

Hade du tänkt dig att 3D-motorn skulle skrivas i Obj-C om du skriver en själv eller blir det C++ eller C?

  • Medlem
  • 2002-07-08 17:58

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

Hehe... Nej det är det väl ingen som kräver av dig!

Citat:

quote:Skapades ursprungligen av: KentH:
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...

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

1
Bevaka tråden