DOS-Forum

Hallo liebe Freunde!

Ich war länger nicht hier und habe etwas zu erklären.

Meine Motivation zu kreativer Arbeit an DOS-Projekten
wird gebremst durch folgendes:

1. Für DOS geht einher, dass man auch bei der letzten Plattform
und Hardware bleibt, die vor der Windows Ära war.
Das heisst für manche, 486er, für mich selbst auch
noch Pentium. Mit dem könnte ich in DOS tolle Sachen
zaubern, aber da muss man sich einig werden ob der noch "gilt".

2. Es ist leider nicht so dass DOS wie eine Konsole (wie die klassische NES)
oder aber auch ein Heimcomputer wie der C64 betrachtet wird, sondern
ein 486er wiederum ist nur ein Schnappschuss aus einer kurzen Zeit
der PC Kompatiblen Rechner. Daher kann man leider nicht sagen
"hey, lass mal sehen was wir aus der Kiste alles rausholen können",
weil die heutigen Generationen von Rechnern aufgrund ihrer Leistung
sowieso alles können.

3. Es besteht keine Not mehr, die Daten möglichst kompakt zu halten.
Schon zu Pentium Zeiten, vor Windows XP, war es normal, wenn ein
Spiel eine ganze CD-ROM füllte.
Aber ich habe Spass daran, Daten möglichst kompakt zu speichern.
Jedoch wird dieser Spass dadurch getrübt, dass mir immer allgegenwärtig
ist, dass die Zeiten wo man sich freute, wenn ein ganzes Spiel auf eine Diskette
passte, längst vorbei sind.
Datenmengen, im Bereich Spiele zumindest, haben kein erschöpfbares
Limit mehr.

Dies macht mir alles Spass, ja. Aber in heutigen Zeiten wo man die Grafiken
gleich am besten als Truecolor 48 Bit BMPs reinknallt, kommt bei mir die
Frage auch ob es langsam überhaupt noch Sinn macht kompakte Daten
zu strukturieren oder nicht gleich drauf sch****** und nur zusehen, dass
man ein tolles Spiel zum Vorzeigen hinbekommt, auch wenn es intern
noch so viele Booleans als 64 Bit speichert, die Sounds einfach als 16 Bit 44.1 Wav uswusf.

Für mich ist es ein bisschen so als hätte ich den Zug verpasst.
Ich hätte 5 Jahre eher geboren werden sollen, dann hätte ich
Anfang der 90er so manches Superspiel rausgehauen, für damalige
Verhältnisse.


Mittlerweile hab ich mich mehr mit dem "Real Life" beschäftigt.
Musik bearbeiten, Boxen bauen, und ich lese mich in Elektronik
ein. Soetwas ist wenigstens zeitlos(er)...

Zu Punkt 2 kann ich noch ergänzen:
Man könnte eine Trennlinie ziehen, und zwar zwischen den
Rechnern die noch 16 Bit Code verstehen und denen die
es nicht mehr können. Man könnte also die neueste noch mit
DOS kompatible Hardware als neue "Konsole" ansehen, auf
der wir DOSler uns austoben können.


Liebe Grüße,

Zatzen

zatzen hat geschrieben:Aber ich habe Spass daran, Daten möglichst kompakt zu speichern.
Jedoch wird dieser Spass dadurch getrübt, dass mir immer allgegenwärtig
ist, dass die Zeiten wo man sich freute, wenn ein ganzes Spiel auf eine Diskette
passte, längst vorbei sind.
Datenmengen, im Bereich Spiele zumindest, haben kein erschöpfbares
Limit mehr.

Einzig die Demoszene widersetzt sich teilweise (es gibt auch >100 MB große Demos) diesem Trend. Dort übernehmen heute die 4k-Intros den Part, der vor wenigen jahren noch den 64k-Intros galt. :D

Hallo Zatzen!

zatzen hat geschrieben: ...
1. Für DOS geht einher, dass man auch bei der letzten Plattform
und Hardware bleibt, die vor der Windows Ära war.
Das heisst für manche, 486er, für mich selbst auch
noch Pentium. Mit dem könnte ich in DOS tolle Sachen
zaubern, aber da muss man sich einig werden ob der noch "gilt".

Ich denke, eher nur ein geringer Teil der Leute verbindet mit DOS die ersten
PCs a la 8088 oder 80286. Für die meisten hat DOS mit einem 486er begonnen.
Und zur Hoch-Zeit von DOS haben fast alle vom Pentium geträumt oder ihn
dann gar gehabt. Der erste Pentium (P60) kam ja schon 1993 heraus und war
sündhaft teuer (weit über DM 10.000,--). Auf jeden Fall kann man ohne Problem
als High-End-Dos-Retro-PC einen P133-P166 mit adäquater Sound- und Grafik-
Ausstattung ansehen. Das ist auf jeden Fall immer noch absolut Retro-Dos.

zatzen hat geschrieben: 2. Es ist leider nicht so dass DOS wie eine Konsole (wie die klassische NES)
oder aber auch ein Heimcomputer wie der C64 betrachtet wird, sondern
ein 486er wiederum ist nur ein Schnappschuss aus einer kurzen Zeit
der PC Kompatiblen Rechner. Daher kann man leider nicht sagen
"hey, lass mal sehen was wir aus der Kiste alles rausholen können",
weil die heutigen Generationen von Rechnern aufgrund ihrer Leistung
sowieso alles können.

Jein. Grundsätzlich hast Du Recht. Andererseits kannst Du natürlich sagen:
„Ich schreibe ein Game für den High-End-Retro-Dos-PC mit P133 und
hole da alles raus, was geht.“ Das ist dann aber nur „Sport“, und wird nur für
Dich alleine von Wert sein. Denn die anderen haben ggf. schnellere PCs und
damit zuwenig Vergleichswerte. Oder sie vergleichen mit ihren Erfahrungen
aus Games, die sie z.B. am PIII laufen hatten, und sind dann nicht sonderlich
beeindruckt.

Ein „Ich hole alles aus der Kiste XY raus, was geht!“ darf man m.E. nur
machen, wenn man das für sich ganz alleine tut („Sport“).

zatzen hat geschrieben: 3. Es besteht keine Not mehr, die Daten möglichst kompakt zu halten.
Schon zu Pentium Zeiten, vor Windows XP, war es normal, wenn ein
Spiel eine ganze CD-ROM füllte.
Aber ich habe Spass daran, Daten möglichst kompakt zu speichern.
Jedoch wird dieser Spass dadurch getrübt, dass mir immer allgegenwärtig
ist, dass die Zeiten wo man sich freute, wenn ein ganzes Spiel auf eine Diskette
passte, längst vorbei sind.
Datenmengen, im Bereich Spiele zumindest, haben kein erschöpfbares
Limit mehr.

Auch da hast Du Recht. Eigentlich bestand schon seit spätestens dem ersten 486er keine
Veranlassung mehr, Daten in Deinem Sinn kompakt zu halten. Es ist halt auch eine Frage
der Geschwindigkeit, ob ich z.B. 32 Booleans in 32bit halten will, oder ob ich dafür 32 byte oder gar 32 dwords anlege.

Daten-kompakt-zu-Halten ist daher vielleicht auch eher „Sport“, d.h. eine Einstellung, die
von Dritten eher nicht wahrgenommen werden wird.

Ich persönlich entscheide solche Dinge immer im konkreten Einzelfall. Arbeite ich viel
mit Pascal, dann verwende ich die dortigen booleans (1 byte). Weiß ich vorher, dass ich mehrere Booleans in ASM-Schleifen abfragen muss, dann packe ich diese in ein Byte/Word
um möglichst viele Register frei zu halten. Genauso, wenn ich mehrere Booleans auf HD ablege.

Das mit der Diskette ist für mich übrigens schon ein Kriterium: Ich wäre schon sehr froh, wenn ich es hinbekäme, ein Game zu schreiben, was eine ganze 1.44 MB-Diskette sinnvoll braucht (also ohne es mit dword-booleans aufzublähen). Momentan bin ich gerade bei der Maximalgröße von 100kb... Zugleich wäre für mich 1.44 MB auch die Obergrenze (für meine selbstgebastelten Programme). Was aber vielleicht auch davon kommt, dass der einzige Kontakt zur Außenwelt für meinen 386sx das Diskettenlaufwerk ist. Alles, was nicht gezippt auf eine 1.44 MB-Disk paßt, hat es grundsätzlich sehr schwer, auf dem 386sx zu landen.

zatzen hat geschrieben: Dies macht mir alles Spass, ja. Aber in heutigen Zeiten wo man die Grafiken
gleich am besten als Truecolor 48 Bit BMPs reinknallt, kommt bei mir die
Frage auch ob es langsam überhaupt noch Sinn macht kompakte Daten
zu strukturieren oder nicht gleich drauf sch****** und nur zusehen, dass
man ein tolles Spiel zum Vorzeigen hinbekommt, auch wenn es intern
noch so viele Booleans als 64 Bit speichert, die Sounds einfach als 16 Bit 44.1 Wav uswusf.

Ich persönlich habe kein Problem, wenn die Sounds für ein gutes Games nur WAVs sind. In erster Linie muss das Game spass machen. Allerdings ist mein Respekt vor den Urhebern schon erheblich größer, wenn die Files kleiner sind und z.B. kompaktere Trackermusik verwendet wird. Und das ist dann schon der Unterschied zwischen 8 und 10 Punkten...

Prinzipiell habe ich aber vor jedem Respekt, der etwas halbwegs Unterhaltsames auf die Beine stellt.

Wenn Du aber etwas Professionelleres vorhast, würde ich mir schon sehr genau überlegen, ob ich ein Game eher für mich persönlich schriebe oder ob ich einen größeren Kreis von
Usern erreichen möchte.

Im letzteren Fall würde ich die Realisierung für Windows machen. Dort ist es sicherlich
einfacher mit einem guten, kleinen Game ein paar User zu erreichen. Da kannst Du Dein Game dann z.B. über Youtube promoten. Und jeder Interessent kann es sich schnell über einen Link downloaden und sofort ausprobieren (falls der Download freigeben ist).

Bei einem Dos-Game ist das schwieriger, da wesentlich weniger Leute die Plattform DOS
benutzen und sich deswegen überhaupt angesprochen fühlen. Außerdem ist der Aufwand zum Ausprobieren viel höher (Download - Kopieren auf Retro-PC- dort ausprobieren ...). Wenn ich persönlich das Know-How hätte, um ein gutes Game zu entwickeln, dann würde ich es zwar für Dos machen, aber nur, weil mein Interesse primär dahin ginge, die Entwicklung zu machen und weniger, um eine Resonanz zu erhalten.

Aber das ist halt eine sehr persönliche Frage. Nur mehr User erreichen, dürftest Du einfach unter Windows. Deswegen ist Programmierung unter DOS immer „Sport“, also etwas was man hauptsächlich für sich selbst und aus Interesse tut (denke ich).

zatzen hat geschrieben: Für mich ist es ein bisschen so als hätte ich den Zug verpasst.
Ich hätte 5 Jahre eher geboren werden sollen, dann hätte ich
Anfang der 90er so manches Superspiel rausgehauen, für damalige
Verhältnisse.

Naja, ich bin 5 Jahre eher geboren als Du. Geholfen hat es mir nicht

zatzen hat geschrieben: Mittlerweile hab ich mich mehr mit dem "Real Life" beschäftigt.
Musik bearbeiten, Boxen bauen, und ich lese mich in Elektronik
ein. Soetwas ist wenigstens zeitlos(er)...

Zu Punkt 2 kann ich noch ergänzen:
Man könnte eine Trennlinie ziehen, und zwar zwischen den
Rechnern die noch 16 Bit Code verstehen und denen die
es nicht mehr können. Man könnte also die neueste noch mit
DOS kompatible Hardware als neue "Konsole" ansehen, auf
der wir DOSler uns austoben können.

Da setzt Du aber die Grenze recht hoch an, oder? 16bit Code verstehen sollte
jedenfalls auch noch ein P4. Aber auch da hätte ich nichts dagegen!

Ich hoffe, ich habe nicht zu negativ geklungen. Ich wäre nämlich schon sehr gespannt, was Du auf die Beine stellen würdest. Auch wenn ich mir dazu einen schnelleren Retro-PC zulegen müßte

Also ich würde ein Projekt für möglichst viele DOS-PCs machen, notfalls eben nach dem Motto "Du willst es am 286er nutzen? Dann schraubt man halt hier und da die Qualität runter".

Ich selbst sehe es als wenig "cool" an, ein Programm für einen P1 oder P2 zu schreiben - da könnte man ja schon fast QBASIC nehmen und es würde noch flott laufen.

Nun ja, warum wird eine DOSe nicht wie ein C64 betrachtet - zum einen fehlt der Charme, zum anderen hat sich die Hardware eines C64 nie geändert. Eine bestimmte PC-Generation ist tatsächlich nur ein "Schnappschuss", was die technischen Details angeht. Außerdem ist ein C64 oder eine Konsole wesentlich leichter zu programmieren - ich habe schon am C64 und am Master System von Sega programme geschrieben - bei beiden habe ich an einem Nachmittag schon Spiele mit Scrolling hinbekommen. Ohne groß etwas zu timen o. ä. - halt 100% Asm und dazu noch selbst gezeichnete Grafiken. Das ist am PC halt alles nicht wirklich möglich.

Für mich heißt DOS-Ära eigentlich, PCs vom 286 (meine erste DOS-Rechner waren 286) bis 486. Ab Pentium hört es dann auch für mich auf - denn bei uns wurden P1-Rechner schon mit Win95 verkauft. Vorher waren es wohl eher Freak-Rechner für reiche Leute.

Ich verstehe auch den "Sinn" dieses Beitrages nicht - denn wenn Du selbst zweifelst, ob und wie sinnvoll ein Projekt für DOS ist, dann solltest Du nochmals tief in Dich gehen und es überschlafen. Von anderen Meinungen würde ich es nicht abhängig machen. Ich gebe Wobo da recht - wenn du einen möglichst hohen Nutzerkreis möchtest, dann schreib lieber etwas für Windows - zumal du da mehr Möglichkeiten hast.

>Dies macht mir alles Spass, ja. Aber in heutigen Zeiten wo man die Grafiken
gleich am besten als Truecolor 48 Bit BMPs reinknallt, kommt bei mir die
Frage auch ob es langsam überhaupt noch Sinn macht kompakte Daten
zu strukturieren oder nicht gleich drauf sch****** und nur zusehen, dass
man ein tolles Spiel zum Vorzeigen hinbekommt, auch wenn es intern
noch so viele Booleans als 64 Bit speichert, die Sounds einfach als 16 Bit 44.1 Wav uswusf.


Jedes Byte zählt. Ich war mal in einem Projekt unterwegs da mussten CAN Beschreibungsdateien in ASCII (Menschenlesbar) in eine DB übertragen werden. Ein Kollege, jung und aus der Pentium Äre hatte die Aufgabe das zu implementieren. Er wählte C++.

Ergebnis:

* aus 2k wurden im RAM 200MB
* aus 200k wurden im RAM 20000MB ...
* Pointer auf Klassen pointer auf .. pointer auf und pointer auf , Gulasch code, völlig konfus. Für ein völlig lineares Problem.

Menschenlesbar heist 70% Redundanzen. Also wären für 2k in der ASCII Datei 2K im Ram oder meintetwegen 4k vertretbar gewesen.

Resultat:

* bootup Phase der Software > 5 Minuten
* Um ein Haar wäre das ganze Projekt gescheitert

Effizient zu programmieren ist eine hohe kunst. Diese muss bewahrt werden. Alle 100 code Zeilen ein Fehler. Je weniger Code desto besser, je weinger RAM usage desto besser!

Wobei mehr manchmal besser ist - je nach Zielplattform. Für einen 80286 ist es sicher besser, wenn der sound nicht komprimiert vorliegt und quasi in einem rutsch zur soundkarte weitergereicht werden kann.

Ja, wichtig ist, einen guten Trade-Off zwischen Speicherverbrauch und Performance zu finden. Das geht natürlich am besten, wenn man auch schon beide Extreme erfolgreich ausprobiert hat:
Extrem 1: Minimale Performance, Minimaler Speicherverbrauch
Benutzt, wenn wenig Speicher zur Verfügung steht, Performance aber egal ist. Funktioniert so, daß quasi alle Werte berechnet werden. z.B. keine Sinustabellen und sowas.

Extrem 2: Maximale Performance, Maximaler Speicherverbrauch
Benutzt, wenn Speicher kein Problem darstellt, aber Rechenpower begrenzt ist. z.B. wenn in inneren Schleifen sehr schnell sehr viele Werte berechnet oder darauf reagiert werden muß. Da kann man z.B. riesige Entscheidungstabellen vorberechnen und in den Code einbauen und braucht dann nur noch Anhand der Eingabewerte indiziert darauf zugreifen.

In den meisten Fällen liegt die Wahrheit irgendwo dazwischen, wenn man gut programmiert.

Wenn man schlecht programmiert - wie es heute ja Standard ist, vermischt man beide Extreme. Und leider den "schlechten" Teil beider Extreme. Heutzutage ist nämlich eher folgendes Extrem Standard:
Minimale Performance, Maximaler Speicherverbrauch.
Oder anders ausgedrückt: Jedes noch so primitive Programm (bzw Programm mit primitivem Zweck) braucht immer gleich Speicher im Gigabyte-Bereich und Rechenleistung im Gigahertz. Weil Manchmal um die 80% der Hardwareressourcen für die Skriptinterpreter und VMs, sowie für die Bearbeitung der Daten-hin-und-her-Übergabe zwischen 20 Abstraktionsleveln benutzt wird. Und natürlich für diverse Fehler-Watchdogs, die die aufgeblasenen (und dadurch leider noch fehleranfälligeren) Routinen die ganze Zeit zu überwachen, um Fehler nicht zu beseitigen, sondern extern zu workarounden, weil im Code keiner mehr durchsieht...

Mancher möge ja vielleicht meinen, das klinge pessimistisch. Leider gibt die Realität mir aber recht...

Also zu der Frage, warum ich hier überhaupt schreibe und nicht einfach in mich kehre -
ich bin zur Genüge in mich gekehrt aber es bleibt dieser Konflikt.
Das darf ich euch ja mal mitteilen. Und es ist tatsächlich eine Sache
wo mir eine Diskussion helfen kann, ich würde darin aufgehen, mit
meinen heutigen Fähigkeiten eine schöne Spielidee umzusetzen...
Und okay, hier muss ich mir überlegen: Reicht es nicht auch wenn
ich das Spiel ausschliesslich für mich mache? So halte ich es jedenfalls
mit meiner Musik, ich "komponiere" was ich will, weil ich das hören
möchte was in meinem Kopf ist, und mir ist egal ob ich Fans für
dieses neue Lied bekomme. Wenn nicht, nicht schlimm, wenn doch,
dann umso toller, weil sie dann die Musik mögen die ich 100%
ausm Bauch gemacht hab.
So, aber nochmal:
Für Windows kann und will ich nicht programmieren, aber DOS-Programme
interessieren (fast) keinen mehr, weil den meisten selbst zu umständlich
und ich sag mal schwierig ist, dosbox zu verwenden. Draufklicken ist
einfacher. Man müsste eine Idee realisieren, die so attraktiv ist, dass
die Plattform Nebensache wird.
Für mich stellt dosbox, so frevelhaft es auch sein mag,
dennoch eine Möglichkeit dar, weiterhin programmiertechnisch kreativ zu sein.
Es ist bei mir nämlich nicht so dass ich DOS wie einen heiligen Gral
betrachte, sondern es ist vielmehr so, dass ich mein "Handwerk" in
DOS gelernt habe, und dass Windows eine ganz andere Sache ist,
und bis heute weiss ich nicht wirklich was objektorientierte Programmierung
ist, denn ich habe mich immer dagegen gesträubt es auch nur zu versuchen,
weil ich im Gefühl hatte, dass einen das von der Hardware meilenweit fernhält.
Das ist überhaupt die "crux" mit Windows, der Programmierer darf ja
überhaupt nur noch virtuell agieren.
Ist auch eine Generationsfrage. Ein Freund von mir ist 10 Jahre jünger
und überzeugter Windows-Programmierer, ich will das auch nicht schlecht
machen. Es ist halt sozusagen die Zukunft, und wenn man sich in dem
Metier wohlfühlt ist es gut und man soll es machen, ja man wäre dumm
wenn man da nicht mitziehen würde.
Für mich sind 100%ige Hochsprachen ohne Hardwarebezug allerdings
so spannend wie Mathematikunterricht.
Sicher benutze ich in Pascal viele Funktionen z.B. Dateioperationen
die auch nur "virtuell sind" und sich auf BIOS-Funktionen stützen,
aber wenn man will kann man immer auch direkt agieren.
Ich habe auch schon in QBASIC einzelne Sektoren einer Diskette
beschreiben können, sozusagen versteckt, ohne FAT Eintrag.
In Windows geht das wohl auch, aber da muss man sich wohl
erst durch einen Urwald von Bürokratie kämpfen.
Aber nochmals zum Respekt gegenüber der heutigen Generation:
Ich habe es eingesehen dass für Windows alles eine bessere
Performance hat, wenn man selbst Booleans als 32 Bit speichert.
Geht wohl alles schneller durch den Datenbus wenn der Prozessor
nicht alles selbst noch von 1 Byte auf 4 auffüllen muss, so genau
kenn ich mich nicht aus mit Windows.
Freepascal erlaubt größenwahnsinnige Freiheiten, einfach
mal eben ein 10 MB großes Array definieren... Und mit einem
blockread Befehl komplett füllen Für irgendwelche
Konvertierungsprogramme die nicht schnell sein müssen sehr
praktisch, mich stört nur dass die Byte-Länge der Datentypen
immer durch 4 teilbar sein muss. Das verhindert u.a. (und
natürlich der für Windows nicht zulässige DOS-Assembler)
dass ich meine bisherigen Pascal Programme mittels Freepascal
nach Windows rüberbringen kann.
So gesehen ist DOS durch die eingeschränkten Speichergrößen
behindert, und Windows durch die unflexiblen Datenstrukturen -
Man muss sich wohl erst dran gewöhnen, nicht in Byte, sondern
in DWORD zu denken...
Angesichts der heutigen Datenvolumina (Festplatten usw.)
auch kein Verbrechen.

Charme von Dos ist für mich übrigens 320x200 (egal wieviel Farben, dennoch bevorzugt 256, weil es mich damals
total fasziniert hat am Computer diesen schönen pixeligen Fotorealismus haben zu können) und 8 Bit Sound.
Wenn es nicht rauscht oder zerrt stimmt irgendwas nicht
Dieser geleckte Perfektionismus von heutigen Spielen sagt mir irgendwie nicht zu, hätte er aber vermutlich,
wenn ich 10 Jahre jünger wäre und meine ersten Spiele in Windows gesehen hätte.

Ich war immer enttäuscht wenn ein Spiel eine höhere Auflösung hatte, irgendwie
fehlte der Realismus, weil man bei 320x200 noch Raum zur Fantasie hatte, während höhere
Auflösungen alles konkret festnagelten.

Vielleicht bin ich ein heimlicher Amiga500 Fan gewesen, denn ich liebe MODs, aber ich
hatte eben einen PC weil man damit vermeintlich mehr machen konnte.
Es war immer ein Wettbewerb zwischen Commodore und IBM bei mir und meinen Freunden


Übrigens, ich schrieb, ich hätte ganz tolle Spiele rausgehauen wenn ich 5 Jahre früher geboren wäre...
Also erstmal, was für Spiele. Ihr könnt auf meiner Homepage sehen, was ich tatsächlich produziert
habe. Ich hatte kreativ viel Ausdauer, war aber eher ein durchschnittlich guter Programmierer.
Für mein Alter vielleicht aussergewöhnlich, aber deshalb sage ich ja auch, 5 Jahre früher.
Es geht darum, dass ich 1996 von Quickbasic auf BPascal 7 umgestiegen bin. Und damit
lag mir nun der Computer als Welt zu Füßen. Ich musste jetzt nur noch ordentliche Literatur
finden, wie man die Hardware bedient. Habe mich (allerdings schon 1995) erfolgreich
durch ein Soundblaster-Buch gekämpft und einen Adlib Tracker, noch in Quickbasic, programmiert.
In Pascal habe ich dann ausgefeiltere Grafikroutinen dank ASM schreiben können (so zum
ersten mal transparente Sprites) und ich habe die Digitalsound-Ausgabe aufm Soundblaster
hinbekommen, ausserdem Zugriff auf XMS. Mit diesem Standard hätte ich was imposantes
machen können, aber zu diesem Zeitpunkt war ich bereits 18 und mein Schwerpunkt lag
mehr beim Trackern, ausserdem, es war 1998, herrschte langsam aber sicher schon Windows
vor!
Die Frage wäre nur, ob wenn ich statt 1992, 1987 mit dem Programmieren angefangen hätte,
es schon entsprechende Literatur für die Hardware sowie ein gutes Pascal gegeben hätte.

@zatzen:
Tja, ich habe ähnliche Probleme: Ich kann auf dem PC viele Dinge, die vor 20 Jahren richtig cool gewesen wären... Ich programmiere ja immer noch in Pascal+ASM unter DOS. Und kümmere mich um Performance. Obwohl ich weiß, daß - wenn überhaupt - 90% der Benutzer meiner Software diese unter Windows oder sogar dort in DOSbox benutzen werden - was bedeutet, daß ich noch so viel "optimieren" kann - es wird ja am Ende sowieso alles virtualisiert und die wahre Performance hängt dann vom "DOS-Fenster" von Windows ab, oder von DOSbox.
Für mich ist es eben nur ein Hobby - und glaube nicht daran, daß ich WIRKLICH jemals einmal etwas derart tolles/krasses programmieren werde, daß sich die heutigen Win7-User dafür freiwillig DOSbox antun.
Ich habe übrigens auch schon einmal mit dem Gedanken gespielt, meine Games gleich mit einem fertig konfiguriertem DOSbox-Configfile auszuliefern, so daß man es mit einer BAT starten kann, die dann DOSbox startet mit dem Spiel - für die ganz bequemen / faulen / dummen User (je nachdem). Ich sehe da nur 2 Probleme:
Erstens gibt es in Windows von DOS heraus für mich nicht die Möglichkeit, herauszufinden, wo sich dosbox.exe befindet - ich könnte auch kein Programm mitliefern, das es sucht, denn das bräuchte ja schon ebenfalls DOSbox.
Zweitens weiß ich nicht, ob ich, wenn ich so etwas tun würde, dann meine Programme schon unter der GNU-Lizenz verbreiten müßte (Sourcen mitliefern und so - da bin ich nicht so'n Freund von).
Drittens könnte man natürlich auch DOSbox selbst in das Paket einpacken - aber da müßte man wohl definitiv das GNU streicheln. Muuh.

Und - zatzen - wie Du ja sicher weißt, bin ich immer noch dran, die Vorbereitungen zu treffen für ein - bzw mehrere - Spiele. Der Editor nimmt langsam Gestalt an, bzw ist zu... na sagen wir mal 80% fertig. (Und ja - wer 320x200 Mode mag, wird diesen Editor lieben...)
Und ich habe ja bekanntermaßen schon öfter mal (laut) darüber nachgedacht, meine Games in Zusammenarbeit mit anderen Leuten zu entwickeln. Da ich so etwas aber noch nie getan habe (war immer Solo-Coder), habe ich nicht einmal eine konkrete Vorstellung davon, wie dies vonstatten gehen sollte - keine Ahnung, wie man so etwas organisiert. Irgendwer müßte ja den "Chef" markieren, weil jemand ja dafür zuständig ist, es alles in das Programm einzubauen - und andere Leute müßten dann bereit sein, sich an gewisse Vorgaben (z.B. Einschränkungen bei Rechenzeit-/Speicherverbrauch) zu halten, wobei darüber natürlich trotzdem diskutiert werden dürfte. Ich gehe auch - um mal auf Sound zu kommen - mittlerweile von meiner 4kB-Idee weg. Das war ja nur eine Anmerkung, weil auf dem C64 die Sounds meist 4kB benutzt haben (wurden in den für eigene Grafik nicht benutzbaren Bereich getan, den der Grafikchip immer mit den ROM-Charset-Daten überblendet hat). Denke eher, für Sounds so ca 16-32 kB zu reservieren, ggf. mehr. Denke aber auch, daß es unter 64kB bleiben sollte. a) will ich sowieso keinen Orchesterqualitäts-Sound, weil das ja zu meinen Spielen nicht paßt (da favorisiere ich eher so alte-Konsolen/C64-artigen Sound) und b) brauchen Grafikdaten und Spielsteuerung auch Platz. (Vor allem Grafikdaten - selbst wenn sie, wie in meinem Fall, schon gepackt sind - sind wahre Speicherfresser. Und die Grafik ständig (also in jedem Frame!) mit XMS zu swappen, war zwar eine Idee, die ich mal hatte, aber ich habe die dann doch verworfen. Definitiv wird aber wohl mit XMS geswappt. Ich habe meine Routinen schon daraufhin angepaßt, daß man bis zu 16 verschiedene Sprite-Grafikbereiche ein-/ausblenden kann und ich denke auch darüber nach, die Levelblockgrafikdaten noch einzugrenzen, bzw swapfähig zu machen.
Was Sound angeht, bin ich aber trotzdem kein Freund davon, große Samples zu benutzen. Die sind nämlich ebenfalls wahre Speicherfresser und würden wahrscheinlich noch mehr Speicher verbrauchen als meine Grafikdaten und der Code zusammen. Das geht so nicht. Und man könnte zwar Sounddaten ebenfalls aus dem XMS swappen - aber während des Generierens der Sounds müßten sie sich ja dann schon im "unteren" Bereich befinden. Ja, ich weiß! Weil ich so lame bin und im 16bit ("Real Address Mode") code. Flat 4G hätte in dieser Hinsicht schon einige Vorteile. Aber ich hab das irgendwie nie recht kapiert. Ich weiß nur, wie er prinzipiell funktioniert, hab ihn aber noch nie selbst eingestellt. Habe zwar Texte dazu hier rumliegen... Aber hab mich irgendwie nie damit beschäftigt.
Ich rede hier schon wieder die ganze Zeit über Zeug, das für fast alle Programmierer heutzutage absolut kein Thema mehr ist. Den Kram, den ich hier mache, würden die mit Flash + Javascript auf irgendnem Android ins iPhone tackern...
(In dem Textfeld macht das Ding hier übrigens Rechtschreibprüfung. Zur Information: Flash kennt er. Javascript kennt er. Sogar iPhone kennt er. Aber Android - was ein ganz normales Wort ist und nicht nur der Name eines neuen OS - kennt er nicht. Und DOSbox kennt er auch nicht... Na wenigstens kennt er DOS...)
Zatzen, hast Du eigentlich in letzter Zeit mal etwas programmiert? Würde gerne mal wieder etwas sehen. Ich interessiere mich eben auch für Programmierung anderer Leute - speziell, wenn sie für DOS programmieren (und Du jetzt auch noch Spiele in Pascal+ASM - quasi genau wie ich).
OK, erstmal genug dazu.

Mir kommt hier gerade in den Sinn, dass ich Konsolen-Emulatoren schwieriger
aufzusetzen finde, als dosbox.
Wenn ich ein NES Spiel laufen lassen will muss ich den Emulator starten
und zusehen dass ich die Steuerung richtig konfiguriere.
Bei dosbox muss ich das Spiel nur mounten und normalerweise
läuft dann alles sofort richtig und wie vom Programmierer gewollt.
Trotzdem werden (man kann es ja auf youtube sehen) immer noch
NES Spiele vorgestellt, und auch "legendäre" DOS Spiele scheitern
nicht an dem Emulationsaufwand von dosbox. Das liegt wohl natürlich
auch daran, dass diese Spiele Kultstatus haben.
Daher ja meine Idee dass man ein wirklich attraktives
Spiel machen müsste. Also thematisch nicht etwas ähnlich machen
wie es schonmal gegeben hat, sondern vielleicht vielmehr eine
Story hinter dem Spiel haben, die es so noch nicht gegeben
hat.
Und für sich selbst gäbe es auch noch etwas zu schaffen.
Es gibt wenige Jump&Run-ähnliche Spiele wo man zu zweit
gleichzeitig spielen kann. Mario Bros. (nicht super mario,
und im Internet vorwiegend nur als "Afro Mario" zu finden)
ist so ein NES Spiel, wo man zu zweit, als Mario und Luigi
durch die Plattformen springt. Es ist sehr simpel gehalten,
macht aber Spass, und zu zweit macht es doppelt Spass.
Soetwas fehlt für mich noch, und ich würde mir so ein
Spiel, aber etwas üppiger mit Grafik und Sound, gerne
selbst programmieren, weil es total schön wäre, eben
so ein 2-Player Spiel zu haben.
Vor einigen Jahren habe ich mich auch mal mit TCP/IP
beschäftigt, aber dafür war mein Atem zu kurz.
Es ist aber auch witziger, wenn man zu zweit an
einem Bildschirm sitzt und einer eben links an der
Tastatur steuert und der andere rechts.

Bubble Bobble ist natürlich noch so eine zwei-Spieler-gleichzeitig Legende.

Aber vom Konzept her würde ich doch eher etwas anderes machen...
Bei Bubble Bobble daddelt jeder ziemlich egoistisch vor sich hin,
zumindest kann er das ohne weiteres, und es besteht nicht die
unbedingte Notwendigkeit, im Team zu arbeiten.

Ich hatte mal so ein ganz simples Spiel angefangen, mit zwei
"Bauklötzen" mit Gesicht drauf, und man musste sich gegenseitig
z.B. dadurch helfen, dass der eine auf den anderen draufhüpfen
konnte, um auf eine höhere Plattform zu gelangen.

Generell würde ich sowas aber eher mit humanoiden Wesen
machen wollen, denen ich ein gewisses Eigenleben einhauchen
möchte, vor allem dadurch, dass sie sich je nach Situation
ohne Zutun von den Spielern miteinander unterhalten, also
miteinander sprechen. Das ginge recht einfach, indem
Man Fragen, Aussagen und Antworten in gewisse Schubladen
einordnet, damit die Gespräche nicht allzu sinnlos werden.

Technisch alles sicher kein Problem. Und mit TCP/IP (und UDP/IP) habe ich mich auch schon (erfolgreich) beschäftigt. Schließlich sollte Xpyderz ja ein Multiplayerspiel werden (mehrere Leute an einem Bildschirm mit Splitscreens funktioniert ja auch schon. TECHNISCH ohne weiteres auch mit 16 Spielern und 16 Splits - nur stelle ich es mir etwas [hier Wort einsetzen, finde gerade kein passendes] vor, 16 Spieler, die alle auf demselben Keyboard rumhämmern.... Das wäre dann wohl eher ein physikalisches Problem.
Allerdings habe ich das Übertragungsprotokoll mehrmals geändert, irgendwas stimmte da nicht... Aber genug davon.

Naja ich dachte ja nur an zwei (2) Spieler. So eine Situation stellt sich auch viel öfter
im Alltag ein, da man ja nicht andauernd LANparties macht.
So war es ja auch zu Konsolenzeiten, es gab nie (oder seltenst) mehr als
den 2 Spieler Modus.
Nur dass jeder seinen eigenen Joystick oder Gamepad hatte, aber wenn einer
den Nummernblock bekommt und der andere ASDWY oder so dann geht das
schon mit dem Platz.
Falls es jemand kennt, BITRIS, ein zwei Spieler Tetris, hab ich als Kind
sehr oft mit meiner Schwester gespielt, ohne dass wir uns dabei physisch
in die Quere gekommen sind.

Grundsätzlich ist es ein anderes "Feeling" ob man zu weit an einem Bildschirm
sitzt oder jeder Spieler seinen eigenen Rechner hat. Natürlich hat man bei
LAN mehr Möglichkeit zu strategischem Handeln, weil ja dann meistens
der Blick auf den Bildschirm des anderen "verboten" ist.

Mehr als 2 Spieler an einem Rechner, darüber habe ich tatsächlich auch
schonmal nachgedacht, das würde als Spielkonzept voraussetzen, dass
man als Kontrolle nur eine Taste hat Sowas wie ein Ballonflug wäre
dann denkbar, wo man ja selbst in der Realität nur "einen Knopf"
bedienen kann.

zatzen hat geschrieben:Also zu der Frage, warum ich hier überhaupt schreibe und nicht einfach in mich kehre -
ich bin zur Genüge in mich gekehrt aber es bleibt dieser Konflikt.
Das darf ich euch ja mal mitteilen.

Ja, gerne.

zatzen hat geschrieben: Für mich stellt dosbox, so frevelhaft es auch sein mag,
dennoch eine Möglichkeit dar, weiterhin programmiertechnisch kreativ zu sein.

Ich finde DosBox großartig: War ein ziemliches Glücksgefühl, als ich das Teil vor ein paar Jahren entdeckt hatte.
Alle meine Sourcen mit allen Mode-X-Tweaks und mit Flat4G-Speicheradressierung liefen auf einmal unter Windows. Und jetzt sogar unter Linux (mittels DosBox). Das war für mich schon ein Grund, warum ich weiter unter DOs programmiert habe. So bleibt wenigstens die Option, dass man einem Bekannten seine Dos-Basteleien zeigen kann, ohne dass der einen Dos-Rechner zu haben braucht.

Nix geht über echte Hardware, aber DosBox ist schon ziemlich gut.

zatzen hat geschrieben: Ich habe es eingesehen dass für Windows alles eine bessere
Performance hat, wenn man selbst Booleans als 32 Bit speichert.
Geht wohl alles schneller durch den Datenbus wenn der Prozessor
nicht alles selbst noch von 1 Byte auf 4 auffüllen muss, so genau
kenn ich mich nicht aus mit Windows.
Freepascal erlaubt .... mich stört nur dass die Byte-Länge der Datentypen
immer durch 4 teilbar sein muss. Das verhindert u.a. (und
natürlich der für Windows nicht zulässige DOS-Assembler)
dass ich meine bisherigen Pascal Programme mittels Freepascal
nach Windows rüberbringen kann.
So gesehen ist DOS durch die eingeschränkten Speichergrößen
behindert, und Windows durch die unflexiblen Datenstrukturen -
Man muss sich wohl erst dran gewöhnen, nicht in Byte, sondern
in DWORD zu denken...

Hast Du vollkommen Recht. Das Problem, das ich dabei sehe ist eigentlich der (jedenfalls von mir) verwendete Compiler: Tp 7.0 ist halt dem Wesen nach ein 16-bit compiler und nicht darauf ausgelegt, 32-bit Daten zu verarbeiten. Und 32 bit Code geht auch nur sehr, sehr umständlich (für mich, mangels Know-How, keine Option).

Und FreePascal war auf meinen Rechner (486er der ersten Generation) jedenfalls nicht zu gebrauchen: das Starten der IDE hat 5 Minuten gedauert (486dx40 mit 8 MB Ram) und Abstürze der IDE erfolgten alsbald.

Ein reiner Pascal-Beispiel-Source mit TP 7.0 kompiliert war 15 kb groß, mit Freepascal 1.10 kompiliert 250kb!

Ich weiß nicht, wie es mit FreePascal auf Pentiums aussieht: Aber für die Programmierung von 32 bit hätte ich als Pascal-Fokussierter ein Problem. Deswegen meine Frage: Willst Du bei Pascal bleiben, oder an welchen Compiler denkst Du?