mboost-dp1

unknown
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
HTTP download, som ikke er på fileplanet's trælse system:
http://www.cs.washington.edu/homes/omicron/quake3-...
<ontopic>
Jaa, det er vildt nice med Q3 engine frigivet, skal klart kigge mere på spiludvikling i fremtiden.
http://www.cs.washington.edu/homes/omicron/quake3-...
<ontopic>
Jaa, det er vildt nice med Q3 engine frigivet, skal klart kigge mere på spiludvikling i fremtiden.
[url=#3]#3[/url] Cosine
Hm, too bad at den bruger en forældet compiler (gcc 2.95).Mon ikke gcc 2.95 var tidssvarende dengang Quake 3 blev skrevet? Selv til Linux 2.6.12 anbefales det, at man bruger gcc 2.95 fordi nyere gcc versioner kan give problemer. Men det står naturligvis enhver frit for at lave de ændringer, der skal til for at kunne compilere den med gcc 3.4.
#3
Ja under Linux - jeg har lige kompileret den med Microsoft's compiler under Windows og det virker smukt.
Gud hvor er det lækkert det her :) - det bedste er at koden er relativt godt kommenteret og struktureret (er dog lidt forbavset over at det er C og ikke C++, troede de skiftede efter Quake II).
Nu skal jeg bare lige have fundet min gamle Quake III CD frem... Krydser fingrene for at den ikke er ridset til ulæselighed! :S
Hm, too bad at den bruger en forældet compiler (gcc 2.95).
Ja under Linux - jeg har lige kompileret den med Microsoft's compiler under Windows og det virker smukt.
Gud hvor er det lækkert det her :) - det bedste er at koden er relativt godt kommenteret og struktureret (er dog lidt forbavset over at det er C og ikke C++, troede de skiftede efter Quake II).
Nu skal jeg bare lige have fundet min gamle Quake III CD frem... Krydser fingrene for at den ikke er ridset til ulæselighed! :S
Det lykkedes også for mig at compile det smertefrit :) Jeg kan forstå på det hele, at enginen ikke kan starte op, uden en Q3-cd?
Har lige siddet og læst lidt på noget af netværkssystemet, og synes generelt koden er til at forstå. Måske man skulle kigge nærmere på lidt Q3-udvikling senere hen :)
Har lige siddet og læst lidt på noget af netværkssystemet, og synes generelt koden er til at forstå. Måske man skulle kigge nærmere på lidt Q3-udvikling senere hen :)
"Dette er meget interessant for spiludviklere verden over, da der ellers ikke er så mange andre engines på markedet, og Q2 var ved at være meget gammel."
Jeg forstår ikke helt den ovenstående del af nyheden? spiludviklere har da kunne bruge QuakeIII motoren i mange år, ligesom der er motorer fra andre firmaer såsom epic (unreal) og reanderware
Jeg forstår ikke helt den ovenstående del af nyheden? spiludviklere har da kunne bruge QuakeIII motoren i mange år, ligesom der er motorer fra andre firmaer såsom epic (unreal) og reanderware
Nu er det smarte jo, at du faktisk ikke behøver at købe q3 motoren længere =) Da den er udgiet under GPL
Mon ikke gcc 2.95 var tidssvarende dengang Quake 3 blev skrevet? Selv til Linux 2.6.12 anbefales det, at man bruger gcc 2.95 fordi nyere gcc versioner kan give problemer. Men det står naturligvis enhver frit for at lave de ændringer, der skal til for at kunne compilere den med gcc 3.4.
Jo den var, men den anbefales sgudde mere... Der findes enkelte rundt omkring der skal bruge Linux på specielle arkitekturer hvor gcc 2.95 er det eneste der dur, men gcc 3.2+ er helt klart default i enhver situation. Der var endda snak om at droppe support for de gamle version i Linux-kernen for nylig (det blev dog afvist af ovenstående grund).
- Simon
#14
Fra linie 1205 i win_main.c:
#if 0
// if we find the CD, add a +set cddir xxx command line
Sys_ScanForCD();
#endif
Så nej :)
Når du bare starter din nycompilerede quake3.exe op, så fejler den fordi den ikke kan finde default.cfg. (det gør min i hvert fald, jvf. debuggeren.)
Yay, sidder også og bliver lidt våd i trussen :)
Nu vil jeg i hvert fald lege lidt med det - tvivler nu på at jeg har tålmodighed til at lave noget seriøst.
Jeg kan forstå på det hele, at enginen ikke kan starte op, uden en Q3-cd?
Fra linie 1205 i win_main.c:
#if 0
// if we find the CD, add a +set cddir xxx command line
Sys_ScanForCD();
#endif
Så nej :)
Når du bare starter din nycompilerede quake3.exe op, så fejler den fordi den ikke kan finde default.cfg. (det gør min i hvert fald, jvf. debuggeren.)
Måske man skulle kigge nærmere på lidt Q3-udvikling senere hen :)
Yay, sidder også og bliver lidt våd i trussen :)
Nu vil jeg i hvert fald lege lidt med det - tvivler nu på at jeg har tålmodighed til at lave noget seriøst.
mums, jeg venter på nogen porter til Java, a la:
Jake - http://www.bytonic.de/html/jake2.html
Undead Arena - http://home.halden.net/tombr/squareheads/squarehea...
Jake - http://www.bytonic.de/html/jake2.html
Undead Arena - http://home.halden.net/tombr/squareheads/squarehea...
#21:
Ja, er heller ikke selv så prof til at programmere, så det ville nok kræve en hel del af mig at lave noget brugbart.. Men en OpenQuake3 kunne da være en god idé, så skal alle models og baner bare laves igen fra bunden, og man har en åben Quake3 der kan udvikles videre på.
Ja, er heller ikke selv så prof til at programmere, så det ville nok kræve en hel del af mig at lave noget brugbart.. Men en OpenQuake3 kunne da være en god idé, så skal alle models og baner bare laves igen fra bunden, og man har en åben Quake3 der kan udvikles videre på.
#15 #16 #17 #18 - forskellen er jo at alle med interesse i engine teknologi nu har adgang til koden. man er fri til at modificere den som man vil, og enda lave helt nye spil med koden. man kan vaelge at saelge det produkt man laver, men kildekoden skal vaere tilgaenglig.
hvis man vil spille quake3, skal man stadig bruge alle data filerne, og de er ikke gratis eller frit tilgaenglige, og kraever derfor at man kober spillet originalt.
saa hvis man sidder og vil fremstille den naeste komercielle castle wolfenstein, skal man stadig koebe en licens af id, for at kunne fremstille et lukket komercielt produkt.
/daniel
hvis man vil spille quake3, skal man stadig bruge alle data filerne, og de er ikke gratis eller frit tilgaenglige, og kraever derfor at man kober spillet originalt.
saa hvis man sidder og vil fremstille den naeste komercielle castle wolfenstein, skal man stadig koebe en licens af id, for at kunne fremstille et lukket komercielt produkt.
/daniel
Hmm.. det er rigtigt at det her er spændende nyt for alle os engine freaks, men hvis folk virkelig vil noget med Engines, så skulle de overveje at støtte et virkeligt godt projekt som f.eks.
Crystalspace?
Crystal Space3d
Denne Engine er ikke for tøsedrenge, den er ikke nødvendig vis så let at lære som Ogre eller Irrlicht, men tilgengæld er den nok også den bedste frie, Engine derude.
Når jeg nu er slut med alt denne reklame, må jeg jo nok indrømme at det i sandhed er et spændende træk. Med Q3 Engienen under GPL så giver det en del nye muligheder for diverse små spiludviklere/private.
Crystalspace?
Crystal Space3d
Denne Engine er ikke for tøsedrenge, den er ikke nødvendig vis så let at lære som Ogre eller Irrlicht, men tilgengæld er den nok også den bedste frie, Engine derude.
Når jeg nu er slut med alt denne reklame, må jeg jo nok indrømme at det i sandhed er et spændende træk. Med Q3 Engienen under GPL så giver det en del nye muligheder for diverse små spiludviklere/private.
[url=#19]#19[/url] Cosine
Jo den var, men den anbefales sgudde mere...Læs hvad der står i dokumentationen til de nyeste versioner: 2.6.12.5 2.6.13-rc6
The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it should be used when you need absolute stability.
#28 - så godt din ;)
men bemærkede du jake2 linket der i benchmark viser at java er hurtigere end C?
Java 1.4+ er væsenligt hurtigere end Java 1.1, som mange ikke har fattet.
og så kan du jo i øvrigt PRØVE spillene - begge links har webstart mulighed.
I øvrigt er OpenGL forbandet ligeglad om det kører gennem Java eller C...
men bemærkede du jake2 linket der i benchmark viser at java er hurtigere end C?
Java 1.4+ er væsenligt hurtigere end Java 1.1, som mange ikke har fattet.
og så kan du jo i øvrigt PRØVE spillene - begge links har webstart mulighed.
I øvrigt er OpenGL forbandet ligeglad om det kører gennem Java eller C...
Hehe ja hurtigere i EN af testene, langsommere i resten :)
Selv med nyeste JRE inde, sker der nada når man klikker på webstart linksne, den viser godt nok java loading screenen, men så sker der nada.
(ATI X800PE kort/dual [email protected]/1GB/XP)
Selv med nyeste JRE inde, sker der nada når man klikker på webstart linksne, den viser godt nok java loading screenen, men så sker der nada.
(ATI X800PE kort/dual [email protected]/1GB/XP)
#30
Du skal have Java 1.4+ installeret. Hvis webstart failer, er det lidt langhåret at finde log filer - så du kan prøve offline.
Jake2 starter med noget swing gejl, hvor den vil have dig til at installere Q2 map filer.
Hehe ja hurtigere i EN af testene, langsommere i resten :)true, men den "lille" hastigheds forskel er irrelevant i en eller anden grad (ligeledes i den hvor java er hurtigere) - i lyset af vi alligevel leger rundt i 300fps+
Du skal have Java 1.4+ installeret. Hvis webstart failer, er det lidt langhåret at finde log filer - så du kan prøve offline.
Jake2 starter med noget swing gejl, hvor den vil have dig til at installere Q2 map filer.
Jeg har nyeste JRE inde fra
http://java.sun.com/j2se/1.4.2/download.html
"
J2SE 1.4.2_09 (11.Aug.05)
Java 2 Platform Standard Edition.
"
Den starter også fint op med Java loading screenen, derefter kører javaw.exe processen bare i bg'en og laver nada / viser nada på skærmen :)
Så meget for runs everywhere, :)
Og allerede her har jeg mistet lysten for at spilde mere tid på det som user :).
Sjovt at java programmer har elendigt UI stadig ( http://www.myip.dk/ui.png ), ved godt det kommer an på dem der har lavet installeren men stadig synes at man ser det i de fleste java programmer (azureus/eclipse undtaget).
http://java.sun.com/j2se/1.4.2/download.html
"
J2SE 1.4.2_09 (11.Aug.05)
Java 2 Platform Standard Edition.
"
Den starter også fint op med Java loading screenen, derefter kører javaw.exe processen bare i bg'en og laver nada / viser nada på skærmen :)
Så meget for runs everywhere, :)
Og allerede her har jeg mistet lysten for at spilde mere tid på det som user :).
Sjovt at java programmer har elendigt UI stadig ( http://www.myip.dk/ui.png ), ved godt det kommer an på dem der har lavet installeren men stadig synes at man ser det i de fleste java programmer (azureus/eclipse undtaget).
#34 -
21. aug. 2005 12:16
Har lige prøvet Jake2, på min Athlon XP +1800 kører Javaquake nu rasende godt.
Det er da gavnligt for alle de folk som sidder og prøver at lære at blive spiludviklere. De kan jo hente noget inspiration. At det så er skrevet i C og ikke i C++ kan man undre sig over, men det er nok stadigvæk bedre end at skulle starte helt forfra, eller kigge på endnu ældre kode.
PS: Jeg håber der kommer en masse sjove mods!
PS: Jeg håber der kommer en masse sjove mods!
#37 -
21. aug. 2005 19:54
Vil C++ ikke som regel blive tungere at eksekvere pga. objektorienteringen?
#37
Ikke nødvendigvis. Hvis C++'en er skrevet ordentligt så behøver det ikke gå langsommere. Husk på at 99% af et programs afviklingstid foregår i 1% af koden (en tommelfingerregel der typisk gælder for spil, ved ikke om den gælder for Word). Dvs at det reelt set er den sidste 1% af koden der rent faktisk betyder noget for hastigheden, og her vil man typisk passe på med ikke at bruge tunge OO-ting.
De tunge OO-ting kan så til gengæld bruges til at gøre de resterende 99% af koden mere forståelig og struktureret.
Vil C++ ikke som regel blive tungere at eksekvere pga. objektorienteringen?
Ikke nødvendigvis. Hvis C++'en er skrevet ordentligt så behøver det ikke gå langsommere. Husk på at 99% af et programs afviklingstid foregår i 1% af koden (en tommelfingerregel der typisk gælder for spil, ved ikke om den gælder for Word). Dvs at det reelt set er den sidste 1% af koden der rent faktisk betyder noget for hastigheden, og her vil man typisk passe på med ikke at bruge tunge OO-ting.
De tunge OO-ting kan så til gengæld bruges til at gøre de resterende 99% af koden mere forståelig og struktureret.
Og måske skulle nogen fortælle mr. C# at C# er ligeså langsomt som Java 1.5 (ihvertfald på min pc), og begge sprog alligevel er framework krævende sprog (compiles til bytecode), og derfor langsommere på nogle punkter end C/C++, som compiles direkte til maskinekode.
Og så er der jo lige den detalje at java + opengl = win/linux, C# + OpenGL = windows stadig (kom ikke og snak om mono, det tæller ikke)
Og så er der jo lige den detalje at java + opengl = win/linux, C# + OpenGL = windows stadig (kom ikke og snak om mono, det tæller ikke)
(compiles til bytecode), og derfor langsommere på nogle punkter end C/C++, som compiles direkte til maskinekode.
Java har en Hotspot agtig compiler som kompilerer bytecode til maskinkode ;) - ret sikker på at C# har noget lign. Dog nok ikke ligeså avanceret (og slet ikke under mono).
Men ja, synes nu at java + opengl giver mere mening end c# + opengl, men tror nu oxo at mange vælger at bruge c# + directx i stedet for, desværre.
#42 -
22. aug. 2005 08:26
Under Swindeldows virker .jnlp-filen direkte. Hvordan gør man for at køre programmet under Linux? Jeg taler her ikke om .jar-filen, men den på siden indlejrede version.
Nu vi er offtopic alligevel... :P
På grund af situationen om Java, ville jeg jo nok desværre måtte anbefale .NET istedet under alle omstændigheder. Mono taler meget til .NETs fordel, og først når Javas modstykker når lige så langt, ser jeg nogen grund til at anbefale anderledes.
OpenGL eller DirectX bliver forhåbentligt snart en ligegylidgt diskussion, jo mere af DirectX Wine folkene får reimplementeret. (Herefter kan andre jo se, hvordan Wine gjorde det... :) Selvfølgelig skal der kæmpes for OpenGL, idet lukkede standarder er en yderst pervers idé som må modarbejdes for enhver pris. Men hvis lukkede standarder bliver gjort åbne af andre, så kompencere det jo lidt for det dårlige... ;)
På grund af situationen om Java, ville jeg jo nok desværre måtte anbefale .NET istedet under alle omstændigheder. Mono taler meget til .NETs fordel, og først når Javas modstykker når lige så langt, ser jeg nogen grund til at anbefale anderledes.
OpenGL eller DirectX bliver forhåbentligt snart en ligegylidgt diskussion, jo mere af DirectX Wine folkene får reimplementeret. (Herefter kan andre jo se, hvordan Wine gjorde det... :) Selvfølgelig skal der kæmpes for OpenGL, idet lukkede standarder er en yderst pervers idé som må modarbejdes for enhver pris. Men hvis lukkede standarder bliver gjort åbne af andre, så kompencere det jo lidt for det dårlige... ;)
Nu vi er offtopic alligevel... :PNyheden er alligevel et stykke nede i kæden, så sikkert i orden nu :)
På grund af situationen om JavaØhh hvilken "situation" ? Taler du her om OSS ? - så er det jo ikke lige alle der mener at det er et problem, endda laaangt fra alle ;)
Problemet er nok nærmere OpenGL vs DirectX, i det at MS har udtalt at OpenGL ikke vil komme til at køre ordenligt under Longhorn - det er noget l-o-r-t. Jeg kommer sq nok aldrig til at kunne lide MS og deres metoder (hvilket gør jeg heller ikke stoler på monos fremtid er sikret. Ret let for MS at nakke dem (i hvert fald de dele der ikke er CLR/IL))
#44 Mazon
Mange af de værste problemer, er dem folk indser alvoren af for sent. Og det her bliver også mere og mere alvorligt, jo længere der går før det bliver løst.
Håber dette kan afværgres. Men ellers har de alligevel tabt.
Så nupper vi bare deres DirectX, og kortslutter den strategi... ;) Wine folkene er nået ret langt med, at reimplementere DX9... :) Og deres reimplementation kan andre lære af. Men derfor skal der stadig investeres kræfter i, at bibeholde OpenGL som den førens 3D API. (Eller hvad det hedder, flame mig ikke for hårdt.)
Muligvis hvis de bruger patenter imod os. Men udover det, så kan jeg ikke se noget der stopper Mono. Og Mono er længere end nogen fri Java desværre... :o/
Øhh hvilken "situation" ? Taler du her om OSS ? - så er det jo ikke lige alle der mener at det er et problem, endda laaangt fra alle ;)
Mange af de værste problemer, er dem folk indser alvoren af for sent. Og det her bliver også mere og mere alvorligt, jo længere der går før det bliver løst.
Problemet er nok nærmere OpenGL vs DirectX, i det at MS har udtalt at OpenGL ikke vil komme til at køre ordenligt under Longhorn - det er noget l-o-r-t.
Håber dette kan afværgres. Men ellers har de alligevel tabt.
Så nupper vi bare deres DirectX, og kortslutter den strategi... ;) Wine folkene er nået ret langt med, at reimplementere DX9... :) Og deres reimplementation kan andre lære af. Men derfor skal der stadig investeres kræfter i, at bibeholde OpenGL som den førens 3D API. (Eller hvad det hedder, flame mig ikke for hårdt.)
Jeg kommer sq nok aldrig til at kunne lide MS og deres metoder (hvilket gør jeg heller ikke stoler på monos fremtid er sikret. Ret let for MS at nakke dem (i hvert fald de dele der ikke er CLR/IL))
Muligvis hvis de bruger patenter imod os. Men udover det, så kan jeg ikke se noget der stopper Mono. Og Mono er længere end nogen fri Java desværre... :o/
#45
Problemet er bare at MS på et tidspunkt smider DX9 ud og går over til XNA i stedet. Og så er det forfra...
Heldigvis er MS's politik angående OpenGL ikke skrevet i sten endnu, så man kan håbe at de ombestemmer sig. Man må gå ud fra at der er nogle store firmaer der vil gå hårdt imod MS på området... ellers ser det sgu sort ud :(
Håber dette kan afværgres. Men ellers har de alligevel tabt.
Så nupper vi bare deres DirectX, og kortslutter den strategi... ;) Wine folkene er nået ret langt med, at reimplementere DX9... :) Og deres reimplementation kan andre lære af. Men derfor skal der stadig investeres kræfter i, at bibeholde OpenGL som den førens 3D API. (Eller hvad det hedder, flame mig ikke for hårdt.)
Problemet er bare at MS på et tidspunkt smider DX9 ud og går over til XNA i stedet. Og så er det forfra...
Heldigvis er MS's politik angående OpenGL ikke skrevet i sten endnu, så man kan håbe at de ombestemmer sig. Man må gå ud fra at der er nogle store firmaer der vil gå hårdt imod MS på området... ellers ser det sgu sort ud :(
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.