Diskussion:Wolfenstein 3D

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 3650 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Egoshooter

Hab unter "Siehe auch" die angegebenen Ego-Shooter gelöscht und einen Verweis auf Ego-Shooter gesetzt. Denke es ist sinnvoller, da man dort eine größere Auflistung und nicht nur einige (von einem Autor wild herausgepickte) Anzahl.Ari

Habe die Seite ein wenig aufgeräumt und ein Bild hinzugefügt. Des weiteren habe ich noch einen Text zur Vorgeschicht von Castle Wolfenstein geschrieben (Muse Software). --Robby4711 08:36, 26. Feb 2004 (CET)

Indizierung

"verboten" ist ein ungenauer Ausdruck (Von wem verboten? Für wen gilt das?), "beschlagnahmt" trifft die Sache präziser. --Matthäus Wander 13:50, 4. Nov 2003 (CET)

Ich habe auf der englischen Wikipedia gelesen, daß das Spiel in Deutschland offensichtlich nicht nur indiziert, sondern anscheinend anschließend auch noch aufgrund des Urteils eines Amtsgerichts konfisziert wurde. Die Quellenangaben dort sind sehr genau und detailliert, deshalb erscheint das Ganze durchaus plausibel. Da ich leider die Gerichtsunterlagen nicht einsehen kann und das Googlen nichts Brauchbares gebracht hat: Kennt sich da einer aus und könnte das noch ergänzen ? -- Hogri 21:31, 28. Nov 2004 (CET)

Ich hab das schon mehrmals korrigiert, irgendjemand nimmt das immer wieder raus und verwässert damit den Artikel (indiziertes Material darf man durchaus vertreiben und verbreiten). Neuer Versuch. --Matthäus Wander 22:59, 28. Nov 2004 (CET)

Entschärfte Version?

Zitat: „Später erschien eine entschärfte Fassung, bei dem Hakenkreuze und andere Symbole entfernt oder durch Eiserne Kreuze ersetzt wurden.“

Gibt es hierfür eine Quelle? Ich weiss, dass die SNES-Version entschärft wurde, aber gab es tatsächlich auch eine entschärfte Version für den PC? Bzw. welche Platform ist hier überhaupt gemeint?

Anorexia 23:29, 7. Nov. 2006 (CET)

Nein für den PC ist nie eine in dem Maßen veränderte Version ersschienen. --Gunnar.offel

• Doch, ist sie. Die war damals in der Schule begehrtes Diskettentauschobjekt. Ich werde mal sehen, ob ich Quellen dazu finde. --88.77.31.151 10:23, 1. Aug. 2008 (CEST)
• * Warum war denn bei euch die entschärfte version begehrtes tauschobjekt? original ist doch besser ;) --80.142.76.247 18:01, 11. Okt. 2008 (CEST)

Es existierten verschiedene Versionen in denen die Gegner durch andere ersetzt wurden. (z.B. Weihnachtsmänner und Schneemänner) (nicht signierter Beitrag von 77.12.120.31 (Diskussion) 20:57, 4. Aug. 2013 (CEST)) In diesen Versionen sind auch keine Hakenkreuze zu sehen. (nicht signierter Beitrag von 77.186.68.169 (Diskussion) 21:21, 24. Aug. 2013 (CEST))

Seit wann sind Fan-Mods offizielle Versionen? Es gab nur die entschärfte Version durch die Nintendo-Vorgaben, was John Carmack auch in mehreren Interviews darlegt. Man könnte wenn überhaupt noch Noahs Ark als entschärfte Version auslegen, da dort einige Level 1:1 übernommen wurden. Aber auch das ist kein Wolfenstein 3D geschweige denn ein von id Software veröffentlichtes Produkt, sondern eine Lizensierung der Engine. -- Gunnar ^💬 10:24, 13. Mär. 2020 (CET)

Das mit den übernommenen Maps ist ein Mythos - ich habe alle Maps aus Wolfenstein 3D und Super Noah's Ark 3D miteinander verglichen und konnte keine einzige Dopplung finden. So albern das Konzept von SNA3D wirkt, spielt es sich tatsächlich besser, weil es deutlich weniger Spaghetti-Labyrinthe hat. Chris Retro (Diskussion) 15:34, 15. Dez. 2022 (CET)

"Auch wegen der Vorgängerspiele hatte es bereits Strafverfahren wegen der Verwendung von NS-Kennzeichen gegeben. Diese endeten teilweise mit einer Einstellung gegen Zahlung einer Geldauflage gemäß § 153a StPO, ..."

Quelle? Im Artikel zu den Vorgängern steht dazu nichts. Sind die überhaupt jemals im deutschen Handel erschienen? Es kann schließlich nur gegen den Vertrieb vorgegangen werden. Die Erschaffung verfassungsfeindlicher Werke wurde eigentlich noch nie verfolgt. Man wird ja wohl kaum Muse Software verklagt haben. Es ist eher unwahrscheinlich, dass diese US-amerikanische Firma eine "Geldauflage" gezahlt hätte. Warum sollte sie das tun? --80.153.250.36 13:57, 6. Jan. 2015 (CET)

Dabei geht's wohl um Händler, die die Spiele als Import angeboten hatten und daher in rechtliche Probleme gerieten. Der Abschnitt sollte imho raus, wenn er unbelegbar ist. Interessanter Weile hat den anscheinend aber ein Jurist eingetragen damals: https://de.wikipedia.org/w/index.php?title=Wolfenstein_3D&diff=17103650&oldid=16969466 und persönlich halte ich das auch für durchaus glaubwürdig. Um es zu verifizieren, müsste man aber wohl alle Staatsanwaltschaften bzw. die Justizstellen aller Länder um Auskunft bitten, und dann wäre das noch Theoriefindung, wenn es von keiner "seriösen" Seiten stammt. Nun ist das Interesse, derart tief über die durchaus ausladende Videospielrechtsgeschichte zu recherchieren, allerdings evident nicht sehr ausgeprägt hierzulande. Das merkt man aber selbst bei Wikipedia, da hier z. B. ewiglang absolut nichts zur Entscheidung des OLG Frankfurt von 1998 drin stand, was als "Wolfenstein-Urteil" einen enormen Einfluss ausübte, oder anhand vieler unhaltbarer Behauptungen zum allgemeinen Thema, die immer wieder unbelegt auftauchen. --Dandoms (Diskussion) 18:11, 25. Aug. 2019 (CEST)

"Daraus resultieren mehrere bis heute verfügbare Modifikationen."

Das klingt so nach einem Dutzend. Seitdem ich das Spiel 1992 zum ersten Mal unter den Fingern hatte, habe ich über 1200 unterschiedliche Mods installiert, dazu kommt noch schätzungsweise eine dreistellige Zahl, die in irgendwelchen Archiven vor sich hinschlummert). Ich will nicht kleinlich sein, würde aber "mehrere" ändern zu "sehr viele", zumal auch im Jahre 2021 noch eine kleine, aber feine Szene dahingehend aktiv ist (ich nicht). 2A02:908:1D47:1B60:C125:5FD4:FD89:8BB3 15:15, 31. Jan. 2021 (CET)

Das müsste aber belegt werden, z.B. mit einem Link in der Zusammenfassungszeile. Etwas enzyklopädischer klänge "zahlreiche", aber das ist eine Geschmacksfrage. Viele Grüße, Grueslayer 15:28, 31. Jan. 2021 (CET)

"zahlreich" klingt tatsächlich besser. Ein Link wäre z. B. https://wl6.fandom.com/wiki/Category:Mods oder http://wolf3d.net/mods/ - Sicher nicht perfekt, aber aussagekräftig. Ich wüsste sonst nicht, wie ich das von meiner Festplatte aus belegen könnte ;) 2A02:908:1D47:1B60:2978:2E53:F0FC:A598 20:28, 7. Feb. 2021 (CET)

PEGI 12 ?

Es ist keine Quelle Verlinkt die Belege würde das Wolfenstein PEGI 12 ist

Außerdem wage ich zu bezweifeln das PEGI Wolfenstein ab 12 freigegeben hat --95.222.119.1 01:31, 17. Sep. 2022 (CEST)

Ja, das ist interessant.

• Steam, GOG: keine Klassifizierung
• Microsoft: Mature 17+ gem. ESRB in den USA, aber PEGI-12 in Israel (wenn ich das richtig interpretiert habe, dass en-il für Israel steht).

Das deckt sich mit dem, was auf IGDB steht...

‣Andreas•⚖ 12:16, 17. Sep. 2022 (CEST)

Nachtrag: Microsoft XBox Store in Deutschland klassifiziert das Spiel mit "12+"... ‣Andreas•⚖ 12:18, 17. Sep. 2022 (CEST)

Formulierung zu SNES-Implementierung

Dass Doom im Anschluss BSP verwendete, ist unter Portierungen bereits erwähnt, insofern schlage ich folgende kürzere Formulierung vor:

Da Wolfenstein 3D auch auf das SNES portiert werden sollte, dessen Hardware allerdings für die Engine, die für den PC verwendet wurde, zu langsam war, führte dies bei id Software zur Entdeckung des bereits bekannten Binary-Space-Partitioning-Algorithmus, der dann in der SNES-Version verwendet wurde. (nicht signierter Beitrag von Player2072 (Diskussion | Beiträge) 22:22, 14. Mär. 2024 (CET))

Der Hinweis bezüglich BSP und dass es DOOM zur Folge hatte, gehört in den Bereich Technik, also den Bereich Implementierung. Deswegen habe ich es da eingebaut. Wer etwas über die Technik der Engine erfahren will, wird kaum den eher unwichtigen Portierungsabschnitt lesen. --93.229.173.137 23:24, 14. Mär. 2024 (CET)

Dem kann ich so nicht zustimmen. Der Implementierungsteil bezieht sich zunächst einmal auf die MS-DOS-Version wie der Artikel auch. Die Portierungen werden ergänzend erwähnt. Ansonsten könnten da Implementierungsdetails sämtlicher Portierungen erwähnt werden, und das geht sicherlich über einen sinnvollen Umfang des Artikels hinaus. Und BSP ist nur ein kleiner Teil des Ganzen und die Erwähnung unter Portierungen ist angemessen. --Player2072 (Diskussion) 13:48, 15. Mär. 2024 (CET)

BSP ist ein bedeutendes Detail und nicht irgendein nebensächliches Detail. Das macht den großen Unterschied und deswegen gehört das in den Abschnitt Technik/Implementierung. Dass es sich auf den SNES Port bezieht, wird im Satz ja erwähnt und es steht am Ende des Abschnitts, die PC Version ist da schon lange abgefrühstückt. --93.229.173.137 11:36, 16. Mär. 2024 (CET)

Gudn Tach!

Ich werde mich an der inhaltlichen Diskussion nicht beteiligen, aber möchte darauf hinweisen, dass erst fertigdiskutiert werden sollte, bevor in dieser Sache weitere Reverts erfolgen. Bitte streng an WP:WAR halten, das ist nötig für eine sachliche Diskussion. Ein Edit-Ping-Pong hilft niemandem und sollte nicht dazu führen, dass jemand sich durchsetzt, nur wegen mehr Ausdauer. Daher setze ich den letzten Re-Revert nun administrativ zurück und bitte um Verständnis.

Gerne kann die Diskussion hier weiterlaufen. Ggf. kann WP:3M zurate gezogen werden. -- seth (Diskussion) 11:49, 16. Mär. 2024 (CET)

Hi, danke für die Klarstellung.

@93.229.173.137 Zurück zum Thema BSP. John Carmack selbst weist darauf hin, dass BSP nicht entscheidend ist. Die Build-Engine von Duke Nukem 3D verwendet kein BSP. Zitat aus https://www.fulcrum.org/epubs/s7526d38h?locale=en#/6/22%5Bchp04%5D!/4/2/44%5Bp_19%5D/9:179:

In his typical fashion, Carmack is far less willing than others to see his contribution in quite such a groundbreaking light.

People like to look for the magic special sauce. They like to look for that narrative. But for almost anything, there are multiple valid ways to get to the same end result. And DOOM started off with a different approach that wasn't getting the speed I wanted. I first used BSPs on the Super Page 44 → Nintendo Wolfenstein 3D port, where I had to come up with more speed than the raycasting approach. And then when I came back to working on DOOM, I wound up working in that way because it seemed like a good approach. Conversely though, the Build engine (Duke Nukem 3D) didn't use BSPs, and it was every bit as effective as the way DOOM was implemented. But certainly because of DOOM's success, thousands of people learned what BSP trees were and followed up on some of those academic threads. (JC)

Ich könnte mich mit einer Formulierung zu BSP unter Technik anfreunden, die das Thema mit der Build-Engine ausbalanciert. --Player2072 (Diskussion) 16:47, 16. Mär. 2024 (CET)

Wie genau meinst du das? Könntest du hier eine Formulierung vorschlagen, wie du das mit der Build Engine meinst? --93.229.173.137 03:52, 17. Mär. 2024 (CET)

Hier mein Vorschlag für unter Implementierung, Belege müssten angepasst werden, die von unter Portierungen verwendeten Sätze würden dort entfernt:

Super Nintendo Entertainment System

Da Wolfenstein 3D auch auf Nintendos SNES portiert werden sollte, die SNES-Hardware allerdings für die PC-basierte Engine zu langsam war, führte dies bei id Software zur Entdeckung des bereits bekannten Binary-Space-Partitioning-Algorithmus (BSP), der dann in der SNES-Version verwendet wurde. Der sich hieraus ergebende Geschwindigkeitsgewinn ermöglichte die Programmierung in C und Assembler für die 65C816-basierte CPU des SNES. Hierzu kam ein Cross-Compiler auf einem Apple IIGS zum Einsatz.[7] Die Validierung des BSP bei der SNES-Version von Wolfenstein 3D führte dazu, dass BSP auch von Doom für den PC verwendet wird.[72]

Damit BSP nicht überbewertet wird, folgende Ergänzung unter Trivia bei Duke Nukem 3D:

Im Gegensatz zur SNES-Implementierung von Wolfenstein 3D verwendet die Build-Engine kein Binary Space Partitioning (BSP), ist aber dennoch genauso effektiv implementiert wie die Doom-Engine mit BSP.[Beleg zu JC Statement] --Player2072 (Diskussion) 18:18, 17. Mär. 2024 (CET)

Ich hätte da einen Änderungsvorschlag:

Super Nintendo Entertainment System

Da Wolfenstein 3D auch auf Nintendos SNES portiert werden sollte, die SNES-Hardware allerdings für die PC-basierte Engine zu langsam war, führte dies bei id Software zur Entdeckung des bereits bekannten Binary-Space-Partitioning-Algorithmus (BSP), mit dem eine effiziente SNES-Version umsetzbar wurde. Hierzu kam ein Cross-Compiler auf einem Apple IIGS zum Einsatz.[7] Die Validierung des BSP bei der SNES-Version von Wolfenstein 3D führte dazu, dass BSP auch von Doom für den PC verwendet wird.[72]

Grund: Ob man das Spiel in C und Assembler programmieren kann, ist nicht vom BSP abhängig. Denn das ist immer möglich. Das mit dem Cross Compiler habe ich mal stehen lassen, auch wenn ich mich frage, warum das hier wichtig sein soll? Es geht ja um die Implementierung und nicht um die Werkzeuge, die für die Implementierung verwendet wurden. Und C und Assembler waren damals ohnehin üblich, auch Cross Assembler, das müsste man also nicht extra erwähnen. Die SNES Hardware war für den Raycasting Algorithmus schlicht zu langsam, da hätte auch reines Assembler nicht zu hohen Frameraten geführt.

Zum Thema Build Engine und genauso effektiv. Das würde ich stark bezweifeln. Doom lief auf einem 486er mit 33 MHz. Duke Nukem benötigte mindestens einen Rechner mit 100 MHz, idealerweise mit Pentium CPU. John Carmack hat zudem nur gesagt, dass man die Detailreduzierung durch Levelabtrennung auch manuell lösen hätte können, so wie es bei der Build Ending dann auch gemacht wurde. Aber ohne Reduzierung der Details geht es gar nicht, weil man dann einen Overdraw hätte, den die damalige Hardware nicht geschafft hätte. Ein Overdraw ist also das Zeichnen von Geometrie mitsamt texturierter Wände, die man nicht sieht und deswegen von den nächsten Wänden gleich überzeichnet werden. --93.229.173.137 20:40, 17. Mär. 2024 (CET)

1. Zur Programmierung in C: damit ist gemeint, dass das BSP sogar die Programmierung in C ermöglicht hat. Es hätte ja sein können, dass trotz BSP alles in Assembler hätte programmiert werden müssen. Aber OK, der Satz kann meinetwegen auch entfallen, so dass ich deiner Formulierung zustimme.
2. in der Quelle steht: Build engine (Duke Nukem 3D) didn't use BSPs, and it was every bit as effective as the way DOOM was implemented. Von Overdraw lese ich da nichts. Ansonsten bitte eine Quelle für deine Behauptung angeben. Deine Meinung allein ist kein Beleg in der Wikipedia.
3. Insofern bleibe ich bei meiner Ergänzung zur Build-Engine, da diese belegt ist.

--Player2072 (Diskussion) 09:20, 18. Mär. 2024 (CET)

1. Ok, jetzt verstehe ich wie du das meinst. Also grundsätzlich lassen sich alle Algorithmen in so gut wie jeder Programmiersprache, deren Sprachumfang dafür ausreichend ist, umsetzen. Der BSP Algorithmus wäre bspw. auch in Python oder Javascript realisierbar. Auf Youtube gibt es dazu auch Implementierungen in Python. Besonders schnell wird es dadurch zwar nicht, aber machbar wäre es, gut auf der alten Hardware von damals wohl nicht, aber auf neuer durchaus. Die Algorithmen sind also nicht auf die Programmiersprache begrenzt, wenn die Programmiersprache ausdrucksstark genug ist um den Algorithmus umzusetzen, dann lässt sich ein Algorithmus in einer solchen Programmiersprache auch umsetzen.
2. Auf Seite 197 bis 198 des Game Engine Black Book Doom Buchs heißt es

The most important part (and what DOOM’s engine is most famous for) is the ability to sort walls and things extremely efficiently thanks to its Binary Space Partitioning tree. Interestingly, there is a back story about how the BSP came to be a central part of the game engine.

In its earlier versions the engine operated on exactly what the designer produced, namely lines and sectors. Starting in the sector containing the player, the engine would look for double-sided lines and treat them as portals, traversing the map in front-to-back order. Each portal lead to adjacent sectors where the process was repeated recursively.

In the map above, with the player located in sector 0, the renderer will flood into other sectors using the red portals. A convex sector 1 is relatively easy to deal with. Things get considerably more complicated when encountering a concave sector like 4. An even worse case is when nesting occurs like where sector 2 contains another sector 3.

Trivia : The design described is exactly what Ken Silverman’s BUILD engine would settle on to power Duke Nukem 3D in 1996. By then the Pentium had taken over the world and was more than able to deal with complex polygons.

Things indeed slowed down significantly with a particular map of John Romero’s creation.

Da steht deutlich, dass die Build Engine nicht ohne Aufteilung des Levels auskommt, es verwendet dafür lediglich nicht den effizienten BSP Algorithmus, sondern hier wird es händisch mit Sektoren gemacht, genau wie ich sagte. Auch wird hier erwähnt, dass der Pentium dafür schnell genug ist, was ein 486DX 33 MHz auf dem DOOM noch flüssig läuft, definitiv nicht mehr wäre. Und ganz unten wo auf John Romero's Karte hingewiesen wird, versagt dann dieser andere Lösungsansatz und ab dem Punkt kommt der BSP Algorithmus bei Doom ins Spiel, der dann auch in solchen Situationen noch performant ist.

Was du bei mir als Meinung missverstehst ist Expertise und Ahnung von der Materie, was glaubst du was ich studiert habe? Dass die Wikipedia mit ihrem Belegzwang nicht zufrieden ist, weiß ich auch und genau deswegen steht so viel Falsches in der Wikipedia drin, weil Laien ihren Unsinn reinschreiben, der es irgendwie schafft zu überleben und dann, wenn man es ohne Beleg korrigieren will, wird es gleich von Belegfanatikern, die nachweislich gar keine Ahnung haben, reverted.

Die Belegfanatiker erkennt man an zwei Dingen, erstens mischen sie in allen Themen mit, d.h. sie warten auf der Eingangsseite in der alle neuen Änderungen der gesamten WP zusammengefasst sind und revertieren dann alles, wo sie keinen Beleg finden und zweitens, sie nicken Änderungen ab, ohne den angegebenen Beleg zu überprüfen und sie erkennen es auch nicht, weil denen das Fachwissen über das Themengebiet fehlt, womit sie ihren eigenen Belegfanatismus ad absurdum führen. Und deswegen bleibt der Müll stehen und die Expertise wird reverted.

--93.229.173.137 22:04, 18. Mär. 2024 (CET)

Ich kann deine Argumente hier nachvollziehen, du stellst offenbar die Arbeitsweise der Wikipedia in Frage. Das kann man natürlich machen o. Verbesserungsvorschläge unterbreiten. Andererseits gibt es die etablierten Richtlinien. Die sind wie Spielregeln. Wenn ich die Spielregeln eines Spiels nicht mag, muss ich ja nicht mitspielen. Keiner wird gezwungen. Zurück zum Thema: ich schlage als Kompromiss einen verkürzten Satz vor: Im Gegensatz zur SNES-Implementierung von Wolfenstein 3D verwendet die Build-Engine kein Binary Space Partitioning.[Beleg zu Seite 197 bis 198 des Game Engine Black Book Doom] --Player2072 (Diskussion) 09:41, 19. Mär. 2024 (CET)

Erst einmal, die Arbeitsweise der Wikipedia gibt es nicht, denn jeder hat hier seine eigene Arbeitsweise. Ich habe meine, du hast deine, andere haben andere, und Belegfanatiker haben sehr dumme Arbeitsweisen usw..

Nun zu den Richtlinien, dass diese Richtlinien völliger Quatsch sind, habe ich dir ja bewiesen. Was nützt es einen Beleg abzuwinken, der kein Beleg ist? Ebenso habe ich dir aufgezeigt, dass und warum diese Belegfanatiker für die Wikipedia den größten Schaden anrichten. Das steht alles oben, es liegt jetzt an dir, das auch zu begreifen und zu verstehen.

Zurück zum Thema. Deinen Kompromiss kann man zwar machen, nur frage ich mich, was die Build Engine im Wolfenstein 3d Artikel zu suchen hat? Es gibt zwischen beiden überhaupt keinen Zusammenhang. Es gibt ihn nicht einmal zeitlich. Die Build Engine ist zur Zeit von Doom entwickelt worden und Duke Nukem 3d, das erste Spiel mit der Build Engine kam etwa zeitgleich mit Quake heraus, nämlich 1996. Da war Wolfenstein 3d schon 4 Jahre alt. Der Wolfenstein 3d Hinweis steht zudem bereits im Build-Engine Artikel. --93.229.173.137 08:18, 20. Mär. 2024 (CET)

Der Eintrag sagt es ja selbst: Wolfenstein 3D inspirierte Ken Silverman zum Programmieren der Nachahmung Ken's Labyrinth. Seine damit gemachten Erfahrungen flossen in seine Entwicklung der Build-Engine ein, die von dem Ego-Shooter Duke Nukem 3D verwendet wird.

Es gibt auch in der Tat Nutzer, die wollen überhaupt keine Trivia. Die könnte man auch alle herausnehmen. Aber du sagt ja selbst, jeder/jede hat seine eigene Präferenzen – auch bei Trivia.

Noch mal zur Sicherheit: du stimmst dem Kompromiss dann also zu. Falls ja, hätten wir uns auf die beiden verkürzten Formulierungen geeinigt. Dein verkürzter Vorschlag oben, meiner unten. Mit der Bitte um Bestätigung. Dann können wir die Diskussion hier abschließen und ich würde das hier, wenn wir auch mit der anderen Diskussion fertig sind, so in den Artikel einbauen. --Player2072 (Diskussion) 10:30, 20. Mär. 2024 (CET)

Schreib den vollständigen verkürzten Vorschlag noch einmal bitte hier hin. --93.229.173.137 11:00, 20. Mär. 2024 (CET)

Von oben anbei:

Im Gegensatz zur SNES-Implementierung von Wolfenstein 3D verwendet die Build-Engine kein Binary Space Partitioning.[Beleg zu Seite 197 bis 198 des Game Engine Black Book Doom --Player2072 (Diskussion) 12:01, 20. Mär. 2024 (CET)

Also so:

Super Nintendo Entertainment System

Da Wolfenstein 3D auch auf Nintendos SNES portiert werden sollte, die SNES-Hardware allerdings für die PC-basierte Engine zu langsam war, führte dies bei id Software zur Entdeckung des bereits bekannten Binary-Space-Partitioning-Algorithmus (BSP), mit dem eine effiziente SNES-Version umsetzbar wurde. Hierzu kam ein Cross-Compiler auf einem Apple IIGS zum Einsatz.[7] Die Validierung des BSP bei der SNES-Version von Wolfenstein 3D führte dazu, dass BSP auch von Doom für den PC verwendet wird.[72]

Im Gegensatz zur SNES-Implementierung von Wolfenstein 3D verwendet die Build-Engine für Duke Nukem 3D kein Binary Space Partitioning.[Beleg zu Seite 197 bis 198 des Game Engine Black Book Doom]

Und das dann unter Implementierung. --84.158.117.168 13:54, 22. Mär. 2024 (CET)

Dies alles unter Implementierung ist für mich auch in Ordnung. D. h. du stimmst dem dann auch zu? Mit der Bitte um Bestätigung. --Player2072 (Diskussion) 14:04, 22. Mär. 2024 (CET)

Ja, vollständig so wie ich es im letzten Kommentar um 13:54, 22. Mär. 2024 (CET) geschrieben habe. Ich habe zwar immer noch Bauchschmerzen wegen der Build Engine Sache, da die ja absolut nichts mit der Wolfenstein 3d Engine zu tun hat und das so wäre, als würde man im Quake Artikel etwas zur Unreal Engine schreiben, aber mir ist die Erwähnung mit dem BSP bei der SNES Version im Abschnitt Implementierung wichtiger, weswegen ich mit der Build Geschichte auch leben kann. Als Leser ist es nämlich einfacher, ein Datum beim Lesen zu übergehen, als ein Datum gar nicht zu erfahren, weil es nicht dabei steht. --84.158.117.168 14:14, 22. Mär. 2024 (CET)

Prima, dann können wir das Thema hier abschließen. --Player2072 (Diskussion) 14:24, 22. Mär. 2024 (CET)

Ja, die Änderung muss noch lediglich in den Artikel rein. --84.158.117.168 15:06, 22. Mär. 2024 (CET)

Laienhafte Darstellung @93.229.173.137

Dass die Darstellung "laienhaft" ist, ist Absicht. Zitat aus Wikipedia:Wie schreibe ich gute Artikel#Verständlichkeit:

Verständlichkeit

→ Hauptseite: Allgemeinverständlichkeit

Die Wikipedia ist eine allgemeine Enzyklopädie und kein Fachbuch. Sie soll auch für Laien verständlich sein.

Insofern kann ich deiner Formulierung nicht zustimmen. Wer sich für die Details interessiert, kann das erwähnte Fachbuch lesen. Insofern habe ich versucht, den Kern des Mechanismus herauszuschälen und beim Gelegenheitsleser verständlich zu machen. Meiner Meinung geht schon die Erwähnung von Mode-X vs. Mode-Y zu weit. Aber ich bin da bereit, das mitzugehen.

--Player2072 (Diskussion) 17:12, 16. Mär. 2024 (CET)

Es gibt Dinge, die besser fachterminologisch beschrieben werden, weil das präzise und eindeutig ist und keine Fehler enthält. Eine Erklärung für Laien, wie der Mode-X bzw. Mode-Y genau funktioniert, wäre in einem eigenständigen Artikel zu Mode-X und Mode-X besser aufgehoben (siehe mein Artikelvorschlag im Bereich Redaktion/Informatik), weil man dort auch mehr Raum und Platz hat und das auch grafisch untermauern kann. Im Wolfensteinartikel würde das zu lange werden und eine Laienhafte Erklärung reicht hier nicht, da sie zu unpräzise ist und nur zu Missverständnissen führt. (nicht signierter Beitrag von 93.229.173.137 (Diskussion) 03:55, 17. Mär. 2024 (CET))

Dem kann ich so nicht zustimmen. Mit demselben Argument könnte man die o. g. Forderung überall unterlaufen. Zudem halte ich die Relevanz für einen Mode-X-Mode-Y-Artikel für fragwürdig. --Player2072 (Diskussion) 10:11, 17. Mär. 2024 (CET)

Die englische Wikipedia hat bereits eigene Artikel zum Mode X und Mode Y und er wurde oft genug in Spielen benutzt, dass er Relevanz hat. Zudem könnte man das auch notfalls in den VGA Artikel einbauen, auch wenn ich das für eine große Unart und für einen sehr schlechten Stil halte, das immer zusammenzuklatschen. Dadurch geht nämlich die beidseitige Verlinkung zur englische WP verloren, man kann nicht zwischen dem englischen und deutschen Artikel einfach wechseln. Also eine ganz große Unart hier in der Deutschen Wikipedia, dieses fanatische Zusammenfassen von Dingen, die auch in einen eigenen Artikel reinpassen würden, meine Meinung. Aber zurück zum Thema Wolf 3d und Mode Y. Du willst im Wolf3d Artikel nicht umfangreich erwähnen, wie Mode Y funktioniert, weil das ansonsten zu Redundanz führt, das gehört daher in einen eigenen Mode Y Artikel. Wer dann wissen will, wie Mode Y funktioniert, besucht den Artikel. Redundanzvermeidung ist sehr wichtig, weil das sonst zu vielen Wiederholungen führt, die nicht alle auf dem gleichen Wissensstand sind und ältere dann auch Fehler enthalten. Außerdem verlängert das unnötig die Länge des Wolf3d Artikels und wer dann doch in einem späteren Mode Y Artikel nachschlägt muss dann teilweise den gleichen Text mehrmals lesen. Das ist nämlich das nächste Problem, wenn man Redundanz nicht vermeidet. Deswegen sollte im Wolf3d Artikel nur kurz erwähnt werden, dass der planare Mode-Y verwendet wurde und dieser eine Auflösung von 320x200 Bildpunkten bei 256 Farben hat und schneller ist, als der Mode 13h. Das reicht vollkommen, der Rest gehört in einen eigenen Mode-Y Artikel.

Ich kann deine Argumente für einen Mode-X/Y-Artikel nachvollziehen, es steht natürlich jedem frei, einen solchen in deutsch zu erstellen. Zurück zum Thema: nach wie vor halte ich deine Änderung für den Laien o. zumindest Gelegenheitsleser nicht verständlich. Was ist planar? Warum schnell und langsam? Welches Seitenverhältnis? All dies kann man meiner Meinung nach für den Gelegenheitsleser klarer und verständlicher ausdrücken. Kannst du hier bitte einen verständlicheren Vorschlag machen? Alternativ könnte aus meiner Sicht die Bemerkung zu ModeX/Y auch wieder komplett entfallen und der Abschnitt auf die Version ohne ModeX/Y zurückgesetzt werden.--Player2072 (Diskussion) 09:46, 18. Mär. 2024 (CET)

Der Laie, der nicht weiß, was planar ist und warum er schneller ist, wird den Mode-X/Y Artikel lesen, auf den man hier verlinken kann und den du gerne schreiben darfst. Ansonsten kann ich mich nur wiederholen, wenn du hier im Wolf3d Artikel den Mode-Y Artikel erklären willst, dann kannst du auch gleich den Mode-Y Artikel schreiben und es dort für Laien erklären, das verhindert Redundanz und sorgt für Richtigkeit und Ausführlichkeit. Mein Vorschlag wäre also der, den ich bereits stehen hatte. Man könnte noch Mode-Y verlinken, also so schreiben Mode-Y und dann muss halt jemand, der die Perspektive von Laien versteht, für Laien verständlich den Artikel schreiben. --93.229.173.137 22:12, 18. Mär. 2024 (CET)

... Kann schneller sein, muss aber nicht. Es kommt darauf an. Wie gesagt, kann ich dein Argument nachvollziehen, ich habe aber nicht vor, Mode-X/Y-Artikel zu schreiben. Falls du das übernehmen willst und zur Kooperation bereits bist, lese ich einen Entwurf von dir gerne im Hinblick auf Korrektur/Überarbeitung. Ansonsten schlage ich vor, dieses Thema hier auf die Seite zur Drittmeinung zu setzen. --Player2072 (Diskussion) 14:48, 19. Mär. 2024 (CET)

Nein, er ist schneller, das liegt an der Zugriffsart und wie die Hardware arbeitet. Die pixelbasierte Zugriffsweise des Mode 13h ist deswegen langsamer. Ich werde keinen Mode-X/Y Artikel schreiben, ich habe ihn bereits als Artikelwunsch an die Redaktion Informatik vor ca. 6 Tagen weitergereicht, ich werde ihn lediglich ergänzen, falls nötig. Der englische Mode-X und Y Artikel kann übersetzt werden, darauf kann man aufbauen. Die Frage der Kooperation reiche ich an dich zurück, denn ich bin bereits Wikipedianer, bist du zur Kooperation bereit?

Nächstes Thema, zum Thema Dritten Meinung, dann mach eine Drittmeinungsdebatte auf. Für die Einleitung, die kannst du in die DM einbauen, wie schon gesagt, meine Argumente sind: Redundanzvermeidung diese vermeidet Fehler, sie vermeidet das mehrmalige Lesen des Gleichen (da du das ja in allen Spielen bzw. deren Artikel, die Mode-X oder Y verwenden, langatmig ausschreiben und dort erklären möchtest, anstatt es in einen Mode-X/Y Artikel zusammenzufassen), und sie hilft dabei, dass Korrekturen sofort überall ankommen, allein dadurch, dass es dafür einen Mode-X/Y Artikel dann geben kann und in den hunderte Spielen, auf diesen Mode-X/Y Artikel dann lediglich verweisen würden. Und ein eigenständiger Artikel hilft hier, dass besser im Detail zu erklären, z.b. auch mit Grafiken, die in einen Spieleartikel nicht reinpassen würden und zum Schluss gehört die Erklärung der Arbeitsweise von Grafikmodi ohnehin nicht in Spieleartikel.--93.229.173.137 08:30, 20. Mär. 2024 (CET)

Wie schon mehrfach von mir gesagt, ich kann dein Argument verstehen. Wir beide wollen aber diesen Artikel nicht schreiben, gerne überarbeite/ergänze ich ebenfalls einen solchen kooperativ mir dir oder den anderen Autoren. Und sicherlich könnte man einen neuen Artikel Wolfenstein-3D-Engine starten analog der Doom-Engine und dann einen Teil des Artikels dorthin auslagern. Ich sehe aber hier bei der Freiwilligenarbeit ein Ressourcenproblem. Niemand kann sagen, wann das passiert. Und dann bleibt Fachjargon im Artikel. Und was die Richtlinie sagt, habe ich oben hineinkopiert. Und solange es den Artikel nicht gibt, sollte das für Laien einigermaßen verständlich sein. Ansonsten könnte man mit deinem Argument – und ich wiederhole mich hier – die Richtlinie stets unterlaufen. Der Fachmann wird es ggf. auch schon wissen und muss das erst gar nicht lesen o. er weiß, wo er die Info herbekommt (VGA-Handbuch). Ok, ich werde dann auf der Drittmeinungsseite das Thema einstellen. --Player2072 (Diskussion) 10:52, 20. Mär. 2024 (CET)

WP:Dritte Meinung

Es geht um diese Änderung

• 3M: Also ohne nun etwas davon zu verstehen, sollte es doch erstmal reichen die Begriffe Modus X und Y unter Video Graphics Array#Auflösung zu ergänzen und das dann zu verlinken. Nicht jeder Begriff braucht immer gleich einen eigenen Artikel. --Siehe-auch-Löscher (Diskussion) 14:05, 20. Mär. 2024 (CET)

Und noch ein Tipp an 93.229.173.137: Leg Dir einen Benutzername zu, und wenn Du im echten Leben schon einen hast, dann einen zweiten für deine anonymen Jugendsünden. :-) Das erleichtert die Ansprache und Diskussion. --Siehe-auch-Löscher (Diskussion) 14:08, 20. Mär. 2024 (CET)

Danke für den Vorschlag. Ich könnte mir vorstellen, so zu tun, als gebe es die Mode-X/Mode-Y-Artikel schon und dann weder eine Formulierung für den Laien noch für den Fachmann im Artikel zu haben. D. h. man verlinkt und das war es. Den alten Text könnte man hier ablegen, von wo er ggf. von einem zukünftigen Autor übernommen wird. --Player2072 (Diskussion) 18:13, 20. Mär. 2024 (CET)

Wir behandeln Themen und nicht Begriffe. Auch wenn en:Mode X existiert heißt das noch nicht, auch wir einen eigenen Artikel dafür brauchen. Erster Schritt ist die Auslagerung der hiesigen Erläuterungen nach Video Graphics Array#Auflösung, zweitens kann man dann eine Weiterleitung Mode X dorthin einrichten und drittens, wohlgemerkt erst bei Bedarf, könnte man dann den Inhalt irgendwann in einen Artikel auslagern. Ob das sinnvoll ist, halte ich erstmal für fraglich. --Siehe-auch-Löscher (Diskussion) 19:43, 20. Mär. 2024 (CET)

Ist für mich auch ok, mache ich mit. Habe mir gerade den VGA-Artikel mal angesehen. Wird anfangs wahrscheinlich sandpapierrauh werden aufgrund von copy&paste, aber nur wer den 1. Schritt macht, kommt irgendwo hin. --Player2072 (Diskussion) 21:05, 20. Mär. 2024 (CET)

Ist leider nicht meine Kernkompetenz. Video Graphics Array ist jetzt schon ziemlich sandpapierrauh. Vielleicht nutzt jemand die Gelegenheit, die Grundsätzlichen Fähigkeiten und Auflösungen etwas aufzuräumen. Modi wäre da vielleicht eine bessere Absatzüberschrift. Den Absatz Flexibilität des VGA-Anschlusses finde ich auch recht unverständlich. --Siehe-auch-Löscher (Diskussion) 21:21, 20. Mär. 2024 (CET)

Der Anfang ist gemacht unter VGA. Ich habe die Überschrift in Anzeigemodi umbenannt und die Modi vervollständigt. --Player2072 (Diskussion) 12:39, 21. Mär. 2024 (CET)

Die verlagerungswürdigen Themen von Wolfenstein 3D sind jetzt im VGA-Artikel samt Belegen, die "Grundsätzlichen Fähigkeiten" sind neu formuliert. Die Wahl des Zeichenprogramms sollte im Wolfenstein-3D-Artikel verbleiben, da die Wahl individuell ist. --Player2072 (Diskussion) 19:59, 21. Mär. 2024 (CET)

Es hat einen enormen Vorteil, wenn jedes technische Thema einen eigenen Artikel hat, weil das erlaubt die Verlinkung zu internationalen Wikipedia Artikel bijektiv zu gestalten. Es ist eine Unart, dass in der deutschen WP immer alles zusammengefasst wird, das führt dazu, dass eine Verlinkung in einen fremdsprachigen Wikipediaartikel oft nicht mehr möglich ist. Dadurch wird dem Leser der Zugriff auf diese anderen fremdsprachigen Informationen erschwert. Außerdem erleichtert die Vorgehensweise jedes Thema in einem eigenen Artikel zu behandeln auch den Ausdruck eines Themas, da man dann nicht ein ganzes Buch ausdrucken muss, sondern nur das, was einem wirklich interessiert oder man benötigt.

Es ist bspw. aus dem deutschen Video Graphics Array#Mode-X und Mode-Y Artikelabschnitt nicht möglich, durch klicken links auf der Leiste bei den Sprachen auf den englischen Artikel zum Thema Mode-X zu kommen, da dieses Zusammenklatschen alles in nur einen Artikel bzw. genauer ein Buch, zu einer surjektiven Fremdsprachenverlinkung führt.

Ich habe einen Benutzeraccount, du musst manchen politisch extremistischen Admins halt klar machen, dass man Benutzeraccounts nicht einfach sperren darf, nur weil man als Admin eine andere Meinung und noch viel weniger Ahnung hat. Ebenso wäre es sinnvoll, die Adminzeit auf 4 Jahre zu begrenzen. Da läuft viel falsch, wenn ein Admin 20 Jahre Admin bleibt und man es somit immer mit den gleichen Extremen zu tun hat. Kannst dafür ja eine Debatte aufmachen. Bis dahin gibt es von mir nur IPs.--84.158.117.168 13:44, 22. Mär. 2024 (CET)

Ich lasse hier mal @Siehe-auch-Löscher den Vortritt. Für mich ist sein Vorschlag akzeptabel. Hier geht das langsam auf wie ein Blumenkohl. Thema ist immer noch die Wikipedia-Richtlinie: Wikipedia ist für Laien. N. B. Unter VGA-Adapter ist ein Edit-War einer IP-Adr. zu sehen. Kling dort aus meiner Sicht recht ähnlich zu dem Thema hier. --Player2072 (Diskussion) 14:13, 22. Mär. 2024 (CET)

Unter VGA-Anschluss, was du vermutlich mit VGA Adapter meinst, sehe ich gar keinen Edit War. Und unter Video Graphics Array ist derzeit Stand 14:16 Uhr auch kein Edit War zu sehen, sondern lediglich Korrekturen wie es bei WP Artikelverbesserungen üblich und auch notwendig ist. Ansonsten könnten die Artikel ja nicht besser werden. --84.158.117.168 14:18, 22. Mär. 2024 (CET)

Ich war vielleicht etwas ungenau. Dort ist ein alter Edit-War zu sehen: z. B. https://de.wikipedia.org/w/index.php?title=Video_Graphics_Array&diff=239181376&oldid=239181273 --Player2072 (Diskussion) 14:26, 22. Mär. 2024 (CET)

Ah dass meinst du. Dieser Georg ist da im Unrecht, denn es gibt auch Multitasking für DOS. Zugriffsschutz auf die Hardware gibt es in DOS aber nicht, auch dann nicht wenn man DOS mit Multitasking verwendet. Für den Zugriffsschutz ist allein eine Trennung in Kernel- und Userspace notwendig und damit die Verwendung von Ring 0 und Ring 3. Das geht aber nur mit dem Protected Mode. Die Korrekturen der IP, also der Hinweis auf den Protected Mode ist somit die allein richtige Antwort und gehören daher in den Artikel. Es wäre bspw. auch HW Zugriffsschutz im Single Mode Betrieb möglich. Der Georg hätte den Rat der IP befolgen sollen und mal den von der IP angegebenen Artikel auch lesen sollen. Mit seinem Edit War hat er nun dem Artikel geschadet, weil das falsche Zeug, das drin blieb und leider immer noch drin steht, eben falsch ist. Das ist halt so ein typisches Problem, wenn absolute Laien in Artikeln herumpfuschen, von deren Thematik sie keine Ahnung haben. Noch schlimmer wird es aber, wenn sie nicht auf die hören, die es besser wissen. --84.158.117.168 15:02, 22. Mär. 2024 (CET)

Ich bin auch grundsätzlich ein Freund von eigenen Artikeln zu eigenen Themen und würde es entsprechend begrüßen, wenn jemand die Mode-x und -y Artikel anlegt. Für den Laien, der sich über Wolfenstein 3D informieren möchte, finde ich den Abschnitt "Implementierung" schon sehr detailliert. Meine Meinung ist, dass weitere allgemeine Details wie oben bereits diskutiert in den VGA-Artikel wandern sollten. Oder besser: den ganzen Abschnitt in einen eigenen Artikel auslagern. Viele Grüße, --Qaswed (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Qaswed (Diskussion | Beiträge) 13:55, 6. Apr. 2024 (CEST))

Redundanz bitte vermeiden! Raycasting gibt es als eigenständigen Artikel

Man muss nicht im Wolfenstein 3d Artikel erklären, wie Raycasting funktioniert, sondern besser auf den Raycasting Artikel verweisen und das, was dort dann fehlt und Wolfenstein 3d spezifisch ist, dann hier erklären, sowie das, was Raycasting generell erklärt, aber im Raycasting Artikel noch fehlt, dort hinzufügen.

Wie oben schon erklärt, sollte Redundanz grundsätzlich so gut wie möglich vermieden werden. Durch Redundanz hat man die Nachteile:

1. Der Leser muss gleiches mehrmals lesen. (bspw. den Spieleartikel und den Raycasting eigenen Artikel)
2. Fehler werden nicht überall korrigiert (wenn Raycasting in 100 Spieleartikeln jedes mal einzeln erklärt wird und zusätzlich noch im Raycasting Artikel und dann später im Raycasting Artikel eine Korrektur erfolgt, weil ein Detail falsch beschrieben war, dann erhalten die 100 Spieleartikel diese Korrektur in ihrer Erklärung nicht.)
3. Ergänzungen gelangen auch nicht in die 100 Spieleartikel, wenn der Raycasting Artikel erweitert wird.

--84.158.117.168 14:11, 22. Mär. 2024 (CET)

Kursivschrift

Im Artikel werden an vielen Stellen im Fließtext Begriffe kursiv geschrieben. Das scheint keiner erkennbaren Systematik zu folgen: Ego-Shooter, Raycasting und Freeware sind kursiv formatiert, Cross-Compiler, Sprite oder Shareware jedoch nicht. Die Kursivschreibung von Spieletiteln deckt sich mit Wikipedia:Typografie#Kursiv_auszeichnen (erster Aufzählungspunkt), bei allem anderen plädiere ich für die Entfernung der Kursivschrift. --Matthäus Wander 16:37, 9. Apr. 2024 (CEST)

Hi,

ich sehe das so: sofern das Wort eingedeutscht oder quasi eingedeutscht ist, okay. Ego-Shooter steht im Wörterbuch, also nicht kursiv. Sprite ist quasi eingedeutscht. Unter dem Link, auf den du verweist, steht aber auch noch:

"Fremdsprachliche Wörter oder Ausdrücke. Damit wird dem Leser der kurzzeitige Wechsel in die fremde Sprache angezeigt, etwa bei etymologischen Angaben am Anfang vieler Artikel:"

D. h. Engine und ggf. andere Wörter sind nicht eingedeutscht und sollten kursiv geschrieben werden. Grüße --Player2072 (Diskussion) 09:23, 12. Apr. 2024 (CEST)

Engine ist auch eingedeutsch. Das erkennt man daran, dass es großgeschrieben und mit Bindestrich zusammengesetzt wird (3D-Engine, Grafik-Engine). Würden die Begriffe als fremdsprachliche Wörter behandeln, müssten sie auch der englischen Rechtschreibung unterliegen (ray casting, nicht Raycasting). --Matthäus Wander 16:53, 12. Apr. 2024 (CEST)