hishadow Skrevet 15. februar 2008 Del Skrevet 15. februar 2008 (endret) Java er ganske rotete oppbygd egentlig. Det er litt sånn "lappeverk" hvor man før hadde Java.Gui-opplegget, så kommer plutselig javax.swing, som inneholder både GUI og mye annet rart. Et gammelt jungelordtak noen lærte meg om Java: Write Once, Debug Everywhere. Ellers er C# sammen med .NET sikkert et fint sted å begynne. Men det er stort og mye å sette seg inn i. Endret 15. februar 2008 av hishadow Lenke til kommentar
steingrim Skrevet 15. februar 2008 Del Skrevet 15. februar 2008 Java er ganske rotete oppbygd egentlig. Det er litt sånn "lappeverk" hvor man før hadde Java.Gui-opplegget, så kommer plutselig javax.swing, som inneholder både GUI og mye annet rart. Et gammelt jungelordtak noen lærte meg om Java: Write Once, Debug Everywhere. Heldigvis skriver de færreste Java-utviklere Swing/AWT/SWT-applikasjoner som skal distribureres til sluttbrukere Og dermed er ikke det ordtaket like sant lenger. Langt på vei de fleste Java-jobber er web/backend vil jeg tro. (Og hvis utvikling, test, pre-prod og prod benytter samme plattform får man luket ut mange feil ...) Lenke til kommentar
GeirGrusom Skrevet 15. februar 2008 Del Skrevet 15. februar 2008 Java er ganske rotete oppbygd egentlig. Det er litt sånn "lappeverk" hvor man før hadde Java.Gui-opplegget, så kommer plutselig javax.swing, som inneholder både GUI og mye annet rart. Et gammelt jungelordtak noen lærte meg om Java: Write Once, Debug Everywhere. Ellers er C# sammen med .NET sikkert et fint sted å begynne. Men det er stort og mye å sette seg inn i. Hehe, fordelen med C# sammen med .NET er at programmeringsspråket er mer moderne, og rammeverket er bedre gjennomtenkt, siden de har lært av java sine feil. Lenke til kommentar
kake_fisk Skrevet 16. februar 2008 Forfatter Del Skrevet 16. februar 2008 hmm, C# høres best ut da, men jeg tror jeg skal velge delphi. :S fordi game maker er skrevet i delphi, da vil det bli enklere å lage dll's til game maker og sånt. Lenke til kommentar
Manfred Skrevet 16. februar 2008 Del Skrevet 16. februar 2008 Er det fortsatt støtte til delphi altså? Jeg vet høgskoler sluttet med delphi for 6-8 år siden... Lenke til kommentar
GeirGrusom Skrevet 16. februar 2008 Del Skrevet 16. februar 2008 Driver med et delphi prosjekt nå faktisk Som kjent så ble Delphi brukt på grunn av at det støttet Oracle såpass bra "If you want to talk to [the] Oracle, go to Delphi" Selv er jeg ikke det minste imponert over delphi. Det er gammeldags. I likhet med Java og Visual Basic, bruker Delphi et interface system for å støtte events. Dette fordi disse språkene mangler noe som C, C++, C#, Visual Basic.NET og D har, nemlig delegates(C#, VB.NET, D), pointer to function(C, C++, D) eller pointer to member (C++) Lenke til kommentar
LysDiode Skrevet 16. februar 2008 Del Skrevet 16. februar 2008 Tror nok VB.Net er enklest å lære, selvom andre språk sikkert har flere fordeler.. Lenke til kommentar
Kenjuudo Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Hei folkens... Jeg er fullstendig klar over at denne tråden er veldig gammel, men jeg synes det ble uttalt en del ulærde kommentarer her og jeg ble rent mentalt nødt til å svare litt... Først litt info om meg siden jeg er ny på forumet: Jeg er 29 år og har programmert i 21 av dem og har hatt mange programmeringsjobber og jobber med den dag i dag. (Ja, jeg begynnte da jeg var 8 og er altså skikkelig programmerernerd. Liker imidlertid å gå rundt og overbevise meg selv om at jeg ikke er Tufte-emne! ) Jeg har også jobbet med en hel rekke med forskjellige programmeringsspråk (Alltid med hovedinteresse dataspill!), og mener derfor at jeg er rimelig kvalifisert på å svare på spørsmålet ditt, kake_fisk. Jeg skal først forklare det helt grunnleggende med hvordan prosessoren i dataen jobber. Og så kommer jeg med en liten liste med noen av de mer relevante språkene i rekkefølge basert på hvor langt vekk fra prosessoren og hardwaren de abstraherer ting. Og jeg er grundig! Som de fleste her inne [egentlig] vet, skjønner ikke dataen noe annet enn elektriske impulser. Lite strøm, masse strøm. Disse blir av en veldig enkel ADC (Analogue to Digital Converter) konvertert til 0'ere og 1'ere (Noe som må gjøres fordig mengden strøm som betyr "på" ikke nødvendigvis betyr 100% strøm på (Normalt jobber ADC'en ut i fra at 60%-100% strøm på betyr 1, og alt under er 0). Disse detaljene er strengt tatt ikke så veldig viktig i dag, fordi du for det meste kan stole på at dataen ikke gjør feil (Men i gamledager, da hardwaren var mye dårligere enn i dag, måtte man allikevel sjekke med noe som heter "parity bit", men det blir altfor off-topic). Siden vi bare har 0'ere og 1'ere, jobber man ut i fra et tallsystem som heter "binary" (bi-nary, eller totallssystemet), og et siffer i dette systemet blir kalt en "bit" (BInary digiT). En bit kan altså ha verdien 0 eller verdien 1. Siden vi mennesker trenger større tall, måtte vi sette sammen en rekke av disse bit'ene. Antallet bits gir deg direkte informasjon om hvor store tall man kan representere, og det med formelen (2^bit_antall) - 1 (Hvor ^ betyr opphøyd i). Eksempelvis kan du telle fra 0 til 255 med 8 bits siden (2^8) - 1 = 255, og fra 0 til 65535 med 16 bits siden (2^16) - 1 = 65535. (Forresten så blir en rekke på 8 bits ofte kallt en "byte", og en rekke på 16 bits blir ofte kallt en "word") Prosessoren i datamaskinen blir ofte kallt dataens hjerne, men i virkeligheten kan den ikke tenke i det hele tatt. Det eneste den kan, er å huske noen få bitrekker i noe som blir kallt "prosessor-registre" (Dette har ingenting med windows registeret å gjøre), og bruke disse til å lese og skrive informasjon i minnet, noe den gjør ved først å lese instruksjoner som hele tiden forklarer den hva den skal gjøre. Registrene er definert til å ha spesial funksjoner. For eksempel har du et register som heter IP (Nei, ikke "internet protocol", men "instruction pointer"). Tallet som IP registeret kan holde på blir automatisk brukt av prosessoren som en adresse i minnet og "peker" alltid på neste instruksjon som skal utføres. Enkelt forklart, så henter prosessoren noen bytes derfra, og oversetter tallene (bytene) til instruksjoner. For eksempel kan en instruksjon bety "les noen flere bytes fra en annen adresse", eller "send noen bytes fra et annet register til en port", eller "hopp til en annen instruksjon". Dette kalles maskinkode, er det *eneste* prosessoren forstår (og er derfor det laveste nivået du kommer) og er dessuten bare leselig for prosessoren og enkelte tullinger uten noe sosialt liv og som aldri har pult. Pga. at maskinkode er så vanskelig for mennesker, lagde man noe som kalles "symbolic instruction code", eller "assembly". Assembly er maskinkode oversatt til liksomengelsk sånn at det går an å forstå det (Og programmere i det). Assembly har også den egenskapen at det er en til en relasjon med maskinkode (Du kan oversette frem og tilbake mellom de to, uten å miste informasjon). Du bruker en Assembler for å oversette Assembly til maskinkode. Assembly ble allikevel for knotete når programmene begynnte å bli større, så man fant ut at man skulle lage høyere nivå språk. Disse språkene ble kallt "procedural languages" og ble oversatt (kompilert) til maskinkode ved hjelp av et kompileringsverktøy (compiler). Kompilerte programmeringsspråk har aldri en til en relasjon med maskinkode/assembly, og man kan derfor ikke oversette tilbake igjen. Men til gjengjeld kunne man nå lage mye større programmer og fremdeles holde oversikten. Eksempler på procedurale språk er blandt annet C og Pascal. I nyere tid kan programmene bli så gigantiske at man selv med kompilerte programmeringsspråk lett kan miste oversikten. Så en fantasifull nerd fant ut at det hadde vært nyttig å kunne skjule deler av koden, som allikevel fungerer selvstendig, slik at man slipper å ta hensyn til det hele tiden og kunne bruke kode om igjen i andre programmer uten å måtte forandre på noe. Og det er dette som er objekt orientert programmering (OOP). Nå kunne man pakke kode inn i såkallte objekter og glemme dem. Et objekt er egentlig bare en datastruktur som kan holde på både data og kode som jobber med disse dataene. Utenfra, ser et objekt ut som en klump gugge (innpakket skummel kode) med enkle funksjoner som den deler med resten av programmet ditt. Eksempler på OOP-språk er C++, Visual Basic (VB) og Delphi. Det mest moderne i dag, er allikevel såkallte "intermediate language"-compilere. Intermediate language (IL) er et slags mellomnivå mellom koden du jobber med, og maskinkode. Du må imidlertid ha et IL-oversetter-rammeverk installert for å kjøre slike programmer, men fordelene knuser ulempene og innbefatter blandt annet at du kan overlate optimering, minnehåndtering, "exception handling", osv. til rammeverket. Nå du kjører et slikt program, kjører rammeverket sin "just-in-time compiler" igjennom IL-koden og oversetter den til maskinkode slik at prosessoren kan forstå det. Det sier seg kanskje selv at disse programmene således ikke trengs å kompileres på nytt igjen av deg for å kjøre på andre platformer som mobiltelefoner, så lenge disse også har dette rammeverket installert. (Mobiltelefoner (blandt annet) har en annen prosessor enn PC-er, og forstår derfor ikke samme maskinkode). Eksempler på IL-språk er C#, Oxygene og Java. Så, da har jeg kommet så langt at jeg kan begynne å liste opp programmeringsspråk, og du/dere har fått en enkel (!) innføring i hva som skjer i innmaten. (Jeg mener helt bestemt at å forstå hva som skjer internt, gir deg fantastiske fordeler når det gjelder programmeringsevne i høyere nivå språk, så jeg anbefaler å google i samme øyeblikk du lurer på noe) 1) Maskinkode (Dritvanskelig, tilnærmet lik umulig. Glem det!) 2) Assembly (Vanskelig å lære, og vanskelig å lage store programmer i, men nyttig å kunne for å lage sykt kjappe rutiner) 3) C (Passe vanskelig, dårlig på store programmer, brukes for drivere og direkte hardware access) 4) Pascal (Rimelig enkelt, men dårlig på store programmer, utdatert og dødt) 5) C++ (Passe vanskelig, dårlig på GUI programmer, veldig bra på spill ) 6) Delphi (Rimelig enkelt, perverst bra på GUI programmer (har den desidert beste GUI designeren)) 7) Visual Basic (Enkelt, men begrenset, treigt og bloated språk... Sky som pesten!) 8) C# (Pisseenkelt... Definitivt det enkleste programmeringsspråket du finner... Alt er lett i C#) 9) Java (Ligner litt på C#, men er bloated og har veldig dårlig rykte. Anbefales ikke!) Det finnes selvsagt hundrevis av flere språk, men disse er de jeg har jobbet med og er også de som er mest relevante når du skal velge språk. Til slutt vil jeg kommentere noen uttalelser! hmm, C# høres best ut da, men jeg tror jeg skal velge delphi. :Sfordi game maker er skrevet i delphi, da vil det bli enklere å lage dll's til game maker og sånt. Velg gjerne Delphi for å lage dll'er, men mitt råd er å heller skifte fra Game Maker og lære seg C#!!! Er det fortsatt støtte til delphi altså? Jeg vet høgskoler sluttet med delphi for 6-8 år siden... Mange bedrifter sitter fremdeles med Delphi, fordi Delphi i grove trekk er bakoverkompatibelt med Pascal, og mange bedrifter har hundretusenvis av linjer med gammel kode skrevet i Pascal (Fordi det var lettere å lære enn C). Dermed slipper de å skrive alt om igjen i et annet språk. På den annen side holder Delphi på å dø ut. De fleste bedrifter skifter i dette øyeblikk til C# eller Java (grøss!)... Driver med et delphi prosjekt nå faktisk Som kjent så ble Delphi brukt på grunn av at det støttet Oracle såpass bra "If you want to talk to [the] Oracle, go to Delphi" Selv er jeg ikke det minste imponert over delphi. Det er gammeldags. I likhet med Java og Visual Basic, bruker Delphi et interface system for å støtte events. Dette fordi disse språkene mangler noe som C, C++, C#, Visual Basic.NET og D har, nemlig delegates(C#, VB.NET, D), pointer to function(C, C++, D) eller pointer to member (C++) Delphi støtter pointere i alle farger og fasonger. Untyped, functions/procedures, members og andre variabler og alle slags datatyper inkludert brukerdefinerte datatyper. Så ikke kom her og kom her. Og da har jeg fått tytt fra meg... Og klokken er altfor mye og jeg må jobb om 4 timer... -Kenjuudo Lenke til kommentar
Manfred Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Jeg bare hang meg litt opp i en kommentar om maskinkode, og mennesker som ikke eier sosialt liv og aldri har pult... og tenkte videre på dette langt innlegget skrevet kl 04:19 på natta midt i arbeidsuken...... hehe Lenke til kommentar
Kenjuudo Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Jeg bare hang meg litt opp i en kommentar om maskinkode, og mennesker som ikke eier sosialt liv og aldri har pult... og tenkte videre på dette langt innlegget skrevet kl 04:19 på natta midt i arbeidsuken...... hehe Hehe, jeg var trøtt! Lenke til kommentar
siDDis Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 (endret) Eg vil påstå at Java er eit betre valgt enn C#. Fordelen med Java framfor C# er at communityen rundt Java er mange gonger større og det finnes masse ekstra rammeverk og verktøy som har fri lisens, fantastisk dokumentasjon som sparer ein for masse tid. Hibernate, og Groovy er eit av mange eksempler. Ellers er dei så og si heilt like å programmere i. Å gå frå Java til C# er som å flytte frå Bergen til Stavanger, det meste er faktisk heilt likt, men det er disse bitte små forskjellane her og der. Ytelsesmessig er dei og heilt like. Men valg av førstespråk kjem mykje ann på kva er det ein vil lære. Uansett kva slags språk ein lærer seg så er det lett å konvertere til eit anna språk. Ingen språk er heller best til alt, spessielt Java og C# prøver å være best på alt, men ofte så er språk som Lua/Python/Ruby/Perl/Erlang/Fortran eit mykje betre alternativ. Ein god utvikler velger det rette verktøyet til jobben og tilpasser ikkje jobben til eit verktøy. Mine anbefalinger for førstespråk er Python eller Javascript som er to utroleg enkle språk å koma i gong med. Eg helst anbefaler Javascript for å lære seg elementere ting, fordi Javascript er så utroleg enkelt å få til å kjøre. Javascript er og veldig lett til å få til meir visuelt enn eit kjedeleg terminalvindauge. Men overlever ein det så er Python eit solid valg! Oppsett og innstallasjon av nye programmeringsspråk er som regel det som er vanskeligst å få til av alt som finnes i ein programmeringsverda. Og det er det eg enda banner og steiker mest over når eg gjør noko i C/C++ som bruker meir enn standardbibloteket. Det er blant ein av grunnane mange begynner med PHP som er rimeleg enkelt å koma i gong med. Syntaxen i PHP er derimot ikkje så lettlest som det er i Python etter min meining. Endret 16. mai 2008 av siDDIs Lenke til kommentar
Kenjuudo Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Uansett er det (foreløpig) C/C++, C# og Java de fleste firmaer bruker. Jeg anbefaler på det sterkeste å lære seg et eller flere ut av disse fire som begynnerspråk, fordi jeg av erfaring vet det er lett å bli "hengende" på det språket i årevis. Velger du et av disse, får du etterhvert veldig gode forutsetninger for å kunne jobbe med dem profesjonellt, og tjene gode penger! Lenke til kommentar
Manfred Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Jeg har det med å henge meg opp i småting, men siddis påstår at java og C# er like ytelsesmessig. Det er en sannhet med endel modifikasjoner. Konsollbasert er Java veldig fint, men med en gang du skal i gang med GUI støter vi på noen ytelses-utfordringer. Det er veeeeldig lett å gjøre et Java-program fullstendig sirup, og jeg har erfaring med når jeg prøver å kjøre to litt store java-programmer samtidig (selv om det ene bare ligger der og ikke er i bruk), så går det andre fullstendig sirup. Erfaring tilsier altså: konsollbasert er de like kjappe omtrent, men GUI-messig ligger fortsatt Java langt bak. Lenke til kommentar
steingrim Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Erfaring tilsier altså: konsollbasert er de like kjappe omtrent, men GUI-messig ligger fortsatt Java langt bak. Jeg er helt enig i det du sier, men det er også verdt å merke seg at Java ikke nødvendigvis ligger "bak". Det er rett og slett ikke vanlig å lage GUI-applikasjoner i Java. Jeg har aldri sett noen Java-stilling kreve Swing/AWT/SWT, "alle" lager web-applikasjoner/tjenester. C# / .NET har sin store styrke på Winforms, det er dette de er gode til. Java prøver ikke være god på tilsvarende applikasjoner. Derfor blir det litt feil å sammenligne synes jeg. Lenke til kommentar
siDDis Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 (endret) Uansett er det (foreløpig) C/C++, C# og Java de fleste firmaer bruker. Jeg anbefaler på det sterkeste å lære seg et eller flere ut av disse fire som begynnerspråk, fordi jeg av erfaring vet det er lett å bli "hengende" på det språket i årevis. Velger du et av disse, får du etterhvert veldig gode forutsetninger for å kunne jobbe med dem profesjonellt, og tjene gode penger! Javascript blir og mykje brukt idag og er svært etterspurt kompetanse. Etter Ajax bølgen kom for 4 år sidan så er Javascript blitt veldig hot! Ijallefall her i landet. Jeg trur det er svært få firmaer som utvikler web applikasjoner som ikkje bruker Javascript idag Java har hatt treig GUI, men det har vært mange forbetringer her. F.eks så synes eg aTunes er eit eksempel på at Java GUI kan være reponsivt, raskt og ta lite minne. Java har og vist seg til å være tilnerma like raskt i OpenGL som C, det er ein bitteliten forskjell på 10-15% som skilles når det kjem til ytelse. Men kor mykje tid blir ikkje spart på utviklingstid? Endret 16. mai 2008 av siDDIs Lenke til kommentar
GeirGrusom Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Hva har JavaScript med dette å gjøre? Anyways, når det gjelder OpenGL har jeg funnet ut at C# har to enorme fordeler over java: pekere og delegates. Jeg har skrevet et OpenGL bibliotek kun i C# som støtter GLSL, og andre extensions kan enkelt implementeres utenfor biblioteket, fordi C# støtter delegates.. public static T GetProcedure<T>(string procname) where T : class { IntPtr ptr = OpenGL.NativeOpenGL.wglGetProcAddress(procname); if (ptr == IntPtr.Zero) return default(T); return (T)Convert.ChangeType(System.Runtime.InteropServices.Marshal.GetDelegateForFunctionPointer(ptr, typeof(T)), typeof(T)); } glCreateShaderObjectARB = GetProcedure<PFNGLCREATESHADEROBJECTARBPROC>("glCreateShaderObjectARB"); // etc. // Shader klassen public void Compile() { int len = m_code.Length; OpenGL.NativeOpenGLExt.glShaderSourceARB(m_shader, 1, new string[] { m_code }, ref len); OpenGL.NativeOpenGLExt.glCompileShaderARB(m_shader); } Dette er utdrag fra klassen Glorg.Shader.Class, og fra OpenGL.NativeOpenGLExt. Et eksempel på et sted der pekere kan være hendige er [System.Runtime.InteropServices.DllImport(OpenGLModule)] public static extern unsafe void glTexImage2D(uint target, int level, int internalformat, int width, int height, int border, uint format, uint type, void* pixels); Teksturen må låses for GC før OpenGL kan bruke det, det gjøres enten ved fixed funksjonen, ved å bruke Bitmap.Lock, eller med GCHandle.Allocate, avhengig av hvordan du har laget teksturen. Lenke til kommentar
Kenjuudo Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Uansett er det (foreløpig) C/C++, C# og Java de fleste firmaer bruker. Jeg anbefaler på det sterkeste å lære seg et eller flere ut av disse fire som begynnerspråk, fordi jeg av erfaring vet det er lett å bli "hengende" på det språket i årevis. Velger du et av disse, får du etterhvert veldig gode forutsetninger for å kunne jobbe med dem profesjonellt, og tjene gode penger! Javascript blir og mykje brukt idag og er svært etterspurt kompetanse. Etter Ajax bølgen kom for 4 år sidan så er Javascript blitt veldig hot! Ijallefall her i landet. Jeg trur det er svært få firmaer som utvikler web applikasjoner som ikkje bruker Javascript idag Java har hatt treig GUI, men det har vært mange forbetringer her. F.eks så synes eg aTunes er eit eksempel på at Java GUI kan være reponsivt, raskt og ta lite minne. Java har og vist seg til å være tilnerma like raskt i OpenGL som C, det er ein bitteliten forskjell på 10-15% som skilles når det kjem til ytelse. Men kor mykje tid blir ikkje spart på utviklingstid? Jeg ønsker ikke å være vanskelig, men Java kan ikke engang komme i _nærheten_ av C når det gjelder ytelse og Javascript er i grunnen en smule off-topic uansett. I gamledager, var Java faktisk også interpretert, noe som har mye av skylden for Java's dårlige rykte i dag. Java blir (på lik linje med C#) imidlertid kompilert til IL kode i dag, som gjør at man nødvendigvis må miste oversikten over hvordan programmet blir optimert av JIT'ens optimizer. Dette gjør at mange av de gamle optimeringsteknikkene ikke lenger fungerer som forventet, og man må settle med å stole på JIT'en... (Java.NET lager samme type IL som C# og VB.NET, mens standard Java lager sin egen) C og C++ lager derimot (i utgangspunktet) maskinkode direkte og du har dermed full (Ja, hvis du er guru...) oversikt over hvordan den ferdige maskinkoden skal se ut. Dermed kan man sitte og flikke på koden for å eliminere ticks både her og der. For ikke å snakke om at slike språk som oftest støtter inline assembly direkte i kildekoden. Når det gjelder både OpenGL og Direct3D (som er to forskjellige typer softwarelayer som snakker med grafikkdriverene, som igjen snakker med skjermkortet), så er ytelsen identisk uansett hva slags språk du bruker, fra det tidspunktet programkontrollen forlater koden din og blir overført til API'en, til det øyeblikket kallet returnerer. Derfor er det ingen vits i å trekke det frem i denne diskusjonen... Jeg skal ikke knuse Java helt, for det er mange som er frelst. Det eneste jeg vil si, er at C# er enklere å lære, og er raskt nok til å lage små produksjonsspill (Ja, også med fantastisk highend 3D grafikk). .NET API'en er dessuten ekstremt godt utbygget for å være så ung, og inneholder absolutt all slags støtte for å gjøre spillprogrammering smertefritt (Det passer kanskje bra å spesifisere her at man som nybegynner kan hente ned XNA til C# gratis fra Microsoft. Funker utmerket med C# Express). XNA er et rammeverk laget for spillutviklere, bruker DirectX, og fikser alt som har med vindu's håndtering og messageloopen slik at man kan konsentrere seg om å lage spill istedenfor å rote med winforms og/eller winapi. Til slutt ville jeg ha sagt at så og si alle kommersielle spill er laget i C++. C++ er kjappt som nøkken (hvis du kan bruke det), men er ganske vanskelig å begynne med som nybegynner. -Kenjuudo Lenke til kommentar
GeirGrusom Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Største fordelen med C++ vil jeg si at først og fremst er tilgjengelige biblioteker. Jeg driver med spillutvikling i C++ og da går det på OpenGL, OpenAL og PhysX. Selv om både OpenGL og OpenAL er ganske enkelt å få¨til å fungere i C#, er PhysX temmelig komplisert å få til å fungere der, fordi en må oversette PhysX sitt "low-level" API, som er ganske stort. Men i C++ er PhysX ufattelig enkelt å bruke, men med alle de ulempene som C++ kan gi deg (og fordelene selvsagt, først og fremst hastighet og kontroll) Lenke til kommentar
siDDis Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 (endret) Jeg ønsker ikke å være vanskelig, men Java kan ikke engang komme i _nærheten_ av C når det gjelder ytelse Fleire implementasjoner har vist at Java kan være raskere enn C, men det er veldig sjeldent. Du kan også kompile Java rett til maskinkode med f.eks GCJ og då reduserer ein *oppstarts* tiden betraktelig som er ein kjempefordel for GUI programmer. Men ein utviklingshastigheit som meir enn dobles samanlikna mot C som har bare *litt* betre ytelse er etter min meining mykje meir attraktivt. Men C er enda kongen på haugen om ytelse er ein viktig faktor, som til f.eks spel. Dessuten så blir fleire og fleire spel idag utvikla i fleire språk, LUA har blant anna blitt veldig populært i fleire kommersielle spel. Endret 16. mai 2008 av siDDIs Lenke til kommentar
steingrim Skrevet 16. mai 2008 Del Skrevet 16. mai 2008 Det er svært få java-programmere som trenger OpenGL eller lignende. Man velger riktig verktøy til jobben, skal man lage spiller ikke Java det riktige, i andre tilfeller er Java det riktige. Lenke til kommentar
Anbefalte innlegg