Runar0 Skrevet 20. september 2006 Rapporter Del Skrevet 20. september 2006 Hei, Har i en god stund tenkt på å prøve litt directx programering i c++, men eg trenger noen tips for å få startet. Det er ønsker å lære meg er å kunne bruke directx i c++ til å lage 3d programer (Spill) og lære meg å bruke noen verktøy for å lage maps/modeller. Eg er klar over at dette målet kanskje er for vanskelig for en hobby programerer men det skader ikkje å prøve eller ? I dag har eg erfaring fra java, web scripting(javascript, php, html osv.) og litt enkel C++ Noen som har noen bøker/websider eg kan lese for å komme i gang ? Lenke til kommentar
Gjakmarrja Skrevet 20. september 2006 Rapporter Del Skrevet 20. september 2006 Velkommen! Har du prøvd google? Start med SDK til DirectX. Lenke til kommentar
prebenl Skrevet 20. september 2006 Rapporter Del Skrevet 20. september 2006 www.gameinstitute.com koster litt penger, men de har utrolig bra metariale. har tatt c++ modul 2 og directx modul 1. anbefales på det sterkeste. Lenke til kommentar
lnostdal Skrevet 20. september 2006 Rapporter Del Skrevet 20. september 2006 (endret) Hum, tja .. off-topic, men har du vurdert OpenGL fremfor DirectX? http://nehe.gamedev.net/ http://www.opengl.org/documentation/red_book/ http://www.opengl.org/documentation/blue_book/ OpenGL har et par fordeler; mens DX kun fungerer på Microsoft-platformen fungerer OpenGL på flere som f.eks. PC (win32/ms), Mac, Linux, Sun, PS3 .. o.s.v. Jeg synes OpenGL er lett å lære og kjapp å komme i gang med; og jeg tror en hobbyprogrammerer kan få til gangske mye artig v.h.a. dette. (edit: dette betyr ikke at man ikke kan lage avanserte ting med OpenGL: Doom3, Unreal Tournament, Half Life 2, WoW, Quake 3 .. o.s.v. .. bruker OpenGL (noen kan skifte mellom OpenGL og DX-modus)) Man bruker ofte hjelpe-biblioteker som f.eks. Ogre3D som tar seg av de vanskeligste oppgavene: http://www.ogre3d.org/ .. denne fungerer også på flere platformer siden den tar i bruk OpenGL i "bakhånd". Endret 29. september 2006 av lnostdal Lenke til kommentar
Giddion Skrevet 20. september 2006 Rapporter Del Skrevet 20. september 2006 GameDev.net Særlig Artiklene. UltimateGameProgramming FlipCode Jeg har ingen personlig erfaring med denne siden, men den skal vist være en slags NeHe (som har hjulpet meg veldig mye med OGL) for d3d NeXe En siste ting som du sikkert vet så er dx flere moduler. Nå har MS annonsert fjerning av hw støtten i DirectSound(3D) i Vista så da er det vel bare DirectGraphics og DirectInput som fortsatt er under utvikling. Merk DI er ikke anbefalt av ms for bare tastatur og mus. Litt off-topic: Jeg er helt enig med lnostdal når det gjelder OGL framfor d3d Ellers lykke til hva enn du måtte velge Lenke til kommentar
Runar0 Skrevet 21. september 2006 Forfatter Rapporter Del Skrevet 21. september 2006 Takk for alle tipsa Har sett litt på både www.gameinstitute.com og OpenGL sidene, og det blir nok OpenGL. Lenke til kommentar
krigun Skrevet 26. september 2006 Rapporter Del Skrevet 26. september 2006 Takk for alle tipsa Har sett litt på både www.gameinstitute.com og OpenGL sidene, og det blir nok OpenGL. 6908240[/snapback] Tenkt på at du kan kode OpenGL i Java? Er jo mye smoothere enn C++, think about it homeboy. Det aller første du kommer til å abstrahere bort er jo nemlig OpenGL kallene, så da sitter du igjen med selve programmeringsspråket. Jeg foretrekker Java any day fremfor C++ og minnepekere... jeeezzz... JOGL: https://jogl.dev.java.net/ jMonkeyEngine: www.jmonkeyengine.com LWJGL: http://www.lwjgl.org Xith3D: http://www.xith3d.org Lenke til kommentar
Giddion Skrevet 26. september 2006 Rapporter Del Skrevet 26. september 2006 Jeg skal prøve å ikke spinne helt ut av topicen og lage en java vs c++ diskusjon, men trådstarter nevner spill som et mål.. og vel java er ikke det jeg ville brukt til å lage spill med (jaja sånne "små" spill går sikkert fint), java har rett og slett ikke det som trengs for å lage spill/programmer som har høy ytelse. OFFTOPIC Du (krigun) vet sikker dette, men JSR 231 (java binding for OGL) v 1.0 er endelig ute. Lenke til kommentar
krigun Skrevet 27. september 2006 Rapporter Del Skrevet 27. september 2006 .. og vel java er ikke det jeg ville brukt til å lage spill med.. OFFTOPIC Du (krigun) vet sikker dette, men JSR 231 (java binding for OGL) v 1.0 er endelig ute. 6946308[/snapback] Nei, vil ikke starte en flamewar her, men det er faktisk fullt mulig å skrive store spill i java. Holder faktisk på med det nå selv, og flere benchmarks av Java vs C++ viser at det er så å si ingen forskjell i hastighet. Java bruker bare lenger tid å starte opp første gangen, og bruker mer minne. Whatever. Spill skrevet i java: http://www.tribaltrouble.com/ Og ja, bruker nå JSR 231 Lenke til kommentar
Giddion Skrevet 27. september 2006 Rapporter Del Skrevet 27. september 2006 Det var først og fremst minnebruken jeg tenkte på ja. Lenke til kommentar
krigun Skrevet 27. september 2006 Rapporter Del Skrevet 27. september 2006 (endret) Det var først og fremst minnebruken jeg tenkte på ja. 6948610[/snapback] Jada, your average PC gamer i 2006 sliter ikke akkurat med for lite minne vil jeg tro... Er vel heller omvendt.. + Si hva du vil om C++ og platformuavhengighet (Gotta love those IFDEFS... ).. men Java koden du skriver mot JOGL kjører på Windows, Linux, OSX, Solaris, *BSD.... Playstation 3 om du vil. Trenger bare JNI bindingene kompilert for platformen du kjører på. Endret 27. september 2006 av krigun Lenke til kommentar
prebenl Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 C/C++ er nå allikevel enormt dominerende i spillbransjen. Fordi om det finnes et halvseriøst java-spill endrer ikke det det faktum at Java er langt tregere. Du kan linke til benchmarkene du snakker om. Men det er jo egentlig håpløst, for hastighetsforskjellene er så store at man fint kan se dem med det blotte øye. Til hobbyting og low-end spill er det vel kanskje brukelig. Men da ville jeg heller gått for C# med Managed DirectX, svært så enkelt og ganske kraftig. Platformavhengig da, men det tar man vel ikke så tungt på et lite hobbyprosjekt. Jeg syns jeg leste at PS3 utelukkende baserer seg på C/C++, i motsetning til PS2 der det var nødvendig med en god del assembly. Lenke til kommentar
krigun Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 C/C++ er nå allikevel enormt dominerende i spillbransjen. Fordi om det finnes et halvseriøst java-spill endrer ikke det det faktum at Java er langt tregere. Du kan linke til benchmarkene du snakker om. Men det er jo egentlig håpløst, for hastighetsforskjellene er så store at man fint kan se dem med det blotte øye. Til hobbyting og low-end spill er det vel kanskje brukelig. Men da ville jeg heller gått for C# med Managed DirectX, svært så enkelt og ganske kraftig. Platformavhengig da, men det tar man vel ikke så tungt på et lite hobbyprosjekt. Jeg syns jeg leste at PS3 utelukkende baserer seg på C/C++, i motsetning til PS2 der det var nødvendig med en god del assembly. 6956678[/snapback] Biased. Og PS3 kjører linux. Lenke til kommentar
Giddion Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 PS3 kjører også OGL Lenke til kommentar
prebenl Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 Ja, men det er vel heller tvilsomt om det er mulig å lansere en offisiell tittel ved bruk av Java. Jeg regner med maskinen i hovedsak er lagt opp for å være en konsoll, og ikke en PC. Lenke til kommentar
lnostdal Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 (endret) Ja, men det er vel heller tvilsomt om det er mulig å lansere en offisiell tittel ved bruk av Java. Jeg regner med maskinen i hovedsak er lagt opp for å være en konsoll, og ikke en PC. 6959735[/snapback] Kjenner du til maskoten til Sony/Playstation? Den er fra en serie meget betydelige spill fra `Naughty Dog'; skrevet i Lisp. ..eller hva med http://mag.awn.com/index.php?ltype=search&..._no=1650&page=2 .. verktøy som Mirai/N-World; så klart Lisp det også.. Ser ikke noe i veien for at man kan gjøre det samme med Java. Du må seriøst åpne øya og innse at det kun er små deler av programvare som trengs å optimaliseres - og at man kan fint skrive assembly rett i f.eks. Lisp eller kombinere C og høynivåspråket via FFI e.l. Man kan vise hva asm-koden for en funksjon er (`disassembly' er en del av standard Common Lisp). Kan ta et eksempel; som utgangspunkt jobber jeg med full debug-info og safety og alt, slik: cl-user> (proclaim '(optimize (compilation-speed 0) (debug 3) (safety 3) (space 0) (speed 0))) ..da blir en funksjon som `sum': (defun sum (x) (+ x x)) ..seendes slik ut når jeg viser asm v.h.a. `disassemble': cl-user> (disassemble 'sum) ; 0C9A51D2: 64 byte #X64 ; no-arg-parsing entry point ; 1D3: 800D4800000004 or byte ptr [#x48], 4 ; 1DA: B920000000 mov ecx, 32 ; 1DF: 64 byte #X64 ; 1E0: 030D20000000 add ecx, [#x20] ; 1E6: 64 byte #X64 ; 1E7: 3B0D24000000 cmp ecx, [#x24] ; 1ED: 7607 jbe L0 ; 1EF: E8E4D46BFB call #x80626D8 ; alloc_overflow_ecx ; 1F4: EB0A jmp L1 ; 1F6: L0: 64 byte #X64 ; 1F7: 890D20000000 mov [#x20], ecx ; 1FD: 83E920 sub ecx, 32 ; 200: L1: 8D4907 lea ecx, [ecx+7] ; 203: C741F93E060000 mov dword ptr [ecx-7], 1598 ; 20A: 64 byte #X64 ; 20B: 80354800000004 xor byte ptr [#x48], 4 ; 212: 7402 jeq L2 ; 214: CC09 break 9 ; pending interrupt trap ; 216: L2: B84A000000 mov eax, 74 ; 21B: 8941FD mov [ecx-3], eax ; 21E: C741050B000005 mov dword ptr [ecx+5], 83886091 ; 225: 8B0500509A0C mov eax, [#xC9A5000] ; "SB-DEBUG-CATCH-TAG" ; 22B: 894109 mov [ecx+9], eax ; 22E: C7410D0B000005 mov dword ptr [ecx+13], 83886091 ; 235: 64 byte #X64 ; 236: 8B050C000000 mov eax, [#xC] ; 23C: 8945C8 mov [ebp-56], eax ; 23F: 8B05F8000005 mov eax, [#x50000F8] ; 245: 64 byte #X64 ; 246: 8B00 mov eax, [eax] ; 248: 8B1518040005 mov edx, [#x5000418] ; 24E: 64 byte #X64 ; 24F: 8B12 mov edx, [edx] ; 251: 8945CC mov [ebp-52], eax ; 254: 8955D0 mov [ebp-48], edx ; 257: 8965C4 mov [ebp-60], esp ; 25A: 8D55D4 lea edx, [ebp-44] ; 25D: 8B0518010005 mov eax, [#x5000118] ; 263: 64 byte #X64 ; 264: 8B00 mov eax, [eax] ; 266: 8902 mov [edx], eax ; 268: 896A04 mov [edx+4], ebp ; 26B: C74208EC62CB0C mov dword ptr [edx+8], 214655724 ; 272: 894A0C mov [edx+12], ecx ; 275: 8B05F8000005 mov eax, [#x50000F8] ; 27B: 64 byte #X64 ; 27C: 8B00 mov eax, [eax] ; 27E: 894210 mov [edx+16], eax ; 281: 8B05F8000005 mov eax, [#x50000F8] ; 287: 64 byte #X64 ; 288: 8910 mov [eax], edx ; 28A: 64 byte #X64 ; 28B: 813D500000000B000005 cmp dword ptr [#x50], 83886091 ; 295: 7402 jeq L3 ; 297: CC0F break 15 ; 299: L3: 8B55EC mov edx, [ebp-20] ; 29C: 8B7DEC mov edi, [ebp-20] ; 29F: E8849E34F4 call #xCEF128 ; 2A4: 7302 jnb L4 ; 2A6: 8BE3 mov esp, ebx ; 2A8: L4: 8BF4 mov esi, esp ; 2AA: 52 push edx ; 2AB: 8975F4 mov [ebp-12], esi ; 2AE: C745F004000000 mov dword ptr [ebp-16], 4 ; 2B5: 8B0DF8000005 mov ecx, [#x50000F8] ; 2BB: 64 byte #X64 ; 2BC: 8B09 mov ecx, [ecx] ; 2BE: 8B4910 mov ecx, [ecx+16] ; 2C1: 8B05F8000005 mov eax, [#x50000F8] ; 2C7: 64 byte #X64 ; 2C8: 8908 mov [eax], ecx ; 2CA: EB6E jmp L8 ; 2CC: 8D73FC lea esi, [ebx-4] ; 2CF: 8B7DC4 mov edi, [ebp-60] ; 2D2: 8BC7 mov eax, edi ; 2D4: 83EF04 sub edi, 4 ; 2D7: 894DF0 mov [ebp-16], ecx ; 2DA: C1E902 shr ecx, 2 ; 2DD: E303 jecxz L5 ; 2DF: FD std ; 2E0: F2 repne ; 2E1: A5 movsD ; 2E2: L5: 8D6704 lea esp, [edi+4] ; 2E5: 8945F4 mov [ebp-12], eax ; 2E8: 8B4DCC mov ecx, [ebp-52] ; 2EB: 8B55D0 mov edx, [ebp-48] ; 2EE: 8B05F8000005 mov eax, [#x50000F8] ; 2F4: 64 byte #X64 ; 2F5: 8908 mov [eax], ecx ; 2F7: 8B0518040005 mov eax, [#x5000418] ; 2FD: 64 byte #X64 ; 2FE: 8910 mov [eax], edx ; 300: 8B75C8 mov esi, [ebp-56] ; 303: 64 byte #X64 ; 304: 8B150C000000 mov edx, [#xC] ; 30A: 39D6 cmp esi, edx ; 30C: 742C jeq L8 ; 30E: L6: 8B42FC mov eax, [edx-4] ; 311: 09C0 or eax, eax ; 313: 7417 jeq L7 ; 315: 8B4AF8 mov ecx, [edx-8] ; 318: 8B5811 mov ebx, [eax+17] ; 31B: 64 byte #X64 ; 31C: 890B mov [ebx], ecx ; 31E: C742F800000000 mov dword ptr [edx-8], 0 ; 325: C742FC00000000 mov dword ptr [edx-4], 0 ; 32C: L7: 83EA08 sub edx, 8 ; 32F: 39D6 cmp esi, edx ; 331: 75DB jne L6 ; 333: 64 byte #X64 ; 334: 89150C000000 mov [#xC], edx ; 33A: L8: 8B75F4 mov esi, [ebp-12] ; 33D: 8B4DF0 mov ecx, [ebp-16] ; 340: 8B45F8 mov eax, [ebp-8] ; 343: 83F904 cmp ecx, 4 ; 346: 750D jne L9 ; 348: 8B56FC mov edx, [esi-4] ; 34B: 8B7DFC mov edi, [ebp-4] ; 34E: 8BE5 mov esp, ebp ; 350: 8BEF mov ebp, edi ; 352: F8 clc ; 353: FFE0 jmp eax ; 355: L9: 8BDD mov ebx, ebp ; 357: 8B6DFC mov ebp, [ebp-4] ; 35A: E9999C34F4 jmp #xCEEFF8 ; 35F: 90 nop ; 360: CC0A break 10 ; error trap ; 362: 02 byte #X02 ; 363: 18 byte #X18 ; INVALID-ARG-COUNT-ERROR ; 364: 4D byte #X4D ; ECX ; 365: CC0A break 10 ; error trap ; 367: 02 byte #X02 ; 368: 18 byte #X18 ; INVALID-ARG-COUNT-ERROR ; 369: 4D byte #X4D ; ECX ; nil ..her er det fryktelig mye som foregår som jeg ikke kommer til å gå inn på; avanserte muligheter og sikkerhet man ikke kan drømme om i C eller C++ (eller egentlig Java).. vi starter altså i riktig ende og begynner først nå til slutt å optimalisere: cl-user> (proclaim '(optimize (compilation-speed 0) (debug 0) (safety 0) (space 3) (speed 3))) ; No value cl-user> (defun sum (x) (+ x x)) ; in: lambda nil ; (+ X X) ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a rational. ; The second argument is a number, not a float. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a float. ; The second argument is a number, not a rational. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a single-float. ; The second argument is a number, not a double-float. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a double-float. ; The second argument is a number, not a single-float. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a (complex single-float). ; The second argument is a number, not a (complex single-float). ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a (complex single-float). ; The second argument is a number, not a real. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a real. ; The second argument is a number, not a (complex single-float). ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a (complex double-float). ; The second argument is a number, not a (complex double-float). ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a (complex double-float). ; The second argument is a number, not a real. ; ; note: unable to ; optimize ; due to type uncertainty: ; The first argument is a number, not a real. ; The second argument is a number, not a (complex double-float). ; ; note: forced to do generic-+ (cost 10) ; unable to do inline float arithmetic (cost 2) because: ; The first argument is a number, not a double-float. ; The second argument is a number, not a double-float. ; The result is a (values number &optional), not a (values double-float ; &rest t). ; unable to do inline float arithmetic (cost 2) because: ; The first argument is a number, not a single-float. ; The second argument is a number, not a single-float. ; The result is a (values number &optional), not a (values single-float ; &rest t). ; etc. ; ; compilation unit finished ; printed 11 notes style-warning: redefining sum in DEFUN sum cl-user> ..legg merke til at kompileren vet at vi nå er ute etter å generere optimalisert kode, og at den dermed spytter ut en masse tips om hvordan en kan gjøre dette.. ..og nå skjønner du .. nå har det skjedd ting her .. når man ser på disassemble nå: cl-user> (disassemble 'sum) ; 0B42ED58: 8BD0 mov edx, eax ; no-arg-parsing entry point ; 5A: 8BF8 mov edi, eax ; 5C: E8E713BDF5 call #x1000148 ; generic-+ ; 61: 7302 jnb L0 ; 63: 8BE3 mov esp, ebx ; 65: L0: 8D65F8 lea esp, [ebp-8] ; 68: F8 clc ; 69: 8B6DFC mov ebp, [ebp-4] ; 6C: C20400 ret 4 ; 6F: 90 nop ; tøfft? selv om dette ser veldig mye bedre ut, så kaller den fortsatt en ekstern generisk funksjon + .. vi vil gjerne inline det her.. hvis vi nå følger noen av tipsene til kompileren .... cl-user> (defun sum (x) (declare (fixnum x)) (+ x x)) ; in: lambda nil ; (SB-INT:NAMED-LAMBDA SUM (X) (DECLARE (FIXNUM X)) (BLOCK SUM (+ X X))) ; ==> ; #'(SB-INT:NAMED-LAMBDA SUM (X) (DECLARE (FIXNUM X)) (BLOCK SUM (+ X X))) ; ; note: doing signed word to integer coercion (cost 20) to "<return value>" okei, vi har nå deklarert at x kun tar i mot argumenter av typen fixnum (fixnum er som int i C).. ..ser at kompileren nevner noe om manglende info ang. typen til return-verdien, så vi deklarerer at også den skal være en fixnum: cl-user> (defun sum (x) (declare (fixnum x)) (the fixnum (+ x x))) style-warning: redefining sum in DEFUN sum cl-user> (disassemble 'sum) ; 0C60D896: 8D0412 lea eax, [edx+edx] ; no-arg-parsing entry point ; 99: 8BD0 mov edx, eax ; 9B: 8D65F8 lea esp, [ebp-8] ; 9E: F8 clc ; 9F: 8B6DFC mov ebp, [ebp-4] ; A2: C20400 ret 4 nil nå er jeg ingen ekspert i optimalisere Lisp-kode da jeg kun har holdt på med dette i 3 år, men dette er en _drastisk_ forbedring av den orginale koden og ligner hva en C-kompiler vil generere .. faktum er at i mange tilfeller så genererer en Lisp-kompiler _bedre_ (raskere) kode enn C-kompilere i dag; grunnen til dette er at man har veldig mange muligheter til å justere hvor generelle funksjoner og kode skal være, mens man i C/C++ ofte mangler muligheter til å finjustere disse tingene og man må enten gå "all inn" eller ingenting; noe som leder til kompromisser der man i stedet kunne fått noe som passet hånd-i-hanske .. om noen ønsker konkrete eksempler ("ikke stoler på meg") der Lisp er raskere enn C er det bare å spørre (denne posten ble lang nok for nå IMHO) -- jeg har stadig støtt borti tråder på c.l.l. der folk sier de er villige til å velge Lisp om C-koden de paster vil gå ..tja.. en si 3-5 ganger tregere i Lisp, men får bakoversveis i det de oppdager at koden går _kjappere_ i Lisp dette med GC i ting som Java og Lisp leder forresten i en del tilfeller til både mindre minnebruk, og økning i hastighet det også .. i Lisp-implementasjonen SBCL kan man slå av og på GC'en; og dermed oppnå mer forutsigbare pauser i koden (det er uforutsigbare pauser i C også! -- tiden før malloc returnerer er f.eks. _ikke_ definert!) .. man kan også deklarere at data skal pre-allokeres på stakken om man ønsker dét .. det finnes en drøss av muligheter ..... edit: jeg har ikke tatt med hvordan man skriver ASM rett i Lisp her; kun hvordan man optimaliserer og viser resulterende ASM -- jeg kan vise hvordan man skriver ASM rett i Lisp også -- om det er ønskelig (og hvis jeg gidder .. lol) .. Endret 28. september 2006 av lnostdal Lenke til kommentar
prebenl Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 (endret) Lisp er nok fint, men du beveger deg litt off-topic. Grunnen til at Java ikke er aktuelt er jo at det krever en JVM, og at et konsollspil som standard ikke kjører under et vanlig operativsystem. Sony kunne sikkert gjort noe med saken, men så godt som ingen enterprise-spillutviklere bruker Java uansett. GC fører til økning i hastighet? Ja, det er jaggu ofte det. GC er vel et av hovedargumentene for å ikke bruke Java/C# til spill. Det fører med seg en viss overhead, og slik vil det alltid være. Må forøvrig la meg imponere av at store deler av Jak & Daxter er skrevet i Lisp. Genialt spill, med en helt fantastisk grafikkmotor. Endret 28. september 2006 av Geofrank Lenke til kommentar
lnostdal Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 (endret) Litt vel mye Lisp-reklame, og vel lite on-topic der lnostdal. ..og du skal kunne "reklamere" (for en absurd måte å se på ting) for dine synspunkter? .. kutt ut; ikke oppfør deg på dette viset; du utnytter eksterne ting/krefter som ikke har noe med saken å gjøre fordi du ikke har egne eller andre argumenter å komme med -- skikkelig skuffende av deg edit: la meg si det slik at jeg bruker lisp som kjøretøy for å illustrere et poeng; et poeng som sier at det finnes andre språk enn C som duger til disse tingene ... jeg mangler erfaring i java, og dét er altså grunnen -- (lisp er andre språk enn C; så greier du kanske å resonomere deg frem til en sammenheng i form av et logisk fellestrekk mellom Java og Lisp i forhold til C) Grunnen til at Java ikke er aktuelt er jo at det krever en JVM, og at et konsollspil som standard ikke kjører under et vanlig operativsystem. Sony kunne sikkert gjort noe med saken, men så godt som ingen enterprise-spillutviklere bruker Java uansett. døh; "JVM" er et "ORD" .. spill og C-kode krever "biblioteker"; det er også "ORD" .. ord for samme ting; generellt sett er man villig til å "la ting" kreve avhengigheter fordi det gjør at man sparer tid og krefter i det man forsøker å nå målet sitt selv om det virker som en investering her og nå (og det er vel her problemet ditt sitter _egentlig_) GC fører til økning i hastighet? Ja, det er jaggu ofte det. 6961836[/snapback] la meg sitere fra Wikipedia og på det viset spare litt tid: Despite these issues, for many practical purposes, allocation/deallocation-intensive algorithms implemented in modern garbage collected languages can actually be faster than their equivalents using explicit memory management (at least without heroic optimizations by an expert programmer). A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion. For example, consider the following program in the (garbage-collected) C# language: dette er fra http://en.wikipedia.org/wiki/Garbage_colle...ce_implications du vet åpenbart ikke hva du snakker om; så kanskje det er du som er offtopic i forhold til hva som egentlig betyr noe her.... Endret 28. september 2006 av lnostdal Lenke til kommentar
krigun Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 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 Lisp virker som et ganske morsomt språk BTW. Skriver Ruby daglig, og det er endel kule språk features der oxo. Lenke til kommentar
lnostdal Skrevet 28. september 2006 Rapporter Del Skrevet 28. september 2006 (endret) 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 Lisp virker som et ganske morsomt språk BTW. Skriver Ruby daglig, og det er endel kule språk features der oxo. 6961931[/snapback] haha, ja; underholdning på høyt nivå under tak med (tydeligvis) lavt nivå vel..ruby virker interessant ja; får vel ta en titt en gang - greit å ha en "open mind" for alt nytt Endret 28. september 2006 av lnostdal Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå