John Carmack stelt broncode Wolfenstein 3D voor iPhone beschikbaar

John Carmack, eigenaar en programmeur van ontwikkelaar id Software, heeft de broncode vrijgegeven van de versie van schietspel Wolfenstein 3D die voor de iPhone verschijnt. Carmack licht bovendien de ontstaansgeschiedenis toe.

Programmeur John Carmack heeft de afgelopen maanden een nieuwe versie van schietspel Wolfenstein 3D gemaakt. Deze versie van de game, die oorspronkelijk in 1991 verscheen voor 286-pc's, is nu te spelen op Apple's iPhone. Het spel zou volgens de bijbehorende website al in de AppStore aanwezig moeten zijn, maar is daar in werkelijkheid nog niet te vinden, wat het ook onduidelijk maakt wat het spel gaat kosten. Carmack heeft al wel de broncode van de nieuwe versie vrijgegeven, die te downloaden is van de site van id.

De oprichter, eigenaar en programmeur van id Software heeft bovendien een uitgebreid document geplaatst waarin hij het project beschrijft, vanaf de eerste ideeën, tot de ontwerpkeuzes en de aanpassingen aan de besturing. Carmack gaat zelfs in op het programmeerwerk, tot en met stukken code aan toe. In het document zegt hij de potentie van de iPhone in te zien en graag een game voor het platform op de markt wil brengen. De eerste stap was het aanpassen van id's eigen DS-game Orcs & Elves, maar dat bleek geen geschikt startpunt omdat de iPhone krachtiger is dan de DS en er bovendien teveel gebruik werd gemaakt van de specifieke DS-api om het spel snel over te kunnen zetten. Uitgeverij Electronic Arts was ondertussen begonnen met een Wolfenstein-rpg voor de iPhone, maar Carmack was teleurgesteld in het resultaat. De game liep niet soepel en Carmack weigerde toestemming te geven voor publicatie. Hij had wel wat tips voor verbetering, maar toen de programmeurs van EA aangaven dat het hen twee maanden zou kosten om die door te voeren, nam Carmack het programmeerwerk zelf op zich, om de klus vervolgens in zijn eentje in vier dagen te klaren, waarna het spel gebruik kon maken van de hardwarematige 3d-acceleratie van de iPhone en niet langer op de software rasterizer van de smartphone hoefde te leunen.

Dat programmeerwerk vormde de start van het eerste eigen iPhone-project van id, een nieuwe versie van schietspel Wolfenstein 3D. Opvallend is dat Carmack, die de broncode van de pc-versie al jaren geleden vrijgaf, hierbij gebruikmaakte van het werk dat een modteam heeft verzet aan de programmacode. De code was aanvankelijk geschreven voor DOS, maar werd door diverse modteams aangepast om gebruik te kunnen maken van OpenGL. Carmack vond de aangepaste broncode van Wolf3D Redux goed genoeg om op voort te borduren en heeft die gebruikt als basis voor de iPhone-versie.

De nu door id vrijgegeven broncode verdient geen schoonheidsprijs, zo geeft Carmack toe, omdat het werk van het modteam rommelig is en zijn eigen bijdrage haastig werd geschreven. Hij wil de code echter toch onder GPL vrijgeven, zodat anderen van de opgedane kennis kunnen profiteren. De programmeur meldt er echter ook bij dat de code alleen interessant is voor iPhone-ontwikkelaars en dat er geen compilers vrij beschikbaar zijn waarmee het omgezet kan worden in een werkende game. Tot slot heeft Carmack nog laten weten verder te zullen werken aan id's racegame Rage, en dat er binnen afzienbare tijd ook een iPhone-versie van Doom te verwachten is.

Reacties (81)

[Dreamvoid]

Eigenlijk wel maf dat een spel dat het op een 16 MHz 286 met 2 MB RAM zonder enige 3D hardware goed deed, daar nu een 620 MHz ARM met 128 MB RAM voor nodig heeft. Is x86 werkelijk zoveel efficienter?

Zelfs het goedkoopste Nokia instappertje vliegt qua rauwe snelheid rondjes om zo'n 286 heen, maar toch zijn de spellen op die dingen veel primitiever qua graphics/snelheid. Kan een game dev me dat eens uitleggen?

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 21:44]

[Rob Coops]

Dat is een beetje appels en peren vergelijken. Ja de processor van de iPhone heeft op sommige valken totaal geen moeite een 286 te verslaan, maar er zijn wel wat verschillen. Het is niet zo zeer dat een x86 ontwerp zo veel efficienter is maar wel dat een x86 ontwerp hele andere instructies mogenlijk maakt en er grote verschillen in snelheid van berekenen zal zijn voor sommige instructies.
Een instructie kan bijvoorbeeld in 1 clock tick gedaan zijn op een x86 waar een ARM processor er 4 nodig heeft, als je dan ook bepaalde instructies niet hebt en je ze dus zelf zal moeten op bouwen uit een combinatie van andere instructies dan kun je al snel op een punt komen waar een instructie die op een x86 2 clock ticks duurt op een ARM 10 fo 20 clock ticks nodig heeft. Uit eindelijk kun je dus best wel eens bedrogen uit komen als je alleen naar de clock snelheid kijkt.
De hoeveelheid geheugen is ook niet echt heel erg van belang voor een game geschreven voor een 2MB systeem is 128MB leuk maar veel al niet gebruikt de snelheid van het geheugen wordt dan wel weer van belang, als het geheugen van de 286 net zo snel is of net iets sneller dan zal de ARM niets winnen door meer geheugen beschikbaar te hebben, anders dan het leven van de luie coder makelijker te maken.

De reden dat bijvoorbeeld Intel en AMD nu aan alle kanten roepen dat meer MHz niet altijd wil zeggen dat de processor ook sneller is. Het enige dat je ziet is dat de tijd die een processor nodig heeft voor een clock tick sneller is. Een twee keer zo hoge clock werkt alleen als de instructie tijd niet langer geworden is. Als je al je instructies in 2 ticks uitvoert in plaats van 1 dan is er dus netto geen enkel verschil.

Ook moet je niet vergeten dat dingen als threads een groot verschil kunnen maken, stel dat je op en 286 4 threads gebruikt om een 3D game te laten draaien, 1 voor de AI, een voor de user input, 1 voor de omgeving en 1 voor de graphics maar op een ARM processor gaat dat niet je kunt er niet meer dan 1 thread per applicatie gebruiken (geen idee of dat waar is maar het zou best wel eens kunnen) dan heb je dus een probleem en zull je dus je programma zo moeten aanpassen dat je steeds 1 handling uitvoert, kijkt of je de speler ziet en op hem kan schieten en dan bekijkt of de speler hier op gereageerd heeft. Dan bouw je her scherm en doe je weer het zelfde...
Zo'n manier van werken is heel goed mogenlijk maar neemt veel meer tijd in beslag omdat een speler wel de kans moet krijgen om te reageeren en je dus niet maar 1 keer kan kijken of er wel input is, dus hier heb je best veel tijd nodig om te controleren of een speler input heeft gelevert, en dus gaat veel van de processor kracht op aan het kijken of een speler op een konpje heeft gedrukt zonder dat je voor de rest iets anders doet.

Wat grafisch en java betreft... java is niet echt een programeer taal die bekend staat om zijn grafische kracht. Je schrijft namelijk code die niet voor een processor gecompileerd wordt maar in een tussen vorm gegoten wordt, dan draait er een Virtual Machine die eigenlijk niet anders doet dan die tussen vorm lezen en dat vertalen naar instructies voor de processor waar deze virtual machine op draait. Dat betekend dus dat je voor alles wat je doet een extra vertaal slag nodig hebt voor je het ook echt als instructie naar de processor stuurt. Je hebt dus op zijn minst twee instructies nodig voor iedere instructie die jouw programma uitvoert. Grafische acties vereisen over het algemeen erg veel handelingen, en dus is er bij gebruik van Java redelijk wat overhead door dat je steeds aan het vertalen bent. Nu zijn er natuurlijk slimme Java VM's die zien dat iets erg vaak gebruikt wordt en dan dus gewoon de vertaling onthouden om op die manier sneller te werken maar toch merk je zeker bij grafisch werk dat Java daar niet echt voor bedoelt is.

Er komt ook nog iets anders bij kijken en dat is de economie, als ik namelijk een oude game over kan zetten naar Java en er dan flink aan kan verdienen door het voor alle Java enabled telefoons aan te bieden dan is dat natuurlijk veel goedkoper dan helemaal op nieuw een nieuwe game moeten ontwerpen. Omdat oude games vaak voor lage resoluties en beperkte aantallen kleuren gechreven zijn is het heel makelijk om zo iets over te zetten naar een flink aantal telefoons omdat veel van die dingen of wel maar 16 kleuren kunnen weergeven of wel niet meer dan 320x240 pixels kunnen tonen etc. iets waar oude games bij uitstek geschikt voor zijn.

Natuurlijk is dit alles een wat simpele uitleg van een veel complexer geheel maar je krijgt wel een beetje een idee waarom mensen als John Carmack het zo leuk vinden om voor een iPhone te ontwikkelen. (het nostalgisch gehalte van op zo een manier code schrijven is erg groot)

[Verwijderd]

Wat een verschil zou kunnen zijn is dat men vroeger gebruik maakte van raycasting om '3d' omgevingen op het scherm te toveren, in tegenstelling tot de libraries zoals opengl wat nu gebruikt is.

Raycasting is gewoon een zeer beperkte en relatief simpele methode om '3d' te suggereren, en voor Opengl en allerlei andere 3d bibliotheken bestonden, gebruikten spelletjesontwikkelaars allemaal hun eigen supergeoptimaliseerde methodes om hun 3d spelletjes te maken.

Verder is het ARM type processor naar mijn weten een behoorlijk snelle RISC processor.
(Welke onder andere met meer dan 2 argumenten per instructie kan werken, tov andere RISC processoren) Of verder CISC (x86) sneller/efficienter is durf ik niet te zeggen... Maar het komt er op neer dat RISC processoren gewoon vaak 1 simpele instructie per klok uit kunnen voeren, en dat CISC processoren vaker 1 complexe instructie uitvoeren over meerdere klokpulsen... (welke dan sneller is weet ik ook niet )

Maargoed, ik ben duidelijk een geval van klok zonder klepel...
We kunnen beter wachten tot .oisyn ofzo hier langskomt

[Reactie gewijzigd door Verwijderd op 25 juli 2024 21:44]

[kalizec]

Eigenlijk wel maf dat een spel dat het op een 16 MHz 286 met 2 MB RAM zonder enige 3D hardware goed deed, daar nu een 620 MHz ARM met 128 MB RAM voor nodig heeft. Is x86 werkelijk zoveel efficienter?

Nee, x86 is niet zo extreem veel efficiënter. Maar de engine doet nu veel meer. De originele engine was een 2D-raytracer met sprites engine. En de versie van nu is een volledige 3D-engine op basis van OpenGL.

[.oisyn]

Raycaster. Er wordt maar 1 ray afgeschoten per verticale beeldlijn, en de afstand tot de geraakte muur bepaalt de hoogte van de te tekenen lijn. Vandaar dat je ook niet naar boven en naar beneden kunt kijken. Ik gebruik hetzelfde principe in m'n Javascript implementatie van wolf3d, alleen dan ipv zelf een lijn te tekenen manipuleer ik de DOM om een slice van een image te laten zien. Werkt ook op de iPhone geloof ik, maar helaas heb je geen toetsenbord om te gebruiken

[noes]

Gaaf JavaScript ding! Jammer dat er geen enemies zijn , hoewel die met slechts een paar FPSjes nogal lastig zullen zijn.

[Neko Koneko]

Hij is heel traag hier, 2.45 FPS IE probleem neem ik aan? Aangezien IE + Javascript =

[cmegens]

boven de 60 fps in Safari 4....

[Verwijderd]

Nou, je had toch echt wel een stevige 486 nodig voor Wolfenstein! Op een 286 zou het beslist niet lopen. Volgens mij is Wolfenstein overigens een 32 bit applicatie (kent iemand DOS4GW nog?) en 32 bits applicaties doen het zowieso niet op een 286. Overigens kan Quake ook op veel Linux embedded devices met een ARM of MIPS processor draaien. Dus zo bijzonder is het nu ook weer niet.

[beantherio]

Je verwart denk ik Wolfenstein 3D met DOOM. Wolfenstein was een 16 bits spel dat uitstekend draaide op een 286. DOOM was wel 32 bits en draaide inderdaad niet op een 286.

[Neko Koneko]

Doom was een Dos applicatie, dus gewoon 16-bits. Klasgenoot van me draaide het op een 286. Liep voor geen meter, maar het liep wel

[SCRAP]

Het draaide anders soepel op een Headstart (V&D) 286 met VGA. Net zo goed als op een 386. Qua framerate maakte het allemaal niet zoveel uit, het draaide gewoon prima op een 286 16mhz.

[Tsurany]

Neem aan dat dit een easy cash is? Want het is basicly het spel direct omgooien. Neem aan dat de iPhone krachtig genoeg is om hem met veel betere graphics te draaien, veel betere AI en veel meer mogelijkheden maar dat ze gewoon geen zin hebben het spel opnieuw te maken. Stukje nostalgie ook.

[Dreamvoid]

Tsja, vergelijk het eens met de spellen die je op een x86 PC met deze specs (600 MHz, 128 MB RAM) vloeiend kan spelen - ik bedoel, Doom wtf? Waarom is er geen Quake 3 Arena (>233 MHz, 64 MB) voor de iPhone (of voor mijn part N96/TouchHD/etc, voordat de Apple fans zich beledigd voelen)?

- snoept het OS zoveel overhead?
- is ARM klok-voor-klok dramatisch langzamer?
- kan er na 25 jaar ARM nog steeds niemand efficiente code op dat platform schrijven?

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 21:44]

[mor0n]

Q3 draait ook prima op de iPhone, dat zei Mac Cormack zelf. Hij moest alleen wel veel werk steken in de render engine. Hij wou eerst de classics uitbrengen. Doom komt binnenkort ook op de iPhone.

[kozue]

dat zei Mac Cormack zelf

Dat zei wie...? Bedoel je misschien John Carmack?

[svenk91]

Kan wel, maar dan moet je het spel helemaal opnieuw schrijven. Nu werkt die waarschijnlijk gewoon soepel op de Iphone met rommelige codes en textures enzo van vroeger (zou veel efficienter kunnen). Wolvenstein is dan ook niet de topgame op de Iphone (zie brothers of arms eens, dat kon echt niet op een 286 zonder 3D acceleratie) maar gewoon een port van een oude game.

[PolarBear]

Ik durf te wedden dat eerder oude games effiecienter (of beter optimaler) geprogrammeerd zijn dan nieuwe. Vroeger konden bepaalde microoptimalisaties een hoop schelen, tegenwoordig maakt het allemaal weinig uit.

[Vytek]

True voor pc games (alhoewel ik vermoed dat performance bij engine bouwers nog steeds prioriteit nummer één is) maar ik denk dat games ontwikkelaar voor de nieuwe handheld devices terug erg met microoptimalisaties bezig zijn...

[kozue]

Die optimalisaties waren vaak genoeg alleen geschikt voor x86, en heb je niks meer aan als je het naar de iPhone port. Quake 3 daarentegen draait al op zowat alles, aangezien open source developers ermee aan de slag zijn gegaan, en is waarschijnlijk een stuk simpeler te porten. Ik neem tenminste aan dat de iPhone OpenGL ondersteund?

[Verwijderd]

Ik heb pas onze oude 286 eens geïnspecteerd.... volgens mij was 3D acceleratie nog niet echt aanwezig. T bakkie had al moeite zat met 2D beelden....tel daar CGA, EGA of als je echt een monster had VGA bij op.... denk dat je t beestje echt vleit door 3D acceleratie als mogelijkheid te vernoemen!

[AlBundy]

Elke 286 die ik heb gehad, had VGA. Een 286 met CGA/EGA was een zeldzaamheid hoor
Dat was anders voor (8086/8088) XT's, waar voor zover ik weet nooit VGA-graphics voor beschikbaar zijn geweest.

[brama]

Er waren 8-bit ISA VGA-kaarten, die kon je ook in een XT stoppen. Maar dat zullen er niet veel gedaan hebben. Dat was toen ongeveer vergelijkbaar met nu een supersnelle nvidia/ati kaart in een oude P3 stoppen.

[hiostu]

Er staat op internet ergens een versie van Quake 3 die geschikt is voor Windows Mobile telefoons. Werkt ook met 3d acceleratie op sommige telefoons. Moet je wel zelf de game files hebben. Het kan dus wel.

[Amanoo]

Misschien is die wat efficienter geschreven.
Hij geeft zelf al aan dat hij haastig en rommelig te werk heeft gegaan.
Maar het werkt, en dat is het belangrijkste.

[Verwijderd]

Ik heb ooit een Java applet van Quake geinstalleerd op m'n E51 maar die gaf alleen foutmeldingen. Doom loopt er trouwens wel op.

[kdhoe]

Quake 3 draait op mijn iPhone en deze draait zelfs heel vlot. Je kan em downloaden via cydia in de xsellize repo.

[cmegens]

Waar staat dat het een directe port is van de oude Dos game?

Er staat dat ie begonnen is met de Wolf 3D Redux code die openGL ondersteunt, en vanaf daar verder is gaan bouwen. Dus niet een port, maar een nieuwe game.

[isama]

nee, het is een port van een mod van de oude dos game

[Robkazoe]

Misschien dat de iPhone een speciale module/software package bevat die OpenGL applicaties kan poorten of emuleren naar de iPhone? Het emuleren van software is nooit efficiënt dus zou dat een verklaring kunnen zijn.

Daarnaast haalt dit spel natuurlijk niet alles uit een iPhone. Als je kijkt naar Moneyball dan is dat wel duidelijk. Spel ziet er veel beter uit en is gewoon van regel 1 geschreven voor de iPhone. Carmack heeft voor Wolfenstein gebruik gemaakt van al bestaande code.

[spNk]

Heb jij ooit ngage games gezien? Die zijn echt wel mooi hoor, stukken mooier als mogelijk was op een 2/3/486.

Klein voorbeeldje:
http://www.goldfries.com/...esat/nokiangage/ngage.jpg

[Verwijderd]

Zelfs het goedkoopste Nokia instappertje vliegt qua rauwe snelheid rondjes om zo'n 286 heen, maar toch zijn de spellen op die dingen veel primitiever qua graphics/snelheid.

Ik herinner me anders nog Prince of Persia, de eerste uit de serie, die onder DOS op een 286 draaide. Die draait nu als Java applet op zo'n beetje elke Nokia die Java ondersteund, iig al op mijn oude 6610.

[Verwijderd]

Die draaide al soepel op een 8086 met hercules hoor(al weet ik niet zeker of dat met of zonder CGA emulator was.

[Upquark]

Eigenlijk wel maf dat een spel dat het op een 16 MHz 286 met 2 MB RAM zonder enige 3D hardware goed deed, daar nu een 620 MHz ARM met 128 MB RAM voor nodig heeft. Is x86 werkelijk zoveel efficienter?

Ho, ho... de minimale specs voor Doom waren echt wel wat zwaarder dan dat hoor!

Volgens mij draaide Doom niet eens op een 286, en kon je het eigenlijk met een 486 pas echt lekker draaien. Ook niet zo gek voor een spel dat in 1993 uitkwam...

[ThunderStrike]

Dit topic gaat niet over Doom, dit gaat over Wolf3D en dat kon op een 'hele snelle' 286 of iedere willekeurige 386 gespeeld worden. Deze specs kloppen dus wel voor Wolfenstein 3D.

Doom, wat ook geport is voor veel platformen, speelt inderdaad pas goed op een 386 DX 33Mhz of SX 40 Mhz of hoger (486 enzo). Ook moest je meen ik minimaal 4 MB hebben voor Doom.

[Upquark]

Argh, volgens mij moest ik eerder naar bed gisteravond...

[Verwijderd]

Dude, t was net 23.00 geweest....

[Neko Koneko]

Ik heb het destijds gespeeld op een 386 SX 25 mhz Liep voor geen meter, maar met F5 kon je het detail verlagen waardoor het toch nog redelijk speelbaar was (al waren de monsters onherkenbare pixelbreien geworden).

[gekko90]

Simpel weg door dat een 286 een X86 cpu is en de cpu's van een telefoon ARM cputjes zijn.

en de instuctie set van een ARM verschilt te veel van de instructie set van een 286

maar idd als er superpi voor een goedkoope Nokia bestaat dan heeft de nokia zeker sneller de PI tot bv 1M berekent

[3phemeral]

De system requirements die je noemt zitten niet ver af van de werkelijke requirements. Je hebt een 33MHz 386 nodig, en maar 640K RAM:

Van de officiele Wolfenstein 3D website:

• IBM-PC and Compatibles
• MS-DOS(R) 5.0 or higher
• 640K RAM
• 3 MB available Hard Disk Space
• 386/33 MHz Processor
• VGA graphics
• Joystick and mouse optional
• Supports Sound Blaster and 100% compatible sound cards

Je kan het spel verder ook nog altijd kopen (als download) voor PC; het kost nu $15!


edit:
(bovengenoemde specs spreken de release note wel wat tegen [behalve als het enkel gaat over de machine waarop de code oorspronkelijk geschreven was]:

The original Wolfenstein 3D code was written in late 1991 / early
1992 using 16 bit Turbo C and the TASM assembler and targeted at 286
based MSDOS systems with VGA graphics and ideally a bit of extended
or expanded memory

)

[Reactie gewijzigd door 3phemeral op 25 juli 2024 21:44]

[dinoballz]

Er staat toch nergens dat ie alles eruit haalt.
Als je Tetris of Pong er opzet haalt ie toch ook niet alles eruit

[Yoozer]

Zelfs het goedkoopste Nokia instappertje vliegt qua rauwe snelheid rondjes om zo'n 286 heen, maar toch zijn de spellen op die dingen veel primitiever qua graphics/snelheid. Kan een game dev me dat eens uitleggen?

Kleine schermpjes maken complexe spellen waar detail belangrijk is niet prettig. Ik noem een Dune II - complexer, maar probeer jij maar eens op zo'n priegelscherm worm alerts te zien. Voeg daar nog eens bediening aan toe - je telefoon heeft geen muis en bij touch-screens blokkeer je het scherm met je vingers - en dan snap je waarom dat het bij Break-Out kloontjes blijft.

[Starr0w]

Het spel is nu inderdaad verkrijgbaar via de appstore en kost €3,99... Published 23/03...

[NTAuthority]

"Hij wil de code echter toch onder GPL vrijgeven, zodat anderen van de opgedane kennis kunnen profiteren."

Als de originele broncode onder de GPL vrijgegeven is, zal elke aanpassing ook onder deze licentie vrijgegeven moeten worden. Verder meende ik ooit gelezen te hebben dat de App Store het officieel gezien verbiedt applicatiebroncode openbaar te maken, maar die bron kan het fout hebben.

[Neko Koneko]

Is dat niet alleen als een ander persoon of bedrijf de broncode oppakt, aanpast en opnieuw als programma uitbrengt? In dit geval is het Carmack's eigen werk, lijkt me dat hij, ongeacht wat de GPL zegt, zelf mag weten of hij eventuele aanpassingen vrijgeeft.

Maar goed, ik weet ook niet precies wat de GPL zegt, maar als de GPL van de orginele auteur van de software eist dat hij alle aanpassingen aan de code vrijgeeft, vind ik het een hele nare, dwingende licentie waar ik zelf nooit iets mee zou doen als ik software ontwikkelaar was Zo van, je zit er voor je leven (of voor de bestaansperiode van je applicatie) voorgoed aan vast.

edit: voordat mensen dit weg gaan modden omdat ik de GPL aan zou vallen, ik wil hem niet aanvallen oid maar ik vind het nogal onbegrijpelijk dat een eigenaar van een bepaalde broncode niet zelf mag kiezen wat hij ermee doet - misschien kan iemand dit voor mij opklaren?

[Reactie gewijzigd door Neko Koneko op 25 juli 2024 21:44]

[NTAuthority]

De broncode van het originele Wolfenstein is wel van John zelf, en daar mag hij verder mee doen wat hij zelf wil. Mijn bericht gaat juist over de aanpassingen voor gebruik met OpenGL, die niet door hemzelf gemaakt zijn. Uiteindelijk zul je, zonder toestemming van de schrijvers van die code, de code (inclusief binaire objectcode) niet verder kunnen distribueren buiten de termen van de GPL om.

[Neko Koneko]

Dus je doelt niet op de code van John, maar de code die andere mensen onder GPL hebben toegevoegd/aangepast. Dat had ik aanvankelijk niet begrepen, en nu klinkt de GPL ook weer een stuk logischer Bedankt

[Thomix]

Hij had wel wat tips voor verbetering, maar toen de programmeurs van EA aangaven dat het hen twee maanden zou kosten om die door te voeren, nam Carmack het programmeerwerk zelf op zich, om de klus vervolgens in zijn eentje in vier dagen te klaren

Dit geeft heel mooi aan wat 1. John Carmack voor een gigantische held is en 2. wat de competenties van EA zijn.

[bolleh]

Mwah, niet zozeer de competenties van EA. Carmack is sociaal gezien slecht maar in andere dingen is hij een genie. En daar bovenop heeft hij ook nog eens de toewijding aan het programmeren om dat te versterken. Dat is iemand die alles wat hij doet met absolute overtuiging doet, althans als het zijn eigen idee is

[Garma]

I sent an email to the Wolf 3D Redux project maintainer to see if he might be interested in working on an iPhone project with us, but it had been over a year since the last update, and he must have moved on to other things

are you kidding me?? John carmac emailt je en je antwoord niet? wat een gast!

[HitDyl]

"Het spel zou volgens de bijbehorende website al in de AppStore aanwezig moeten zijn, maar is daar in werkelijkheid nog niet te vinden, wat het ook onduidelijk maakt wat het spel gaat kosten. Carmack heeft al wel de broncode van de nieuwe versie vrijgegeven"

Het lijk me dat het spel gratis is anders ga je er ook geen broncode van uitgeven

[Blonde Tux]

Dat hoeft niet, er zijn zat progsels die opensource zijn waar je toch voor moet betalen.

Het is jammer om te zien dat veel mensen als ze het woord (acroniem)GPL of Opensource zien staan het meteen gaan associëren met gratis.

Tuurlijk ik weet ook wel dat het het eerder regel dan uitzondering is dat veel GPL/Opensource software gratis is maar dat hoeft niet zo te zijn. Veel Opensource licenties geven de mogelijkheid om geld te verdienen met je code, zodat het niet helemaal vrijwilligerswerk hoeft te blijven.

GPL
BSD licentie

Zo kan ik nog wel door gaan met de licenties, waarmee je toch geld kan krijgen voor je werk maar toch opensource is.

[Amanoo]

Het komt gewoon erg vaak voor dat open source wél gratis is.
Bijna altijd als ik naar een open source programma zoek ergens voor is het eerste (en het tweede zelfs ook) dat ik vind gratis.

[The Zep Man]

Het komt gewoon erg vaak voor dat open source wél gratis is.
Bijna altijd als ik naar een open source programma zoek ergens voor is het eerste (en het tweede zelfs ook) dat ik vind gratis.

Bijna altijd != altijd. Zo heb je XChat, een open-source IRC programma. Toch moet je voor de pre-compiled Windows binaries betalen na 30 dagen shareware gebruik.

Ook is het mogelijk om een programma te verkopen onder (bijvoorbeeld) de GPL licentie. Programma A is uitgegeven onder de GPL. Ik gebruik de broncode van Programma A om Programma B te ontwikkelen. Programma B is dan prima te verkopen aan iemand anders, mits de GPL maar gerespecteerd wordt (lever de broncode mee en plaats geen restricties op het gebruik/verspreiding).

Vrije software != Gratis software. In de Nederlandse taal is het verschil aan te tonen dankzij twee verschillende woorden. In het Engels wordt er vaak gepraat over "free as in free speech" voor vrije software en "free as in free beer" voor gratis software.

Vrije software kan gratis zijn. Gratis software kan vrij zijn. Maar dit hoeft niet in beide gevallen.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 21:44]

[Verwijderd]

Bijna altijd != altijd. Zo heb je XChat, een open-source IRC programma. Toch moet je voor de pre-compiled Windows binaries betalen na 30 dagen shareware gebruik.

En als ik zelf de sources door een compiler jaag kost het me dus niks. Of is dat zo'n project dat onder windows 50 pagina's met instructies nodig heeft hoe je het moet compileren?

[Antipater]

Je hebt gelijk, maar dat is natuurlijk vooral juridisch en niet erg praktisch. Als je verplicht bent de broncode vrij (en gratis!) te verspreiden, kan iedereen je programma voor gratis compileren en gebruiken of verder verspreiden. Ik zou zomaar een gratis XChat binary voor windows kunnen aanbieden zonder daarmee enige wet te schenden.

Wat games betreft vallen de graphics en geluidsbestanden niet onder GPL, dus dat is makkelijker te verkopen. Zonder die media files heb je vrij weinig aan de code. Op de meeste GPL software wordt echter verdient door support, of als onderdeel van hardware (TomTom).

[Neko Koneko]

Er zijn ook gratis pre-compiled versies van Xchat te vinden. Weet zo even de naam niet meer, maar heb er ooit een gehad

[weeraanmelden]

correct. Water is ook open source...
Water kost ook niets,0,0002 cent de liter of zo, maar als je geld in marketing en verpakking stopt, mag je het ook voor 1 euro de liter verkopen...

[svenk91]

Er zijn geen compilers voor de code, zonder jailbreak is er geen manier om eigen gemaakt spul op de iphone/ipod touch te zetten. Dus kunnen ze er zekers te weten geld voor vragen lijkt me.

[sorted.bits]

Ik ga er van uit dat het Cocoa code, is welke elke developer op zijn Mac kan compilen en daarna op zijn iPhone kan zetten.

Zeer handig, alleen die FTP is overvol...

[I386DX]

Ik vermoed dat het is zoals alle andere ID-titels waarvan de source al openbaar is gemaakt.

De broncode is vrijgegeven, de data van het spel (maps, textures ed) niet...

[svenk91]

Vind ik wel netjes. Hoef je het spel maar 1 malig te kopen en kan je het op praktisch elk beetje krachtig en populair apparaat gebruiken. Beter dan dat je moet betalen voor elke heruitbrenging.

[Reactie gewijzigd door svenk91 op 25 juli 2024 21:44]

[FitTiv]

De programmeur meldt er echter ook bij dat de code alleen interessant is voor iPhone-ontwikkelaars en dat er geen compilers vrij beschikbaar zijn waarmee het omgezet kan worden in een werkende game.

Dus code vrijgeven =/= gratis spelletjes spelen

[Verwijderd]

Maar de chipset die in de iphone gebruikt wordt, zit in héél veel smartphones, dus er zal vast wel wat bruikbaar zijn, in de meeste duurdere smartphones zitten ook chipsets met een bak meer performance maar ook weer een vier tot zes keer hogere resolutie, dus ben benieuwd hoe 't daarop gaat draaien.

[Database freak]

toen de programmeurs van EA aangaven dat het hen twee maanden zou kosten om die door te voeren, nam Carmack het programmeerwerk zelf op zich, om de klus vervolgens in zijn eentje in vier dagen te klaren

Om gelijk maar even het niveau van EA-programmeurs aan te geven.

[Bert2000]

Bij EA zitten ze vast aan planning, procedures etc. Dit is noodzakelijk gezien de omvang van het bedrijf, dat carmack het in zn eentje ff fixed omdat ie toevallig veel vrije tijd heeft, zegt niets over EA.

Net alsof de EA programmers 2 volle maanden eraan zouden moeten werken, volgens mij zouden ze het pas over 2 maanden af kunnen hebben. Wat niet zegt dat ze dan ook 2 maanden full time ervoor over hebben.

[Stijn]

Of het niveau van John Carmack natuurlijk, die heeft z'n sporen ook wel verdiend ondertussen

[Verwijderd]

Dat krijg je in een groot bedrijf: procedures, vergaderen, afstemmen, toestemming vragen. En dan maar klagen dat de productiviteit zo laag is.

[josttie]

het is wel leuk, dat de bakbeesten van toen nu al voorbij worden gestreefd door een telefoon =)

[Neko Koneko]

Ik was laatst in het Science Museum in London, en daar stonden echt van die gigantische computers die een hele kamer vullen. Stond ik een foto te nemen met mijn mobieltje, dacht ik opeens aan het feit dat mijn mobieltje waarschijnlijk krachtiger is dan die rekenmonsters waarvan ik foto's stond te nemen

[SuperNull]

Het aantal FLOPS/Watt (ranzige maatstaf, ik weet het) blijft toenemen ja. De grote vraag is wanneer die toename stopt.
Wat games betreft zie je tegenwoordig steeds vaker dat meer processor kracht helemaal niet betekend dat de games ook leuker zijn om te spelen.
Herspeel Quake1 met de Darkplaces engine maar eens bij voorbeeld.
Draait als een trein op een oudere Intel grahics laptop en is ook leuker dan een heel aantal nieuwere FPS games imho.

[- peter -]

Mooi verhaal dat van Carmack. Leuk om zo je in te kunnen leven in wat die man allemaal doet.

[zanza006]

Mooi ideaal voor research