Diskussion:Quake-Engine

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 27. Juni 2022 um 12:22 Uhr durch imported>IT-Compiler(3871605) (→‎Mouselook und Tastatursteuerung: typo).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Source-Engine enthält Quake-Code

"Laut offiziellen Angaben beinhaltet sie jedoch keine einzige Quellcode-Zeile des ursprünglichen Spiels." Laut offiziellen Angaben, ja. Aber das stimmt definitiv nicht. Allein im SDK der Source-Engine kann man einige eindeutige Überschneidungen finden - ich bin mir recht sicher sogar irgendwo in den Kommentaren was von Quake gelesen zu haben. War wenn ich mich Recht erinnere im Codeabschnitt für die BSP-Dateien. Vielleicht könnte das jemand genauer recherchieren? -- Yarin Kaul 18:53, 8. Jun 2006 (CEST)

dass die source engine zu weiten teilen auf "geklautem" code aufgebaut bzw nicht lizenziertem code aufgebaut ist, weiss man spaetestens seit dem half-life 2 leak - das ist genau des selbe bloedsinn wie die "voellig neu programmierte doom 3 engine" welche nicht mehr auf der quake engine basiert - from scratch programmiert in dieser branche keiner - waer ja noch schoener ;) --suit Benutzer Diskussion:Suit 20:46, 8. Jun 2006 (CEST)

Plattformen

Welche Plattformen werden denn außer Windows noch unterstützt? --92.226.198.120 11:32, 11. Dez. 2007 (CET)

---so ziemlich alle, es gibt unmengen ports.

Link zu "Quake Engines Family Tree"

Der Link auf [Quake Engines Family Tree] führt ins Leere.

quakesrc.org scheint gerade down zu sein (komplett) - bitte erneut checken in einiger zeit und dann den link ggf entfernen --suit Benutzer Diskussion:Suit 23:55, 7. Apr. 2008 (CEST)

Wirklich erste echte 3D Engine?

Ich bin mir nicht sicher, ob diese Aussage so richtig ist. Descent hatte schon einige Zeit davor eine echte 3D Engine (veröffentlich mitte Mai 1995). Zwar wurde sie nicht wie bei Quake als "eigenständige" Engine vermarktet, aber als Bestandteil von Descent kann man trotzdem von einer Engine sprechen. Auch Terminal Velocity von 3D Realms hatte eine echte 3D Engine und wurde bereits einige Tage vor Descent veröffentlicht. Dass es sich dabei ebenfalls um eine echte 3D Engine handelte, zeigt zB ein Patch, der den 3D Beschleuniger Chip ViRGE von S3 unterstützte (inkl. Z-Buffer, bilinearer Filterung und primitives alpha blending).

Die Frage ist halt, ob die Spiele wirklich eine Engine hatten. Darunter versteht man üblicherweise, wenn dei Engine von den Spiel-Inahlten (also texturen, Maps,...) getrennt ist. 3D Tetris (1989) ist auch shcon ein echtes 3D-Spiel, trotzdem würde keiner von einer 3D-Engine sprechen. Jedenfalls änderst sich mMn bei den von dir genannten Spielen nichts daran, dass Quake der erste vollständig 3-dimensionale First-Person-Shooter war, weil die Descent und Terminal Velocity sind ja Weltraum-Shooter (also wo man mit eionem raumschiff herumfliegt und z.B. andere Raumschiffe abschießt), die üblicherweis nicht zu den FPS gezählt werden. --MrBurns 18:22, 3. Mai 2010 (CEST)
Das steht so aber nicht im Text - sondern es steht explizit:"ist die erste 3D-Spiel-Engine, welche statt 2-dimensionalen Sprites echte 3-dimensionale Modelle nutzt.", und ist somit falsch. --Zilti (Diskussion) 20:16, 21. Mai 2016 (CEST)

Mouselook und Tastatursteuerung

insbesondere die Kombination aus Mouselook und Tastatur-Steuerung eröffnete neue Möglichkeiten für die Spieleentwicklung

Das geht schon in vielen früheren FPS, z.B. Duke Nukem 3D (Build-Engine). Die ersten Spiele, die mouselook unterstützen, werden unter en:Free look erwähnt. --MrBurns 05:50, 3. Mai 2010 (CEST)

afaik aber nicht in einer vollständigen 3D-Umgebung --suit Datei:Rebell at 13x13.jpg 15:32, 3. Mai 2010 (CEST)
Ich schreib mal, wie es bei Duke Nukem 3D war: Das Gelände war schon vollständig 3D, nur dass es aus einer 2D-Map gerendert wurde (was z.B. dazu führt, dass Gebäude nicht perspektivisch verzerrt werden, wenn man nach oben schaut, was aber nicht so extrem auffällt, weil der Winkel, den man nach oben schauen kann, begrenzt ist) und die Gegner und Pickups waren Sprites, von denen es aber für jedes Objekt mehrere gab, um einen 3D-Eindruck zu erzeugen, was meistens auch ganz gut funktionierte. Aber das ändert alles nichts am Prinzip der Steuerung. Das was wirklich neu war bei Quake war eben, dass der erste "echte" 3D-Shooter war, nicht die Steuerung. --MrBurns 17:59, 3. Mai 2010 (CEST)
Ich würde sagen, dass der erste echte 3d Shooter eher The Terminator: Future Shock war. Das wird auch auf der Diskussionsseite von Quake so diskutiert. The Terminator: Future Shock hatte nämlich bereits eine echte 3d Engine und Mouslook und Mouseaiming. Die Gegner waren auch in 3d. --IT-Compiler (Diskussion) 14:21, 27. Jun. 2022 (CEST)

Planung des Abschnittes "Design der Engine und Meilensteine"

Ich wurde vom englischsprachigen Artikel inspiriert und kam auf die Idee, diese englische Version zum Teil auf die Deutsche zu übersetzen. Damit will ich ankündigen, dass bei diesem Artikel wahrscheinlich irgendwann mal ein neuer Abschnitt erscheinen wird. Aber erstmals ein paar Informationen zusammenkriegen...--Multiguy18 17:17, 16. Dez 2014 (CEST)

Besseres Lemma "Id-Tech"

Die offiziellen Bezeichnungen der Engines sind "Id-Tech" und somit sollte auch das Lemma angepasst werden. Abgesehen davon, dass der komplette Artikel sehr unvollständig ist, insbesondere im Hinblick auf die letzten 10 Jahre. --Sibajaleoaj (Diskussion) 20:51, 2. Dez. 2020 (CET)

Warum ID Software für Quake vom Watcom C Compiler zum DJGPP Compiler wechselte

Was in dem Artikel auch noch erwähnenswert wäre, ist die Ursache, warum ID Software, die für DOOM noch den Watcom C Compiler verwendeten, bei Quake zu DJGPP wechselten. Charles Sandmann, der Entwickler von CWSDPMI welches von DJGPP verwendet wird, hat diese Frage vor vielen Jahren in einem Kommentar in der Newsgroup comp.os.msdos.djgpp beantwortet, da er damals sich mit den Leuten von ID Software diesbezüglich auch unterhielt. Darin schrieb er unter anderem, dass die Gründe die folgenden seien:

„1) Cross development. They wanted fast stable boxes (Unix) to do development on with minimal effort to migrate. 2) Possibility to ship the compiler. 3) Source availabiltiy and the libc sources - including DJ's commercial policy and willingness to provide lightning fast response to questions. 4) Verbal assurances the development team would make DJGPP work for them.“

Dies war auch aus dem Grund wichtig, damit Spieler das Spiel besser modden können. Das könnte man in dem Artikel noch erwähnen. --IT-Compiler (Diskussion) 14:17, 27. Jun. 2022 (CEST)