Is het redelijk om een game-engine in C te schrijven? [gesloten]

Zou het schrijven van een hele game-engine in C vandaag echter onredelijk zijn?

Het is redelijk, maar de vraag is wat je ermee koopt? Waarschijnlijk heb je de extreme draagbaarheid die C biedt niet nodig, en het is zonde om alle functies die C ++ biedt op te geven, tenzij je er echt filosofisch tegen bent.

Welke eventuele voordelen heeft C ten opzichte van C ++?

Betere compilatietijd?

Waarom zou iemand Wil je C boven C ++ gebruiken?

Ik denk dat het vooral een esthetische keuze is. Veel mensen houden van C omdat het eenvoudig en minimaal is en schoon aanvoelt. C ++ heeft veel leuke functies (alleen al de naamruimten maken het de moeite waard om te gebruiken), maar het is ook groot en rommelig.

Opmerkingen

• Tot Id Tech 4
• @Josh: gemakkelijker te debuggen !? C-programmas zijn notoir moeilijk om te debuggen, grotendeels dankzij pointers en geheugenbeheer. C ++ -programmas (bij gebruik van echte C ++ -programmeertaal, die de neiging hebben om waar mogelijk pointers en geheugenbeheer te vermijden) zijn verscheidene ordes van grootte gemakkelijker te debuggen.
• C kan door gewone stervelingen worden begrepen. C ++ lijkt veel functies te hebben en doorgewinterde programmeurs leren ervan uit, zelfs na een decennium van dagelijks gebruik voor het leven.
• C ++ is een grote taal, maar het is ' s angstaanjagende reputatie wordt voornamelijk verspreid door mensen die ' zojuist horrorverhalen hebben gelezen en ' niet de tijd hebben genomen om het te leren . Er valt nog veel te leren, maar daar krijg je veel waarde voor terug. Met C ++ kun je veel dingen uitdrukken die C gewoon kan ' t.
• @ BlueRaja-DannyPflughoeft #define malloc(x) my_malloc(x) #define free(x) my_free(x) en je bent nu bezig met het debuggen van geheugen. Met C ++ weet je nooit wat wanneer zal worden toegewezen, omdat er zoveel manieren zijn om geheugen toe te wijzen (new, malloc, class constructors, etc.)

Ik heb uitgebreid gewerkt met een pure-C game-engine die verschillende producten heeft geleverd, dus het is absoluut mogelijk. Hier is mijn persoonlijke ervaring met het werken in beide C- versus C ++ -motoren:

1. Door pure-C-structuren te gebruiken, kunt u profiteren van kennis over het uitlijnen van structuren, en u kunt deze informatie vervolgens gebruiken om uw objectpersistentie- en serialisatielagen op te bouwen. De engine waarmee ik werkte, had enkele eenvoudige header-parsers die automatisch deze metadata over structuren zouden creëren, en het maakte bepaalde soorten gegevensbewerkingen triviaal. Het parseren van willekeurige C ++ header-bestanden is in wezen onmogelijk, en zo snel als je overerving en virtuele functies toevoegt, verlies je het vermogen om precies te weten waar dingen in het geheugen zijn.
2. De compilatietijd is aanzienlijk korter omdat je je header-bestanden zeer compact kunt houden en voordeel kunt halen uit voorwaartse declaraties van structuren. / li>
3. Debuggen kan worden verbeterd omdat het zonder het gebruik van sjablonen en overerving heel gemakkelijk is om erachter te komen wat een bepaald object precies is en wat het doet.

Al deze voordelen kunnen ook net zo gemakkelijk worden bereikt met behulp van ingehouden c ++ -code die geen gebruik maakt van sjablonen en overerving op geserialiseerde objecten, maar het was de beslissing van de CTO dat het gemakkelijker zou zijn om de eenvoud af te dwingen als de meer verwarrende elementen van C ++ niet beschikbaar waren.

Persoonlijk denk ik dat dit enigszins extreem was, omdat ik echt de mogelijkheid miste om op een verstandige manier variabelen in for-lussen te declareren en de vele volledig legitieme toepassingen voor overerving. Maar het heeft ons uiteindelijk niet veel productiviteit gekost, alles in aanmerking genomen.

Opmerkingen

• Daar ' is echt niets dat je tegenhoudt om overerving in C te implementeren. En als je C99 gebruikt, kun je variabelen declareren in for-loops.
• Ik ben het niet eens met punt 3. Het ' is net zo gemakkelijk om rommelige, moeilijk te debuggen code te schrijven in C als in C ++. Betere foutopsporing is n ' t iets dat inherent is aan de C-taal.
• Zelfs schone code kan moeilijker te begrijpen zijn in C ++ – met overbelasting, sjablonen, virtuele functies en uitzonderingen, het ' is veel moeilijker om in één oogopslag precies te zien wat de feitelijke controlestroom zal zijn.
• @Dan: gewoon door meer dingen te hebben, is C ++ moeilijker te debuggen. Je kunt jezelf natuurlijk beperken in het gebruik van al die dingen, in welk geval het net zo gemakkelijk wordt om te debuggen als C – omdat het C wordt.
• Minder dingen is eigenlijk de reden waarom ik C leuk vind. in CI kan gewoon bits en bytes kopiëren met een memcpy voor wat dan ook, omdat het type systeem geen ' dingen toestaat als copy ctors en dtors . Ik kan code schrijven wetende dat ik ' niet de bijwerkingen hoef terug te draaien op bijna elke regel code, aangezien ik het ' niet impliciet kan verlaat een functie tenzij ik er expliciet uit terugkeer; er zijn geen uitzonderingen. Dit alles maakt het schrijven van datastructuren zoveel gemakkelijker – in C ++ is het schrijven van een standaard-compliant vector erg tijdrovend, vooral als je het wilt maken …

Ik herschrijf een 2D-game-engine die in C ++ en Lua is geschreven in C en Lua. Tot nu toe was de ervaring redelijk goed. Het is duidelijk dat het uitvoeren van vector- en matrixbewerkingen niet zo mooi uitziet in C. Maar afgezien daarvan vond ik de ervaring behoorlijk verfrissend na meer dan 10 jaar als C ++ ontwikkelaar te hebben doorgebracht.

C heeft een aantal voordelen ten opzichte van C ++:

1. De compiler zorgt ervoor dat er geen code wordt uitgevoerd op het statische initialisatietijdstip. Dat maakt het volkomen veilig om algemene gegevens statisch toe te wijzen, zoals strings die als sleutels worden gebruikt, bijv.
2. Transparantie. In C zal het toewijzen of toewijzen of definiëren van een variabele er niet voor zorgen dat er heel veel code wordt uitgevoerd. C ++ genereert automatisch copy constructors voor je, zodat je minder controle hebt over wat er wordt uitgevoerd bij het uitvoeren van een opdracht.
3. Veel foutopsporing kan gemakkelijker zijn doordat functienamen niet worden verminkt.
4. Het is meestal oké om memcpy te gebruiken in C, maar het zal gemakkelijk problemen veroorzaken in C ++, omdat copy constructors niet zullen worden uitgevoerd. tha t memcpy is veel sneller dan std :: kopieer dat er toe doet.

Afgezien daarvan zijn er een aantal voordelen om in de C-manier van denken te komen. In C ++ merk ik dat ik dingen vaak een beetje overgeneraliseerd en abstract maak. In C verwijder ik meestal zaken als get-set-methoden en wijs ik vaak arrays met een vaste grootte vooraf toe in plaats van dynamische arrays te gebruiken. Vaak eindig ik met kortere en gemakkelijker te debuggen code in C. De datastructuren zijn meestal vlakker en gemakkelijker te bekijken in een debugger.

Om eerlijk te zijn zou ik nooit een app exclusief in C maken. De reden het werkt zo dat ik het combineer met een taal op een hoger niveau zoals Lua die C heel goed kan aanvullen, waar C niet zo sterk is.

Id-software schrijft de meeste van hun engines in CI geloof, je kunt kijken naar Keer terug naar kasteel Wolfenstein dat was geschreven in C.

Ik schreef over een deel van mijn ervaringen op schaalbaarheid van C versus C ++ en nadelen van STL-vector vergeleken met gewone arrays.

Opmerkingen

• Ter info, in elk geval dat ik ' heb gecontroleerd (dat is, denk ik, darwin gcc en vc2008), zal std :: copy compileer gewoon naar een oproep naar memcpy als beide typen POD zijn.
• Ook RE: STL-vector versus gewone arrays, waarom niet de mooie delen van vecto gebruiken r en normale C-pointers gebruiken in plaats van iterators als je ze niet ' leuk vindt? Je kunt gewoon & myvector [N] doen.Het ' is als het beste van twee werelden, ervan uitgaande dat je C-code geheugentoewijzing op dezelfde manier uitvoert. Of kijk voor loops naar BOOST_FOREACH. Maakt het zelfs nog eenvoudiger dan C.
• Bedankt voor de tip over std :: copy memcpy. Ik wist ' dat niet. Toen Alexandrescu dit enkele jaren geleden behandelde, was dat niet het geval. Over C ++ iteratoren. Het gaat vooral om de filosofie, ik probeer te programmeren hoe C ++ bedoeld was om programma te zijn, zowel voor de mensen met wie ik werk als om te profiteren van de C ++ -functies. Het werd voornamelijk gemaakt om erop te wijzen dat sommige C ++ -verbeteringen zoals STL-containers niet altijd beter zijn dan het op de oude C-manier te doen.

Zoals iemand anders opmerkte, biedt C ++ het voordeel van grote schouders waarop je kunt staan (BOOST, STL etc.). Het is uiteindelijk een persoonlijke keuze, maar ik zou voor C ++ kiezen vanwege de beschikbare bronnen. Als er functies in C ++ zijn die u niet wilt gebruiken, gebruik ze dan niet.

Opmerkingen

• Merk op dat 99% van de commerciële en interne game-engines sturen om verschillende redenen weg van Boost en STL (prestatiegarantie, foutopsporing, veiligheid van threads, controle).
• En 99% van de statistieken bestaat.
• Ik vind dat het een beetje een regel zou moeten zijn om alle statistieken te vermelden.

Ik niet ” Ik denk niet dat iemand C tegenwoordig exclusief gebruikt, het wordt meestal gecombineerd met een taal van een hoger niveau.

Programmeren in C heeft enkele voordelen ten opzichte van bijvoorbeeld programmeren in C ++. C ++ kan veel dingen doen onder de motorkap die onzichtbaar zijn voor de gebruiker, wat de prestaties kan schaden als je niet oppast. C ++ kan ook verschrikkelijk zijn als het gaat om cachegebruik, wat weer je prestaties kan schaden.

Het kan dus enkele voordelen opleveren om de prestatie-kritische delen van een game op een C-achtige manier te schrijven, in plaats van op een traditionele C ++ -wijze. nog nooit van iemand gehoord, in de afgelopen jaren, die een volledig spel in C heeft geschreven.

Op sommige platforms, zoals de iPhone, kan het gebruik van C ++ uw uitvoerbare grootte vergroten met een bepaald stuk kilobytes (ik vergat hoe sorry), wat een reden is waarom sommige iPhone-ontwikkelaars ervoor kiezen om hun code in een combinatie van C en Objective-C te schrijven.

Ik zal je nog een paar redenen geven waarom het onredelijk zou zijn om vandaag een game-engine in C te schrijven in plaats van C ++: STL en BOOST.

Ik kan me niet voorstellen hoe het zou zijn zijn het waard om nog een list impleme te schrijven notatie wanneer u zou kunnen vertrouwen op code die direct werkt (en die u “niet hoeft te schrijven!)

Reacties

• Is er geen grote studios daadwerkelijk boost gebruiken? Zelfs STL-gebruik staat nog steeds ter discussie, vanwege draagbaarheid. In ieder geval voor console-engines.
• Persoonlijk gebruik ik ' Boost.FunctionTypes voor c ++ / lua-interactie (zie gamedev.net/reference/programming/features/CPPLuaExport/ … ) en de Boost-bibliotheek met willekeurige getallen voor het genereren van uniforme willekeurige getallen (voor deeltjessystemen). Bovendien is Boost.Foreach netjes. Trouwens, wat maakt het uit als grote studios geen BOOST gebruiken? Ze hebben de mankracht om hun eigen STL-bibliotheken helemaal opnieuw te schrijven, dat wil ik niet ' t.
• Ja, maar besef ook dat er ' s vergelijkbare bibliotheken ook voor C.
• Veel mensen gebruiken boost in games, geloof ik. Maar het ' is verre van een vereiste (of zelfs wenselijk) voor velen van ons.
• Mensen, wat je gelooft is niet relevant : u weet of u weet niet ' weet niet .

Het schrijven van een game-engine in C is redelijk. Het is snel en kan naar meerdere systemen worden overgezet. Je zou het bijvoorbeeld kunnen gebruiken voor Android (met gebruik van de NDK). Je zou het voor de iPhone kunnen gebruiken (Objective c is gewoon een extensie van c). Je zou ook kunnen gebruiken het voor en van het hoofdbesturingssysteem zoals Linux, Mac of Windows. Als je je op je gemak voelt met c, raad ik je aan het eens te proberen!

Natuurlijk is het redelijk. Ik zou het persoonlijk niet doen, en de meeste C-fans die ik ken, schrijven eigenlijk gewoon C-achtige code in .cpp-bestanden. Maar de talen lijken genoeg op waar het er niet echt toe doet.

Wat betreft waarom iemand ervoor zou kiezen om dit te doen, ik denk dat het voornamelijk te maken heeft met de anti-C ++ filosofie. Persoonlijk denk ik nog steeds niet dat dit een goede reden is om C te verkiezen boven “C-stijl C ++”. typedef struct-gekte is een goede reden om C te vermijden, en er zijn een aantal andere.

Helaas zijn C en C ++ beide behoorlijk vreselijke talen als we er aan beginnen. Dat is een van de redenen waarom mensen de afgelopen jaren veel van hun code in script hebben geprobeerd.

Als je voorbeelden zoekt van mensen die in C werken, kun je id negeren, aangezien ik me herinner dat ze gelezen hebben dat ze C al lang geleden hebben verlaten. Cryptic Studios (Star Trek Online) doet echter al hun motorontwikkeling in C. Voor zover ik weet, ja, is het meer vanwege filosofie dan vanwege enig tastbaar voordeel.

Ja en nee. Ja, ik heb het een paar jaar geleden gedaan, maar ik had mijn spel nodig om in 3D te draaien op een unix (niet linux) 64 bit remote server met de spelers op domme terminals. Het was niet triviaal. C kan leuk zijn is je wilt LUA integreren, maar ik heb uiteindelijk lua ertoe gebracht om in C ++ te werken, dus ik zou zeggen dat het mogelijk is, maar doe het niet.

Mag een mogelijk goed antwoord zijn” gebruik beide “?

Zoals ik heb gehoord dat panda3d-projecten kunnen worden geoptimaliseerd, waarbij de bottleneck kan worden opgelost door ofwel een cython te gebruiken, ofwel die onderdelen opnieuw te coderen.

Meestal zijn de onderdelen die moeten worden geoptimaliseerd, het onderdeel met veel iteraties en nesten of met veel numeriek computergebruik, dus mijn (wilde) gok is dat een redelijk compromis zou zijn om beide talen te gebruiken , gebruikmakend van C voor onderdelen die veel programmeren op laag niveau bevatten, dus je kunt geen y misbruik van de C ++ -taal voor het gedeelte dat snelheid nodig heeft, en C ++ voor de rest van het spel.

Idealiter doe je het snelle gedeelte van de engine, rekening houdend met het hoge niveau in gedachten, en gebruik dan een scripttaal of C ++ die veel minder nest / loops zal gebruiken.

Natuurlijk zou je nooit zon engine kunnen maken die zou passen bij alle games die ontwikkelaars zouden moeten doen, behalve als je je engine zou wijden aan een speciale soort spel …

Maar neem mijn advies niet als vanzelfsprekend aan, aangezien ik “geen ervaren game-ontwikkelaar of ervaren ontwikkelaar ben … Ik denk dat C je dwingt om snelle code te schrijven tijdens het schrijven goede en snelle C ++ code voor een project zo groot als een game is iets anders …

C werkte voor John Carmack , je zou veel voordelen kunnen behalen door C te gebruiken, maar het kan even duren voordat je daar bent om ervan te profiteren.

Hier vindt u een lijst met game-engines , enkele van Als ze in C zijn geschreven, kun je misschien wat inzichten krijgen in hoe je een C-game-engine kunt maken door hun broncode te doorlopen.

C-code is normaal gesproken geldige C ++ -code.

De belangrijkste problemen met C ++ zijn onjuist gebruik ervan ( Linus Torvalds haat het om deze reden , hij had ook een aantal andere problemen met de overdraagbaarheid van de bibliotheek en zo verder, hij werkt op het niveau van het besturingssysteem en moet dingen kunnen uitvoeren op elke willekeurige chip die er is).

Bijvoorbeeld het heeft bijna geen voordeel om een cstyle-array [] te gebruiken in plaats van een c ++ std :: vector <> (of vergelijkbare container).

De vectoren zijn typeveilig en kunnen worden gecontroleerd (je kunt toegang krijgen tot elementen met get () of [], zelfs als je de array-gecontroleerde methode niet gebruikt, kun je nog steeds de grootte opvragen in plaats van het rond te slepen met de aanwijzer).

Maar vectoren kunnen langzamer zijn als u bijvoorbeeld niet de standaardgrootte aangeeft in de constructeur. Ook het toevoegen van dingen aan een vector kan vertragingen veroorzaken als de grootte ervan moet worden aangepast. C ++ 11 voegt ook veel voordelen toe, zoals uniforme initialisatie (je kunt nu vectoren declareren en initialiseren met dezelfde syntaxis) en er zijn verplaatsingsconstructors waarmee je kopiëren kunt voorkomen. U kunt zelfs uw eigen aangepaste initializers maken (als u om de een of andere reden iets anders wilde doen dan malloc te gebruiken).

Of natuurlijk, als u de grootte van dingen moet wijzigen, dan zijn vectoren nog steeds gemakkelijker om mee te doen , je hoeft niet met malloc te rommelen, dingen handmatig te kopiëren, enzovoort.

C ++ geeft je objectgeoriënteerde code. Bij het compileren zal het net zo efficiënt zijn omdat het eigenlijk gewoon een abstractie voor mensen die met de code werken. Hoewel dingen als constructors het maken van objecten kunnen vertragen. Maar je hebt ofwel de constructor nodig om de standaardwaarden in te stellen, of je kunt objecten initialiseren zonder de constructor te gebruiken (door de () s weg te laten ).

Maar objectoriëntatie maakt het programmeren van spellen veel eenvoudiger. Games hebben vaak te maken met objecten.