Gå til innhold

Trenger tips, directx


Anbefalte innlegg

LOL, nå er jeg ingen ASM ekspert (vil heller si at jeg kan pent lite Assembly eller Lisp), men du skal få cred for en av de drøyere postene jeg har lest her i det siste  :thumbup:

 

Lisp virker som et ganske morsomt språk BTW. Skriver Ruby daglig, og det er endel kule språk features der oxo.

6961931[/snapback]

 

Nå er jeg helt enig, men jeg følte at du sporte av ganske grundig, helt til du i en senere post forklarte hvorfor du kom med en lang post om LISP.

 

Jeg programmerer til vanlig i java og vil påstå at for en newbie som skal lære seg openGL så er nok java å foretrekke, å lære seg minnehåndtering i større programmer i C++ er nok en egen vitenskap :p

 

... bare se på alle spillene som blir sluppet med minnelekasjer ;)

 

Sjansen for å få bedre ytelse ved bruk av c++ istedetfor java i opengl ser jeg som nærmest garantert, ettersom det nok er skrevet vesentlig mer c++ kode en java kode på dette området - og det er jo greit å ikke måtte finne opp hjulet på nytt hver gang?

 

Jeg vil påstå at java sin sterkeste side er business software som skal være kjapp å utvikle og ha god nok ytelse...

Lenke til kommentar
Videoannonse
Annonse
LOL, nå er jeg ingen ASM ekspert (vil heller si at jeg kan pent lite Assembly eller Lisp), men du skal få cred for en av de drøyere postene jeg har lest her i det siste  :thumbup:

 

Lisp virker som et ganske morsomt språk BTW. Skriver Ruby daglig, og det er endel kule språk features der oxo.

6961931[/snapback]

 

Sjansen for å få bedre ytelse ved bruk av c++ istedetfor java i opengl ser jeg som nærmest garantert, ettersom det nok er skrevet vesentlig mer c++ kode en java kode på dette området - og det er jo greit å ikke måtte finne opp hjulet på nytt hver gang?

6962035[/snapback]

 

Vel; jeg har allerede nevnt (veldig kort her, men flere ganger tidligere) at det man gjør da er naturligvis å ta i bruk C++-koden/bibliotekene (eller C; C-biblioteker er ofte mye lettere her) som allerede finnes; direkte i høynivåspråkene. Det er lett!

 

Ta f.eks. http://www.ogre3d.org/wiki/index.php/Alternative_Languages

 

cl-user> (foreign-funcall "strlen" :string "Hello World!" :unsigned-int) ==> 12

 

Lisp <==> C (man kan gå begge veier m.t.p. f.eks. funksjonskall!)

 

..dette er da CFFI, naturligvis i Lisp - noe som i ditt tilfelle (Java) blir noe sånnt som JNI.

Endret av lnostdal
Lenke til kommentar
Jeg er relativt sikker på at å kalle native libraries fra java ikke nødvendigvis er det kjappeste som finnes...

6962230[/snapback]

 

åpenbart at du driver å fisker; jeg hadde en lang post her(#1), men ok - hvis jeg i stedet sier:

 

* inline ASM

* ekstremt fleksibel optimalisering v.h.a. deklarasjoner av typer m.m. som genererer bedre ASM enn C i noen tilfeller

* FFI mot kode i annet språk

 

..så har du kanskje fantasi nok (edit: eventuelt ikke .. haha) til å se at det finnes et hav av muligheter her..

 

#1: edit, okei - kort;

 

jeg har altså ikke noe inngående greie på java, og sier som jeg nevnte over her at det generelt sett finnes andre høyst reelle alternativer fremfor C/C++ innen programmering der hastighet er kritisk (spill om du vil; som er det vi snakker om her) - og at det er dette som er poenget her .. det er dog helt sikkert noen ideer her som også vil fungere i sammenheng med java..

 

.. vel - det jeg snakket om var:

 

* hvordan man kan designe ting slik at main/event-loop er representert v.h.a. en eller flere av de tre mulighetene nevnt over...

* hvordan man behandler objekter som "state-machines" representert i "delt minne" (Lisp er _meget_ godt utrustet når det gjelder manipulering av binære data; bedre enn C - uten tvil) mellom høy- og lavnivå-koden; eller generelt sett har data/state-fokus fremfor "callback"-fokus

* og nevner samtidig at ikke-forutsigbare egenskaper (edit: ser du for deg en drøss implikasjoner av det jeg mener med "ikke-forutsigbare egenskaper" nå? kombiner disse med utsagnet "optimaliser tilslutt" og de tre punktene over) endres ytterst sjeldent i forhold til hvor ofte en main/event-loop leser av disse ..

 

er du med på tankegangen der man f.eks. gjør ett enkelt FFI-kall mot et bibliotek som fra da av tar seg av main/event-loop kontinuerlig og kaller callbacks definert "hvor som helst" - altså både i høynivå og lavnivå-delen ytterst sjeldent fordi løsningen er state/data-sentrisk? - og at dette kun er ett eksempel på hvordan dette kan gjøres?

 

edit2: vil her legge til en ting; når jeg sier "både i høynivå og lavnivå-delen" så betyr ikke dette nødvendigvis "Lisp-delen og C-delen" med en FFI i mellom disse, da man som vist over her i praksis altså kan generere _høyst_ lavnivåish-kode i Lisp og t.o.m. inline ASM om ønskelig (jeg antar at dette går i andre høynivåspråk også; kanskje ikke alle, og da øker muligens kompromisset når man velger dét språket, men det er heller altså ikke poenget her)

 

..jeg kan godt nevne en drøss andre eksempler, men poenget er at de fleste(?) ikke-hjernedøde biblioteker (f.eks. GTK+, OpenGL) eller løsninger er designet slik at dette ikke bare er mulig; det er t.o.m. trivielt eller "meningen"..

 

edit3:

nå kommer sikkert "alle andre"-gjengen inn her; det er åpenbart at mange baserer sin strategi på "sauementalitet"

 

jeg kan sitere fra en post på USENET (her: http://groups.google.com/group/comp.lang.l...c4e62f60b05a18a )

 

>> Britney Spears sells more copies of her albums than artists that are

>> miles better than her. That is a fact. Now apply this to your statement

>> about number of users and it'll redefine your view of what success

>> means or widen your understanding of it.

>

> Success can be measured taking in count several variables. Popularity is

> one of them. It is in fact an important one. It is not the only. But it

> is there.

> Britney Spears has succed. You may think that her music is a shit, but

> it is only your opinion. What you cannot say (if you are mimimaly

> tolerant and compasive) is that her music is worse than other ones just

> because you think so. You may say that _in your opinion_  her work is

> worse, and can discuss this tolerantly and pacifically. But the fact is

> that, despite what you think, she has clearly succed.

 

You need to remember that you are not buying something that is pre-made

for you; you are choosing what to use for solving _your_ problems. I do

not want to use Britney Spears to write my code. (lol - this is getting

kind of stupid)

 

..og samtidig henvise til det jeg snakket om helt i starten her: https://www.diskusjon.no/index.php?showtopi...0entry6961667 og legge til at det der kun er et fåtall eksempler på ting som viser at det jeg snakker om fungerer veldig bra i praksis selv om det "ikke er så mange som gjør det"

 

..det å snu trender for hva som er populært innen programmering tar mange-mange år.. 15-30 år er ikke uvanlig.. tenk også over grunnen til at man i 1960-70 valgte å fokusere på språk i "C-familien" fremfor de i "Lisp-familien" ennå man visste at språk i sistnevnte var mye bedre m.t.p. muligheter til å uttrykke seg enn førstnevnte -- grunnen var naturligvis dårlig maskinvare og kompilere som ikke ennå var gode nok til å optimalisere; to problemer vi ikke har lengre

 

..tilbake til dette med populæritet; se på hva google gjorde - de går sin egen vei (mye python) .. samme med amazon (lisp+c), naugty dog (lisp+asm), yahoo/viaweb (lisp) + de jeg har nevnt over m.fl. .. selv om et par av eksemplene akkurat her er web fremfor spill/grafikk er det greit å ha i bakhodet at flere av disse håndterer enorme mengder data; og hastighet er dermed viktig naturligvis .. suksess er altså ikke nødvendigvis koblet sammen med populæritet eller det å gjøre det samme som alle andre; definitivt ikke her - tvert i mot er det ofte det å gå på tvers av det som er trender og i stedet fokusere på det som er viktig; nemlig den letteste og beste måten å nå sine mål på - om det være seg Lisp, C eller Java (så kan ingen si at jeg fokuserer eksklusivt på én av dem og kalle det "offtopic" fordi det blir for "voldsomt")

 

..så ble visst denne lang likevel .. :)

Endret av lnostdal
Lenke til kommentar

hmm.. voldsomt seint på natta denne diskusjonen går da.

 

Når du (lnostdal) snakker om saumentalitet har du tydeligvis ikke helt skjønt hvor mye arbeid som blir lagt ned. Det er for de fleste ikke mulig å skifte fra et språk til et annet over natten, man snakker fort om flere årsverk som settes inn her. Og for 3-part kode er det jo rimelig selvfølgelig at man bruker det samme språket som de man lager koden til.

 

Når det gjelder den ASM koden du legger fram, så kan du ikke bare slenge ut noe kode å si "sånn gjør c det" Hallo det finnes jo mange forskjellige kompilatorer og de har sikkert mange forskjellige innstillinger for ikke snakke om hvilke os de er kompilert til.

 

Men du har helt rett i at GC kan! være raskere, men det er vel ingen som setter ytelse høyt som bruker ordinær new/malloc uten noen form for systemer alla memory pool.

 

Du har også rett i det er små deler av koden som trenger optimalisering det jo ikke uvanlig at store deler spill bruker skripting (Lua, gamemokey,angelskript,python osv) har ikke funnet lisp her men det finnes nok :)

 

Når det gjelder C# så er det mange som ser på det som det nye C. JIT språk har jo den fordelen at de kan optimaliseres til den enkelte maskin. Og på den måten kan JIT språk en fordel som gjøre at de kan bli langt raskere.

 

En siste ting: lnostdal har du noen linker (det har du nok :) ) med større tester av lisp vs andre språk, de jeg har funnet er bare enkle tester.

 

OFFTOPIC

hehey ny smily :ph34r:

Lenke til kommentar

lnostdal: Så fordi "JVM" er et ord, og "C++-biblioteker" er et ord, så er det liksom det samme? Poenget mitt er jo bare det at JVM er et rammeverk, som må eksistere på den aktuelle platformen, og at en slik ikke eksisterer native i en Playstation 3. Det burde da ikke være så vanskelig å forstå.

 

Man kan alltid gjøre ting raskere enn Javas automatiske GC. Jeg har selv laget en GC for C++, og det tok vel ca. en dag. Da har jeg også full kontroll over hvordan den skal fungere, og kan bruke den om og når jeg vil. Klart det er raskere. Og GC er ikke det eneste ressurssluket. Hvert enkelt funksjonskall har ekstra overhead siden koden kjøres i JVM og må gjennom et abstraksjonslag for å nå inn til systemet.

 

Jeg har forøvrig stor tro på C# og JIT, men stusser litt på at .NET Framework ikke blir lansert for andre plattformer.

 

lnostdal: Hvorfor henger du egentlig på C/C++-forumet, når du nesten utelukkende snakker om Lisp? Når noen spør om 3D-programmering på et C/C++-forum, regner jeg med at det er det de faktisk er interessert i (noe som er hensiktsmessig nok). Man kan sikkert koke sammen noe bra i Lisp, men C++ er det universalt anbefalte verktøyet for denne oppgaven, enn så lenge.

Endret av Geofrank
Lenke til kommentar

For å bringe diskusjonen litt tilbake på spor..

 

For meg (som ønsker å bli en uavhengig spillutvikler) er det minst like viktig at utviklingen går relativt fort og kan mest mulig effektivt nå ut til mange forskjellige platformer. Mitt primærspråk er Java, men hadde klart meg fint i C++ om jeg hadde sett fordelene med å bruke nettop det språket.

 

Som uavhengig spillutvikler så har man som regel ikke noe særlig med startkapital, og har ikke råd til å lisensiere et virkelig bra og grundig gjennomtestet spillmotor. Da må man ty til Open Source alternativer som Irrlicht, Ogre3D eller Genesis3D m.f. Alle disse APIene er skrevet i C++, og selv om de skal i utgangspunktet være "platformuavhengige", så fører det med seg problemer når spillet ditt skal for eksempel distribueres til alle forskjellige typer oppsett av Linux. OSX vil muligens være litt enklere siden det er en relativt definert platform, men alle de forskjellige versjonene av samme applikasjon som du må håndtere fører fokus bort fra det som du egentlig skal/har lyst til å drive med, og det er å skrive spill.

 

Jeg mener at bra programvare bør være tilgjengelig for alle, uansett platform. Derfor er DirectX og C/C++ strøket av lista mi som gyldige alternativer for spillutvikling. Har derfor testet de forskjellige alternativene man har innen Java verdenen og det ser veldig lovende ut. Det finnes noen spill/grafikk motorer også for Java (jmonkeyengine, Xith3D), men siden jeg ikke er så fryktelig begeistra for eksklusiv bruk av scenegraphs for å representere objekter i spillet (dette er et tema for en annen tråd) så har jeg valgt å skrive en egen komponentbasert spillmotor i JOGL, som er en ren speiling av OpenGL for Java. De testene jeg har gjort av JOGL viser at det absolutt ikke er noen problemer med ytelse, optimalisering vil nok være nødvendig av enkelte algoritmer som occlusion culling, kollisjonshåndtering, skeletal animation o.l. men dette ville vært akkurat det samme for C/C++.

 

Dette er min forklaring på hvorfor jeg syns det er riktig å skrive spill i Java.

Lenke til kommentar
lnostdal: Så fordi "JVM" er et ord, og "C++-biblioteker" er et ord, så er det liksom det samme? Poenget mitt er jo bare det at JVM er et rammeverk, som må eksistere på den aktuelle platformen, og at en slik ikke eksisterer native i en Playstation 3. Det burde da ikke være så vanskelig å forstå.

 

Det finnes andre "rammeverk" (om du ønsker å bruke dét som samme ord for begge ting; biblioteker/JVM eller VMs generelt) som også ikke eksisterer på PS3 ennå. Ingen forskjell. Jeg vil dog tro flere er interessert i en eller annen JVM på Cell-arkitekturen; gjetter jeg ikke galt så vil jeg tro Sun er mer enn interesserte.

 

Man kan alltid gjøre ting raskere enn Javas automatiske GC. Jeg har selv laget en GC for C++, og det tok vel ca. en dag. Da har jeg også full kontroll over hvordan den skal fungere, og kan bruke den om og når jeg vil. Klart det er raskere.

 

Jeg antar at du snakker om reference-counting. Da får jeg gratulere; du har greid hva ingen andre har greid, nemlig å lage ref.counting som er raskere enn andre typer GC i alle tilfeller - noe ingen andre har greid til nå.

 

Du får redigere wikipedia-artikkelen, kontakte utallige "PhD"'s (ikke at sånt i seg selv "har noe å si") og fortelle dem at de publiserte resultatene deres faktisk ikke stemmer lengre etter ditt gjennombrudd her som kun tok én dag.

 

lnostdal: Hvorfor henger du egentlig på C/C++-forumet, når du nesten utelukkende snakker om Lisp?

6963755[/snapback]

 

Jeg har flere poster om C/C++ her enn det du har. Jeg har hjulpet flere med konkret C/C++-kode og andre 1-1 C/C++-spørsmål enn det du har. Du må få med deg at selv om dette er et C/C++-forum så kan man ikke komme med gale utsagn og forvente at alle skal bøye seg for det bare fordi dette er et C/C++-forum; først og fremst er dette et forum under kategorien programmering og flere av oss har såpass oversikt at vi bruker flere programmeringsspråk. Det er andre mer viktige mål/emner enn utelukkende étt spesifikt språk som taes opp her; og spesielt i denne tråden. Det er barnslig å inbille seg at noe annet er mer riktig eller viktig - enten teknisk, sosialt eller "moralsk" sett.

 

..det er skikkelig lavmål at en skal måtte nødt til å forklare det her, og synke så lavt at en diskusjon leder til et spørsmål som tilsier at en skal måtte være nødt til å forsvare seg hva eksterne krefter angår bare fordi "motparten" (som egentlig ikke bør regne seg som det!) ikke har andre (relevante) argumenter..

 

Jeg liker bruken av C eller minimalistisk C++ kombinert med Lisp - naturligvis fordi det i noen tilfeller har en hastighetsmessig fordel, men når du (og/eller noen andre - gidder ikke sjekke hvem som sa hva ATM) sier at C/C++ eksklusivt er det eneste realistiske alternativet i sammenhenger som blir tatt opp her er jeg overbevist om at det ikke stemmer i det hele tatt.

 

Hvorfor spør du? - Har du ikke lest det jeg skriver - dette er jo nevnt tidligere?

 

Når en nevner Java som et gyldig alternativ og en annen sier at det ikke er realistisk i noen betydelig skala er naturligvis dét bare tull (jeg har nevnt konkrete eksempler). Som sagt bruker jeg Lisp som kjøretøy for å illustrere poengene mine; at man kan generere rask kode med andre språk enn C - og både Lisp og Java er to eksempler på andre språk enn C. Du skjønner åpenbart ikke det jeg nevte bak her; så jeg får vel mate det inn. Ser man på Lisp og Java så er det Lisp jeg har mest greie på; som igjen leder til grunnen til at jeg bruker akkurat det som kjøretøy for å illustrere ..øh.. det generelle poenget at det finnes andre gyldige alternativer enn eksklusiv bruk av C. U C?

 

..en kan jo lure på hvorfor du spør meg om det her uten å vise at du også har spurt deg selv; tipper du egentlig har andre intensjoner og at du rett og slett har lyst til å bli kvitt meg slik at du slipper å _tenke_ - du vil ikke en gang at andre skal kunne tenke..

 

Tipper du ikke gidder; du anser en hver form for investering i noe nytt som i det hele tatt kan regnes som betydelig som en byrde - og kjører heller til neste fergestopp selv om det totalt sett tar lengre tid (30 min) og sløser mer med resurser enn det å vente på ferga ved dette stoppet vil ta (15 min). Du er vel typen som bruker Ch til scriptingen din .. haha :}

 

Det du imidlertid ikke tenker over er at selv om ikke du er interessert i det her - du vil ikke en gang høre av det, men foretrekker å lukke alt som er av øyner og ører - så er det naturligvis andre som er interessert i slike ting. ..de setter naturligvis det reelle målet høyere enn verktøyene for å nå dem..

 

edit: det du nevner om å "reklamere" bak her viser egentlig i seg selv hvor galt du tenker; hadde jeg byttet ut Lisp-koden med C-kode og vist hvordan man kan optimalisere for å generere kort, kompakt og rask ASM v.h.a. C hadde du ikke sagt et kløva ord -- du misser dermed totalt poenget som er at det samme nemlig er mulig v.h.a. andre språk enn C også; og at andre språk enn C dermed duger til utvikling der hastighet er kritisk (spill) .. synd - men det behøver ikke å bety at du skal "få lov til" å komme med utsagn som er direkte gale uten å forvente at "kødder" som meg påpeker det; poenget (for noen) er tross alt fremgang

Endret av lnostdal
Lenke til kommentar
hmm.. voldsomt seint på natta denne diskusjonen går da.

 

Når du (lnostdal) snakker om sauementalitet har du tydeligvis ikke helt skjønt hvor mye arbeid som blir lagt ned. Det er for de fleste ikke mulig å skifte fra et språk til et annet over natten, man snakker fort om flere årsverk som settes inn her. Og for 3-part kode er det jo rimelig selvfølgelig at man bruker det samme språket som de man lager koden til.

 

Fair ennuff - jeg kan ikke si noe på dét, men det siste der kan jo settes litt på spissen; -Selv om deler av et OS er skrevet i ASM betyr ikke det at store deler av det ikke er skrevet i C - og at det å gjøre dette er ikke er lurt; faktum er at de største delene er skrevet i høynivåspråket C (relativt) fordi det er det som er mest hensiktsmessig. Bytt ut OS med "spill", ASM med C og C med et høynivåspråk- så har du en lignende situasjon.

 

Når det gjelder den ASM koden du legger fram, så kan du ikke bare slenge ut noe kode å si "sånn gjør c det" Hallo det finnes jo mange forskjellige kompilatorer og de har sikkert mange forskjellige innstillinger for ikke snakke om hvilke os de er kompilert til.

 

Det er naturligvis _blindingly obvious_ at jeg mener noe slikt tilsvarer hva en C-kompiler ville generert på _min_ platform. Skjerpings..... :}

 

Uansett er det du nevner ikke noe som er unikt for C og kompilere der. ASM-koden er naturligvis generert for maskinen jeg sitter ved nå; dette er native kode - og den ville generert annen ASM om jeg satte andre innstillinger og/eller gjorde dette på en annen maskin.

 

..i utgangspunktet sier det seg selv; alternativet er at ting ikke kjører i det hele tatt - og spørsmålet eksisterer ikke da, eller blir et annet spørsmål - et om portabilitet..

 

En siste ting: lnostdal har du noen linker (det har du nok :) ) med større tester av lisp vs andre språk, de jeg har funnet er bare enkle tester.

6963457[/snapback]

 

Regner med at du her utelukkende kun tenker på kjøremessig hastighet; om du derimot mener andre hensyn tror jeg det er like greit at du sjekker selv: http://www.linuxguiden.no/index.php/Common...seg_Common_Lisp (gratis-bøker/resurser m.m.)

 

Kan dra frem to eksempler:

 

* cl-ppcre er et regex-lib som er raskere enn Perls eget i mange tilfeller (de som betyr noe) som altså er skrevet i optimalisert C. Forfatteren har testet med CMUCL, men jeg er rimelig sikker på at SBCL er endel raskere enn CMUCL noe som øker forskjellen ennå mer.

 

* Tradisjonelt er det helt naturlig å regne C som raskere enn Lisp, spesielt når det er snakk om "number crunching", "image processing" og slike ting - men ta en titt: http://www.lrde.epita.fr/~didier/comp/rese...na.06.ecoop.pdf http://www.lrde.epita.fr/~didier/comp/rese...coop-slides.pdf

 

Man må hele tiden ha i bakhodet at fordelen med Lisp ofte øker drastisk når det er snakk om å løse ikke-trivielle (ofte "ikke-sekvensielle") problemer, både med tanke på utviklingen og kjøremessig hastighet. Litt av grunnen til dette er en kombinasjon av en rikere mulighet til å uttrykke seg, og en mulighet til å justere hvor generiske ting skal være med en mye finere oppløsning enn i f.eks. C++ (dårlig eks: partial templates vs. lisp-macros).

 

Flere spørsmål direkte om Lisp kan gjerne taes opp i en egen tråd under Generell/annen slik at ikke folk her får hysterisk sammenbrudd og begynner å grine eller lignende. :}

Lenke til kommentar

Om man velger "reference counting" er jo opp til en selv. Av andre algoritmer har man jo for eksempel "mark and sweep" og "copying"-algoritmene. Selvfølgelig kan man gjøre det tregere enn Java, men selvfølgelig er det også mulig å gjøre det raskere. Det er simpel logikk.

 

Vil man ha ting portabelt kan man jo bruke OpenGL. Stort sett alle OpenGL-programmerere bruker også C/C++. Sant nok at det er mer stress å måtte kompilere for hver plattform, men er det snakk om mer enn et hobbyprosjekt, burde ikke det være den avgjørende faktoren.

 

Jeg har ikke sagt at Java er et urealistisk valg, men at det ikke er spesielt godt egnet til 3D-programmering. Den meningen står jeg ikke alene om. Faktisk er jeg lidenskapelig opptatt av temaet, og du (lnostdal), er den første jeg møter av folk både innenfor og utenfor bransjen, som sitter med den oppfatningen du har.

 

Du snakker som om jeg sier at C++ er eneste valg. Jeg sier bare at det er det mest brukte, og mest hensiktsmessige valget. Jeg sier også at Java er et dårligere valg (og da snakker jeg ikke om hobbyprosjekter, som jeg nevnte tidligere). Lisp har jeg ikke kritisert. Faktisk sitter jeg på et par bøker om Lisp jeg hadde tenkt å lese etter hvert. Java bruker jeg faktisk mye selv, men for det aller meste til Web. Benytter meg også av C# og ASM til tider. Så ikke kritiser meg for å evangelisere for C++: Jeg kommer bare med min anbefaling, som står sammen med stort sett alle anbefalinger man kan finne fra bransjen.

 

"Det finnes andre "rammeverk" (om du ønsker å bruke dét som samme ord for begge ting; biblioteker/JVM eller VMs generelt) som også ikke eksisterer på PS3 ennå. Ingen forskjell. Jeg vil dog tro flere er interessert i en eller annen JVM på Cell-arkitekturen; gjetter jeg ikke galt så vil jeg tro Sun er mer enn interesserte."

 

Ja, men ikke native. Det er forksjell på et hobbyprosjekt man må boote linux, og installere programvare for å spille, og kommersielle titler med Sony-emblem på esken. Java har da eksistert en god stund, men har ikke vært integrert i hverken PS2 eller Xbox'ene. Sony fokuserer da på det som faktisk er i bruk. Jeg sier ikke at dette aldri vil endre seg, men det er slik det ligger an i dag.

Lenke til kommentar
Om man velger "reference counting" er jo opp til en selv. Av andre algoritmer har man jo for eksempel "mark and sweep" og "copying"-algoritmene. Selvfølgelig kan man gjøre det tregere enn Java, men selvfølgelig er det også mulig å gjøre det raskere. Det er simpel logikk.

(edit: glømte å kommentere dette)

 

Nei, dette er ikke simpelt, ingenting er selvfølgelig - og det er ikke en gang der problemet med hastighet sitter 99% av tiden. I tillegg er hastighet i "tight inner loops" bare en brøkdel av problemene du støter på. Tar man C++ så finnes det en drøss problemer av design- og algoritme-messig art - begge ting som er mer avhengig av språk enn hastighet "der nede", man støter på lenge før man i det hele tatt har begynt å tenke på optimalisering i det som tilslutt viser seg å ende opp i "tight inner loops".

 

Vil legge til at man kan deaktivere GC og generelt sett "styre den" om ønskelig i andre språk enn C/C++ også; tror jeg glømte å nevne det bak her.

 

 

Du snakker som om jeg sier at C++ er eneste valg. Jeg sier bare at det er det mest brukte, og mest hensiktsmessige valget.

 

Ok, jeg synes ikke det er det mest hensiktsmessige i alle tilfeller; ikke en gang "de fleste". Jeg synes det du sier er en jumbo-generalisering - og det at det er det "mest brukte" er ikke et argument.

 

Når du sier at det er det _mest hensiktsmessige_ - noe som ikke stemmer i alle tilfeller, så utelukkes automatisk alle andre forslag og C++ gjenstår dermed som "eneste valg". Dette er fordi ingen vil bruke noe som er "dårligere eller _mindre hensiktsmessig_ enn C++" - en feilaktig generalisering som leder til tilsvarende feilaktig indusert fakta eller viten. Altså du generaliserer feilaktig, og tilskuere - de passive i hvertfall, induserer da automatisk frem gal informasjon basert på dette.

 

 

Vil man ha ting portabelt kan man jo bruke OpenGL. Stort sett alle OpenGL-programmerere bruker også C/C++. Sant nok at det er mer stress å måtte kompilere for hver plattform, men er det snakk om mer enn et hobbyprosjekt, burde ikke det være den avgjørende faktoren.

 

Som om det er mindre stress om man bruker DX om man siden skal porte? Her kan det høres ut som om du mener at OpenGL er manglende og at man kun aksepterer OpenGL som et kompromiss fordi det er portabelt - dette stemmer heller ikke.

 

Igjen snakker du om ting som "antall" og "alle" som om det skulle vært argumenter. Hadde alle (haha, "alle" igjen - sirkelen er sluttet) drevet på som deg så hadde verden stått stille.

 

 

Jeg sier også at Java er et dårligere valg (og da snakker jeg ikke om hobbyprosjekter, som jeg nevnte tidligere).

 

Vel, folk er tydeligvis uenige i det der - og samme hva du sier så utelukker du tilslutt alt annet enn C++ når du sier sånt; selv om vi holder oss innenfor "store spill". Kategoriseringer av prosjekter ser jeg bort i fra; det faller inn under "antall"- og "alle"-diskusjonen på samme vis som tidligere.

 

 

Lisp har jeg ikke kritisert. Faktisk sitter jeg på et par bøker om Lisp jeg hadde tenkt å lese etter hvert. Java bruker jeg faktisk mye selv, men for det aller meste til Web. Benytter meg også av C# og ASM til tider. Så ikke kritiser meg for å evangelisere for C++: Jeg kommer bare med min anbefaling, som står sammen med stort sett alle anbefalinger man kan finne fra bransjen.

 

Samme greia igjen; du baserer egne meninger utelukkende på ting utenfor deg selv og statistikk - har du i det hele tatt egne meninger?

 

 

Det finnes andre "rammeverk" (om du ønsker å bruke dét som samme ord for begge ting; biblioteker/JVM eller VMs generelt) som også ikke eksisterer på PS3 ennå. Ingen forskjell. Jeg vil dog tro flere er interessert i en eller annen JVM på Cell-arkitekturen; gjetter jeg ikke galt så vil jeg tro Sun er mer enn interesserte.

 

Ja, men ikke native.

 

Jo, med JIT blir det native. I tillegg tror jeg det finnes Java-kompilere som kan genere native kode i utgangspunktet også. (Kan noen bekrefte/avkrefte dette?)

 

 

Det er forksjell på et hobbyprosjekt (der) man må boote linux, og installere programvare for å spille, og kommersielle titler med Sony-emblem på esken.

 

Tulling; må man ikke "installere" .dll/.so-filer for at C-programvare skal fungere? Programvare ordner slike ting og avhengigheter generelt sett automatisk for brukerene. Igjen generaliseres dette altså til "avhengigheter" man ofte er (bør være) mer enn villig til å investere i.

 

Det at du kommer med slike argumenter som du åpenbart må (bør) innse at er svake viser at du er villig til å gjøre nesten hva som helst for å beskytte boblen eller illusjonen du sitter i. Du forsøker å "beskytte deg selv" mot det du feilaktig anser som "trusler" mot fundamentene du baserer dine valg og påstander på, men glømmer det som foregår rundt deg. Har du tenkt på at det vi snakker om her ikke handler om deg, meg, Java eller C++, men at det:

 

* Handler om en som ikke kan programmering i det hele tatt - noe som leder til det at det for han/hun ikke vil koste noe å "starte på nytt"? (noe som for andre som allerede kan programmering bør ansees som å "lære seg mer")

* Handler om en som er villig til å bytte språk eller bruke flere språk? (noe jeg er veldig fan av btw.)

* Handler om en som allerede kan et annet språk enn C/C++?

 

Vil legge til at jeg ikke kan fordra Java som språk i det hele tatt egentlig; så kan du jo fundere på hvorfor jeg gidder å argumentere "på vegne av Java" i utgangspunktet. (hint: jeg gjør ikke det; jeg argumenterer hverken for java eller lisp (ok - kanskje litt; men c/c++ har også fordeler) egentlig)

 

edit: om du lurer så er det forresten mulig - og helt vanlig, å boote et OS (et ribbet et med kun drivere til ting som GFX-kort og lyd o.l.) med Linux som kjerne rett fra CD/DVD uten at noe behøver å installeres først.. prøv selv: http://www.ubuntu.com/download/ .. som du ser her http://en.wikipedia.org/wiki/Linux_%28kernel%29#Portability så er linux støttet på Cell noe som tilsier at dette er mulig der også

 

 

Java har da eksistert en god stund, men har ikke vært integrert i hverken PS2 eller Xbox'ene. Sony fokuserer da på det som faktisk er i bruk. Jeg sier ikke at dette aldri vil endre seg, men det er slik det ligger an i dag.

6972628[/snapback]

 

Jeg aner ikke; men gløm de tingene der - vi snakker om språk (ikke maskinvare) og antar at innlegget bak her som nevnte Java tar utgangspunkt i platformer der Java allerede eksisterer. Bør vel si seg sjøl men .. :}

Endret av lnostdal
Lenke til kommentar
Det finnes andre "rammeverk" (om du ønsker å bruke dét som samme ord for begge ting; biblioteker/JVM eller VMs generelt) som også ikke eksisterer på PS3 ennå. Ingen forskjell. Jeg vil dog tro flere er interessert i en eller annen JVM på Cell-arkitekturen; gjetter jeg ikke galt så vil jeg tro Sun er mer enn interesserte.

 

Ja, men ikke native.

 

Jo, med JIT blir det native. I tillegg tror jeg det finnes Java-kompilere som kan genere native kode i utgangspunktet også. (Kan noen bekrefte/avkrefte dette?)

 

Ja, det er mulig å kompilere java til native kode. Et eksempel er JET, som vil kompilere til native hvis du ønsker. Den legger riktignok til en JIT compiler for å kunne takle dynamic class loading, som "bloater" den en del, men det er ingen installering som trengs.

 

For flere alternativer kan du søke etter AOT (Ahead Of Time) compiler.

 

Ellers vil jeg bare peke til denne. Den er kanskje ikke den mest objektive artikkelen, men han har litt peiling på hva han snakker om...

Lenke til kommentar
vi snakker om språk (ikke maskinvare) og antar at innlegget bak her som nevnte Java tar utgangspunkt i platformer der Java allerede eksisterer.

 

Nei, vi snakker om språk OG maskinvare. Om Java fungerer native på PS3 er et hardware-spørsmål. Det er selvfølgelig ingen ting i veien for å kompilere Java native generelt sett, men det avhenger av at det eksisterer et verktøy for dette til den aktuelle plattformen. Det er vel heller tvilsomt at dette er noen prioritet blant utviklerverktøyene for PS3-spill.

 

Tulling; må man ikke "installere" .dll/.so-filer for at C-programvare skal fungere? Programvare ordner slike ting og avhengigheter generelt sett automatisk for brukerene. Igjen generaliseres dette altså til "avhengigheter" man ofte er (bør være) mer enn villig til å investere i.

 

Offisielle konsolltitler krever ingen installasjon. De har avhengigheter, og det er bestemte biblioteker og funksjonalitet som ligger i systemets (her PS3s) native del. Man har så absolutt restriksjoner som konsollspillutvikler.

 

Vel, folk er tydeligvis uenige i det der - og samme hva du sier så utelukker du tilslutt alt annet enn C++ når du sier sånt; selv om vi holder oss innenfor "store spill".

 

 

Jeg utelukker da vel ikke Java selv om jeg anbefaler C++.

 

Samme greia igjen; du baserer egne meninger utelukkende på ting utenfor deg selv og statistikk - har du i det hele tatt egne meninger?

 

Jeg referer til mine egne erfaringer, og så er kommentaren at alt der basert på ting utenfor meg selv? Jeg sier jo at dette er min mening, og nevner samtidig at de fleste deler min mening. Det er da vel ikke noe galt i å se på andres erfaringer, og det gir jo absolutt argumentene mine mer hold at profesjonelle mener det samme. Her er eksempler:

 

http://www.gameinstitute.com/ - skolering i 3d-programmering, med en drøss av spillprorammerere i spissen

 

http://www.gamedev.net/reference/design/fe...tlang/page8.asp - en av verdens største og mest brukte ressurssider for temaet

 

http://www.igda.org/breakingin/path_programming.htm - den offisielle, internasjonale hovedorganisasjonen for spillutviklere

Lenke til kommentar
vi snakker om språk (ikke maskinvare) og antar at innlegget bak her som nevnte Java tar utgangspunkt i platformer der Java allerede eksisterer.

 

Nei, vi snakker om språk OG maskinvare. Om Java fungerer native på PS3 er et hardware-spørsmål. Det er selvfølgelig ingen ting i veien for å kompilere Java native generelt sett, men det avhenger av at det eksisterer et verktøy for dette til den aktuelle plattformen. Det er vel heller tvilsomt at dette er noen prioritet blant utviklerverktøyene for PS3-spill.

 

Nei, når Java ble nevnt sier det seg selv at det som menes er plattformer der Java eksisterer - eller man tar utgangspunkt i noen som er villige til å porte/implementere Java på aktuell plattform. Dette er en uaktuell diskusjon.

 

Tulling; må man ikke "installere" .dll/.so-filer for at C-programvare skal fungere? Programvare ordner slike ting og avhengigheter generelt sett automatisk for brukerene. Igjen generaliseres dette altså til "avhengigheter" man ofte er (bør være) mer enn villig til å investere i.

 

Offisielle konsolltitler krever ingen installasjon. De har avhengigheter, og det er bestemte biblioteker og funksjonalitet som ligger i systemets (her PS3s) native del. Man har så absolutt restriksjoner som konsollspillutvikler.

 

Dette er også en uaktuell diskusjon om du ikke har fantasi nok til å innse at det finnes avhengigheter man kan ta i bruk (eller lage) som ikke er bygget inn i selve maskinen, også på maskiner uten harddisk. Generelt sett - noe jeg må anta er manglende vilje til å forstå dette, gjør altså at jeg ikke er interessert i å fortsette diskusjonen i denne retningen; om du ikke har spørsmål da .. Dog sammenligningen med en linux-live-cd på PC burde egentlig vært nok; jeg kan røske ut alt av harddisker her og stappe inn en live-cd som booter en minimalistisk (eller ikke) linux med avhengigheter som drivere og også java til spillet mitt som da altså starter automatisk uten at man merker/ser at linux er der :}

Endret av lnostdal
Lenke til kommentar

Jeg må forøvrig få sagt at noe av det jeg har sagt i senere poster fremstår feilaktig nå, etter som lnostdal har endret enkelte av sine tidligere poster, antakeligvis for å oppnå akkurat dette.

 

Men han påstår vel bare at han retter skrivefeil ni dager etter innlegget ble postet, og at jeg husker helt feil når jeg påstår at innholdet i posten har forandret seg.

 

Patetisk. Det er alt jeg har å si.

Lenke til kommentar
Jeg må forøvrig få sagt at noe av det jeg har sagt i senere poster fremstår feilaktig nå, etter som lnostdal har endret enkelte av sine tidligere poster, antakeligvis for å oppnå akkurat dette.

 

Men han påstår vel bare at han retter skrivefeil ni dager etter innlegget ble postet, og at jeg husker helt feil når jeg påstår at innholdet i posten har forandret seg.

 

Patetisk. Det er alt jeg har å si.

6983582[/snapback]

 

https://www.diskusjon.no/index.php?showtopi...=entry6961667 28/9 - sist endret 28/9 (~12 minutter)

https://www.diskusjon.no/index.php?showtopi...=entry6961948 29/9 - sist endret 29/9 (~1 minutt)

https://www.diskusjon.no/index.php?showtopi...=entry6962078 29/9 - sist endret 29/9 (~20 minutter)

https://www.diskusjon.no/index.php?showtopi...=entry6961899 28/9 - sist endret 29/9 (~20 minutter)

https://www.diskusjon.no/index.php?showtopi...=entry6962336 29/9 - sist endret 29/9 (~ett par timer, men grytidlig på morran; ingen svar eller lesere i løpet av tiden)

https://www.diskusjon.no/index.php?showtopi...=entry6964685 29/9 - aldri endret

https://www.diskusjon.no/index.php?showtopi...=entry6964429 29/9 - sist endret 29/9 (~1.5 timer; men ingen redigeringer etter svar)

https://www.diskusjon.no/index.php?showtopi...=entry6973533 30/9 - sist endret 1/10 (~13 timer; - postet sent og redigert på formiddag dagen etterpå, men ingen redigeringer etter svar (fra deg))

https://www.diskusjon.no/index.php?showtopi...=entry6980223 1/10 - sist endret 1/10 (~25 minutter; ingen endringer etter svar her heller)

 

..vel; jeg legger ofte til mer og retter skrivefeil - men ikke 9 dager etter .. heh .. og det er ytterst sjeldent jeg fjerner noe jeg har sagt i en tidligere post om jeg ikke nettopp har postet den da - og spesielt ikke om jeg allerede har fått svar på tingene jeg har sagt i innlegget

 

(om noe er endret i postene mine nå (edit: orker ikke se over i detalj ATM) så skal du ikke se bort i fra at noen admins/mods har fjernet det de mener er "usakelig personangrep" ellernoeannet opplegg - noe som selvfølgelig leder til ødelagte og brekte tråder de-luxe.. det er ikke første gang slike ting skjer med hverken meg eller andre; sjekk: http://nostdal.org/~lars/usenet.html )

 

edit: tids-greiene i parantes blir lagt til nå mens jeg redigerer; knotete :}

Endret av lnostdal
Lenke til kommentar
Oisann, du glemte visst en.

 

https://www.diskusjon.no/index.php?showtopi...0entry6901957 20/9 - sist endret 29/09

(~9 dager)

 

Og ja, det var den posten jeg siktet til. Men nå skulle vi snakke om mer fornuftige ting, så da kan heller de som har noe å tilføye få slippe til.

6984996[/snapback]

 

ok, greit - men ingenting der hører til det du og jeg har diskutert - derfor tok jeg ikke den med når jeg tittet over det vi diskuterte; jeg trodde du gjorde en "wild guess" når du sa 9 dager

 

om jeg ikke husker helt feil så la jeg til det om Ogre3D og linkene til blue/red-book; mer info om samme ting, altså kun om OpenGL i seg selv -- og jeg anser ikke den eller det som en del av diskusjonen vi har hatt i det hele tatt og forstår ikke hvordan du kan "ha noe med det å gjøre" da du ikke har kommentert/svart på det innlegget i det hele tatt

 

edit: det er selvfølgelig åpenbart at du troller .. så om du ikke har noe mer å legge til om andre ting er jeg ikke interessert i å diskutere dette sub-emnet noe mer

 

edit2:

bare legge til at om jeg visste (eller i det hele tatt tenkte på) at det var den du kunne mene så hadde jeg _selvfølgelig_ tatt med både den og det jeg sier her - det kan jeg garantere deg; jeg har ikke utelatt den for å "jukse" - jeg er ikke feig sånn

Endret av lnostdal
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...