Einfachste und effektivste 3D-Spieleprogrammierung?! [Archiv]

FireMail

30.03.2004, 22:55

ziemlich schwammige antworten von euch jungs - hätte mir mehr erwartet ;)

also, ich und meine truppe, wir programmieren PC spiele. die sache ist die. du kannst - wie gencha bereits gesagt hat, spieleSDKs verwenden. das problem hierbei liegt darin dass es mehr eine art dragndrop bastelei als programmierung ist. du hast diene modells - stellst alles ein und manche systeme haben auch eine scriptsprache für deren engine zur verfügung. das ist aber schon alles! renner oder hits kannst damit nicht machen - deshalb sind dieses systeme in spieleprogrammierer kreisen total verschrien :)

und eine engine lizenz kaufen wie schaf meinte is für eine einzelperson oder einen hobby developer totaler schmarrn :) habter schonmal an die ganzen opensource engines gedacht? das ist die beste lösung für nonfulltime developer!
wenn ich an die OGRE engine denke - eine der besten graphik engines (raytracing) (nicht die beste für spiele)
die neoengine - unter der wir entwickeln - hat zB alle features der HL2 engine großteils implementiert und ist noch nichtmal offiziell auf der v1.0

die sache ist also die - such herum bzgl engines und arbeit dann mit jener! es gibt immer wunderbare docs, tutorials und foren dazu! das ist der beste weg um in die graphische programmierung reinzuschlittern.

was ich dir aber noch sagen möchte - ein programmierer macht kein 3d spiel! du brauchst modells, dazu texturer, skinner, evtl sounder, animierer - also ne handvoll leute.
wir sind zB 14 leute und suchen immernoch welche die mitarbeiten!

bzgl engine in c - bah totaler mist. du kannst über c++ regelrecht komfortabel die graphik pipes direkt programmieren! is sicher schneller als ansi c gewusel :) und asm brauchst für graphische algorythmen kaum!
ebenso ist das erstellen einer engine auch nicht schwer wenn man nur grundfunktionen will! mittels OGL oder cG kann man leicht gewisse dinge schon rendern - auch effekte wie bumpmapping oder lightmapping is nicht so schwer. schwerer wirds erst bei envmapping, terrain rendering and such stuff

my2cents, verbessert mich ruhig wenn ich falsch liege ;)

Jan Krüger

30.03.2004, 23:11

C++ ist nicht schneller als C. C ist auch nicht schneller als C++. Es kommt immer darauf an, wie man es macht.
Ich würde aber in diesem Fall auch generell eine existierende Engine empfehlen. Wenn dir die, die es schon gibt, nicht reichen, kannst du immer noch deinen Teil dazu beitragen, dann haben auch andere etwas davon.

gencha

31.03.2004, 11:06

also unsre antworten wären sicher unschwammiger ausgefallen wenn das nich schon der fünfte post zu dem thema wär

Scavi

31.03.2004, 11:17

und asm brauchst für graphische algorythmen kaum ...also das ist mir ja total neu. Erstens heisst das "Algorithmen" ;) und zweitens kriegst du keine Echtzeiteffekte wie Wasser oder Plasma schneller ohne ASM hin. Geschweige man redet von Echtzeittexturen.

FireMail

31.03.2004, 12:53

also ich steh auf mein y in dem wort ;)

wasser - aus meiner sicht nur eine ansammlung von alpha, shadering roam effekten. damit kriegste das leicht hin

Scavi

31.03.2004, 12:56

Na wenn du das so betrachtest, iss heutzutage alles nur eine Art von Shadering.

FireMail

31.03.2004, 13:01

deshalb is shadering auch eines der wichtigsten kapiteln beim engine programmieren ;)

Scavi

31.03.2004, 13:05

Als ich den Spass gelernt habe gabs noch keine Graphikkarten die das unterstützten. Aber das iss schon ne feine Sache, vorallem relativ einfach.

gencha

31.03.2004, 13:18

es heisst übrigens auch Grafikkarten wenn wir schon beim rechtschreibung verbessern sind ;)

Scavi

31.03.2004, 13:23

Gra|fik,

Gra|fik, (auch:) Graphik, die; -, -en [griech. graphike (téchnē) = Schreib-, Zeichenkunst, zu: graphikós = das Schreiben betreffend]: 1. ...

Quelle: Duden: Das große Wörterbuch der deutschen Sprache in 10 Bänden. 3., völlig neu bearbeitete und erweiterte Auflage. Mannheim, Leipzig, Wien, Zürich: Dudenverlag 1999.

...ergo: sowohl als auch!

summer

08.04.2004, 19:19

3d engine wird in c gecodet, mehr is dazu nich zu sagen. alles andre halte ich für schwachsinn

aha? dann erklär mal warum.
ne gute 3D engine kannst du heute auch notfalls in VB programmieren.
Ist übrigens bemerkenswert, dass du Carmack dann wohl für nen schwachkopf hälst, der vor einiger zeit komplett auf C++ umgestiegen ist (von C) :D

zweitens kriegst du keine Echtzeiteffekte wie Wasser oder Plasma schneller ohne ASM hin. Geschweige man redet von Echtzeittexturen.

mit nem compiler von 1987 vielleicht nicht...

Scavi

09.04.2004, 11:23

Zeig mir den Compiler, der dir komplett Laufzeit-optimierten Code liefert und dann noch eine kleiner Executable liefert als ein mit ASM geschriebenes Programm. ..Träum weiter.

summer

09.04.2004, 11:43

wen interressiert die größe der datei? höchstens demo coder. aber hier war von SPIELEprogrammierung die rede.
oooohoho, ich benutze 3GB für grafik und sounds, aber pass mir ja auf, dass die exe nicht zu groß wird, sonst kriegen wir das nicht mehr auf die DVD !!! *gg*

ich glaube kaum, dass du mit ein paar assembler tricks so schnell z.b. MSVC6 (natürlich > standard, der ja nicht optimiert ;) ) in die ecke drängst.
neuere compiler, die dann auch 3dnow!, sse etc mit einbeziehen... also da musst du wirklich ein asm und CPU guru sein, was generell zu empfehlen wäre, wenn du deine routine nicht versehentlich langsamer machen willst... :D was sehr leicht passieren kann, wenn man sein cure-all rezept der optimierung aus älteren zeiten auf neuere prozessoren anwenden will.
die meisten halten sich ja schon für programmier gurus, wenn sie heut zu tage überhaupt irgendwie noch Asm können... ;)

also ich war auch mal ein asm freund, inetressant find ichs immernoch und es ist ja ein gewisser reiz dahinter, wo das absolute maximum rauszukitzeln... allerdings war ich bisher zu faul, mich mit den ganzen neuen sachen zu befassen, und asm gefriemel ist nicht gerade mein schwerpunkt.

FireBird2002

09.04.2004, 20:00

Assembler-Wissen ist echt kein Fehler, besonders wenn der Compiler nicht das aus dem Code macht, was man will...

Außerdem würde ich eher einen 20 Jahre alten C/C++-Compiler als VB für meine Programme verwenden.

Größe interessiert eben doch noch. Vielleicht nicht auf dem PC. Versuch mal z.B. nen Mikro-Controller zu programmieren der 8k Progr.-Speicher hat. Der ist mit nem printf schon zu 1/4 voll... (OK. Hat jetzt nicht so direkt mit 3D-Programmierung zu tun, ginge aber auch mit nem µC)

Scavi

09.04.2004, 22:37

Schon mal an in Echtzeit berechnete Modelle (Bäume, Farne usw. mit windflow) gedacht ? Wenn man Spiele programmiert, die nur vorgefertigte Texturen / Modelle nutzen mag das ja wohl ausreichen, herkömmliche Standardcompiler zu nutzen. Dennoch denke ich, sollten Spieleprogrammierer auch auf ihr ASM-Wissen, dass hoffentlich vorhanden ist, zurückgreifen. Ausserdem zählt immer die Größe. Was nutzt mir eine 130 Mb große Exe, wenn ich nur 128 Mb RAM hab ? ...Da müssen nur wieder die Mindestvorraussetzungen hochgeschraubt werden ...irrsinnigerweise, bloss weil die Programmierer zu unfähig waren.

summer

11.04.2004, 00:28

ööööööhm, was hast du denn da für lustig große exes *g*

um n paar KB muss man sich bei spielen wirklich nicht streiten...
und wie gesagt, nur dadurch, dass du assembler benutzt, ist der code nicht automatisch schneller...
und natürlich rede ich zumindest von animierten texturen.
das mit den angebelich unnötig hohen systemanforderungen ist so eine sache.
ewig lange mit asm rumzufriemeln und das debuggen dafür kosten unnötig aufwand, zeit und damit geld. wenn du bereit bist, für vermeintlich niedrigere systemvoraussetzungen einen wesentlich höheren preis für ein spiel zu bezahlen... ich bin's nicht.
daher ist asm einsatz in der spiele industrie längst sehr dünn gesäht...

FireBird2002

11.04.2004, 11:46

Wobei Optimierungen bei einigen Spielen wirklich Not tun würden. Ich bin sicher das sich durch geeignete Optimierungen (ob nun mit asm oder ohne) die Hardwareanforderungen von einigen Spielen auf ein Drittel Reduzieren ließen.

Bei Spielen wird eh schon genug gespart, da muß man sich nur mal die Verpackungen anschauen. Außerdem haben sich die Preise für neue Spiele in den letzten Jahren verdoppelt. Noch dazu muß man jedes 2. Spiel erst einmal uodaten um es spielen zu können. Etwas mehr Sorgfalt würde der Spieleindustrie gut zu Gesicht stehen. Ich hab keinen Bock für so ein Spiel dann 60 ? auszugeben.

Scavi

11.04.2004, 16:13

daher ist asm einsatz in der spiele industrie längst sehr dünn gesäht Schade eigentlich, ich rede ja auch nicht vom Einsatz für Graphikroutinen sondern für Matrizenberechnungen, Vektorarithmetik, Algorithmenbeschleunigung für viele oft gebräuchliche Algorithmen ...

summer

11.04.2004, 17:38

Schade eigentlich, ich rede ja auch nicht vom Einsatz für Graphikroutinen sondern für Matrizenberechnungen, Vektorarithmetik, Algorithmenbeschleunigung für viele oft gebräuchliche Algorithmen ...

aaaaaha, okay das ist etwas anderes aber dat macht man einmal bzw lädt sich irgendwo ne open source bibliothek runter und feddich is :D
wir redeten hier ja übers programmieren einer gafikengine, und sowas is irgendwie "standard", also, das macht man ja nicht ständig neu, als dass man sich jetzt hier darüber extra auslassen müsste.

das mit den systemanforderungen... naja, ich glaube schon, dass die niedriger gehalten werden könnten, als sie sind, aber die zeiten, wo der onkel carmack das letzte bisschen aus dem 386er rausquetscht, um ne bisher nie dagewesene grafikengine zu ermöglichen,
sind vorbei, unter multi tasking windows und den heutigen fetten rechnern, und wo grafik- und sound-hardware so viele sachen übernimmt, ist das alles sowieso etwas grober...

also, ich sag mal, gutgemachte spiele haben auch angebrachte systemvoraussetzungen...
diese schnell zusammengebatschten trendspielchen, die es zu hauf gibt und wohl von der masse gekauft werden, haben allerdings oft für die grottige grafik viel zu hohe anforderungen...

was völlig anderes ist das wohl im konsolenbereich, da wird rausgequetscht was geht, aber das müssen sie auch :D

Wostok

19.09.2004, 11:45

Mhhh ich hab zwar null ahnung von programmieren, aber ich arbeite seit einem Jahr an einer Modifikation zu Command&Conquer Zero Hour.
Wir haben einfach ein kleines Team auf die Beine gestellt und jetzt haben wir einige scripter, Modeller und skinner.
Kann man auch schon ganz ordenliche Sachen mitmachen....
Also am einfachsten ist es daher immer einfach ein Spiel zu modifizieren.
Auch wenn man dann leider keine Rechte hat es als eigenes Game zu veröffetlichen....
Es gibt nur leider immer sehr wenig leute die an sowas Teilnehmen....

Scavi

19.09.2004, 19:40

Es gibt nur leider immer sehr wenig leute die an sowas Teilnehmen... ..Ja, weils absolute Zeitverschwendung ist!

Wostok

20.09.2004, 16:22

..Ja, weils absolute Zeitverschwendung ist!Ich würde sagen das ist Ansichtssache...:rolleyes:
Dem einen gefällts dem anderen nicht....
und wenn man sowas beruflich machen möchte sehe ich es nicht als Zeitverschwendung:mauer:

Scavi

21.09.2004, 14:23

und wenn man sowas beruflich machen möchte sehe ich es nicht als Zeitverschwendung ...das geht aber nicht ohne Lizenz! Oder willst du beruflich Charakteranimator/Skinner/Leveldesigner werden?

Wostok

22.09.2004, 14:41

Jo möchte ich ....

gencha

22.09.2004, 15:10

außerdem hier von zeitverschwendung zu sprechen ist ja wohl mehr als lächerlich. manche leute würden auch musik machen oder bilder malen als zeitverschwendung betrachten. fernsehn oder ins kino gehn ist auch absolute zeit verschwendung. trotzdem macht mans.
manche leute haben an sowas eben spaß und den sollte man ihnen auch lassen und sich auch hier bitte nich so negativ äußern.
und jetz komm mir bitte nich mit "man wird ja wohl noch seine meinung sagen dürfen" ;)

mod entwicklern haben wir schließlich auch counterstrike zu verdanken, und obwohl ich dieses spiel verachte haben immernoch haufenweise leute spaß dran. und im endeffekt wurde sogar geld damit verdient.

Scavi

22.09.2004, 16:31

manche leute haben an sowas eben spaß und den sollte man ihnen auch lassen und sich auch hier bitte nich so negativ äußern
Suum cuique!

FireBird2002

22.09.2004, 16:45

Suum cuique!
Hä???????????

Scavi

22.09.2004, 19:48

Hä??????????? Jedem das Seine!

devor

01.02.2005, 13:51

Das klingt ja fast schon als ob asm ne blöde sinnlose spielerrei ist...:confused:
Eigentlich ist es aber eher so dass jede andre sprache so gut wie nie so gut wie asm code sein kann.. Sicher kann man ne engine in vb machen, aber mann muss halt dann auch mit nicht so tollen ergebnissen zufrieden sein. Ich sag auch gar nicht dass das mit vb unmöglich ist, aber es ist halt schwierig den je komplexer und damit meist auch langsamer alles wird, umso stärker zeigen sich die schwächen von vb. Das sollte man schon bedenken und es steigert auch die Mindestanforderung...

Wa´s mich auch gleich zu asm bringt... Kurz und bündig, wenn die heutigen spiele mit asm (zumindest bei den rechenintensiven teilen) geschrieben wären dann würd man nicht einen so extremen high end rechner brauchen...
MAn braucht sich ja nur z.b. die normale Halflife engine ansehen... Ich sag nicht das ichs besser kann aber dann sind haufenweise sachen die langsamer machen... allerdings ist ein großer teil der verlangsamung auf kosten der erweiterungsfähigkeit (mod) draufgegangen... was ich persöhnlich eigentlich eh gut find... aber hätte man das extrem optimiert ohne mod und so dann würds sicher auf ziemlich jedem rechner mit 3d beschleunigung rennen schätzt ich (also ab ~500 mhz (oder so)) Is aber auch wurscht, fakt ist es wär echt nicht schlecht wenn es an den rechenintensiven stellen verwendet wird z.b. in c++ mit inline asm. Das ist doch eigentlich sehr intelligent! Man kann alle vorteile von c++ nutzen und trotzdem den extrem schnellen code generieren. Also bei Unternehmen fänd ich es gut wenn darauf wieder mehr wert gelegt wird.

Allerdingst muss ich sagen ist beim thema asm auch die portablität ein thema welche nat. mit c++ da ist! Das muss ma halt abwägen.

Deshalb würd ich auch am schluss sagen dass man das für sich abwägen muss, und zwar jeder für sich.

Ich persöhnlich mach grad ne engine in c bzw(c++ nutze aber nix von den extensions) die nur über funktionen funktionieren soll (also dll mit funktionen so wie opengl z.b.) und verwende in moment kein asm da ich beim code ein paar sachen hab die zuerst gut geschreiben werden müssen, wo der compiler nicht sooo viel rolle spielt (z.b. verwendeung einen vertex objekts [opengl] statt alles einzeln zeichen...) => das sind halt sachen wo der einsatz von asm unnötig ist da ich zuerst mal alles andere so schreiben muss das es von opengl her max. geschwindigkeit erreicht. Allerdings falls ich das sch*** ding endlich mal fertig kriegen sollte (:D ) werd ich nat. über eine Optimierung rechenintensiver und oft genutzter teile durch asm nachdenken da portablität in Moment mir persöhnlich nicht so wichtig ist... aber mal sehen!

cu devor

FireMail

01.02.2005, 13:55

schön und gut, hast aber mal an die wirtschaftlichkeit gedacht? dass was ein hauptberuflicher C++ programmierer in 8h am tag programmiert braucht der ASM typ sicherlich wesentlich länger -> kostet mehr -> wahrscheinlich unwirtschaftlich.

und eigene ASM profis zu engagieren ist auch wegen der unbrauchbaren kosten sicherlich nicht tragbar.

vorsätze schön und recht, aber vergiss unser liebes geld nicht :D

gencha

01.02.2005, 15:38

also erstmal, bei aktuellen spielen ist die belastung der cpu im vergleich zur grafikkarte minimal. halflife 2 läuft auch auf schlechteren rechnern solang du ne dicke graka drin hast. alles was mit der grafik zu tun hat geht heute dank pixel und vertex shadern über die gpu. die cpu wird für kollisionsabfragen und physikengine benutzt. und du kannst mal kräftig einen drauf lassen das in aktuellen spielen sicher hier und da auch inline assembly zu finden ist. und wenn nicht dann glaub ich gibts dafür gute gründe. carmack wird sich sicher in seiner laufbahn als engie programmierer über sowas mal gedanken gemacht haben ;)
ich glaube auch ernsthaft das der geschwindigkeitszuwachs durch assembly zu optimiertem code trivial ist. ich lass mich aber gerne vom gegenteil überzeugen.
fest steht jedenfalls, wer schlechten code schreibt, dem wird auch kein assembly helfen.

crashgod

01.02.2005, 16:10

man labern die hier einen scheiß, natürlich ist es auch für hobbycoder möglich ne engine zu coden. so was codet man natürlich nich in c. nimm dir vc++ net oder c# net(in verbindung mit managed dx ne nette sache), und zieh dir das directx 9 sdk und kauf dir nen buch, gibts ja genügend zu.

und schau mal bei www.zfx.info (http://www.zfx.info) vorbei, is die beste community was gamecoding angeht.

gencha

01.02.2005, 16:25

natürlich ist es einfach ne engine zu coden. aber definier mal den begriff. ich schreib dir innerhalb einer stunde ne engine die texturierte polygone aufn bildschirm zeichnet. fertig is die 3d engine. aber vielleicht ist dir ja schonmal aufgefallen das in heutigen spielen ETWAS mehr steckt. und für eine einzelne person ist es einfach nich möglich da mitzukommen.

devor

02.02.2005, 12:40

Da hat getcha recht! Ne gescheite engine die viels was heute verlangt ist kannst du als einzelperson hobbycoder nur mit extrem hohem Zeitaufwand machen... und nur die wenigsten bleiben da echt konsequent dahinter!

@ getcha:
Du hast schon recht das die gpu natürlich ne menge erledigt aber wenn du mir erklären willst das halflife 2 auf vollen details auf einem 200-500 Mhz rechner mit graka deiner wahl läuft dann kann ich mich nur auf den Boden werfen und dich laut auslachen... :D ! Ne spaß beiseite... sicher werden die effekte und so schon zum hauptteil von der gpu brechnet... aber es gibt schon noch viele sachen die der cpu überenhmen muss... Mann kann nat. auch viel ohne asm optimieren; z.b. nur Objekte in die Zeichen pipline schicken die auch wirklich sichtbar sind.... und ich würd sagen optimieren duch asm ist eben die endstufe die oft ausgelassen wird weil viele coder heutzutage keine ahnung mehr von asm hab. Und ich find dass man da nicht extra leute anstellen sollen müsst... ein vernünftiger c++ coder sollte da schon ein bisschen asm können... aber das ist ansichtssache. Es ist ja auch nicht umbedingt nötig da heutige rechner das eh locker packen, nur bevor man systemvoraussetzungen noch weiter hochschraubt könnte man auch mal daran denken richtig zu optimiern. Das Problem bei asm ist nat. der verlust von portablität... Das ist auf jeden fall auch ein aspekt der vielen Leuten was bedeutet...

cu devor

butterkeks

02.02.2005, 13:16

Ob Portabilität bei kommerzieller Software so wichtig ist, bezweifle ich mal, denn viele SPiele erscheinen ohnehin nur für Windows x86

gencha

02.02.2005, 14:30

natürlich läuft half life 2 auch mit der dicksten karte nich auf nem 200er wahrscheinlich auch nich auf nem 500er. und mit optimiertem code meine ich nich solche grundlegenden sachen wie "was zeichne ich in diesem frame".
wenn man weiss was der compiler aus deinem code macht, dann kannst du recht gut bestimmen wie danach das assembly aussieht. denn im grunde macht der compiler ja nichts anderes. also warum soll ich mir als coder gedanken über asm machen? dafür wurden programmiersprachen schließlich entwickelt. und mal ganz abgesehn davon, heutige compiler an denen jetz mittlerweile über 10 jahre gearbeitet wurde haben doch die ein oder andere optimierung hinter sich. daher sagte ich ja das inline assembly optimierungen heutzutage trivial sind. die leute die ich kenne die asm benutzen tun das aus platzgründen aber nich wegen der performance.

ExE

02.02.2005, 15:16

Ich hab auch schon überlegt, 3D zu programmieren. Soweit ich da erfahren habe, brauch man einfach nur C++. Allerdings hab ich beschlossen, damit noch etwas zu warten. Erstens will ich noch ein paar Wisssenslücken füllen und zweitens kamen da teilweise Mathethemen, die wir noch garnich hatten, wie z.B. Vektoren. Was kommt n da noch so? Vektoren nehme ich grad selber durch, ich hab gehört, das soll dafür ziemlich wichtig sein...

gencha

02.02.2005, 15:41

3d programmierung kannst du in jeder sprache machen die text (oder auch nur zeichen) irgendwie aufn bildschirm packen kann.
ich muss sagen ich hatte mich 3d programmierung sehr schwer vorgestellt anfangs. aber es kommt halt drauf an wo man ansetzt. eine schnittstelle wie opengl zu schreiben ist natürlich schwer. opengl zu benutzen ist kinderleicht.
vektoren brauchts natürlich, aber viel intressanter sind andre dinge. du sachst deiner rake einfach, hier pass mal auf ich will jetz n dreieck aufn schirm. dann will deine graka von dir 3 punkte in nem dreidimensionalen raum wissen. die gibst du ihr halt und dann ist sie auch schon zufrieden und wird dir dein dreieck aufn schirm malen. da kann man natürlich noch mit texturierung und beleuchtung anfangen. oder einfach nurmal mit farben ;D
aber ich reduziere realtime 3d programmierung eigentlich immer gerne auf diese wenigen dinge.

crashgod

02.02.2005, 16:23

ja sicher man muss halt immer konsequent dahinter bleiben, aber ich finde es ist gar nich so schwer so was zu coden, man muss aber einiges an zeit investieren.
also ich code grad ne engine, hier mal paar screenshots, damit ihr ma seht was möglich is, hab ich alles allein gecodet:
http://www.code-artists.de/screenshots/new.PNG
http://www.code-artists.de/screenshots/new2.PNG

Fadan

03.02.2005, 20:14

Der Thread "war" ja schon etwas älter, ich geb auch mal mein Senf dazu:

Wa´s mich auch gleich zu asm bringt... Kurz und bündig, wenn die heutigen spiele mit asm (zumindest bei den rechenintensiven teilen) geschrieben wären dann würd man nicht einen so extremen high end rechner brauchen...

mmmmh, falsch. Sicher ist es gut rechenintesive Routinen in ASM zu programmieren, es ist aber nicht unbedingt notwendig (besonders nicht im "Hobby"-Bereich). Einer von vielen Fehlern ist daß Hobbycoder (ich bin selbst einer) versuchen den Source zu sehr zu optimieren so daß es umständlich wird. Ich selber arbeite zZ. auch an meiner "Hobby"-Engine (mit dem Ziel zu lernen) und mit der Zeit kommst du an den Punkt wo deine Grafik-Hardware die Performance des Spiels bestimmt. Es ist viel wichtiger unnötige Polies zu clippen, das Terrain entsprechend zu speichern bzw. zu unterteilen, mehrere Objekte in einem zusammenfassen (reduzierung der Aufrufe) und und und anstatt eine wichtige Schleife oder sonstwas in ASM zu schreiben. (was dir vergleichsweise wenig Performance bringt bzw. garnicht ins Gewicht fällt). Meine Engine nutzt LUA als scripting interface (über welches sogut wie alles gesteuert wird) - das bringt mir Performance-Verlust - welcher allerdings nicht groß auffällt (wie gesagt, GPU bestimmt Speed).

Ob Portabilität bei kommerzieller Software so wichtig ist, bezweifle ich mal, denn viele SPiele erscheinen ohnehin nur für Windows x86

naja, wenn du von der richtigen Branche ausgehst dann ist Portabilität ein wichtiges Thema. Dadurch daß das Spiel auch auf Linux und evlt. Mac etc. läuft werden die Verkaufszahlen erhöht (genauso wie animierte Brüste) - 95% aller Spiele machen Verlust, da wird um jeden Käufer gekämpft.

ich muss sagen ich hatte mich 3d programmierung sehr schwer vorgestellt anfangs. aber es kommt halt drauf an wo man ansetzt. eine schnittstelle wie opengl zu schreiben ist natürlich schwer. opengl zu benutzen ist kinderleicht.
vektoren brauchts natürlich, aber viel intressanter sind andre dinge. du sachst deiner rake einfach, hier pass mal auf ich will jetz n dreieck aufn schirm. dann will deine graka von dir 3 punkte in nem dreidimensionalen raum wissen. die gibst du ihr halt und dann ist sie auch schon zufrieden und wird dir dein dreieck aufn schirm malen. da kann man natürlich noch mit texturierung und beleuchtung anfangen. oder einfach nurmal mit farben ;D
aber ich reduziere realtime 3d programmierung eigentlich immer gerne auf diese wenigen dinge.

wenn du es darauf beschränkst wirst du in deinem Leben in dem Bereich nicht weit kommen. Sicherlich ist OpenGL "leicht" zu benutzen, wer ein wenig Fantasie hat oder zur Schule gegangen ist kann sich 3D Objekte im Raum vorstellen und demnach auch blitzschnell mit OpenGL auf dem Screen zaubern. Auch die Daten in Buffern zu speichern, Multitexturing usw. ist "leicht" mit OpenGL (trotzdem sollte man da mind. 1 buch gelesen haben), aber in einem Spiel ist der Source welcher auf OpenGL zugreift recht klein (mehr als 5% sollten es nirgenswo sein, wohl noch weniger). Der Rest ist das Spiel und ggf. die Engine (nicht die GameLogic, sondern verwalten von Daten uvm.).

Was mich gleich zum Thema der 1-Mann-Engine bringt: Sicher kann man als Hobby-Coder mit viel Zeit und Intelligenz eine eigene Engine bauen. Die wird aber NIEMALS im Vergleich zu kommerziellen Engines oder Hobby-Engines mehrerer Personen stehen. Leicht ist es sicherlich nicht und ich denke jede Hobby-Engine welche von einer Person programmiert wird dient alleine dem Zweck dem Erbauer etwas beizubringen. Ich baue zZ. auch meine eigene "Engine" (alleine), welche "kleine, simple Spiele" erschaffen soll (ich hab schon einige Jahre und versuche eigener "Engines" hinter mir). Dabei muss ich auf dermaßen viele Features verzichten was "normale" Spiele haben daß das Spiel letzendlich stark eingeschränkt ist...

hier sind ein paar screens...
Screen1 (http://home.arcor.de/fantadan/screen0new.jpg)
Screen2 (http://home.arcor.de/fantadan/screen2new.jpg)
Screen3 (http://home.arcor.de/fantadan/screen4new.jpg)

gencha

03.02.2005, 20:21

guter beitrag, intressante screens :)

crashgod

03.02.2005, 20:45

Sicher kann man als Hobby-Coder mit viel Zeit und Intelligenz eine eigene Engine bauen. Die wird aber NIEMALS im Vergleich zu kommerziellen Engines oder Hobby-Engines mehrerer Personen stehen.
naja gut, man kann in nem team sicherlich wesentlich schneller zu guten ergebnissen kommen, aber ich bin mir sicher, alleine kann man das auch schaffen.
wenn man wirklich bereit ist 200% zu geben. heutzutage ist es dank den shadern nich mehr sonderlich schwer imposante effekte wie Wasserspiegelungen und ähnliches zu implementieren.
Selbst das Bump oder Normalmapping um welches so ein großes tamtam gemacht wird ist da nix mehr besonderes. Auch das sagenumwobene "virtual displacement mapping"(= Parallax Mapping (http://www.infiscape.com/doc/parallax_mapping.pdf)/OffsetMapping) is da nix besonderes mehr.

@Fadan: sieht nett aus deine terrain-engine. was für ne art des LoD verwendeste ? Verwendest du Frustum Culling ? Und wie groß ist das dargestellte Terrain ?

Fadan

03.02.2005, 21:15

ich hatte eine eigene variante von LOD (also schon nach den normalen richtlinen, aber nicht nach irgenteinem bekannten Algo, im grunde wurden die quadtrees in der ferne nur subdivided) - war allerdings nicht so erfolgreich (brauchte auch viel speicher). da ich ein RTS plane hab alle FPS clipping methoden beiseite gelassen (Terrain LOD, occl. culling usw.) und mich auf ein quadtree spezialisiert. aus der map wird also ein quadtree generiert welcher es mir erlaubt jegliche terrain-größen bei konstanten fps zu rendern (die quads werden durch frustum culling überprüft, der quadtree um die checks zu verringern). Die Größe des Terrains wird also durch die Größe deines Speichers beschränkt (sollte dein Speicher 5120x5120 daten speichern können dann würde theoretisch auch das laufen wie eine 128x128 map) - terrain-streaming von der HD wird nicht gebraucht und ist von daher auch nicht implementiert (soll kein RP mit extrem großen Welten werden sondern eine Karte, wie bei fast allen RTS Games) - der aktuellsten Version sind FPS-Screens wie der 2. auch kaum noch möglich (wie gesagt jetzt auf RTS spezialsiert à la screen3)

edit:
für Teams gibts ja nich nur das eigentlich Engine-Coding zu tun. Ein Team welches eine Engine baut hat bspw. die Zeit und evtl. das Wissen ein Exporter zu coden (für 3dmax, was auch immer) um die Models der Engine genauer anzupassen. Sie können einen umfangreichen Editor coden (der früher oder später für komplexe Spiele benötigt wird) - sie haben mehr Zeit und versch. Varianten zu testen und die schnellste zu wählen, sie können sich gegenseitig helfen usw. - wenn man pers. 6 Jahre Zeit hat um eine Engine zu coden dann "kann" man das auch schaffen (solange bleibt aber keiner bei einem eigenen "Hobbyprojekt" zumal nach 6 Jahren der größte Teil wieder neu gemacht werden müsste)

ExE

04.02.2005, 14:28

Zitat von gencha:

3d programmierung kannst du in jeder sprache machen die text (oder auch nur zeichen) irgendwie aufn bildschirm packen kann.

(ich habs einfach stumpf eingefügt :) )
In anderen Sprachen auch, aber was ich meinte, war, dass C++ am besten dafür geeignet sein soll, wegen der Systemnähe und weil sie die Zeiger unterstützen, die das Spiel schneller machen (und das tun ja nich alle Sprachen)
(Für mich persönlich wärs jetzt mit C++ sowieso einfacher, da ich mit C angefangen habe).

PS: Kennt jemand n gutes Tutor zur 3D Programmierung? Muss nicht Spiel sein, einfach nur Design

Fadan

05.02.2005, 03:39

design von was? der bereich ist verdammt groß, du solltest nach tutors in bestimmten bereichen suchen, wie ein komplettes game/engine "designed" ist wirst du nur sehr selten finden, und wenn dann auch nur sehr oberflächlich... ansonsten ist diese reihe interessant (allerdings lernst du da kein bischen "programmieren", ist eben über engine-design): http://www.extremetech.com/article2/0,3973,594,00.asp

ansonsten public source codes durchschauen (q3 gibts bald sogar opensource)

ExE

07.02.2005, 16:32

Ich hab noch nie was in 3D gemacht: Zu Anfang erstmal irgendwelche Bälle, Würfel oder Landschaften...

Das würd mir zuerst einmal vollkommen reichen :D
Ich weiß, dass es schwer ist, es muss sich also noch nichts bewegen.
Dazu komme ich dann auch später :p

Fadan

07.02.2005, 17:39

Dann kann ich dir nur raten die DirectX SDK zu ziehen (irgentwo auf www.microsoft.com) - in der documentation gibts ein paar beginner tutorials wie du dreiecke färben kannst, rotieren, bewegen usw. - allerdings ist es (besondern bei DX9) dringend notwendig sich ein Buch zu kaufen (aus meiner Sicht). OpenGL ist da schon etwas freundlicher für Einsteiger (damit habe ich auch begonnen), wohl die ultimative OpenGL-Tutorial Seite: nehe.gamedev.net - ansonsten schau öfters bei GameDev.net und Gamasutra.net vorbei so bleibst einigermaßen auf dem neuesten Stand

ExE

11.02.2005, 10:49

Wow, ziemlich umfangreich :rolleyes:

Pack ich schon. Erst mal thx :p

Chlodwig

25.02.2005, 20:14

Zieh Dir mal http://www.codesampler.com/dx9src.htm rein, enthält alles was man zu DX für'n Anfang braucht um mal was auf den Schirm zu kriegen.

ExE

15.03.2005, 16:47

Hmmm... thx

Es soll auch Leutz geben, die tatsächlich alles in Codes schreiben. Wie soll das gehn, muss man da jetzt jeden Pixel einzeln proggen oder wie. Ich meine eigentlich schon, aber in aufwendigeren 3D Spielen ist das doch sehr aufwendig. Vor allem im Spiel, denn wenn sich das Objekt bewegt, dann verändert sich auch der Lichtwinkel und somit verändern sich logischerweise auch mehrere Pixel.
Wie genau würde man das machen? :confused:
Und bei Grafiken mit höheren Grafikanforderungen ist das doch ziemlich heftig, da sind doch dann mehrere 1000 Pixel, wenn nicht noch mehr, die sich dann alle verändern sollen...

gencha

15.03.2005, 16:51

für sowas gibts directx und opengl. 1000 pixel sind außerdem n witz. es wird eh jede sekunde das komplette bild neu gezeichnet.

Fadan

15.03.2005, 22:24

jede sekunde ist aber ein bischen langsam... :)

und @exe: ein spiel ist nie komplett im code gecodet (ob du nur images oder 3d models laden musst ist ja letzendlich egal..)

Xpyder

15.03.2005, 22:41

War sicher nur n Tippfehler...
Eigentlich wird nicht jede Sekunde, sondern viele Male pro
Sekunde das komplette Bild neu gezeichnet.

Und: Ich bin der Meinung, daß man ASM durchaus einsetzen
kann und sollte, um zu optimieren. (Aber denke, das wird
auch gemacht.)
Zu Carmack: Ja, Carmack ist von C auf C++ umgestiegen. Nur
ist das n schlechtes Beispiel für C++ - denn seine
effizienteren Engines sind eindeutig die, die er VORHER
gemacht hat. (Denn: DOOM3 hat nicht grad ne gute Engine,
da leisten andere mehr bei deutlich geringeren Anforderungen!)

Achja: Habe selbst schon einige 3D-Engines gecodet, auch
100% Assembler wäre denkbar (meine aktuelle wird z.B. 100% asm).
Assembler ist an sich gar nicht so schwer. Man zerlegt ein
großes Problem in viele kleine Teilprobleme. ICH z.B. code
immer alles erst in Hochsprache und debugge das, bis es erstmal
prinzipiell funktioniert und dann setze ich es (entweder
vollständig oder teilweise) in Assembler um.

Ich weiß, wie man jeden denkbaren Effekt (bilineare Interpolation,
Spiegel, Transparenz, Shading, Bump-/Normal-Mapping, Wasser,
Feuer, Dampf, Nebel, etc... SOFTWAREMÄßIG programmieren
muß bzw müßte. (Brauche daher eigentlich keine 3D-fähigen
Grafikkarten.)
Wenn ich, um die 3D-Fähigkeiten einer Grafikkarte benutzen zu
können, irgendein betriebssystem-abhängiges Software-Inferface
brauche, dann sollen die mich damit in Ruhe lassen. Werd mir
bestimmt nicht Unfug wie Windows auf den Rechner klatschen, bloß
um Zugriff auf die 3D-Fähigkeiten der Graka zu kriegen (weil es
außer doofen Softwareschnittstellen keine weitere Möglichkeit
gibt...)

Bin ein großer Feind davon, Zeug einzusetzen, das andere Leute
gecodet haben, vor allem an zeitkritischen Stellen (und die 3D-Engine
IST ne zeitkritische Stelle).
Denn: Ich weiß nicht, was die Engine macht - ist dann wie
ein "Black Box" Dingens - Daten gehn rein, Daten kommen
raus. hab keinen Einfluß auf das, was dazwischen passiert...
(Und muß davon abgesehen alles dran anpassen.)
Außerdem isses immer gut, zu wissen, was man tut (und
selbst WENN man anderer Leute Zeug einsetzt, sollte man wissen,
wie es arbeitet).
Und schließlich arbeitet man ja dann nicht frei von Rechten
Dritter - was ich generell IMMER als was schlechtes empfunden
habe (da ich Kommerzgegner bin). Eigenes Zeug dagegen kann man
weiterverteilen, wie man will.
Will sagen: Sind Routinen anderer Leute enthalten, wollen die ja
eventuell einen ANTEIL daran haben, was man damit VERDIENT.
Und das setzt voraus, daß man ÜBERHAUPT etwas damit verdient -
bringt einen also um die Möglichkeit, es einfach zu VERSCHENKEN!

Achja: Wieso werden hier eigentlich ständig Aufwand-/Nutzen-
Rechnungen betrieben? Seit wann ist GELD denn für Hobby-Coder
wichtig? Ich dachte, man codet, weil es einem Spaß macht und weil
einen das Ergebnis interessiert? Oder gehts hier nur darum, in
kürzester Zeit soviel wie möglich Kohle zu scheffeln? - Wenns nur
um GELD geht, braucht man sich den Aufwand, ÜBERHAUPT zu
programmieren, ja garnicht geben - weil es viel einfachere Methoden
gibt, um Geld zu machen: Drogen dealen beispielsweise, oder auf den
Strich gehen.
Wenns nur um die Kohle geht, und darum, schnell fertig zu werden,
hat man sich mit Programmieren das falsche Hobby ausgesucht.
(Naja. Man könnte immer noch bei Microsoft anfangen. Die bringen
ihre Programme ja auch raus, bevor sie richtig debugged sind.
Optimieren ist da eh kein Thema und die verdienen halt ein
Schweinegeld...)

Falls jemand wissen will, wie verschiedene so Dinge gehen, kann er/sie
mir ja schreiben. Allerdings kann ich keine Fragen zum Thema
"wie steuere ich 3D-Funktionen der Grafikkarte an" oder "wie benutze
ich Direct-X" beantworten, eher so Sachen, wie der Kram prinzipiell
funktioniert, wie die mathematische Theorie dahinter ist, oder wie man
sowas in asm optimiert.
Und btw: Es passiert dermaßen oft, daß ich irgendwas inASM mache, weil
ich es in ASM viel EINFACHER finde, als das mit irgendwelchem
abstrakten Hochsprachen-Code zu umschreiben. GERADE und GANZ BESONDERS
Grafikprogrammierung ist in fast allen Hochsprachen viel zu abstrakt
und systemfern gelöst...
(Man erlebt's leider immer wieder, daß Leute selbst für zeitkritische
Bereiche IM ERNST so "universelle" Pixelsetzroutinen irgendwelcher
Hochsprachen einsetzen... Nur mal so'n Beispiel.)

Jan Krüger

16.03.2005, 00:05

ein spiel ist nie komplett im code gecodet (ob du nur images oder 3d models laden musst ist ja letzendlich egal..)
Unterschiedlich. Bei kkrieger (http://www.theprodukkt.com/kkrieger.html) ist tatsächlich alles Code, wenn auch teilweise eine Art Scriptcode.

Jan Krüger

16.03.2005, 00:10

Ich weiß, wie man jeden denkbaren Effekt (bilineare Interpolation,
Spiegel, Transparenz, Shading, Bump-/Normal-Mapping, Wasser,
Feuer, Dampf, Nebel, etc... SOFTWAREMÄßIG programmieren
muß bzw müßte. (Brauche daher eigentlich keine 3D-fähigen
Grafikkarten.)
Ich kenne deine Ziele bei der Programmierung inzwischen ganz gut, weil du sie ja öfters mal detaillierst. Aber wenn jemand eben gerade das Ziel hat, ein grafisch raffiniertes Spiel zu produzieren, muss er bei einer reinen Softwareimplementation entweder erhebliche Abstriche machen oder die Ausgabeauflösung drastisch reduzieren, denn du kommst mit keinem noch so raffinierten Algorithmus an die Fähigkeiten eines 3d-Chips heran.
Klar, wenn man lieber alle mathematischen Finessen selbst austüfteln will, ist es reizlos, den Chip zu benutzen, aber wenn man etwas schreiben möchte, das eine gewisse Modernität hat (und das wollen hier offensichtlich sehr viele Leute), kommt man wohl nicht drum herum. Und dieser Thread drehte sich nunmal ursprünglich darum, wie man am einfachsten 3-dimensionale Dinge produzieren kann -- sicherlich nicht, wenn man erst alle mathematischen Grundlagen und Optimierungserwägungen selbst lernen muss.

Scavi

16.03.2005, 09:03

@Xpyder: Sehr guter Beitrag, stimme ich 100%ig mit überein. Jedoch finde ich, dass eine Mischung zwischen GraKa-Alg. und eigenem Code die besten Resultate bringt (hinsichtlich Performance).

Bei kkrieger ist tatsächlich alles Code, wenn auch teilweise eine Art Scriptcode. ...das ist Definitionssache, denn die 3D-Modelle wurden schon "modelliert".

Fadan

16.03.2005, 14:09

Unterschiedlich. Bei kkrieger (http://www.theprodukkt.com/kkrieger.html) ist tatsächlich alles Code, wenn auch teilweise eine Art Scriptcode.

hehe ich hab schon damit gerechnet daß dieser Einwand kommt ;) Die Demo-Szene ist wieder was anderes (kenne mich da auch nicht so genau aus, irgentwie müssen sie die Models ja auch erstellt haben)

@Xpyder: hab ich dich richtig verstanden? (Du verzichtest auf OpenGL und Direct3D?) - wenn ja, viel Spaß. Wenn man das Wissen, die Lust und das Aushaltevermögen kann das sicherlich Spaß machen (für mich wär das nichts) - aber um komplexe Spiele zu programmieren welche technisch einigermaßen auf dem neuesten Stand sind ist eine eigene Engine aus 100% Assembler mit eigenen Grafikroutine reine Utopie! Alleine die Zeit für die Grafikroutinen müssen ewig dauern, dazu kommt daß alles ASM ist (ich hab früher selbst ASM programmiert, und du ob es dir besser gefällt oder nicht, es dauert um einiges länger!). Und um deine GraKa anzusprechen musst du nicht Windows installiert haben. Wie Jan Krüger schon meinte, an die Performance eines GPUs werden deine ASM routinen nie ankommen... in diesem Gebiet trifft der Satz tatsächlich zu: "Wieso das Rad neu erfinden?" (ich hasse diesen Satz sonst auch).

EDIT: dazu muss ich sagen daß wir hier über Game-Engines und nicht 3D-Engines reden... (die Begriffe wurden oft durcheinander gewürfelt..)

Jan Krüger

16.03.2005, 16:48

Okay, das stimmt, aber in den Programmdaten sind keine Mesh-Daten oder Texturbitmaps oder Ähnliches enthalten. Naja, lassen wir das einfach. ;)

Ich habe übrigens auch nichts gegen Optimierung. Da ich aber selbst keine Grafikprogrammierung mache, kann ich nicht sonderlich gut beurteilen, welche Optimierungen sich in welchem Umfang bezahlt machen.

DaSteph

28.03.2005, 19:07

@Xpyder mal ne Frage die mir kommt:
Alle unterstellen dir ja jetzt, dass du mit deinem asm nur die CPU ansprichst, was natürtlich langsamer wäre als eine Api zu verwenden. Oder sprichst du soagr die Grafikkarte direkt mit deinem asm an, das wär natürlich sehr interessant, aber ich glaube, da müsstest du ja die gleiche Arbeit machen wie die Grafikkartenherstellern in ihren Treibern, und da unterstelle ich dir einfach mal, dass die es besser können ;).

Aber wenn du die GPU direkt mit asm und so ansprichst würden mich deine Quellen und die specs dazu auf jedenfall mal interessieren.

Back2Topic: ist das noch relevant? :D

comastalker

05.04.2005, 15:24

schreib mal einen pixelshader komplett in asm.
viel spaß...

so und der restliche Senf :
1.) die asm-nicht-asm-diskussion hilft dem Fragestellenden überhaupt nicht und ist so OT, dass ihr am besten einen neuen Thread aufmacht
2.) der Duden ist weder orthographisch noch semantisch korrekt. Er spiegelt den SprachGEBRAUCH wieder. Beispiel ?

Anarchie heißt im Duden Abwesenheit von Ordnung
eigentlich heißt Anarchie (gr. an-arkos) aber Herrschaftslosigkeit.

Nehmt den Duden NIE ernst. Richtige Vorgehensweise :
1. Enzyklopedie (oder die WikiP)
2. eymologisches Wörterbuch
3. ortographische Festlegungen vom Amt - und nach denen ist Graphik falsch.

Fillbert

14.04.2005, 22:07

Man, man, man...

was geht denn hier? Ein ASM vs. hochsprache Fight ?
Gut dem schliess ich mich an. ich komme aus der demo scene und dort ist es üblich 3d engines zu schreiben, sicher sind diese in manchen punkten game engines unterlegen, in anderen aber überlegen. Das liegt aus meiner sicht an folgenden dingen:
1. die leute machen sich nen kopp um algo's, soll heißen wo kann ich performance gewinnen in dem ich einfach mal um die ecke denke
2. die leute machen sich gedanken um compiler: ich kenne nach ner weile die macken meines compilers, wo ist er schlecht und wo ist er gut. damit kann ich dann die stellen umschreiben (in ASM) die der compiler verbockt. und die, die der compiler gut macht lasse ich, weil man will ja auch irgendwann mal fertig werden mit der prod. oder dem project....
3. die leute machen sich vorher nen kopp um das softwaredesign, der beste code ist nur halb so gut wenn das sw-design shit ist.

Mein statement:
nimm ASM an den stellen die häufig benutzt werden, innerloops, math (incl. vector), physic etc. natürlich nur dann wenn wirklich etwas an performance rauszuholen ist, soll heißen, der compiler einfach gewisse structuren nicht gut umsetzten kann oder der c (oder was auch immer) code damit noch schlimmer zu lesen wird als der vergleichbare ASM code e.g.: bitwise rotating ... in c geht es einfach nicht nur mit krücken die der compiler dann so umsetzen muss das er einfach langsamer sein muss. (ich warte jetzt förmlich auf die aufschreie derer leute die sagen bit's brauch man doch nicht mehr, man kann doch bytes nehmen, speicher ist genug da)
nimm OOP weil es dein programm übersichtlicher macht, aber nimm nur soviel OOP wie nötig, nicht zu jeder variablen (attribute) eine get/set method...
ein weiteres schönes abfall produkt an OOP ist, das du, mal davon ausgegangen du hast ein gutes design, eine stelle in asm änderst und der komplette code wird damit optimiert (an diesen stellen natürlich nur)
nimm soviel gute algo's wie irgendwie möglich, es bringt nix ne einfach liste in ASM zu coden wenn es ein baum viel besser, von mir aus auch in VB kann. (log vs. linear)
nimm nicht allen schnick-schnack in deine engine von denen du mal gehört hast, versuche sparsam zu sein und mit den geschaffenen mitteln das optimum an eye-candy und performance zu holen.
nimm nicht immer fertige biblotheken, weil die meist so gehalten sind das man jeden spezialfall mit abdecken kann, was unglaublich an performance klaut.

THEMA: Zu grosse maschinen (Rechenpower) für ein modernes game...
die developer sind heute fast nur noch auf das ziel = funktionieren aus. die zeit (und somit geld) für debuggen und optimieren ist sehr begrenzt (siehe alpha/beta treiber/software).
allerdings gibt es ab und zu mal ganz nette produkte (spiele) die vielleicht mehr geld gekostet haben, aber vom gameplay, performance etc besser sind als heldtitel mit 5DVD's.mit gameplay erreicht man leute die nicht C&C 13 spielen wollen und mit performance einfach mal mehr leute.
ich habe selber einen p3 650mhz, und freue mich immer über coole games die hier noch laufen... wer unbedingt wegen 20 bunter pixel die mehr im screen sind bereit ist aller 3 monate ne neue graka zu kaufen (150 EUR), aber sich dann bei nem spiel einkackt was mal 10 EUR mehr kostet weil die leute optimiert haben, der tut mir einfach nur leid....

MfG
Fillbert
if (critic == CONSTRUCTIVE)
return THNX;
else
__asm {
xor eax,eax
call eax
}

Schönen Tag noch

Xpyder

15.04.2005, 02:44

@Fillbert: Ja, endlich hat es mal einer verstanden.
Stimme Dir 100%ig zu.

(Die bloße Existenz schneller CPUs als Vorwand für
oberflächliches Coding zu nehmen, finde ich eben auch
Müll.)

Und für alle, die hier C so anpreisen von wegen "Wer C
codet, braucht keinen Assembler mehr"

siehe VICE und ZSNES.

VICE = C64 Emulator
ZSNES = SNES Emulator

In beiden hat man zu Anfang auf ASM Routinen gesetzt - und
später - wegen der Portierbarkeit (ECHT - IM ERNST!)
ASM-Routinen wieder entfernt (!!) um sie durch C-Routinen
zu ersetzen (!!!)
Man sieht es am Ergebnis: Die Performance ist absolut im
Keller (und dabei war der ZSNES früher der schnellste SNES
Emulator wo gab - bevor diese anderen Typen den versaut
haben).
Gerade bei nem Emulator - wo man ja quasi mehrere andere
CPUs emulieren muß, sollte ASM zumindest für den Emulator
selbst Pflicht sein (also die "Emulatorschleife") - seine
GUI (wenn er eine hat) kann man ja meinetwegen in Hochsprache
coden, weil da ASM wohl keinen Sinn macht.

Und: Ja, genau. Nur weil es Rechner mit über 3 GHz gibt, muß
das nicht heißen, daß auf keinem Rechner unter 2 GHz
überhaupt noch irgendwas zu funktionieren braucht.

Und wer Argumente der INDUSTRIE auf seine eigenen
Programmiergewohnheiten anwenden will - der sollte sich
eigentlich lieber n anderes Hobby suchen. Weil: Leidlich
performante Software "von der Stange" braucht man nicht
mühevoll selber coden - das macht schon die Softwareindustrie.
(Übrigens lustig: Die sagen immer, daß sie damit
Entwicklungskosten sparen. Dieser These zufolge müßte
kommerzielle Software heutzutage nahezu kostenlos sein.
Das Gegenteil ist aber der Fall...)

Und: Auch was diese fertigen Schnittstellen angeht: Genau
so seh ichs auch: Die sind halt "universalkompatibel" und
supporten einen Haufen Kram, den man NICHT braucht (killt
Performance), den Kram, den man braucht, supporten sie
halt nur als Teil eines Gesamtkonstrukts, ohne im
Besonderen speziell DARAUF einzugehen (killt weiter
Performance) und davon abgesehen haben sie oft halt
"user-/anfänger-freundliche" Fehlerabfragen drin (etwas, was
man SELBST nach dem Debuggen normalerweise zum
Performance-Gewinn ausbaut, da man selbst ja wohl keine
fehlerhaften Daten produzieren wird - weil, wenn DOCH, muß
man ja sowieso weiter debuggen.)

(Das ist das lustige an Microsoft-Kram: Es hat einen
Haufen Fehler - aber eben auch dauernd lustige Erkennung
und Anzeige derselben, im Sinne von: "Ja, ich weiß, daß
ich Scheiße bin - kann nur nix dagegen machen...")

Und @ comastalker: Also GERADE und GANZ BESONDERS
Pixelroutinen (die Teil der "inner Loops" - also innersten
Schleifen sind - und damit extremen und fast DIREKT
PROPORTIONALEN Einfluß auf die Performance haben!) sollten
SO SCHNELL wie nur IRGEND MÖGLICH sein.
Wenn die Pixelroutine der inner Loop langsam ist, kannste
noch so viel effizienten Code "drumherum" coden und wirst
trotzdem ne ziemlich lame Performance haben!

@ DaSteph: Wer ist "alle"? Wieso unterstellen die mir das?
Also: Wenn ich 256 Farb-Zeug code, spreche ich direkt die
Grafikkarte und die Register an - brauch ich keine APIs
oder sowas. Wenn ich Zeug für >256 Farben code oder über
256k Grafikspeicher, benutze ich VESA - das kann man auch
von ASM aus anlabern, und es ist in Grakas implementiert -
d.h. lobenswerterweise völlig OS-unabhängig.
Und zu dem Punkt, daß "Graka-Hersteller es besser können":
Ich erinnere nur daran, daß UniVBE - das NICHT von
Grafikkartenherstellern, sondern von UNABHÄNGIGEN TYPEN
gecodet war, viel mehr Performance aus den Grakas geholt
hat als das implementierte Zeug auf der Graka. Zusätzlich
hat es Zeug ermöglicht, das die Graka zwar konnte, das die
Hersteller aber (frag mich wieso) nicht im VESA supportet
haben. Und nicht zuletzt haben sie sogar Bugs entfernt,
die von Graka Herstellern verbockt wurden.
Achja: Zu meinem Thread bezüglich des ätzenden VESA-Bugs,
die einen guten Teil der ATI-Radeon-9x00 Serie betrifft,
hab ich bisher immer noch keine Lösung gefunden.
MEINER Erfahrung nach können Softwarehersteller keine gute
Hardware bauen - und Hardwarehersteller keine gute Software
proggen.
Und IMO sind Treiber der Hemmschuh Nummer eins überhaupt.
Und ohne Treiber wären wir alle besser dran. Würde man
Hardware gleich vernünftig funzend bauen und mit nem
vernünftigen Standard versehen, könnte man diese
a) OS-unabhängig einsetzen
b) hätte mehr Performance
Ich verstehe natürlich vollkommen, daß die INDUSTRIE an sowas
kein Interesse hat - deswegen muß ich das aber nicht gut
finden. Treiber - oder wie ich sie nenne: Resident Evil.
Und daß direkte Ansteuerung von Hardware - egal bei
welcher Art Hardware! - LANGSAMER wäre als die Nutzung von
Softwareschnittstellen (aka APIs) kannste dem Weihnachtsmann
erzählen... - das ist echt der Witz des Jahres...
Und: Ja, ich weiß, daß VESA auch bloß ne blöde
Softwareschnittstelle ist... - da braucht mich jetzt nicht
wieder jeder zweite drauf hinzuweisen. (Wenigstens muß man
aber dafür nicht seinen Rechner mit Windows verseuchen.)

Xpyder

15.04.2005, 02:49

Achso, ja: Natürlich kann man ohne Windows wahrscheinlich
nicht die 3D-Fähigkeiten der Grafikhardware benutzen (da
man keine Möglichkeit hat, die jeweiligen Specs rauszufinden
- nicht, weil man zu blöd wäre, das anzusteuern).
Aber manchmal sehe ich so DOS-Demos, die leisten ohne
3D-Hardware mehr als manche 3D-Spiele MIT. Ob da der
Performancegewinn der 3D-fähigen Graka wieder durch die
Windows-Bremse oder ineffizienten Code ausgeglichen wird?
- Ich glaube schon.

Achja, für alle, die das evtl falsch verstehen: Ich code
auch nicht alles in 100% asm. Ich fand halt nur, ich sollte
mich zumindest mal zu Wort melden, wenn Thesen verbreitet
werden wie sinngemäß sowas wie "eigentlich braucht niemand
mehr asm heutzutage" und so weiter.

Hab mal neulich bei nem Kumpel diese Spiel "Yeti Sports"
gesehen. Ziemlich primitives Game. Aber bis auf das
"Ursprungs-Spiel" (mit den Pinguinen und dem Baseballschläger)
waren die ganzen Nachfolger schweinelahm, haben geruckelt
wie die Pest, teilweise unspielbar (2 fps und so! ZWEI!)
auf einem 350 MHz-Rechner!
Und das, wo das alles nur so paar (vorgerenderte) Sprites
sind - also so 2D-Grafik Kram, was jeder Demo Coder mit
links und verbundenen Augen coden würde... (und wofür
selbst ein 50 MHz-System normalerweise schon total
überdimensioniert wäre)
Naja. Halt imo Flash oder sowas. Meine ja nur: Da sieht
man halt, wohin das eines Tages führt: Dazu, daß Programme
gemacht werden, bei denen über 80% der Prozessor- und
Systemleistung dazu verbraten werden, den umständlichen
Code zu interpretieren und nur der klägliche Rest für das
eigentliche Programm/Spiel zur Verfügung steht.
Und dazu kann ich nur sagen: Selbst wenn Rechner mal 100 GHz
schnell sind - DIESE Art von "Coding" werde ich nie jemals
erstnehmen können - und abgesehen davon würde ich dafür
auch kein Geld ausgeben.
Naja. Liegt unter anderem wohl daran, daß ich selbst code.
Und wenn ich was kaufen würde und dann sähe: Krieg ich mit
ein bissel Mühe selber hin - auf nem System mit nem Zehntel
der Mindestanforderungen - tja, dann wär's mir echt schade
ums Geld.
FRÜHER war's den Leuten ja auch nicht zuviel, den Code ein
wenig an das jeweilige Problem anzupassen. -- Daß diese
oberflächlichen Coder den RICHTIGEN Codern heutzutage die
Arbeit wegnehmen, liegt wohl daran, daß viele User "einsehen",
was man ihnen ständig einzureden versucht: Nämlich, daß
man alle Vierteljahre ein Systemupgrade braucht - bzw daß
man übers Jahr mindestens einmal jede Komponente des
Rechners (bis auf das Gehäuse vielleicht) ausgewechselt
haben muß...
Ich habe neulich im Scherz mal zu jemandem gesagt:
"Irgendwann kommen die ersten Quantenrechner - und Multicore
gibts ja schon demnächst. Aber ob Rechner mal irgendwann so
schnell sein werden, daß selbst Microsoft es nicht mehr
schafft, die durch ihre jeweils aktuelle Windows-Version
runterzubremsen? - Oder anders ausgedrückt: Ob jemals ein
Rechner gebaut wird, der mal schnell genug ist für Bill Gates?"
(Ich meine: Irgendwann will ich mal einen Rechner sehen,
wo einer das jeweils aktuelle Windows laufen hat und man
was anklickt und das in Echtzeit passiert und nicht mit
ner Sekunde Verzögerung.)

Oder, um das ganze auf einen Satz zu bringen:
Weiterentwicklung der Hardware sollte nicht zwangsläufig
zur Rückentwicklung der Coder führen. (sondern vielleicht
eher als Herausforderung angesehen werden).

Zum Off-Topic: So wie ich das sehe, lautet das Topic
"Einfachste und effektivste 3D-Spieleprogrammierung".
Also imo ein Widerspruch.

Einfach = Benutze Softwareschnittstellen, benutze
vorgefertigte Engines, benutze "3D-Game-Maker" Zeug (gibts
alles, kann mich gerne nochmal erkundigen, wie es heißt)

Effektiv = Vermeide alles, was ich unter "einfach"
geschrieben habe.

OK, an alle HTML- und JAVASCRIPT- "Programmierer" da
draußen: Jetzt dürft ihr mich wieder steinigen...

Scavi

15.04.2005, 09:16

Da kann ich euch komplett zustimmen, ganz meine Meinung!

Fillbert

15.04.2005, 11:03

tja der gute alte VESA standard. leider kann er bloss nix, oder sagen wir fast nix. es ist wirklich schade um ihn, den er war bisher der einzige standard für vga am pc der wirklich konzept hatte. leider setzt ein standard immer voraus das die leute sich gegenseitig in die karten schauen können, was in der marktwirtschaft niemand will. ich habe mich wirklich geärgert als ich feststellen musste das so manche moderne vga nicht mal vesa 3.0 unterstützt, weil ich auch gerne betriebssystem unabhängig oder sogar eigenes system code, und wenn du da nur vesa 2.0 hast ist das ein wenig zu wenig. Wenn aber nicht ein wunder geschieht bleibt das so und es wird immer den weg erfordern das man einen treiber des herstellers für ein spezielles system lädt, sonst geht halt nur der standard von 93.

Willkommen in der Steinzeit.

ps:
allen leute die mal nen spiel programmieren wollen weil sie irgendwie in ner woche info-unterricht in der 8.klasse gefallen gefunden haben, programmiert erst mal nen kleines einfaches game, auch wenn euch 1000 leute sagen "gibt es doch schon".
ich persönlich mag kleine games. schnell installiert, meist frei oder halb (free/shareware), nicht die hammer performance, coole ideen (aber das ist ein anderes thema) und man merkt das die leute es irgendwie aus leidenschaft machen und nicht des geldes wegen.

#define KLEINES_GAME
Haltet den Graphic output erstmal flach.
Kümmert euch um das Gameplay. Wenn das scheisse ist merkt jeder spätestens nach 3 minuten das sich das game nicht lohnt, nicht mal in zeit von DSL und T1 ;-)
Haut das Gameplay hin kann man immernoch die komplete Graphic und Sound Engine kicken und das game "aktueller" machen.
Klingt jetzt als muesste man es zweimal coden? und ja allen anfängern sei gesagt: Ihr habt keinen Plan auf was ihr euch einlasst. Aber das ist auch gut so sonst wärt ihr wahrscheinlich im vorfeld schon abgeschreckt.
Und wer meint moderne Spiel, oder besser dessen Gameplay sei wirklich gut, naja der soll sich mal nen EMU besorgen und wirklich in die vergangenheit von SEGA & Co. kriechen. Aus heutiger sicht shitten Hardware, aber man hat sich kopp ums spiel gemacht, nicht darum das die laufkundschaft das 10fach FullscreenAntiAliasing und das 12.1 Soundsystem geil finden.

Als tipp:
Capcom Spiele für MAME, komplett 2D mit super wenig HW aber richtig spielspass
Smugglers3 - Shareware, richtig geiles Weltraumsim., komplett 2D und sofern ich mich noch richtig erinner nur 2 animierte gfx im game, sonst alles standbild!!!!!!
Transport Tycoon Deluxe, komplett 2D und ich spiele es ab und zu immernoch (und freue mich auf die opensource variante, weil die dann mit richtig coolem netzwerk :-))
RPG auf Konsolen: Zelda, Phantasy Star, Y's... graphic so gut wie es ging, Gameplay mindestens 101%
so und damit niemand sagt ich zock nur 2D
Unreal aufm PC (erster Teil), 3D Shooter mit ner Story!!!
Kyodai Mahjongg - wie der name schon sagt

so mal wieder schluss, freu mich auf die comments
Fillbert

Xpyder

15.04.2005, 18:01

(Auch wenn das jetzt wie Werbung klingt, was es nicht ist,
weil das Projekt selbstredend Freeware wird) :

http://www.imperial-games.de/html/prea1.htm

XPYDERZ - das Spiel hab ich selber im Herbst 2001 angefangen
zu coden - hab auch zwischendurch ne Menge anderen Kram
gemacht (nicht daß einer denkt, ich code 3einhalb Jahre an
so einem Ding). Mittlerweile nerven mich aber ziemlich viele
Leute, daß ich das fertig machen soll (es kriegt auch noch
Multiplayer und so).

ANGEFANGEN hatte ich auch mit einer Engine in 100% Pascal.
Hab dann nach und nach ein paar Teile in asm übersetzt -
es hat halt im Moment 1600 bewegliche Objekte (aka
"Figuren") gleichzeitig - Kollisionsabfrage usw natürlich
mit Hilfe einiger Tricks... (Ich frage nicht wirklich
1600! (Fakultät) Kollisionen ab.)

Wie man leicht sieht, sieht die Grafik auch aus wie Hund
hinten. - Aber das werde ich noch "upgraden" - ich hatte
es damals aus Bequemlichkeit und der Einfachheit halber
mit nem selbstgeproggten (vor langer Zeit) "Malprogramm"
gemacht, das in TEXTMODE (16 Farben) arbeitet.
D.h. eventuell kriegt das Game noch 256-Farb-Grafik.
Gameplay ist halt: Man steuert einen Panzer, hat etliche
Waffensysteme und jagt damit kleine und große Spinnen.
(Eigentlich ist die Idee sowas in der Art wie dieses alte
Textmode-Spiel SNIPES (von Novell Netware), war bei dem
IPX Kram von denen als "Test-Dingens" dabei...)

Wie ich die Leute kenne, werden die meisten im Multiplayer
sich eh wieder für "Deathmatch" entscheiden. (Es gibt auch
noch Cooperative + TeamBattle.)

Achja, btw: Auch ich hätte nie erwartet, daß so viele
Leute so einen Mist geil finden könnten - grade im
Zeitalter von 3D und so. Aber offensichtlich tun sie das.
(Und btw: Hab auch selbstgeproggte 3D-Engines hier, könnte
also, wenn's mich interessieren würde, durchaus auch 3D
Games coden.)

Als nächste Projekte mach ich dann wahrscheinlich so Game
"Clones" zu Dingen wie R-Type/Gradius, Turrican und/oder
Super Probotector. Die Grafikengines dafür sind lange fertig.
Will sagen: Ich bin eigentlich eher so ein "Engine-Coder"
- schätze, mit dem ganzen selbstgebauten Kram, den ich so
hier rumliegen habe, könnten Heerscharen von Leuten, die
gerne Games coden würden, ne Menge anfangen... - Aber ich
weiß es ja - und mir selber gehts nicht anders: Man hat
normalerweise keine Lust, Zeug zu benutzen, das andere
gecodet haben.

Zum Thema VESA nochmal: Zumindest, was 2D angeht, erfüllt
es den Zweck. Und außerdem: Wenn ich VESA vermeiden kann,
vermeide ich es. Ich benutze es eigentlich eher, wenn ich
für irgendjemanden ein Tool code und ihm ne windows-artige
Oberfläche verpasse (damit derjenige keinen Kulturschock
kriegt, wenn er feststellt, daß es auf der Welt noch andere
Programme als Windows&Co. gibt...) - ist ja nicht grade
so, als wär so bissel Fensterchen-/Icon-/Mauscursor-Kram
oder Proportionalschrift jetzt wirklich das Problem - auch
wenn einem in letzter Zeit immer weisgemacht werden soll,
daß man dafür solche Kriegsschiffe von Rechner bräuchte...

Ich brauche zB keine "Pixelsetzroutine" irgendwelcher APIs
oder Treiber - was kann schließlich schneller sein, als ein
(oder mehrere) Bytes direkt in den Grafikkartenspeicher zu
setzen?

(Gerade für so "Sprite" Routinen - oder im 3D für "Textur"
Routinen: Da sollte man NIEMALS(!!!) konventionelle Pixel-
Routinen benutzen! Immerhin liegen die Pixel da ja in
"Zeilen und Spalten" direkt nebeneinander - diesen Umstand
sollte man sich definitiv zunutze machen.)

Kleiner Tip an alle Mini-Coder da draußen: Man nehme 2
Maschinencodebefehle (irgendwie einfügen - ich schreib
mal, wie es in Pascal geht)

asm {jetzt kommen 2 Assembler-Befehle}
mov ax,13h {Modus 13h - 320x200 mit 256 Farben}
int 10h {Int 10h aufrufen, schaltet in diesen Grafikmodus}
end; {Damit schaltet man "Assembler" wieder aus}

Rückwärts (zurück in Textmode) schaltet man genauso, nur
daß man statt 13h dann 03h benutzt!

Dies ist der 256-Farben-Modus. Ist nicht besonders "cool",
man hat auch nur eine Bildschirmseite und so und 320x200
Pixel ist vielleicht auch keine klasse Auflösung.

Aber die Pixel liegen direkt zeilenweise im "Grafiksegment"
(also $A000) und können so als Bytes angesprochen werden.
Die (imo) einfachste (wenn auch nicht effektivste) Lösung
ist, ein 320x200 Bytes großes Array genau auf die Stelle
zu klatschen:

var Screen:array[0..199,0..319]of byte absolute $A000:$0000;

Damit kann man dann Pixel setzen, indem man einfach Werte
zuweist (beachten: Das erste ist die Zeile (also Y), das
zweite die Spalte (also X)) :

Screen[45,178]:=14; {gelben Pixel in Zeile 45, Spalte 178 setzen}

Genauso kann man z.B. mit

A:=Screen[92,87]; {Pixelfarbe nach Variable A holen}

die Pixelfarbe auslesen. Als Farben sind 0 bis 255 möglich.

Xpyder

15.04.2005, 18:08

Standardmäßig ist die Palette vorgegeben.
Farben 0-15 sind die normalen EGA-Farben (wie im Textmode)
Farben 16-31 sind 32 Graustufen, von schwarz nach weiß.
farben 32-55 sind 24 Farben von Blau->Grün->Rot->Blau im "Farbenkreis"
Diese 24 Farben wiederholen sich noch ein paarmal.
Die nächsten 24 sind etwas heller, die übernächsten noch
heller. Und dann kommen diese 3x24 Farben noch zweimal,
insgesamt in zwei Stufen dunkler.
Die letzten 8 Farben, die übrigbleiben, sind "undefiniert"
- enthalten also die letzten Werte, die die Palette beim
letzten Benutzen eines 256-Farb-Modus hatte (und sind
default alle schwarz).

Das ist alles gut und schön... Noch besser wäre jetzt ein
lustiger BIOS-Aufruf, um die Palette selbst zu definieren.
Aber das erkläre ich bei Interesse das nächste Mal genauer.

Will nur sagen: SO SCHWER isses garnicht mal, mal eben fix
in den Grafikmode zu schalten und ein kleines lustiges
Spiel zu machen. Dinge wie "Pac Man" und "Tetris" und so
sollten damit schon ohne weiteres möglich sein.
(Will sagen, ist bunt und schindet meistens schon ne Menge
Eindruck...)

Und dabei fällt mir ein, ich sollte wirklich mal eine
Tutorial-Sammlung basteln: "Wie programmiert man ein Spiel?"
(Das ist die Frage, die einem als Coder von Nicht-Codern
imo am häufigsten gestellt wird - wohl aber in der Hoffnung,
daß die Antwort nicht länger als 3 Minuten dauert.)

Achja, an alle Programmier-Anfänger da draußen: Wenn man
kaum die Theorie, die hinter 2D-Spielen steckt versteht -
oder es nichtmal schaffen würde, Tetris zu coden, sollte
man nicht hoffen, ohne Probleme ein 3D-Spiel machen zu
können. Selbst "Game-Maker" setzen ein Mindestmaß an
Verständnis für die "3D-Welt" voraus.

Und, achja: Der Computer wurde ursprünglich mal als
RECHENMASCHINE gebaut - das ist er auch heute noch - auch
wenn man die Grafik-/Sound-Fähigkeiten zum Spielen
mißbrauchen kann... - Das schlägt sich in der ganzen Art,
wie man das Ding programmieren muß, nieder.

Daher an alle, die vielleicht schonmal die Frage gestellt
haben oder noch stellen wollen:
"Ich will ein Spiel coden - wie geht das und geht das auch
ohne Mathe?"

- Nein, geht es nicht. Zumindest ein wenig Mathe ist IMMER
beim Programmieren dabei. Das sollte man bedenken, wenn man
sich für dieses Hobby entscheidet.

"Auch bei 3D-Spielen?"

- GANZ BESONDERS bei 3D-Spielen!