John Carmacks erfaringer med mobiltelefoner

Nææ Java og begrænsede ressourcer hører ikke rigtig sammen, men nu er Carmack jo også vant til at skrive low-level C og ASM til sine grafik motorer så det er lidt at sammenligne æbler og pærer.

Hans artikel bærer tydeligt præg af at han ikke har erfaring i udvikling til begrænsede platforme. Tæt på alle hans argumenter viser tydeligt han er C/asm udvikler.

J2ME er en glimrende platform til udvikling af applikationer til mobiltelefoner.

Hvis man tager en hardcode embeddet udvikler og beder ham/hende skrive en application til en multiprocessort server med 1 TB ram, kommer der nok også argumenter og alt muligt nonsens.

Disky: Du er ekstrem farvet når du udfolder dig på newz.dk. Ja, Java har nogle fordele - men det har også en lang række ulemper. Én af disse ulemper er at man ikke har mulighed for at optimere på low-level niveau, som f.eks. kan være ønskeligt i forbindelse med spil-programmering.

Én fordel er tilgengæld at man er sikker på at de programmer og spil der bliver sendt ud i mobiltelefonerne ikke smadrer hukommelsen i telefonen eller andre mystiske ting.

#1
Det er ikke rigtigt at man ikke kan bruge java på platforme med begrænsede ressourcer. Det har man gjort længe. MEN du har også ret i at en programmør som Carmack skal man nok ikke tage alt for seriøst når han pludselig udtaler sig om noget han kun har leget med i en månedstid. Frem for folk der arberjder med det til daglig.

#2
Jeps... Kernekompetencer :-D det gælder også for alm. folk og ikke kun virksomheder :-D

3#
Nu er Java jo et Høj niveau sprog så det er naturligt at man ikke kan optimere på lavt niveau. Du kan dog finde kompilere der laver en del optimering for dig.

#3

Som #4 siger, java er et højniveau sprog, ikke noget man laver low level optimering i.

Netop dette gør java brugbart i mobiltelefoner, hvor man som du sjovt nok selv nævner, ikke vil risikere telefonen ødelægger memory osv.

Det er et kompromis imellem sikkerhed og hastighed.

p.s. Hvis der er en person der er farvet, så er det JC.

#4 Når jeg referer til "begrænsede ressourcer" er det fordi Java med dens garbage collector typisk vil bruge 20-25% af ressourcerne til denne non-deterministiske process, samtidig med at Java's native event-drevne paradigme i sig selv koster mere end et typisk C message loop/dispatch (som Carmack er vant til). Java løser jo så nogle andre ting tilgængæld...

Hvis man begynder på den slags ASM kodning, så mister man ligesom også platforms uafhængigheden.

Jeg må dog indrømme at jeg ikke ser så meget platforms uafhængighed på de spil der udvikles til mobiltelefoner. Men igen kan man også se en stor forvirring på området på java.sun.com 's hjemmeside.

Jeg vil nu stadig holde på at han burde have kastet sig over Symbian i stedet - Java er sgu ikke lige der vildeste til mobilen, de spil jeg har haft i java på mobilen har ikke været meget værd, men jeg har været meget imponeret over symbian spillene - hvis nogen er i tvivl så hent SPmark04 ned på mobilen og i skal se fed grafik!!!!

Men selvfølgelig, java er platformsuafhægigt... Men jeg tror nu ikke det ville være noget større problem at lave spil som blev udgivet til de mest populære platforme, dvs. Symbian, Windows Mobile, Nokias eget system, SE's eget system, Samsungs eget system osv.

Problemmet med J2ME's platformsuafhængighed er at mange programmører ønsker funktionalitet der ikke er fastlagt en standard for.

Det har tidligere været 3d grafik, SMS/MMS afsendelse/modtagelse osv. Så derfor kan det være nødvendigt at lave properitære ting, følger man dog standarden virker det også på telefoner der understøtter standarden.

amokk:
Problemmer er man så skal udvikle til 17 forskellige systemmer istedet for 1.

Og Java er nu engang mest udbredt til sådanne enheder også PDA'ere osv.

#6: buzzword overflow.

#8: Ja, Symbian OS giver i hvert fald lov til at udvikle i C++ og benytte diverse low-level features.

#9: Problemet med Java er at det ikke er platformsuafhængigt. Java er netop afhængig af én bestemt platform - nemlig en JVM*. At denne type virtuelle maskiner så er relativ udbredt har ikke noget med platformsuafhængighed at gøre.

* Ja, jeg ved godt der findes enkelte CPU'er der kan eksekvere Java Byte Code.

Det er måske lidt en overdrivelse at Java performance på mobiltelefoner svarer til en 20 år gammel PC, men Java er altså noget langsommere når det ikke er JIT'et. I et vist omfang kan man slippe omkring den slags, men hvis JC sidder og skriver per-pixel rendering i Java, så kan jeg godt forstå at det bliver noget ged.

Det er rigtigt at netværks-latency er skidt. Svjv kan man vist ikke regne med andet end 0,1 s - 5 s over gprs (dårlig basis ping + mega jitter).

#2 disky.

Din post bærer tydeligt præg af at du ikke har erfaring i udvikling af grafik motore. Din kommentar " J2ME er en glimrende platform til udvikling af applikationer til mobiltelefoner. ", viser stort mangel på arugmenter for at J2ME skulle kunne bruges til at kode en grafik motor som JC's post handler om !

Hvis man tager en nørdet Disky skrive en grafik motor til en Pc x86-IA32 windows platform, kommer der nok også argumenter og alt muligt nonsens.

// dette skal ikke tages som flame bait, men mere fordi normalt så virker det som om du ved hvad du snakker om og denne gang træder du bare så langt ved siden af, og selv om der er gået en del timer så har du på ingen måde opdaget din fejl, Carmack skriver ikke applikationer, men SPIL engines. er der forskel på lysbilleder og spille film hmm tja det tror jeg nok. //

ovenstående kommentar er ikke kun rettet mod disky, men alle som skriver at J2me er anvendeligt til spil, tja enda java er ikke anvendeligt. ( kun på PC hvis der er embedded andre stumper af compilet kode som IKKE er java. )


det er da lidt sjovt at man kan afvikle programmer på en mobil telefon, men som telefonerne er nu skal man ikke lave grafiske spil til dem, det er de ALT for langsomme til. J2ME er fint nok til programmer og ja vi kan sikkert alle sammen lave en lommeregner eller ligende hello world applikationer som kan afvikles på vores små telefoner. men spille spil som ikke er tekst baseret eller med extremt ringe slide show grafik, det skal vi desvære vente noget tid med endnu.

java er sikkert godt, jeg kender bare ingen som syntes det er godt til andet en til "simple" programmer. det virker fint som web applikationer der kan slå op i en stor sql eller anden database, men bruges til grafiske programmer STOP DET..

Prøv bare at hente og installere sun's java på jeres 3.X Ghz maskiner og prøv det lille program som kan teste om java virker som det skal. de små programmer som findes der i viser grafiske ting, som er fede nok ( hvis man ikke forventer mere end da man legede med sin windows 3.1 på en 33 Mhz 486 ) maskine...

Jeg tror at i siger java er fedt fordi det er det i kender som sejt eller det eneste lort i kan kaste en klam web applikation sammen i. John carmack ( JC ) laver ikke applikationer han udvikler engines til at underholde med grafik og lyd, det kan man ikke bruge java til på en mobil telefon fordi der er så latterligt mange latency's i de Java VM's som de små telefoner bruger.

JC siger jo ikke noget om at det ikke kan lade sig gøre at lave fine applikationer til en telefon, han snakker om at lave et stykke spille software som vil være toppen for mobil telefon games, ganske som resten de game engines han har kodet på til PC. manden er ikke helt som os andre.

så det er ekstremt latterligt at skrive han ikke ved en skid om j2me manden er ikke palle almindelig til at kode han har levet af det i MANGE år. kan nogen af jer huske commander keen ???.

Hvis du vil lave en game engine har man behov for at kontrollere hardwaren med så små latencys at det kan lade sig gøre real time ellers er det jo ikke et interaktivt spil, så vil det mere blive en interaktiv vente psykose og hvor fedt er det ?.

Well var det min rant for nu..

Jeg syntes det mest sjove er at 4 telefoner = 4 forskellige j2me. Det er da noget gøjl. Troede en standard var en standard.

Men jo, Java er godt til mange ting, spil med heftig 3D grafik er bare ikke et af dem endnu. Jeg tror nu heller ikke JC havde forventet Doom3 grafik på en Mobilos.

#14 Svjv, så er der kun små fortolkningsspørgsmål i standarderne, men det her CLDC (Connected Limited Device Configuration) og MIDP (Mobile Information Device Profile) er en slags laveste fællesnævner for J2ME på mobiltelefoner.

MIDP 1.0 er noget indskrænket og derfor findes der en bunke JSR'er (f.eks. JSR184 Mobile 3D Graphics API for J2ME) som giver mere funktionalitet. Om den slags er implementeret er dog helt produktspecifikt.

Derudover er der varierende performance og eksekveringsmiljø. Der er jo typisk ikke en JIT-compiler på mobile enheder, men enten en ren fortolker eller noget lidt bedre.

Macaw:
Ud fra din definition af platformsuafhængighed, eksisterer der ikke sprog eller lignende som er platformsuafhængigt.

faetteren:
Har du nogensinde prøvet spillet 'Munkiki' på en Nokia 3410 det er med som standard. Spillet er lavet i Java og er 3d grafik, selvfølgelig ikke på Half Life 2 niveau, men stadigvæk 3d og det kan spilles, til tider lidt langsomt men det er ikke java's skyld men derimod den langsomme CPU der sidder i 3410'eren, samt måden LCD'en tilgåes på.

Husk vi taler om mobiltelefoner ikke om spille maskiner.

Problemmet med JC og øjensynligt også dig, er at i forventer en mobiltelefon er en 3.4 GHz P4 HT computer med 2 stk. GFX kort i SLI mode.

Men det hele afhænger selvfølgelig af ens forventninger til hardware/software.

#16 jeg vil ik kalde munkiki islands for 3d grafik.... Nogle monokrome billeder af nogle plettede firkanter som ændrer form, er altså ikke direkte 3D, jeg tvivler på spillet er udviklet med en egentlig 3d engine...

Men hvis i vil se flot 3D så prøv en nokia fx. 6600 med symbian, og spillet Rally Pro eller bare en SPmark04...

amokk:
Tro mig Munkiki er lavet i java og det bruger en 3d engine, der følger opengl standarden.

disky: hvem siger der findes noget der er platformsuafhængigt?

I store træk er jeg enig med fætteren og vil knytte en kommentar til disky: Lad være med at debatere alting som om du altid har ret og ved alt. Java er ikke platformsuafhængig, men er porteret til mange platforme (her i ligger en ikke skjult sandhed).

J2ME er efter min bedste overbevisning langt fra hvad det skulle have været.

Man kunne pege fingre af mobiltelefon producenterne, og formedelest Nokia og Siemens - og nu også Sony Ericsson - men det tjener ingen formål.

Fakta er blot at vi står og ser på at den såkaldte cross platform er fordærvet i og med de respektive mobilproducenter laver hver deres "ekstra instruktioner" man kan køre op imod, og selvom dette i første omgang kan gøre det lettere, så skaber det kæmpe problemer mht. kompatibilitet.

Den ENESTE humpel der kan undskyldes er skærmstørrelse.


Der burde være regler mht. regnekraft for MIDLET-versionerne, det ville i alle tilfælde gøre det lettere både for udviklere og købere/brugere. Udviklerne kan i dag udvikle efter strict Midlet 1.0 eller 2.0 - fint nok. Men man kan også udvikle dedikeret, som man ser mange gør til Nokia serie 40 og serie 60. Og så går det jo galt når man sidder med sin Sony Ericsson mobiltelefon...


Jeg har stor respekt for John Carmack, og synes han har fat i rigtigt mange gode ting i sin artikel. Man kan kun bede en stille bøn til at han bliver hørt, men desværre taler penge højere end eksperter nu om dage. Og indtil nogen kommer op med gode og holdbare argumenter for hvorfor det skulle være en bedre forretning hvis alle telefoner J2ME-telefoner var 100% kompatible når det gælder midlets, så vil det blive ved med at gå dårligt.


Symbian er også splittet - mellem series 60 og UIQ -- kun Windows Mobile med sit .NET ser ud til at være crossplatform (for alle mobiltelefoner med Windows Mobile vel at mærke).


En "newcomer" vi endnu ikke har set på det danske marked er Linux - jeg ser frem til at Motorola tør satse på deres Linux-telefoner i Danmark. De er trods alt at finde i Sverige... :)



EDIT:

Mht. tilgængelig processorkraft, så er det latterligt at påstå at det alene skulle skabe den usammenhængende konvergens der i dag eksisterer for midlets. Se eks. på Amiga 500 og de 8 kB demoer man lavede til den i sin tid. Jovist, programmørerne kodede direkte op imod den i assembler, og det fortolkningslag som j2me jo er, eksisterede ikke.

MEN det rører stadigvæk ikke ved at j2me selv i version 2.0 (3D) er mangelfuld på mange punkter.

Et problem er så at i og med man kan række dybere ned i telefonens funktioner så øges risiko'en også for virus.

Alle der har programmeret OpenGL applikationer ved at man selv skal allokere og lukke det segment i RAM'en man vil benytte.

Hovsa, var der nogen der nævnte buffer underrun? Og kender vi det fra PC-verdenen som sikkerhedshul? Yup og yup!


J2ME er et protected runtime environment - det skal man også huske på. Ligesom Macromedia Flash Player skaber et protected runtime environment.

En ting man heller ikke lige sådan kan tage højde for er de services der kører i baggrunden, og den måde de kører på.

En 10 MHz mobiltelefon kan meget vel være langsommere til J2ME end en 6 MHz mobiltelefon.

Min mobiltelefon (SPV C500) har 200 MHz processorkraft, og jeg har endnu ikke prøvet en midlet der fik den til at gå i knæ (end ikke J2ME Midlet 2.0).

Nu om dage kan man faktisk sagtens skabe ÆGTE 3D-spil med teksturer til mobiltelefoner - og jeg hentyder naturligvis ikke til det wanna-be 3D spil der var i Nokia 3410!!


Midlet 2.0 sætter faktisk en række standarder, men hvordan mobilproducenterne så bygger oven på er jo op til den enkelte producent.

macaw:
Nu er det ligesom dig der forsøger at fjerne udtrykket 'platformsuafhængighed' ikke mig.
Så det er nærmere dig der forsøger at få ret hele tiden.

Det er ikke mig der forventer en telefon kan køre en fuld blown 3d engine ligeså godt som en high end PC som JC åbenbart forventer. Jeg forsøger bare at forklare at han er meget biased i sine udtalelser, og kommer med eksempler for at J2ME fint kan bruges til det som det er lavet til + simplere 3d spil.
Du forsøger kun at nedgøre mine postings, uden reele argumenter osv.

Så i stedet for at være efter andre skribenter, skulle du tage og argumentere for dine udtalelser, ellers er de bare tom luft.

p.s. Man kunne tro at du stadigvæk var mobset over noget kritik jeg engang kom med om noget af din kode :-)

På OSnews om samme artikel fandt jeg dette indlæg som meget godt beskriver hvad JC's problem kunne havde været.


I have worked many yeas with Java and C++ on enterprise level projects and am very comfortable in either environment. I recognize Carmack’s frustrations because I ran into the same issues of control (or lack thee of). I was able to overcome these issues by pulling myself out of the C++ paradigm and open myself up to other methodologies. Carmack admits he has not spent much time on Java other then some side projects. He shares the same frustrations that many respectable developers I know had when making the transition to Java (including myself). You can see in his reaction that he is frustrated and not very comfortable with Java. You can also see he tries to solve a Java problem with a C approach. All I’m saying is that if you want to solve the problem using C then take the C approach, if you want to solve it using Java then take the Java approach. Don’t bash a technology just because you can’t make the cube fit in a round hole. You have to go with what you’re comfortable with. Java is a different paradigm then C and for some people it is difficult to make that shift.

The other thing is that the current hardware may not be mature enough yet to support a robust 3D platform. I think it is good that he is testing the limits on this but maybe he should go back to a Commander Keen port until the handsets mature a bit more. Or better yet, why not come up with original game ideas that compliment the platform instead of Doom x, Wolfenstein y, and Quake z. That may save him some frustration and keep him sane enough for his next game.

#21: Jeg tror blot vi holder her, nu hvor du forsøger at køre det over i en traditionel flamewar.

Mit synspunkt om at Java ikke er svaret på alt deler du tydeligvis ikke, omvendt har du ekstremt ved at opfange at andre deler mit synspunkt.

Mht. platformuafhængighed, så er det i visse kredse anerkendt, at der ikke findes noget der reelt er platformuafhængigt - alt skal emuleres i den ene eller anden retning for at kunne eksekveres* og kræver derfor en fortolker. Det svarer lidt til at sige, at emacs lisp er platformuafhængigt i det emacs (emacs lisps fortolker) er porteret til mange platforme.

* Dejlig fordansket ord :-)

macaw:
Du er nu underholdende.

Okay hvor skriver jeg i denne tråd java er svaret på alt, eller hvor har jeg skrevet det i f.eks. de sidste 12 måneder ?

Er det nu jeg skal fortælle dig jeg bruger PHP til webudvikling og C# og vb.net til applikations udvikling ?

Hvor er java der ? Tja faktisk har jeg ikke udviklet i java i over 2 år. Ups det passer vist ikke i din ide.

Det er sjovt at læse nyheden omkring "scorched earth"-spillet, og så se på denne tråd, hvor opfattelsen synes at være at spil ikke er noget værd uden 3d?

Hvis man gav lov til at rode rundt uden for sandkassen ville man hurtigt få et problem med distributionsmulighederne, hvis alle distributører skulle teste i hoved og røv for at være sikre på at en given applikation ikke "ødelagde" noget.
Det er tilfældet med QUALCOMM's BREW. Der kan du bruge C/C++ og assembly, men du kan ikke distribuere gennem andet end QUALCOMM, og som udvikler skal man selv betale for tests, for at bestå kvalitetskravene.

Som Carmack beskriver under udformningen af mobiltelefonen (bl.a knappernes placering), så er det ikke en spillemaskine. Det er et kommunikationsapperat, hvis man vil lave spil til sådan et må man sgu være kreativ nok til at lave et spil, der egner sig til at blive spillet på en mobiltelefon, istedet for f.eks at forsøge at mase en 3d engine ned i den.

(#20 Jeg tror du mener MIDP 2.0?)

#25
Så sandt så sandt :-)