Welche guten grafischen! Spiele, gibt es für Linux, die in der Shell
laufen, also in der Shell aber grafisch mit Auflösungen von 640x480 oder
so, also nicht im Textmodus.
Also Spiele bei denen die Grafische Oberfläche Xserver? nicht benötigt
wird.
Auf die Schnelle habe ic nur Spiele im Textmodus gefundes, wusste aber
auch nicht, wie ich danach am besten googeln soll.
Gibt es z.B. einen Wolfenstein clone für Linux?
Also ohne wine und grafischer Benuzeroberfläche
Scherzkeks schrieb:> Auf die Schnelle habe ic nur Spiele im Textmodus gefundes, wusste aber> auch nicht, wie ich danach am besten googeln soll.
Früher war das Stichwort SVGAlib, heute SDL. Wobei Du vermutlich selbst
zum Compiler greifen musst, Binary-Packages dürften immer eine
X11-Variante von SDL als Dependency mitbringen.
Ich müsste auch erst mal eine Suchmaschine bemühen:
https://www.fossmint.com/linux-terminal-console-games/
Aber um die Vollbildausgabe von Baldurs Gate 2 z.B. habe ich mich bisher
auch noch nicht gekümmert.
So grundsätzlich ist man mit DosBox besser dran, weil ja u.a. auch viele
Emulatoren (für alles mögliche..) für Dos bereitgestellt werden.
Scherzkeks schrieb:> Welche guten grafischen! Spiele, gibt es für Linux, die in der> Shell> laufen, also in der Shell aber grafisch mit Auflösungen von 640x480 oder> so, also nicht im Textmodus.> Also Spiele bei denen die Grafische Oberfläche Xserver? nicht benötigt> wird.>> Auf die Schnelle habe ic nur Spiele im Textmodus gefundes, wusste aber> auch nicht, wie ich danach am besten googeln soll.>> Gibt es z.B. einen Wolfenstein clone für Linux?> Also ohne wine und grafischer Benuzeroberfläche
Der Linux Kernel hat einen Framebuffer Modus.
Den kannst du nutzen.
Die Spiele müssen dafür dann natürlich compiliert sein.
Die SDL kann auch auf den Framebuffer ausgeben.
Das ganze ist dann ohne X.
Nano schrieb:> Die Spiele müssen dafür dann natürlich compiliert sein.
Bzw. die Lib, wie bspw. die SDL, wenn die Spiele diese nutzen.
Ob man das auch on the fly umschalten kann, wäre auch denkbar, weiß ich
aber nicht.
Ich habe nie den Framebuffer zum Spielen benutzt.
Bei Linux gibt es:
1) Den Framebuffer
2) DRM/KMS (Direct Rendering Manager) (Kernel Mode Setting)
3) TTYs/VTs
Der Framebuffer war zuerst da. Im Grunde ist das ein Device File, über
den direkt man auf das Display zeichnen kann. Das geht ganz einfach per
memory mapping, oder direkt per write und seek. Die verhalten sich wie
eine normale Datei. Mit "yes >/dev/fb0" kann man den Bildschirm z.B.
Violet füllen. Es gibt auch noch IOCTLs für das setzen der Auflösung,
einstellen des Panning, und solchen Kram, sofern das entsprechende Gerät
das unterstützt. Theoretisch wären auch Device spezifische IOCTLs
möglich, z.B. für OpenGL usw., aber momentan sind keine Treiber mit
derartigen mehr in Linux vorhanden. Und man sollte es nicht gleichzeitig
mit DRM/KMS verwenden.
DRM/KMS ist das neuere Ding. Im Kernel gibt es da andere Treiber, und
die fbdev Treiber werden nach und nach durch KMS ersetzt. Viel ist nicht
mehr übrig von fbdev. DRM/KMS Treiber, haben aber eine
Emultaionsschicht, mit dem sie das alte fbdev interface weiter zur
Verfügung stellen. DRM ist ein Horrorinterface, bei dem jeder Treiber
seine eigenen IOCTLs hat. Erst mit libdrm+mesa wird das abstrahiert.
Immerhin wurde da später noch KMS und DRM dumb buffers drauf gesetzt.
Wenn man mit den DRM Interface (den /dev/dri/* Device files) das selbe
machen will, wie mit fbdev, ohne externe libs, ist das um einiges
Komplexer. Die kernel schreiber haben da ein paar dumm heiten gemacht.
Ich überspringe das warum mal, aber es läuft darauf hinaus, dass man
root und der erste der das Gerät öffnet sein muss, um DRM Master werden
/ weitergeben zu können (ist ne funktion / IOCTL), DRM Master braucht
man für KMS, KMS braucht man für Auflösung setzen, drm dumb buffer
erstellen, und anzeigen, und wenn man all den Kram hinter sich hat, kann
man endlich wie beim framebuffer einfach in den Speicher schreiben, btw.
hier in den drm dumb buffer... Absolut absurd über verkompliziert das
ganze. Kernelintern werden die KMS+dumb buffer dinger auch für die fbdev
emulation gebraucht. Ohne libdrm ist KMS nicht lustig, und ohne
gbm/mesa/egl kann man 3D schon fast vergessen, falls man das will, macht
nämlich sonst jeder anders. Und gbm ist buffer und memory management
zeugs, kann auch buffer erzeugen, hat aber nichts mit KMS oder drm dumb
buffern zutun, und nvidia nutzen als einzige was anderes...
Und dann gibt es da noch die Linux Konsole. Meistens ist das fbcon.
fbcon setzt auf den Framebuffer (fbdev) auf, aber kernel intern. Das ist
ein terminal emulator im Kernel. Also Eingabe und Ausgabe geht dann über
/dev/tty*. Man schreibt Text, Escapesequenzen, etc. nach /dev/tty*, und
es landet auf dem Framebuffer. An dem Punkt werden Sachen etwas
komplexer, die tty können framebuffern zugewiesen werden, auf denen
fbcon aktiv ist, und können dann aktiviert werden. fbcon zeigt dann den
Text vom aktiven tty, btw. den dazugehörenden VT, im framebuffer an. Das
ist also das VT (virtual terminal) und VT switching zeugs von linux, und
woher die Idee mit dem multiseat kram ursprünglich kam. fbcon hat noch
die Limitation, dass selbst wenn 2 fbs unterschiedliche TTY zugewiesen
sind, wird nur der Inhalt des zuletzt aktivierten VT/TTY geupdated, das
kann echt verwirren. Die fbcon tty sind in dem sinne speziell, weil sie
VTs haben, die auf einem framebuffer angezeigt werden. Es gibt auch
andere TTY, z.B. für seriell, wo man auch Terminals anschliessen könnte,
aber die haben dann natürlich keinen dazugehörenden framebuffer. In die
TTY schreiben ist quasi der text modus von linux.
Die APIs haben erst mal nichts direkt mit der Bildschirmaufzeichnung
Zutun. Da ist kein spezieller Modus, den eine Anwendung wollen könnte,
um zu laufen.
Was eventuell Auswirkung auf die Auflösung haben könnte, ist, wenn man
die Grafik dem BIOS überlässt. Mit Vesa, oder neu efifb. Das ändert aber
nichts an den APIs, die die Anwendungen nutzen könnten, ausser, dass
einem dann Treiber spezifisches fehlt, vermutlich sogar immer noch das
ganze DRM subsystem (vesafb ist glaube ich immer noch nur ein fbdev
statt ein KMS treiber), nützt einem also nichts.
Für Anwendungen, die ohne Xorg oder Wayland auskommen, suche nach
solchen, die direkt auf KMS oder FBDEV aufsetzen. Die meisten
Anwendungen basieren auf diversen Libraries und Frameworks. Alles, was
directfb (ist tot) (framebuffer basiert), QT (kann fb und kms), SDL
(kann fb und kms), etc. basiert, lässt sich theoretisch so verwenden.
Das beinhaltet theoretisch Dinge wie Retroarch, sämmtliche QT/KDE
Anwendungen (wobei ich die noch nicht ohne X/Wayland zum laufen gekriegt
habe), mpv, mplayer, gst-launch kmssink (gstreamer), dosbox, directvnc,
und vieles mehr.
Aber sowas wie den DOS Mode wie alten Windows gibt es in dem sinne
nicht. Braucht es hier schlicht nicht.
Daniel A. schrieb:> Ohne libdrm ist KMS nicht lustig, und ohne> gbm/mesa/egl kann man 3D schon fast vergessen, falls man das will, macht> nämlich sonst jeder anders.
Und der Grund dafür ist, dass eigentlich nur die VESA Modi und efifb
sich generisch und einheitlich gleich ansprechen lassen.
Für jede höhere Sonderfunktion einer Grafikkarte, wie z.B. die ganzen
Beschleunigerfeatures, inkl. 3d Beschleunigungsfunktionen (früher gab's
auch 2d Beschleunigungsfunktionen, wie Linien, Rechtecke, Kreise malen
usw.) braucht man dann auf die GPU spezialisierte Treiber.
Deswegen spricht man beim Framebuffer auch in der Regel von einem reinen
2d Modi ohne Beschleunigerfeatures.
DirectFB war der Versuch, Beschleunigerfeatures noch zusätzlich zu
unterstützen, brauchte dann aber eine entsprechende zusätzliche
Spezialisierung auf die Hardware, denn die Hardware ist da ja nie
einheitlich gewesen.
hmmm, keine Ahnung was ihr mir jetzt damit sagen wollt.
Also es kling als ob es das nicht gibt.
Die Shellgames, da komme ich wie bereits gesagt....nur auf Texmode
Spiele
Also offenbar gibt es da für Linux nichts oder so gut qibt nichts.
Hatte ich mir schon gedacht.
Also doch zu MS DOS.
Mir ging es aber eigentlich ums Frickeln, und dabei dachte ich halt
zuerst an Linux.
Unter Dos hat es keinen Reiz, da gibt es viel zu viel und alles läuft
sofort.
Also Spiele wie
https://jonesinthefastlane.com/
Aber das kann ich dann auch gleich dort online spielen:-)
Scherzkeks schrieb:> Mir ging es aber eigentlich ums Frickeln, und dabei dachte ich halt> zuerst an Linux.
Mit Linux kann man nicht frickeln, wenn du frickeln willst, brauchst du
MS Windows 2.0 oder Windows for Workgroups 3.1.
Scherzkeks schrieb:> Bei Win 3.11 gibt es nichts zu frickeln..ich komme aus der DOS> Generation. und hatte mitdem Schneider CPC bzw IXM XP angefangen.
Dann hast du nie die ini Dateien von Win 3.11 entdeckt.
Scherzkeks schrieb:> doch doch, mir sind Win.ini System.ini ...sehr wohl bekannt...> Ich war auch ein meister in der Optimierung der config.sys und> autoexec.bat
Ich denke jetzt ist alles gesagt.
Der Thread kann nach /dev/null wandern.
Scherzkeks schrieb:> Ich war auch ein meister in der Optimierung der config.sys und> autoexec.bat
Es ist schon tragisch was da an Wissen und Erfahrung immer mehr verloren
geht.
Georg
Nano schrieb:> Ich denke jetzt ist alles gesagt.> Der Thread kann nach /dev/null wandern.
Man könnte auch aufhören, den Thread in gewisse Richtungen zu kapern und
auf die Frage des TE eingehen.
Dann könnte man den Thread vermutlich hier stehen lassen.
Denn trotz der interessanten Theoretischen Ausschweifungen und den
weniger Interessanten Linux/Win-Diskussionen wurde die Frage bisher noch
nicht so richtig angegangen.
Vermutlich sucht der TE Spiele wie Gobliiins oder ähnliche
Point&Click-Adventures.
Die liefen damals direkt unter DOS und setzen keine Windows-Installation
vorraus.
Der TE schreibt zwar "keine graphische Oberfläche" (womit jeder erstmal
eine DesktopEnvironment assoziert), meinen tut er aber "ohne X/Wayland".
Textbasierte Spiele (z.B. Rogue-likes) scheiden auch aus.
Ich kenn sowas nicht.
Die meisten Grafiklibs malen nicht direkt in den framebuffer sondern
setzen auf X auf.
Le X. schrieb:> Nano schrieb:>> Ich denke jetzt ist alles gesagt.>> Der Thread kann nach /dev/null wandern.>> Man könnte auch aufhören, den Thread in gewisse Richtungen zu kapern und> auf die Frage des TE eingehen.> Dann könnte man den Thread vermutlich hier stehen lassen.> Denn trotz der interessanten Theoretischen Ausschweifungen und den> weniger Interessanten Linux/Win-Diskussionen wurde die Frage bisher noch> nicht so richtig angegangen.
Die Frage wurde ausführlich und vollständig beantwortet.
Allerdings hat der TS mit seinem Posting bei
Beitrag "Re: Grafische Linux Spiele im "DOS" Modus"
gezeigt, dass er an der Frage eigentlich gar kein ernsthaftes Interesse
hatte und es hier nur ums Trollen geht.
> Vermutlich sucht der TE Spiele wie Gobliiins oder ähnliche> Point&Click-Adventures.> Die liefen damals direkt unter DOS und setzen keine Windows-Installation> vorraus.> Der TE schreibt zwar "keine graphische Oberfläche" (womit jeder erstmal> eine DesktopEnvironment assoziert), meinen tut er aber "ohne X/Wayland".> Textbasierte Spiele (z.B. Rogue-likes) scheiden auch aus.
Wie ein Spiel dargestellt wird, ist keine Kategorie in der man Spiele
einteilt.
Wenn er bestimmte Spiele eines bestimmten Genres sucht, dann kann er
danach ja fragen, seine Frage war aber wie das ohne X/Wayland technisch
gelöst werden kann und diese Frage wurde beantwortet.
Letzten Endes sollte ihm auch klar sein, dass früher bis auf Quake und
Doom kaum kommerzielle Spiele erschienen.
Die erste größere Menge war mit Lokigames und die verwendeten alle schon
eine X Umgebung. Selbst Civ Call to Power.
> Ich kenn sowas nicht.> Die meisten Grafiklibs malen nicht direkt in den framebuffer sondern> setzen auf X auf.
Zur Jahrtausendwende hat man recht schnell damit angefangen die Grafik
von Spielen direkt in ein OpenGL Fenster zu zeichnen.
Weil das schneller war, als bspw. die SDL zu nutzen.
Nano schrieb:> Daniel A. schrieb:>> Die kernel schreiber haben da ein paar dumm heiten gemacht.>> Ich überspringe das warum mal,>> Warum wurde es so gemacht?
Das ist historisch gewachsen.
Mit KMS macht man Dinge wie die Bildschirmauflösung setzen, den
anzuzeigenden Buffer setzen, und andere Dinge rund um die Verwaltung der
Bildausgabegeräte. Die Idee hinter drmSetMaster ist, dass wenn 2
Programme versuchen würden, auf diese Funktionen zuzugreifen, um etwas
anzuzeigen, gäbe es ein durcheinander, also will man sicherstellen, dass
zu jedem Zeitpunkt nur eine Anwendung all das Verwaltet.
(Wobei der DRM Master aber eigentlich ein Zustand einer File description
eines geöffneten /dev/dri/card* devices ist, und nicht ein Zustand der
Anwendung).
Das mit dem zuerst öffnen müssen ist glaub ich eine historische
Geschichte, früher war die erste Anwendung, die die Card Node öffnete,
glaub ich automatisch DRM Master.
root braucht man für drmSetMaster, weil es neben KMS diverse Funktionen
gibt, die Anwendungen je nach dem für anderes, (z.B. das Rendern von
dingen in BOs, BOs alloziieren, etc.) brauchen könnten, was nichts
direkt mit der Anzeige und Verwaltung der Bildausgabegeräte Zutun hat.
(Wobei, mittlerweile kann man für das meiste derartige die render nodes
verwenden). Dadurch, dass diese Anwendungen auch Schreibzugriff auf die
Card node brauchen, aber nicht unbedingt KMS Zeugs tun können sollten,
aber alle Interfaces teil des selben Device Files waren, wo man die
Zugriffsrechte nicht feiner einstellen kann, hat man dann als eine art
Hack einfach Root für drmSetMaster vorausgesetzt.
Ich bin mir nicht sicher, ob das root requirement von Anfang an da war,
und Anwendungen einfach setuid nutzten und dan root droppten, oder ob es
erst bei der consolekit -> logind umstellung gemacht wurde. consolekit
gibt dem Benutzer ja Lese und Schreibzugriff auf die card nodes per ACL,
sicherheitstechnisch natürlich völliger Unfug, da Sicherheitsprüfungen
ja nur beim Öffnen der Dateien stattfinden, aber falls das root
Requirement nicht immer da war, wäre das auch ein weg gewesen.
Um Heute ohne root und ohne setuid KMS nutzen zu können, braucht es
einen Mediator, der als root die card node öffnet, drm master wird, und
den device descriptor weiter gibt. Per drmDropMaster kann dieser den KMS
zugriff auch wieder entziehen. Zuerst gab es nur logind (welches
consolekit ablöste) dafür, (was im kernel source code Kommentar zu
drmSetMaster auch direkt genannt wird/wurde), und für einiges an
Aufschrei bei der Umstellung sorgte. Mittlerweile gibt es auch noch
seatd/libseat[1] als alternative, die kein systemd voraussetzt.
Das Zugriffsproblem hatte man auch bei den Framebuffer devices, die
Anwendungen dort nutzten damals, falls sie überhaupt darauf achteten,
die Assoziation der VTs, auf denen sie gestartet wurden, sowie die job
logik von linux/unix (das TTY und process group zeug wäre zu erklären
könnte noch ein paar seiten füllen), um zu entscheiden, ob sie was auf
dem fb anzeigen dürfen. Ging aber nicht mit allen Anwendungen gut. Vor
dem seat managemant zeugs (logind/seatd) nutzten KMS Programme
vergleichbare Logik, um selbst drmSetMaster/drmDropMaster aufzurufen,
und auch wenn das nicht immer glatt lief, ging das besser, als mit den
FBs, weil wenigstens nicht 2 Anwendungen gleichzeitig aktiv sein
konnten. Wobei, die VT Switching teil wurde meines wissens nicht
vollständig von logind/elogind übernommen, und müssen glaube ich immer
noch zu einem gewissen Grad von der Anwendung gehandhabt werden.
Zum Thema seat managemant und DRM/KMS solle ich eventuell noch DRM
Leases erwähnen. Im Grunde kann ein DRM Master damit einen neuen DRM
Master Filedeskriptor erstellen, aber einen der nur zugriff auf
bestimmte DRM/KMS Resourcen hat, z.B. nur auf einen bestimmten
CRTC/Bildschirm, usw. Auch DRM Leases können zurückgezogen werden,
ähnlich, wie man DRM Master droppen kann. Dieses Interface wurde
ursprünglich für VR Games unter Xorg entwickelt, diese wollten volle
Kontrolle über ihre VR Hardware, am X Server vorbei. Theoretisch könnte
man dies auch nutzen, um granulareres Seat Managemant zu machen, also
einen Bildschirm einer KMS Anwendung geben, den anderen einer anderen,
aber meines Wissens wird dies momentan noch nirgends gemacht.
1) https://git.sr.ht/~kennylevinsen/seatd/
> [SDL] Ob man das auch on the fly umschalten kann, wäre auch denkbar,> weiß ich aber nicht.
Per Umgebungsvariable (spez SDL_VIDEODRIVER):
https://wiki.libsdl.org/FAQUsingSDL
Daniel A. schrieb:> DRM ist ein Horrorinterface, bei dem jeder Treiber> seine eigenen IOCTLs hat. Erst mit libdrm+mesa wird das abstrahiert.> Immerhin wurde da später noch KMS und DRM dumb buffers drauf gesetzt.> Wenn man mit den DRM Interface (den /dev/dri/* Device files) das selbe> machen will, wie mit fbdev, ohne externe libs, ist das um einiges> Komplexer.
In der WP steht:
"In early 2011, during the Linux 2.6.39 release cycle, the so-called
dumb buffers—a hardware-independent non-accelerated way to handle simple
buffers suitable for use as framebuffers—were added to the KMS
API.[130][131] The goal was to reduce the complexity of applications
such as Plymouth that don't need to use special accelerated operations
provided by driver-specific ioctls"
Die dumb buffers scheinen heutzutage also das zu sein, was dem fbdev am
nächsten kommt.
Also das echt kein Missverständnis gibt.
Ich meine nichts weiter als den VGA oder SVGA Modus unter DOS.
Keine 3D Unterstützung, kein Open GL etc pp.
Einfache Spiele die im VGA/SVGA Modus laufen
oder du meine darauffolgenden Anmerkungen, das ich unter Shellspielen
nur welche im Textmodus finde...
Also Tetris, PAacman aber eben im 8Textmodus mit 80 zeichen oder so bzw
ansii
Es gibt mit EGLFS übrigens unter Linux auch die Möglichkeit, ohne X
sogar 3D-Beschleunigung zu verwenden, allerdings nicht auf dem PC, aber
z.B. beim Raspberry Pi.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten