Derfor duer Nvidias Cg ikke

Tjah, det er jo nok som man kunne forvente, Codeplay vurderer at Nvidia's CG vil understøtte features, efterhånden som Nvidia's hardware gør det.

Uden at være den helt store C++ programmør, hvad er der galt med DirectX? Jeg har selv prøvet det lidt, og det så da meget godt ud, men det var ikke særlig nemt (Men det synes jeg sådan set om alt C++ :-).

tja, han har da nogle gode argumenter...

det lidt jeg kan huske fra da jeg programerede er da at jeg var glad for mine break og goto commands... skulle nødigt programmere uden.. (kommer igen an på hvad jeg programmerer)

Ham der har skrevet artiklen er dog ikke helt med på den:

No break, continue, <STRONG>goto</STRONG>, switch, case, default. These are useful features that can be used without penalty on other vector processors.

Der er INGEN grund til nogensinde at bruge en 'goto'. Programmerer man højniveau sprog, er det helt unødvendigt at have en 'goto'

No pointers. This is Cg's most serious omission. Pointers are necessary for storing scene graphs, so this will quickly become a serious omission for vector processors that can store and process the entire scene or even sections of it.

Jeg tror igen ikke manden kender til programmering.
Det er IKKE nødvendigt med pointere, Java klarer sig ganske fint uden, og fordi java ikke har pointere forsvinder der en hel masse chancer for fejl, buffer overrun osv.

Jeg vil dog give manden ret i at man skulle havde bygget videre på et kendt sprog, f.eks. nogle klasser til C++.

#3 Disky:
"Jeg vil dog give manden ret i at man skulle havde bygget videre på et kendt sprog, f.eks. nogle klasser til C++."

Nu er sproget altså bygget på et kendt sprog, nemlig Renderman, modificeret med henblik på real-time-rendering - at bruge et "general purpose language" (GPL??? What the hell???) til noget så specialiceret som pixel- og vertex-shaders er lidt som at bruge en traktor til at køre til Tyskland for at handle lidt ind. Det virker sikkert ganske fint, men det er ikke specielt handy.

"Jeg tror igen ikke manden kender til programmering.
Det er IKKE nødvendigt med pointere, Java klarer sig ganske fint uden, og fordi java ikke har pointere forsvinder der en hel masse chancer for fejl, buffer overrun osv."

Java udmærker sig også med en tragisk performance og en komplet manglende egenskab til at fungere på low-level niveau og er 100% uegenet til at kode moderne 3d spil i. Pointers er absolut ikke ligegyldige - de giver betydelige performance fordele samt muligheder for at tilgå resourcer man ikke kan tilgå gennem sprog som java.

well.. som sagt programørende som er med på vores spil project er som sagt glade for det... Så tror enligt det er en smags sag

Regus:
Åh nej ikke igen.
En der udtaler sig om java fordi han/hun engang lavede en applet i jdk1.1 og forresten mangler helt kendskab til sproget.

Performance i Jdk1.4 er meget tæt på C++ hastighed.
Selvfølgelig når man aldrig helt derop men det er meget tæt på.

Jeg er imponeret over dit kendskab til Java og low level ting, jeg kan fortælle dig jeg til dagligt roder med Java programmering i embeddet devices, tro mig jeg har fat i hardwaren uden problemmer.

Pointere kan være en smart ting, desværre skaber det tit problemmer for folk, og mit påstand var at man SAGTENS kunne klare sig uden. Java bruger selvfølgelig pointere inde bagved, men fra programmørens synspunkt er de der heldigvis ikke.

Pga. java's platformsuafhængighed, ville folk være rigtigt glade hvis f.eks. Spil var lavet i Java så kunne de nemlig fint køre på Windows,Linux,Mac osv.

En helt anden ting jeg sagde ikke man skulle bruge Java istedet, jeg kritiserede bare mandens manglende viden om programmering.

Disky:

Som det er nævnt kan du ikke sammenligne Cg med normale højniveu sprog. For det første er det slet ikke så højniveu som nVidia prøver at gøre det. Du er nødt til at have 100% styr på hvilken hardware der ligger under dit program for at kode Cg. Og til dette brug er goto faktisk ganske nyttig ting. Da det er ret vigtigt at kode optimal kode i dette miljø kan det være nyttigt at bruge goto fordi man ved præcis hvordan kompileren oversætter en sådan en kommando. Andre metoder til at springe i koden kan være omkostningsrige. For det andet er det anderledes at kode 3D end det er at kode normale programmer, nvidia prøver at få sytaksen til at lige C for at gøre det nemmere for programøre at kode 3D.

Desuden er det nok en fejl at sige at han ikke har forstand på at kode. Det er jo ham der har lavet den kompiler der generere kode til PS2's 3d enhed. Den mest komplicerede 3d enhed til dato ;) Ikke et let job, kan jeg forsikre dig om.

#5 Regus:
"Java udmærker sig også med en tragisk performance og en komplet manglende egenskab til at fungere på low-level niveau og er 100% uegenet til at kode moderne 3d spil i. Pointers er absolut ikke ligegyldige - de giver betydelige performance fordele samt muligheder for at tilgå resourcer man ikke kan tilgå gennem sprog som java."

Nu er det muligt, at du er hoppet helt væk fra emnet (og er gået til angreb på java), men jeg tror, du stadig sparker ud efter Cg baseret på nogle af javas "svagheder".

Jeg citerer lige fra slashdot:

"Whomever wrote that article may understand 3D, but doesn't understand where shaders fit in and the history and experience already here. Pixel and Vertex shaders have been around since the inception of commercial 3D in the form of Renderman surface and displacement shaders. They are small and very modular programs which don't need access to a large amount of information at one time. Thus because of the implied modularity, and the isolation of the calculations relative to the rest of the scene there is no need for OO (I know you didn't mention it, but someone in the FIRST story about this did, and its a good question), and no real need for pointers.

Furthermore because of the very analog nature of what is being descibed, control statements and desicion shortcuts aren't a very big deal. Of course there are if else statements, but they are not used as much as simple and very general algorithms. Hard desicions lead to aliasing, because they rule out a gradual change. Also because of the analog nature of what is being reproduced integers are used very rarely, almost exclusivly for loop counters.

Using float indices for arrays is a kick ass design descision. It allows for smooth and elegant interpolation between discreet values, and I can't stress what a cool idea that is.

In short, the register is wrong, and this IS a formula for a widespread language, because it is copying another very mature widespread language, the Renderman shading language. The only thing I am worried about is that it will be geared towards only Nvidia products, thus competing with OpenGL 2.0 (whenever the vapor settles).

Keep in mind that I am not trying to argue you, but I am trying to argue the register's stance. The designers of Nvidia are very aware of the vast history of Renderman I am sure, and this language looks just fine.

For anyone who wants to get into writing shaders, the book 'Advanced Renderman: Creating CGI for motion pictures' by Anthony Apodaca and Larry Gritz is your bible. it covers everything you need to know and more, and I highly recommend it."

#8 OndePik:
"Du er nødt til at have 100% styr på hvilken hardware der ligger under dit program for at kode Cg. Og til dette brug er goto faktisk ganske nyttig ting."

Ville det ikke være uligt meget nemmere at lave noget i stil med:

cg_compile -target ATI_PS1_4 shader.cgs

altså at lade compileren lave forskellige shaderprogrammer til de forskellige stumper hardware, som så kan loades ind uden at have alt muligt andet skrammel med, som er irrelevant for det aktuelle hardware?

ondepik:
Manden der skrev artiklen er 'Andrew Richards, founder of Codeplay,'

Læg mærke til ordet 'founder' :-)

Hvis Cg ikke er assembler, er det en form for højniveau sprog.

#11 Disky:
"Hvis Cg ikke er assembler, er det en form for højniveau sprog."

Ja, men der er forskel på højniveau-sprog.

C er et lav-niveau-sprog i forhold til f.eks. java.

Jeg synes, jeg har hørt noget om "lag" i den henseende ... noget i stil med:

1: Maskinkode
2: Assembly
3: C
4: C++ og Java

Så vidt jeg har forstået, vil Cg placere sig omkring 2&frac12; til 2,75 i den skala ...

#7 Disky,

du vil ha spil i java, se hvad det kan.
spil runescape, og lad os andre være.

wee, ingen store bogstaver.
whin over det istedet, og spil even mere runescape.

crash:
Nix, jeg spiller det fedeste Multi Player Rollespil på nettet nemlig:
<STRONG>Dark Age Of Camelot</STRONG>

Dit runescape ville sagtens være muligt at lave i Java, men selvfølgelig ville det ikke kunne køre helt så hurtigt.
Men hvis du nu omskrev spillet til hardcore håndoptimeret assembler, ville du kunne spille det på end endnu mindre PC'er, så hvor vil du hen med den udtalelse ?


Hektor; det har du ret i, men ondepik skriver selv 'højniveau' i sin nyhed, og vil senere ikke vedkendes det. Ret morsomt

Hej, jeg ser at kilden til denne nyhed er The Register, jeg troede ikke deres artikler kunne tages for gode varer, da de angiveligt skulle være at sammenligne med Se & Hør ?


Hvornår skal vi forøvrigt se en masse sure mennesker råbe om <STRONG>det her</STRONG> ?

#15 px:
Ja, det er da helt vildt forfærdeligt, at APG går efter folk, der rent faktisk laver piratkopierer. Hvad bliver det næste monstro? At politiet giver sig til at jagte lovovertrædere?

Hektor:
Det må du for guds skyld ikke skrive, tænk hvis en politimand kommer til at læse din posting og får gode ideer.

p.s. Det er da på tide folk der distribuerer ulovligt software får det at mærke.

Denne her er også ok:
http://www.computerworld.dk/default.asp?Mode=2&...

Disky:

Jeg er ganske vist ikke java ekspert men jeg har kodet en pæn del mere java end en applet og er absolut ikke clueless omkring sproget og det funktionalitet. Jeg har en del mere C++ erfaring, og har tænkt mig at lade det blive sådan dels fordi jeg synes java mangler mange features ud over lowlevel, desuden afskyr jeg garbage collection der typisk laver flere praktiske memory leaks end en midelmådig programør uden garbage collection.

"Performance i Jdk1.4 er meget tæt på C++ hastighed."
*host* bullshit *host*
ja i javas egen tests i programmer designet til at vise ens performance. Der er en mangler en række features i java heriblandt pointeraritmetik der er nødvendige for at nå optimal performance og det er mere en et par procent vi taler her. Desuden tynges java af ting som RTTI sder også koster performance. Det er jo f.eks. sjovt at se at større java værktøjer typisk bruger 2-4 gange så meget memory som tilsvanrende værktøjer i C++/VB/Pascal og har en tendens til at bruge mere og mere jo længere tid man arbejder med dem.

"Jeg er imponeret over dit kendskab til Java og low level ting, jeg kan fortælle dig jeg til dagligt roder med Java programmering i embeddet devices, tro mig jeg har fat i hardwaren uden problemmer."
Hvad har java i embeddet devices med sagen at gøre?
naturligvis har du adgang i embeddet devices. Men det ændrer ikke rigtigt på at der er ingen lowlevel access i java på PC.

"Pointere kan være en smart ting, desværre skaber det tit problemmer for folk"
Pointere skaber problemer for folk der ikke ved hvad de laver, og de folk vil med lige så stor sansynlighed falde i anonymous class fælden eller på anden vis skabe praktiske memory leaks i Java. Desuden er den eneste forskel på C++ pointere og Java referencer at man ikke kan bruge aritmetiske funktioner på referencerne så jeg kan ikke forstå hvorfor folk har svært ved at fatte dem.

"mit påstand var at man SAGTENS kunne klare sig uden."
Og min påstand er at det afhænger så sandelig af hvad du laver og om du er villig til at betale performance prisen for ikke at kunne benytte pointeraritmetik.

"Pga. java's platformsuafhængighed, ville folk være rigtigt glade hvis f.eks. Spil var lavet i Java så kunne de nemlig fint køre på Windows,Linux,Mac osv."
Dere glæde ville hurtigt forsvinde når de fik at vide at de skulle bruge 4GB RAM 5 GHz CPU og GForce 6 for at kunne trække et spil med samme performance som C/C++ spil i dag.

"En helt anden ting jeg sagde ikke man skulle bruge Java istedet, jeg kritiserede bare mandens manglende viden om programmering."
Bare fordi du er hoppet på java vognen og tror at java er den hellige gral betyder det jo ikke at manden ikke ved hvad han taler om.

Hektor
Jo jeg er ude på et sidespor - jeg ved ikke mere om Cg end hvad jeg har kunnet læse her gennem newz og jeg aner hat om grafik programering så jeg ville aldrig forsøge at argumentere hverken for eller imod Cg - men jeg vil argumentere imod at pointere er unødvendige.

Jeg synes virkelig at de folk der skriver artikler her på newz bør lære at stave før de skriver. Eller i det mindste kigge på det de har skrevet.

"Nu forklare grundlæggeren af Codeplay hvorfor han mener at Cg ikke er det gennembrud i grafik industrien, som Nvidia skriver i deres pressemedelelse."

Det hedder "Nu forklareR" ... det sidste r hedder et nutids-r !

Man kan ikke tage en tekst med stavefejl seriøst!

<STRONG>#10 Hektor</STRONG>
<STRONG></STRONG>
Jo det ville være meget smartere, og det er også klart et af de største kritikpunkter af Cg. Ideen med et højniveu sprog er jo at hæve abstraktions niveuet. Så compileren selv optimere så godt som den nu kan til forskellige hardware implementationer.

Problemet er dog større endnu da nVidia overhovedet ikke understøtter PS1.4 i deres kompiler. Og den kodegenererene del af kompileren er jo "closed source". Nvidia siger dog at ATI "bare" kan lave deres egen kompiler der optimere til PS1.4, men den vil jo aldrig være en officiel kompiler, desuden vil ATI altid være bagud hvis nvidia beslutter sig for tilføjelser til deres sprog.

Selve ideen bag Cg er rigtig god, men for det første var det jo ikke nVidias idé(MS D3DX anyone?). Og for det andet opfylder Cg overhovedet ikke de krav der skal til før idéen er virkeliggjort.


Tilsidst vil jeg siger at jeg ikke tror det er særlig godt for industrien at en af chip udviklkerne selv sidder på det sprog der bruges til at kode 3d. Det giver jo ikke andre firmaer særlig gode odds. Nvidia ved godt at de ikke kan slippe af med at lave det helt lukket og "nVidia only" da de slet ikke er store nok. Men det det har gjort er faktisk ret tæt på, kodegenratoren er lukket, og der optimeres kun til egne kort.

3Dmorten.

Det er jeg ked af, jeg vidste sgu ikke hvad et nutids-r var...

#19
Jeg synes virkelig at de folk der skriver artikler her på newz bør lære at stave før de skriver. Eller i det mindste kigge på det de har skrevet.

Man kan ikke tage en tekst med stavefejl seriøst!

Vil det sige du mener at folk der ikke staver "perfekt", skulle holde sig fra at bruge newz.dks forum?

Regus:
features ud over lowlevel, desuden afskyr jeg garbage collection der typisk laver flere praktiske memory leaks end en midelmådig programør uden garbage collection.

Hvor har du dog hørt det ævl ?
Tro mig GC'en laver mindre memory leaks end du selv gør.

Hvad har java i embeddet devices med sagen at gøre?
naturligvis har du adgang i embeddet devices. Men det ændrer ikke rigtigt på at der er ingen lowlevel access i java på PC.

Hvad er dit kendskab til Java egentligt ? Ligegyldigt om det er embeddet, til PC eller webside, så kan man bruge JNI Java Native Interface, til at få hardware adgang.
Bortset fra det i et almindeligt windows C++ program (under nt/win2k) får du aligevel ikke adgang til hardwaren uden drivere.

Pointere skaber problemer for folk der ikke ved hvad de laver, og de folk vil med lige så stor sansynlighed falde i anonymous class fælden eller på anden vis skabe praktiske memory leaks i Java. Desuden er

Det er de færreste, selv prof. udviklere der bruger anonymous classes,
Men igen laver de altså ikke memory leaks.

Definer lige memory leaks, du bruger ordet ret tit, og noget siger mig vi ikke har helt samme definition af det.

den eneste forskel på C++ pointere og Java referencer at man ikke kan bruge aritmetiske funktioner på referencerne så jeg kan ikke forstå hvorfor folk har svært ved at fatte dem.

Ved du egentligt hvad en pointer er ?
Ud fra ovenstående skulle man tro du ikke gjorde, i C++ laver jeg bare en void pointer, og vupti så kan jeg lave ravage af dimensioner, prøv lige at poste et java eksempel med det der svare til en void reference.
Du kan typecaste en reference, men ligeså snart du forsøger at kalde en metode på den nye type giver det problemmer. Som igen bliver fanget af JVM'en og ikke som i C++ får programmet til at crashe

Og min påstand er at det afhænger så sandelig af hvad du laver og om du er villig til at betale performance prisen for ikke at kunne benytte pointeraritmetik.
Som er ret lille, ellers er vi enige på dette punkt.

Dere glæde ville hurtigt forsvinde når de fik at vide at de skulle bruge 4GB RAM 5 GHz CPU og GForce 6 for at kunne trække et spil med samme performance som C/C++ spil i dag.

Det glæder mig du lige netop kommer med dette eksempel, det ventede jeg faktisk på :-)
Prøv at køre de spil der findes idag, på en maskine købt for 2 år siden, går det godt ? nej vel, folk upgraderer hele tiden hardware. Bortset fra det er dine størrelser noget overdrevet.

Bare fordi du er hoppet på java vognen og tror at java er den hellige gral betyder det jo ikke at manden ikke ved hvad han taler om.
Jeg tror skam ikke det er den hellige gral, men dine synspunkter var tydeligtvis forældet og på baggrund af længere og dybdegående erfaring.
Jeg kan fortælle dig at det jeg roder med i øjeblikket, er en blanding af C og Java, for den sags skyl også assembler.

imod Cg - men jeg vil argumentere imod at pointere er unødvendige.
Det det hele gik på var at man sagtens kan klare sig uden pointere. Hvilket Java er beviset på.

Jeg vil bare lige pointere at der vidst var noget med at der er blevet lavet en OpenGL implementation til Java - må da være muligt at få en del spil til at køre på den.

Et spil som Half-life ville da ihvertfald ikke kunne miste performance på det.....tror nok det kunne bruge en ordentlig omgang GC ;P

"Hvor har du dog hørt det ævl ?
Tro mig GC'en laver mindre memory leaks end du selv gør."

Teknisk set har du ret fordi det jeg referer til som memory leaks ikke i den strengeste tekniske forstand er en memory leak - at de så har nøjagtigt samme praktiske indflydelse som en memory leak er så en anden side af sagen...

scenarie:
1: Jeg opretter et object A der har samme levetid som mit program
2: jeg opretter et object B som f.eks. i sin constructor opretter en eventlistener hos A.
3: Jeg nedlægger og opretter nu B objecter i en lind strøm
men da de alle har en reference gennem eventlisteren bliver de aldrig nedlagt af garbage collectoren.

Jeg kunne nu løse dette ved at lave en release metode på B samt at jeg, istedet for at følge javadocs eksempel og oprette et anonymt object i addListener metodekaldet, sørger for at holde en reference så jeg kan kalde removeListener i min release metode.

Nu er der så kun et problem tilbage og det er at eftersom det ikke er kutyme at nedlægge objecter manuelt i java så er der næppe nogen der vil opdage at klassen har en release metode (jeg har aldrig mødt nogen der nærlæser dokumentationen af en klasse før de bruger den).

Bemærk desuden at i dette scenarie er der ikke bare en memory leak men også en cpu leak fordi alle de "døde" klasser vil blive notificeret hver gang en event opstår.

Som sagt jeg er godt klar over at det teknisk set ikke er en memory leak men jeg kender ikke noget ord der dækker bedre, og effekten er den samme.

"Hvad er dit kendskab til Java egentligt ? Ligegyldigt om det er embeddet, til PC eller webside, så kan man bruge JNI Java Native Interface, til at få hardware adgang."
Ok fair nok jeg tør ikke bevæge mig ud i en JNI debat

"Bortset fra det i et almindeligt windows C++ program (under nt/win2k) får du aligevel ikke adgang til hardwaren uden drivere."
Sandt men du har da i det mindste en direkte adgang til OS API'en - men så kommer vi ud i hele platforms(uafhængigheds) diskutionen og den gider jeg ikke tage

"Ved du egentligt hvad en pointer er ?"
Øh, ja - gør du?
det er præcist det samme som en reference i java - en hukommelses adresse, den eneste forskel er at du har mulighed for at tilgå dens værdi direkte i C++ og det har du ikke i java.

" i C++ laver jeg bare en void pointer, og vupti så kan jeg lave ravage af dimensioner, prøv lige at poste et java eksempel med det der svare til en void reference."
Sandt men det kræver altså en aktiv indsats at lave den ravage det er ikke noget man kan komme til at gøre ved et uheld, memindre man vælger at rode med pointer aritmetik i hvilket tilfælde man selv er ude om det. Ligesom der ikke er nogen der tvinger dig til at bruge inline asm er der ikke nogen der tvinger dig til at rode med pointeraritmetik.

"prøv lige at poste et java eksempel med det der svare til en void reference."
Selvfølgelig kan jeg ikke det, men det har ikke noget med pointerer som sådan at gøre det har noget med java beskyttede miljø hvor man for at beskytte programøren mod sig selv har frataget ham muligheder.

"Du kan typecaste en reference, men ligeså snart du forsøger at kalde en metode på den nye type giver det problemmer. Som igen bliver fanget af JVM'en og ikke som i C++ får programmet til at crashe"
Det har ikke noget med pointere at at gøre det er drejer sig om RTTI(Run Time Type Information). Og det er et meget mere omfattende koncept der bla. kræver at alle klasser arver fra en grundklasse - og at der udføres tjek ved hvert cast, noget der koster i performance.

Desuden behøver et false cast ikke føre til fejl det kan sågar udnyttes.

int a;
class b {
int d;
int gangmed2() {
return d * 2;
}
}

b* f = (b*) &a;
f->gangmed2();

fungerer fint i c++ det er måske ikke så fandens pæn kode men det er intet ivejen for det.

Du har nogle flere muligheder i C++, men det medfører selvfølgelig også et større ansvar og hvis man ikke er det ansvar moden bør man nok ikke kode C++.

"Prøv at køre de spil der findes idag, på en maskine købt for 2 år siden, går det godt ? nej vel, folk upgraderer hele tiden hardware. Bortset fra det er dine størrelser noget overdrevet."
Ja men skulle det være at argument? Du vil altså sætte os 2 år tilbage i spiludviklingen bare for at få lov til at kode java?
Argumentet med at folk opgradere er nok Suns slappeste argument for at performe så dårligt og de har også indset det og prøver nu desparat et indhente performance i forhold til C++ hvilket aldrig vil lykkedes fordi java har en del overhead som de ikke kan slippe af med uden at bryde med hele deres koncept. Blandt dem kan nævnes RTTI, Garbage collection, manglende ASM support, Systemuafhængighed gennem ekstra lag og der er sikkert flere.

"jeg tror skam ikke det er den hellige gral, men dine synspunkter var tydeligtvis forældet og på baggrund af længere og dybdegående erfaring."
Det er da fint at du mener mine holdninger er forældede - det du siger er effektivt set lad os sløse med resourcerne der er alligevel nok af dem - det er bare ikke rigtigt for en lang række systemer, herunder spil. Java vil aldrig kunne løse de opgaver fordi softwarens krav til hardwaren vokser lige så hurtigt som hardwaren selv. Og ´du kan sige hvad du vil java har ingen reel mulighed for at producere samme ydelse som C++ uden dramatiske ændringer i deres grundkoncepter, der er simpelthen en lang rækker systemoverheads i java som man ikke kan optimere sig ud af.


"Jeg kan fortælle dig at det jeg roder med i øjeblikket, er en blanding af C og Java, for den sags skyl også assembler."
Jammen godt for dig - det gør ikke dine holdninger mere korrekte - det beviser i og for sig bare at du ikke har været istand til at undvære pointers...

"Det det hele gik på var at man sagtens kan klare sig uden pointere. Hvilket Java er beviset på."
Jammen det har du bare ikke ret i - det koster for dyrt i performance.

#24

der er ikke nogen der påstår man ikke kan lave en 3d shooter i java - vi påstår bare at det ikke vil være istand til at performe så godt som et spil skrevet i C++

#26 Regus:
"vi påstår bare at det ikke vil være istand til at performe så godt som et spil skrevet i C++"

Det er da lige meget. Man kan ikke få et spil skrevet i C++ til at yde lige så godt som samme spil skrevet i ren C. Og laver man det i assembler, kan det køre endnu bedre.

C++ er tættere på "metallet" end java - big fucking deal. En af grundende til, at C++-spil yder bedre end tilsvarende java-spil er f.eks., at der er meget større viden om tuning af C++ end java, da C++ har en hel del flere år på bagen end java.

En af fordelene ved java er, at man ikke behøver koncentrere sig om en enkelt platform; det er så et ganske ligegyldigt punkt på dette tidspunkt i historien, da 98+% af nyere spil sælges til Windows (konsoller ikke medregnet). Skulle man have et ønske om at nå ud til alle, uanset platform (find selv på en sær grund til dette), er der så to muligheder:

1) Brug tid på at krydskompilere og sikre kompatibilitet på samtlige platforme med C++ og forsink udgivelsestidpunktet på grund af dette.
2) Lav det i java, og brug tidsbesparelsen til at optimere på tværs af platformene.

Der er sikkert nogle, der kan lave et 100% platformsuafhængigt spil, som bare virker på mere end to platforme (f.eks. linux og Windows), men kan de også gøre det på tværs af hardware-arkitektur? Så PPC, Sparc, Alpha, Itanium osv bare kan køre dem? Nej, det kan man heller ikke med java - ikke før, der er lavet en jvm til platformen, og den yder sikkert heller ikke sit bedste fra starten.

Hvorfor er folk så forhippede på at overbevise alle andre om, at deres religion ... sludder ... programmeringssprog er det bedste? Er en hammer bedre end en skruetrækker? Er den bedre end sav?

Vælg da for helvede det rigtige værktøj til opgaven! Når man kun har en hammer, ender alting med at ligne søm.

regus:
Tak for nogle gode svar.

Dit eksempel på Memory Leak, vil jeg ikke mene er java's skyld der er udviklerens skyld. Intet sprog er sikret imod dumme udviklere.

Enhver dygtig java udvikler sætter referencer til 'null' hvis man ved at man forbliver i et scope i længere tid, men ikke har brug for objektet.

"Tak for nogle gode svar"
Det var så lidt :-)

"Dit eksempel på Memory Leak, vil jeg ikke mene er java's skyld der er udviklerens skyld. Intet sprog er sikret imod dumme udviklere."
Jammen det er vi helt enige om problemet er at den er ret svær at undgå, i mine øjne sværerer end den typiske C++ memory leak (der heller ikke er en fejl i sproget men en generel og svært undgåelig brugerfejl). Det er et generelt garbage collection problem, som ingen managed sprog kan se sig fri for - måske med undtagelse af pascal, hvor det er kutyme at relese selv


"Enhver dygtig java udvikler sætter referencer til 'null' hvis man ved at man forbliver i et scope i længere tid, men ikke har brug for objektet."
Ja men problemet er jo netop at det ikke er nok at sætte referencen til null du skal også kalde en release metode på objecter af typen B

eks:
program scope
A a = new A();

meget mindre scope
B b = new B(a); //b registrerer en eventlistener hos a
b = null; //b bliver ikke gc'et her fordi der stadig er en reference fra a

//derfor må man skrive
b.release() //custom release metode der kalder removeListener
b = null;

og for at vide at man skal gøre det skal man have læst reference materialet til B ret grundigt, hvilket man typisk ikke gør og ikke burde være nødt til - man bør kunne forvente at alt er encapsulated i objektet og ikke giver problemer så længe man følger almindelige forholdsregler hvilket i java er at sætte alle sine kendte referencer til null - problemet er at her der en ukendt reference.

Udvikleren af B har jo ikke noget problem han ved godt at problemet findes, men en senere bruger af klassen har ikke en kinamands chance for at gætte at der er problem og vil derfor komme til at lave en memory leak

"Det er da lige meget. Man kan ikke få et spil skrevet i C++ til at yde lige så godt som samme spil skrevet i ren C. Og laver man det i assembler, kan det køre endnu bedre"

Det er da ikke ligemeget - prisen for at skrive i java frem for C++ er måske flere års performance setback for spilindustrien, at skrive i C++ med asm optimering frem for C med asm optimering sætter dem måske et par måneder tilbage tilgængæld for at have en trediedel time to market.

"C++ er tættere på "metallet" end java - big fucking deal. En af grundende til, at C++-spil yder bedre end tilsvarende java-spil er f.eks., at der er meget større viden om tuning af C++ end java, da C++ har en hel del flere år på bagen end java. "
jeg vil nøjes med at citere mig selv:
"indhente performance i forhold til C++ hvilket aldrig vil lykkedes fordi java har en del overhead som de ikke kan slippe af med uden at bryde med hele deres koncept. Blandt dem kan nævnes RTTI, Garbage collection, manglende ASM support, Systemuafhængighed gennem ekstra lag og der er sikkert flere"

"En af fordelene ved java er, at man ikke behøver koncentrere sig om en enkelt platform; det er så et ganske ligegyldigt punkt på dette tidspunkt i historien, da 98+% af nyere spil sælges til Windows"
Jammen hvordan kan det både være en fordel og ligegyldigt - det er da diskutionen irrellevant om der i en fjern fremtid i en fjern galakse vil opstå en situation hvor java får en reel fordel som måske kan overgå fordelen ved C++. I de situationer hvor man har brug for platformsuafhængighed kan man vælge at bruge java muligvis med fordel afhængigt af opgaven og det må være op til den der har problemet at vælge.

"Der er sikkert nogle, der kan lave et 100% platformsuafhængigt spil, som bare virker på mere end to platforme (f.eks. linux og Windows), men kan de også gøre det på tværs af hardware-arkitektur? Så PPC, Sparc, Alpha, Itanium osv bare kan køre dem? Nej, det kan man heller ikke med java - ikke før, der er lavet en jvm til platformen, og den yder sikkert heller ikke sit bedste fra starten. "
Jammen godt for dem - det er stadig fuldstændigt uinteressnt for spilbrancen i nuværende situation.

"Hvorfor er folk så forhippede på at overbevise alle andre om, at deres religion ... sludder ... programmeringssprog er det bedste? Er en hammer bedre end en skruetrækker? Er den bedre end sav? "
Det har jeg sådan set hller ikke forsøgt jeg har forsøgt at bevise C++ fortsatte berretigeslse i forhold til Java - samt modargumenteret påstanden at pointere er definitivt unødvendige.

"Vælg da for helvede det rigtige værktøj til opgaven! Når man kun har en hammer, ender alting med at ligne søm."
Jammen jeg kan da kun være enig - C++ er bare et bedre værktøj til spil end java - desuden vil jeg så påsta at C++ er en toptunet multidremel og Java kun er en mindre schweizer kniv - det betyder ikke at java ikke kan bruges det har bare færre anvendelseområder end C++ i mine øjne. Hvilket vel er en både rimelig og saglig påstand, så kan man så være enig eller uenig.

mem leak = mere RAM

:-) Sådan !!!!

Regus:
Den 'memory leak' du beskriver er altså ikke hvad jeg ville kalde en leak.
Men ene og alene en dårlid udviklers skyld.

I Java bliver de fleste objekter free'et helt af sig selv, hvorimod i C++ sker der absolut intet hvis man ikke explicit husker at gøre det.

I begge tilfælde skal programmøren tænke sig om.


thrawn:
Helt enig :-)))