alte Spiele

[=Floi=]

Hallo
wie wurden denn eigentlich die alten spiele programmiert?
gab es da auch schon den trick mit dem bitmaps ala VB?
wurde da pixel für pixel einzeln programmiert?

wie wurde das realisiert?
eigentlich müsste da alles über den prozessor laufen und theoretisch müsste es die ersten voxel engines gewesen sein ;D

gibt es uu auch beispiele und gute artikel dazu?


MFG
Floi

[catamaran]

Welche "alte" Spiele meinst du denn speziell?

[SgtTynis]

Wird wohl meist ein Gemisch aus Assembler und C gewesen sein.

[Shink]

Hallo
wie wurden denn eigentlich die alten spiele programmiert?
gab es da auch schon den trick mit dem bitmaps ala VB?
wurde da pixel für pixel einzeln programmiert?

Naja, so blöd war man früher auch wieder nicht: Wenn man pixel für pixel programmieren kann, kann man sich auch funktionen machen, die man später wiederverwenden kann und die alles ähnlich abstrakt wie heute machen - so etwas funktioniert sogar mit Assembler.

Früher nahm man für Spiele gerne Assembler, Turbo Pascal und C her - oder in gewissen Fällen auch Basic.

Wenn man heute Bitmaps in 2D-Spielen verwendet, läuft auch (fast) alles über den Prozessor.

[Monger]

Wird wohl meist ein Gemisch aus Assembler und C gewesen sein.
Das kommt jetzt sehr darauf an, wie weit man jetzt in der Zeit zurück geht. Aber es würde mich stark wundern, wenn man seit C64 Zeiten noch irgendwo ernsthaft mit Assembler gearbeitet hätte. Und auch vor 20 Jahren gab es schon Bildbearbeitungsprogramme, mit denen z.B. Hintergrundgrafiken gezeichnet werden konnten. Damals wie heute hat man da Engines geschrieben, die solche Inhalte laden und zusammenfügen können.

Für den PC ist C/C++ schon seit Urzeiten das Maß aller Dinge. C++ ist nun schließlich auch weit über 20 Jahre alt. Wie es z.B. auf Amiga und C64 aussah, weiß ich nicht.

[catamaran]

Aber es würde mich stark wundern, wenn man seit C64 Zeiten noch irgendwo ernsthaft mit Assembler gearbeitet hätte.


Natürlich wurde da auch noch viel Assemler eingesetzt.

[ShadowXX]

Das kommt jetzt sehr darauf an, wie weit man jetzt in der Zeit zurück geht. Aber es würde mich stark wundern, wenn man seit C64 Zeiten noch irgendwo ernsthaft mit Assembler gearbeitet hätte. Und auch vor 20 Jahren gab es schon Bildbearbeitungsprogramme, mit denen z.B. Hintergrundgrafiken gezeichnet werden konnten. Damals wie heute hat man da Engines geschrieben, die solche Inhalte laden und zusammenfügen können.

Für den PC ist C/C++ schon seit Urzeiten das Maß aller Dinge. C++ ist nun schließlich auch weit über 20 Jahre alt. Wie es z.B. auf Amiga und C64 aussah, weiß ich nicht.
Kommerzielle Games für C64 & Amiga nur per Assembler.

EA hatte am Anfang mal versucht auf dem Amiga Games in C zu proggen und es dann seinlassen, da Sie bemerkten das die Amiga HW dafür nicht schnell genug war und die Spezialchips auch nicht brauchbar angesteuert werden konnten.

Es kann aber sein, das es verschiedenen Freeware/Shareware-Games aus den späteren Amiga-Tagen gibt (also mit 68030++ CPUs) die auch in C geschrieben sind.


Wenn man heute Bitmaps in 2D-Spielen verwendet, läuft auch (fast) alles über den Prozessor.

Weniger.....3D-Grafikkarten können auch 2D-Bitmaps manipulieren und durch den Speicher schieben (DirectDraw, wurde sogar schon bei Diablo2 benutzt).

Auch die Windows-Oberfläche wird durch die Grakas Beschleunigt....deinstallier mal deinen Grafikkartentreiber und fang an zu Surfen, Fenster mit dargestellten Inhalt zu verschieben oder mit Office zu arbeiten...viel spass.

Natürlich wurde da auch noch viel Assemler eingesetzt.
C64 eigentlich nur Assembler (von so ein paar Hobby-Programmen in Basic mal abgesehen).

Wobei man dazu sagen muss, das Assembler auf einem C64 so einfach und übersichtlich war, das es einfacher als C/C++-(Spiele)-Programmierung heute ist.

[catamaran]

Ich bezog meine Aussage mehr auf den PC, aber egal.

Heute programmiert kein vernünftiger Mensch mehr Assembler wegen der Geschwindigkeit (Embedded und ein paar Spezialfälle mal ausgenommen). Die (c/C++)-Compiler heute sind mit denen früher auch nicht zu vergleichen und optimieren oft besser als man das selbst mit Assembler tut.

[elianda]

Das Problem mit Assembler ergibt sich durch die Komplexitaet der aktuellen Prozessoren. Wo bei einem 386er das Laufzeitverhalten noch nachvollziehbar war, konnte man das beim Pentium schon nichtmehr zu 100%. Aktuelle Prozessoren erfordern aufwendige Regelsaetze zum optimieren, die man per Hand nichtmehr sinnvoll umsetzen kann.

Wenn es um Size geht, ist Assembler immernoch das Mittel der Wahl.

In Spielen werden vermutlich selbst heutzutage noch spezielle Routinen in Assembler implementiert. Gerade wenn es zB um SSE usw. geht.

[Shink]

Weniger.....3D-Grafikkarten können auch 2D-Bitmaps manipulieren und durch den Speicher schieben (DirectDraw, wurde sogar schon bei Diablo2 benutzt).

Auch die Windows-Oberfläche wird durch die Grakas Beschleunigt....deinstallier mal deinen Grafikkartentreiber und fang an zu Surfen, Fenster mit dargestellten Inhalt zu verschieben oder mit Office zu arbeiten...viel spass.
Wegen Windows-Oberfläche: Das betrifft aber AFAIK (zumindest in der pre-vista-Ära) nur primitive Zeichenfunktionen (Füllen mit Farbe etc.)
Wg. Diablo2: Ja, OK, mag sein. Ich bin aber ziemlich zuversichtlich, dass noch immer 2D-Spiele herauskommen, die nicht so effizient arbeitet.

[ollix]

Ich erinnere mich, daß ich damals über 2 Jahre gebraucht habe um ein kleines IIRC 4bit-Sprite über den Bildschirm meines 286ers zu bewegen; die Hürden waren aber schon größer (kein Internet). Dem war ein Textadventure in GWBasic vorausgegangen, daß so viele Dead Ends hatte, daß nur ich es "bug-frei" spielen konnte. :)

[ShadowXX]

Wegen Windows-Oberfläche: Das betrifft aber AFAIK (zumindest in der pre-vista-Ära) nur primitive Zeichenfunktionen (Füllen mit Farbe etc.)
Wg. Diablo2: Ja, OK, mag sein. Ich bin aber ziemlich zuversichtlich, dass noch immer 2D-Spiele herauskommen, die nicht so effizient arbeitet.
Wenn du mit DirectDraw programmierst, benutzt du automatsich die geschwindigkeitssteigernden Fähigkeiten der Graka. AFAIK greifen selbst STL & Co. auf DirectDraw & D3D zurück.

Zur Oberfläche.....unterschätz nicht, was die Grakas heute so alles an der Oberfläche beschleunigen. Wenn ich mich richtig erinnere kann man sich das mit SiSoft Sandra anzeigen lassen. Du wirst erstaunt sein.

Und selbst wenn "nur" der BitBlt per HW benutzt werden würde, deckst du damit schon 80% der Operationen des Windows-Desktops mit ab.
Zusätzlich werden noch Linien , Chords, Boxes, Elipsen, Circle, alles wahlweise gefüllt oder sogar mit Muster und vieles andere beschleunigt (Floodfill natürlich auch, auch mit Muster oder Bitmap).

[catamaran]

Wenn du mit DirectDraw programmierst, benutzt du automatsich die geschwindigkeitssteigernden Fähigkeiten der Graka. AFAIK greifen selbst STL & Co. auf DirectDraw & D3D zurück.


Was soll eine STL mit DirectDraw & D3D anfangen? Die STL ist eine C++ Bibliothek und nicht auf Windows beschränkt.

[ShadowXX]

Was soll eine STL mit DirectDraw & D3D anfangen? Die STL ist eine C++ Bibliothek und nicht auf Windows beschränkt.
Es gibt aber eine STL-Version für Windows, mit deren Hilfe man auch Spiele programmieren kann.
In dieser sind auch Schnittstellen für DirectDraw & D3D bzw. es werden Teile der STL, die sich z.B. mit Bitmaps beschäftigen, per DDraw beschleunigt.

[catamaran]

Es gibt aber eine STL-Version für Windows, mit deren Hilfe man auch Spiele programmieren kann.
In dieser sind auch Schnittstellen für DirectDraw & D3D bzw. es werden Teile der STL, die sich z.B. mit Bitmaps beschäftigen, per DDraw beschleunigt.
OT: Ich überlege noch welche der STL-Container sich mit Bitmaps beschäftigen - aber ich komme nicht drauf? :confused: Bitte kläre mich auf!


T: Wir können aber froh sein, daß ModeX nicht mehr zeitgemäß ist und man kein Peek und Poke mehr benutzen muss um seine Pixel in angemessener Geschwindigkeit auf den Bildschirm zu bringen. Es lebe der Fortschritt.

[Gnafoo]

Vielleicht verwechselt ShadowXX gerade SDL und STL?
http://www.libsdl.org/index.php

[ollix]

Vielleicht verwechselt ShadowXX gerade SDL und STL? Wäre auch mein erster Tipp :)

[Shink]

Zur Oberfläche.....unterschätz nicht, was die Grakas heute so alles an der Oberfläche beschleunigen. Wenn ich mich richtig erinnere kann man sich das mit SiSoft Sandra anzeigen lassen. Du wirst erstaunt sein.

Und selbst wenn "nur" der BitBlt per HW benutzt werden würde, deckst du damit schon 80% der Operationen des Windows-Desktops mit ab.
Zusätzlich werden noch Linien , Chords, Boxes, Elipsen, Circle, alles wahlweise gefüllt oder sogar mit Muster und vieles andere beschleunigt (Floodfill natürlich auch, auch mit Muster oder Bitmap).
Bei der Oberfläche trifft dies zu. In Spielen benötigt man diese Dinge wohl kaum.

Aber stimmt: Selbst mit Java kann man seit Version 1.4 Images im Grafikspeicher sichern (VolatileImage).

[=Floi=]

alte spiele wie
-indianer jones
-tetris
-commander keen
-super mario
also richtige 2D engines/games

mir geht es weniger um die programmiersprache sondern wie der content entstanden ist

[Gast]

Es gab schon entsprechende Bildbearbeitungsprogramme damals auf Pixelbasis. Wenn auch sehr einfach...

[catamaran]

alte spiele wie
-indianer jones
-tetris
-commander keen
-super mario
also richtige 2D engines/games

mir geht es weniger um die programmiersprache sondern wie der content entstanden ist

Für Commander Keen gibt es irgendwo in den Weiten des Internet die Entstehungsgeschichte. Wie sich ID-Software gefunden hat, Apogee usw.
Bei Keen wurde der Code nur für die jeweilige Trilogie weiterverwendet. Es gab neue Levels ein paar neue Grafiken, aber das wars auch schon.

Bei Indiana Jones kann man vielleicht von einer Engine sprechen. Viele der LucasArts (früher Lucasfilm Games) Spiele bauen auf dem hauseigenen SCUMM System auf.

Mit welcher Software die Grafiken erstellt weiß ich leider auch nicht. Das vielleicht gängigste Grafikprogramm dafür war DeluxePaint (I+II). Ich habe mich damals mit Neopaint beschäftigt.

[tokugawa]

Weniger.....3D-Grafikkarten können auch 2D-Bitmaps manipulieren und durch den Speicher schieben (DirectDraw, wurde sogar schon bei Diablo2 benutzt).


Wenn du mit DirectDraw programmierst, benutzt du automatsich die geschwindigkeitssteigernden Fähigkeiten der Graka. AFAIK greifen selbst STL & Co. auf DirectDraw & D3D zurück.

Zur Oberfläche.....unterschätz nicht, was die Grakas heute so alles an der Oberfläche beschleunigen. Wenn ich mich richtig erinnere kann man sich das mit SiSoft Sandra anzeigen lassen. Du wirst erstaunt sein.

Und selbst wenn "nur" der BitBlt per HW benutzt werden würde, deckst du damit schon 80% der Operationen des Windows-Desktops mit ab.
Zusätzlich werden noch Linien , Chords, Boxes, Elipsen, Circle, alles wahlweise gefüllt oder sogar mit Muster und vieles andere beschleunigt (Floodfill natürlich auch, auch mit Muster oder Bitmap).


Eine Engine die DirectDraw verwendet (also etwa Sprite-basierte 2D-Engines) ist allerdings trotzdem 99% Software und verwendet von DirectDraw höchstens den beschleunigten BitBlt.

Es gibt aber eine STL-Version für Windows, mit deren Hilfe man auch Spiele programmieren kann.
In dieser sind auch Schnittstellen für DirectDraw & D3D bzw. es werden Teile der STL, die sich z.B. mit Bitmaps beschäftigen, per DDraw beschleunigt.


SDL meinst du. STL ist was anderes.

alte spiele wie
-indianer jones
-tetris
-commander keen
-super mario
also richtige 2D engines/games

mir geht es weniger um die programmiersprache sondern wie der content entstanden ist

Gemalt. Gerade LucasArts verwendete für die alten Grafikadventures wie Indiana Jones (nicht Indianer, verdammt!) etwa das Programm DeluxePaint. Es gibt ja die Anekdote, wonach für Secret of Monkey Island das File für den Hauptcharakter GUYBRUSH.LBM hieß, da in DeluxePaint die Sprites "brushes" genannt werden. Erst danach haben die Entwickler gefunden dass "Guybrush" eigentlich ein cooler Name ist und den dann tatsächlich verwendet.

Entweder wurde der Content direkt in einem Pixelmalprogramm gemalt, oder auch gezeichnet (per Hand auf Papier) und digitalisiert.

Teilweise gibt es Spiele (etwa einige spätere Sierra-Adventures, etwa Larry 7 oder King's Quest 7), die teilweise Produktionstechniken aus der Animationsfilmproduktion verwendet haben (Cell Animation/Limited Animation).

Auch gab's schon teilweise vorgerenderte Dinge. In Sam'n'Max kommt etwa ein 3d-vorgerenderter Hubschrauber vor (bei dem Fischer).

Zusammenfassend kann man sagen: alles was 2D-Bilder produziert hat, ist verwendet worden.

[Gast]

In früheren Zeiten habe auch ich mittels einer Basic/Assembler-Kombination interessante Sachen auf meinem (leider nicht sehr verbreiteten) System gemacht. Auf dem System musste der Prozessor ALLES alleine machen (Daten saugen, aufbereiten und am Ende an den Fernsehausgang oder den Monitorausgang rauspusten). 8 MHz reichten damals für Spiele mit 320 x 256 Pixeln VÖLLIG aus. Mit heutigen Prozessoren (immerhin 80 mal schneller getaktet) kann man auf SmartPhones/PocketPCs bestimmt auch was hinkriegen....