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.
...alle DOS-Spiele, die eine grafischen Ausgabe hatten (und wenn du in deiner Frage "Shell" gegen dosbox oder dosemu austauschst...)
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.
Bei Win 3.11 gibt es nichts zu frickeln..ich komme aus der DOS Generation. und hatte mitdem Schneider CPC bzw IXM XP angefangen.
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.
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
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.
Daniel A. schrieb: > Die kernel schreiber haben da ein paar dumm heiten gemacht. > Ich überspringe das warum mal, Warum wurde es so gemacht?
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/
Daniel A. schrieb: > Mit KMS macht man Dinge wie die Bildschirmauflösung setzen, den > anzuzeigenden Buffer setzen, ... Besten Dank. Ich lese mir gerade folgenden WP Artikel durch, da wird das recht gut erklärt: https://en.wikipedia.org/wiki/Direct_Rendering_Manager
> [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
Scherzkeks schrieb: > Also das echt kein Missverständnis gibt. Vielleicht solltest Du einfach mal die Antworten lesen, die Du bekommst, z.B. gleich die erste: Beitrag "Re: Grafische Linux Spiele im "DOS" Modus"
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
Scherzkeks schrieb: > oder du meine darauffolgenden Anmerkungen, das ich unter Shellspielen > nur welche im Textmodus finde... Und warum suchst Du nach "Shellspielen", wenn ganz andere Stichworte genannt wurden? Hmmm schrieb: > Stichwort SVGAlib, heute SDL Und wenn Du dann noch eine Suchmaschine bedienen kannst, landest Du z.B. bei: https://www.svgalib.org/programs.html https://en.wikipedia.org/wiki/List_of_games_using_SDL
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.