Onko järkevää kirjoittaa pelimoottori C-muodossa? [suljettu]

Olisiko kokonaisen pelimoottorin kirjoittaminen C: hen tänään kuitenkin kohtuutonta?

Onko se järkevää, mutta Kysymys kuuluu, mitä se sinulle ostaa? Et todennäköisesti tarvitse äärimmäisiä C-siirrettävyystarjouksia, ja on sääli luopua kaikista C ++: n tarjoamista ominaisuuksista, ellet ole todella filosofisesti vastusta sitä.

Mitä mahdollisia etuja C: llä on C ++: een nähden?

Parempi käännösaika?

Miksi joku pos haluatko varmasti käyttää C: tä C ++: n kanssa?

Luulen, että se on enimmäkseen esteettinen valinta. Monet ihmiset pitävät C: stä, koska se on yksinkertainen ja minimaalinen ja tuntuu siistiltä. C ++: lla on paljon mukavia ominaisuuksia (pelkästään nimitilat tekevät sen käyttämisen arvoiseksi), mutta se on myös iso ja sotkuinen.

Kommentit

• Id Tech 4: een asti
• @Josh: Helpompi virheenkorjaus !? C-ohjelmia on tunnetusti vaikea virheenkorjaus, mikä johtuu pääasiassa osoittimista ja muistinhallinnasta. C ++ -ohjelmat (kun käytetään todellisia C ++ -ohjelmointidioneja, jotka pyrkivät välttämään osoittimia ja muistinhallintaa aina kun mahdollista) ovat useita suuruusluokkia helpompaa virheenkorjaus.
• C voidaan ymmärtää pelkästään kuolevaisilla. C ++: lla näyttää olevan paljon ominaisuuksia ja edistyneitä tapauksia, joista kokeneet ohjelmoijat oppivat jopa vuosikymmenen ajan sen jälkeen, kun ovat käyttäneet sitä päivittäin elämiseen.
• C ++ on iso kieli, mutta se ' Pelottavaa mainetta levittävät enimmäkseen ihmiset, jotka ' ovat juuri lukeneet kauhutarinoita ja eivät ole ' käyttäneet aikaa oppia sitä . Opittavaa on paljon, mutta saat vastineeksi paljon arvoa. C ++: n avulla voit ilmaista paljon asioita, joita C yksinkertaisesti voi ' t.
• @ BlueRaja-DannyPflughoeft #define malloc(x) my_malloc(x) #define free(x) my_free(x) ja olet nyt virheenkorjaamassa muistia. C ++: n avulla et koskaan tiedä, mitä jaetaan milloin, koska muistia voidaan jakaa niin monella tavalla (uudet, malloc, luokan rakentajat jne.).

Olen työskennellyt paljon puhtaan C-pelimoottorin kanssa, joka on toimittanut useita tuotteita, joten se on ehdottomasti mahdollista. Tässä on henkilökohtainen kokemukseni työskentelystä molemmissa C vs C ++ -moottoreissa:

1. Pure-C-rakenteiden avulla voit hyödyntää tietoa rakenteiden kohdistamisesta, ja voit sitten käyttää näitä tietoja rakentaa objektisi pysyvyys- ja sarjallisuuskerrokset. Moottorissa, jonka kanssa työskentelin, oli joitain yksinkertaisia otsikkoparametreja, jotka luovat automaattisesti nämä metatiedot rakenteista, ja se teki tietyntyyppisistä datatoiminnoista vähäpätöisiä. Mielivaltaisten C ++ -otsikkotiedostojen jäsentäminen on käytännössä mahdotonta ja heti kun lisäät perintö- ja virtuaalitoimintoja, menetät kyvyn tietää tarkalleen missä muistissa olevat asiat
2. Kääntöaika on huomattavasti lyhyempi, koska voit pitää otsikkotiedostosi erittäin pieninä ja hyödyntää rakenteiden eteenpäin tulevia ilmoituksia.
3. Virheenkorjausta voidaan parantaa, koska ilman malleja ja perintöä on erittäin helppo selvittää tarkalleen, mitä tietty objekti on ja mitä se tekee.

Kaikki nämä edut voidaan saavuttaa yhtä helposti käyttämällä pidätettyä c ++ -koodia, joka pidättäytyy käyttämästä malleja ja perintöjä sarjoitetuissa objekteissa, mutta CTO: n päätös oli helpompaa yksinkertaisuuden varmistamiseksi, jos C ++: n sekavampia elementtejä ei ollut saatavilla.

Henkilökohtaisesti luulen, että tämä oli hieman äärimmäistä, koska kaipasin kykyä ilmoittaa muuttujat sanella silmukoita varten ja monet täysin lailliset käytöt Perintö. Mutta se ei todellakaan maksanut meille paljon tuottavuutta lopulta kaikki huomioon otetut asiat.

Kommentit

• Siellä ' ei todellakaan mikään estä sinua perimän toteuttamisessa C: ssä. Ja jos käytät C99: tä, voit ilmoittaa muuttujat silmukoille.
• Mene eri kohtaan kohdassa 3. Se ' s yhtä helppoa kirjoittaa sekava, vaikeasti virheenkorjaava koodi C: hen kuin C ++. Parempi virheenkorjaus ei ole ' t jotain C-kielelle ominaista.
• Jopa puhdasta koodia voi olla vaikeampaa ymmärtää C ++: ssa – ylikuormituksen, mallien, virtuaalisten toimintojen ja Poikkeuksia ' on paljon vaikeampi nähdä yhdellä silmäyksellä tarkalleen, mikä todellinen ohjausvirta on.
• @Dan: Yksinkertaisesti, kun sinulla on enemmän tavaraa, C ++ on vaikeampaa virheenkorjaus. Voit tietysti rajoittaa itsesi käyttämästä mitään sellaista tavaraa, jolloin virheenkorjaus on yhtä helppoa kuin C – koska siitä tulee C.
• Vähemmän tavaraa on itse asiassa syy, miksi pidän C. CI: ssä voi vain kopioida bittejä ja tavuja memcpy: n kanssa mihinkään, koska tyyppijärjestelmä ei salli ' ei salli sellaisia asioita kuin kopiolokit ja lääkäri . Voin kirjoittaa koodia tietäen, että minun ei tarvitse ' joutua palauttamaan sivuvaikutuksia melkein millä tahansa tietyllä koodirivillä, koska en voi ' t implisiittisesti poistua toiminnosta, ellet palaa nimenomaisesti siitä pois; ei ole mitään poikkeuksia. Kaikki tämä tekee tietorakenteiden kirjoittamisesta niin paljon helpompaa – C ++ – standardin mukaisen vector kirjoittaminen on erittäin aikaa vievää, varsinkin jos haluat tehdä siitä …

Kirjoitan C ++: lla ja Lua: lla kirjoitetun 2D-pelimoottorin uudelleen C: ksi ja Lua: ksi. Toistaiseksi kokemus on ollut varsin hyvä. Ilmeisesti vektori- ja matriisitoimintojen tekeminen ei päädy niin hyvältä C: n näkökulmasta. Mutta sen lisäksi olen kokenut kokemuksen melko virkistävän vietettyäni yli 10 vuotta C ++ -kehittäjänä.

C: llä on useita etuja C ++: een verrattuna:

1. kääntäjä varmistaa, ettei mitään koodia käytetä staattisella alustuksella. Tämä tekee täysin turvalliseksi globaalien tietojen, kuten avaimina käytettävien merkkijonojen, staattisen allokoinnin.
2. Läpinäkyvyys. C-määrityksessä tai muuttujan allokoinnissa tai määrittelyssä ei tapahdu koodin kuormitusta. C ++ luo automaattisesti kopiorakentajat sinulle, joten sinulla on vähemmän hallintaa siitä, mitä suoritetaan tehtävää suoritettaessa.
3. Paljon virheenkorjauksia voi olla helpompaa, koska funktioiden nimiä ei saada sekoitettua
4. Se on yleensä hyvä käyttää memcpy C: ssä, mutta se aiheuttaa helposti ongelmia C ++: ssa, koska kopiointirakentajia ei suoriteta. tha t memcpy on paljon nopeampi kuin std :: copy sillä on merkitystä.

Sen lisäksi C-ajattelutapaan pääsemisellä on useita etuja. C ++: ssa huomaan usein tekevän asioita hieman yleistetyiksi ja abstrakteiksi. C: ssä leikkaan yleensä asioita, kuten get-set -menetelmät, ja usein paikoitan kiinteän kokoiset taulukot ennenkuin käytän dynaamisia taulukoita. Usein pääsen lyhyempään ja helpommin virheenkorjattavaan koodiin C. Tietorakenteet ovat yleensä tasaisempia ja helpommin tarkasteltavissa virheenkorjaimessa.

Ollakseni oikeudenmukainen, en koskaan tekisi sovellusta yksinomaan C: ssä. se toimii, että yhdistän sen korkeamman tason kieleen, kuten Lua, joka voi täydentää C: tä hyvin, jos C ei ole niin vahva.

Id-ohjelmisto kirjoittaa suurimman osan moottoreistaan CI: ssä. Voit katsoa Palaa Wolfensteinin linnaan , joka kirjoitettiin C: ssä.

Kirjoitin kokemuksistani sivulle C: n skaalautuvuus vs C ++ ja STL-vektorin haittapuolet tavallisiin matriiseihin verrattuna.

Kommentit

• FYI, kaikissa tapauksissa, jotka olen ' tarkistanut (mikä on mielestäni darwin gcc ja vc2008), std :: copy will vain kääntyä kutsuksi memcpy: lle, jos molemmat tyypit ovat POD.
• Lisäksi RE: STL-vektori vs. tavalliset taulukot, miksi et käytä vecton hienoja osia r ja käytä normaaleja C-osoittimia iteraattoreiden sijaan, jos et pidä niistä '? Voit tehdä vain & myvector [N].Se ' pitää molempien maailmojen parhaista, olettaen, että C-koodisi jakaa muistia samalla tavalla. Tai katso silmukoita varten BOOST_FOREACH. Tekee siitä vielä yksinkertaisemman kuin C.
• Kiitos vinkistä std :: copy memcpy: stä. En tiennyt ' sitä. Kun Alexandrescu kohteli tätä muutama vuosi sitten, niin ei ollut. Tietoja C ++ – iteraattoreista. Kyse on lähinnä filosofiasta. Yritän ohjelmoida, miten C ++: n oli tarkoitus olla ohjelmaa sekä ihmisten, joiden kanssa työskentelen, että C ++ -ominaisuuksien hyödyntämiseksi. Pääasiassa huomautettiin, että jotkin C ++ -parannukset, kuten STL-kontit, eivät aina ole parempia kuin tekemällä se vanhalla C-tavalla.

En ” Luulen, että kukaan käyttää C: tä yksinomaan nykyään, se sekoitetaan yleensä ylemmän tason kielen kanssa.

C: n ohjelmoinnilla on joitain etuja verrattuna esimerkiksi C ++: n ohjelmointiin. C ++ voi tehdä konepellin alla monia käyttäjälle näkymättömiä asioita, mikä voi vahingoittaa suorituskykyä, jos et ole varovainen. C ++ voi olla myös kauhea, kun on kyse välimuistin käyttö, mikä taas voi vahingoittaa suorituskykyäsi.

Joten se voi tuoda joitain etuja, kun pelin suorituskyvyn kannalta kriittiset osat kirjoitetaan C-tyyppisellä tavalla perinteisen C ++ -menetelmän sijaan. Olen en ole koskaan kuullut kenenkään viime vuosina kirjoittaneen koko peliä C: ssä.

Joillakin alustoilla, kuten iPhonessa, C ++: n käyttö voi lisätä suoritettavan koon tietyllä palalla kilotavua (unohdin miten paljon, anteeksi), mikä on syy, miksi jotkut iPhone-kehittäjät päättävät kirjoittaa koodinsa yhdistelmään C ja Objective-C.

Pelimoottorin kirjoittaminen C: hen on järkevää. Se on nopea ja voidaan siirtää useisiin järjestelmiin. Voit esimerkiksi käyttää Androidia (NDK: n avulla). Voit käyttää sitä iPhonessa (tavoite c on vain c: n laajennus). Voit myös käyttää se pääkäyttöjärjestelmälle, kuten Linux, Mac tai Windows. Jos tunnet olosi mukavaksi c: n kanssa, suosittelen, että kokeilet sitä!

Kyllä ja ei. Kyllä, olen tehnyt sen muutama vuosi sitten, mutta tarvitsin pelini toimivan 3D-muodossa 64-bittisellä unix (ei linux) 64-bittisellä etäpalvelimella, jossa soittimet ovat tyhmillä päätelaitteilla. Se ei ollut triviaali. C voi olla mukava on haluat integroida LUA: n, mutta sain lopulta luan työskentelemään C ++: ssa, joten sanoisin kyllä, se on mahdollista, mutta älä tee sitä.

C työskenteli John Carmack , saatat saada paljon etuja käyttämällä C-merkintää, mutta se voi viedä hetken, kunnes pääset sinne hyötymään niistä.

Täältä löydät luettelon pelimoottoreista joitain Jos ne on kirjoitettu C-kirjaimeksi, saatat saada oivalluksia C-pelimoottorin tekemisestä käymällä läpi heidän lähdekoodin.