Forum: PC Hard- und Software Grafische Linux Spiele im "DOS" Modus


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 50c (Gast)


Bewertung
0 lesenswert
nicht lesenswert
...alle DOS-Spiele, die eine grafischen Ausgabe hatten (und wenn du in 
deiner Frage "Shell" gegen dosbox oder dosemu austauschst...)

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Daniel A. (daniel-a)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:-)

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei Win 3.11 gibt es nichts zu frickeln..ich komme aus der DOS 
Generation.  und hatte mitdem Schneider CPC bzw IXM XP angefangen.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel A. schrieb:
> Die kernel schreiber haben da ein paar dumm heiten gemacht.
> Ich überspringe das warum mal,

Warum wurde es so gemacht?

von Daniel A. (daniel-a)


Bewertung
2 lesenswert
nicht lesenswert
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/

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von foobar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> [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

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Scherzkeks (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hmmm (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.