Eigentlich sind die Computer nicht zu langsam. Die Programmierer sind nur faul geworden.
Und natürlich spielt auch Geld eine Rolle. Wenn ein Publisher mehr Geld damit verdienen kann, daß er ein zusammengeschustertes Teil verkauft, das die 10-20fache Rechenleistung/Speicher-etc. verbraucht als nötig wäre und das danach noch 1 Jahr Patches ziehen muß, wird er es trotzdem tun, wenn er dafür (aufgrund der weniger aufwendigen Programmierung) billigere Programmierer und systemfernes Skripting benutzen kann.
Desweiteren kommt hinzu, daß je systemferner etwas programmiert ist, umso weniger performt es (ganz normal, weil Besonderheiten/Stärken/Schwächen einzelner Systeme nicht mehr berücksichtigt werden können) - ABER: Man kann es auf mehr verschiedenen Systemen anbieten ohne zusätzliche Programmierung (da im günstigsten Fall einfach crosscompiliert werden kann).
Daß das Ganze nicht so sehr dem Nutzer, sondern eher dem Publisher nützt, ist bekannt. Denn es bewirkt ja nicht, daß durch die durch die oben erwähnten Dinge gewonnene Ersparnis an Aufwand die Software billiger wird - sondern nur, daß sich die Gewinnspanne des Publishers vergrößert.
Das interessiert aber heutzutage kaum noch jemanden. Muß es ja auch nicht. Wenn es sowieso ALLE machen, ist es ohnehin alternativlos - also nimmt man es hin.
(Oder eben nicht - und dann ist man eben so ein dämlicher kleiner Privatkrauter (wie ich), der sein Zeug selber aus Bits zusammenschraubt und IRGENDWANN mal IRGENDWAS fertigkriegt, was dann VIELLEICHT noch IRGENDWEN interessiert, SEHR WAHRSCHEINLICH aber eher nicht.)
Entscheidung was man für ein Spiel kreieren könnte
Re: Entscheidung was man für ein Spiel kreieren könnte
Das ist wohl das Los eines Indie-Kreativen, dass man Dinge bastelt, die kaum jemanden interessieren.
Da sollte man sich einfach mal für nen Moment die ganze Welt wegdenken und das Zeugs einfach für
sich selber machen. Und wenn man dafür nicht motiviert genug ist, sollte man es vielleicht besser sein lassen.
Wenn man keinen Spass an der Sache hat und nur der Anerkennung bzw. dem "mein Werk ist überall in der
Welt beliebt"-Prinzip entgegenfiebert.
Ich mache z.B. Musik und es ist mir völlig schnurz, ob das ausser mir noch jemand gut findet.
Und wenn sich dann ein paar Leutchen finden, die es gut finden, dann ist das umso besonderer.
Zu der Sache mit dem Unreal-Mode:
Das ist einfach etwas völlig neues für mich.
Eigentlich will ich nur da weitermachen, wo ich vor 15 Jahren Dank Windows aufgehört habe.
Ein Spiel wie "Giana Sisters Twisted Dreams", und ich denke soetwas muss es heute sein
damit das überhaupt wer bemerkt, soetwas kriege ich beim besten Willen nicht hin und
ich will das aber auch überhaupt nicht.
Mein technischer Stand ist 320x200x256, Soundblaster, Real Mode.
Darin fühle ich mich wohl, da bin ich zu Hause.
Gegen Ende meiner "Karriere" hatte ich mir den XMS erschlossen, aber nur mit so ein
paar Routinen die ich nur irgendwo rauskopiert habe, wie eine schnellere Festplatte benutzt,
blockweises Laden von großen Datenmengen in einen Puffer im RAM für die weitere Verwendung.
Ich denke Grafik, wo man die Pixel sehen kann, also sowas wie 320x200, ist
heute verpönt. Dabei möchte ich hier einwerfen, dass Pixelgrafik und hochauflösende
Grafik eigentlich nicht vergleichbar sind. Klar kann man sagen, niedrige Auflösung ist
sch**sse, aber mal anders gesehen birgt pixlige Grafik auch eine ganz andere Ästhetik.
Gutes Beispiel hier, "The Incredible Machine", die hatte ja 640x350 (oder 480?) wenn ich
nicht irre, und da war ich enttäuscht, weil diese gläsern wirkenden Anti-Aliasing-Pixel
und Farbverläufe nicht da waren. Grafisch umgehauen hat mich damals vor allem
Monkey Island II. Alles aus so schönen kleinen durchsichtigen Würfeln zusammengesetzt.
Kann das noch jemand nachvollziehen?
1995 habe ich mein letztes größeres Spieleprojekt abgeschlossen.
Damals noch in QBASIC (aber mit Compiler), und ohne eigene Sprite-Routinen, habe
einfach PUT benutzt, hatte somit keine Transparenz und alles was sich bewegte
musste das auf schwarzem Hintergrund tun, selbstlöschend durch schwarzen Rahmen,
1 Pixel breit. Damit erübrigte sich auch die Sache mit dem Screenbuffering, es gab keins.
Dann meine ich, war man in QBASIC auf 128K beschränkt, 64 für Code, 64 für Daten.
Somit habe ich zu dem Zeitpunkt schon lernen müssen, wie man mit wenig Speicher
auskommt, und beim Umstieg auf Pascal mit theoretisch 640K kam mir das als eine
riesige Erleichterung vor, wie der Umzug aus Studentenwohnung in ein Schloss.
Man kann QBASIC sicher pimpen ohne Ende, aber dann kann man irgendwann
auch einen eigenen Compiler schreiben.
Es hängt davon ab wie ernst mir ein Spieleprojekt wäre. Wenn ich etwas wirklich
großes vor habe, von dem ich denke dass man es auch trotz der Tatsache dass
es DOS ist heute noch spielen wird, dann wäre ich bereit im großen Stil neue
Programmiertechniken zu lernen. Wenn es aber nur so eine kleine Sache aus
Spass an der Freud sein soll, dann reicht mir der Real Mode und meine bisherigen
Kenntnisse, um ein Spiel im reinen 16 Bit Stil zu machen, und das meiste
aus diesem beschränkten Modus rausholen. Und irgendwie brauche ich ja erst
gar nicht versuchen, mit heutigen Spielen mitzuhalten. Warum dann nicht
einfach richtig retro.
Das wird's wohl sein, erst in den 90ern haben sich 32 Bit Rechner erst
langsam durchgesetzt, so wurden Spiele erst ab Mitte der 90er vorwiegend
im Protected Mode oder anderen nicht-Real-Modes entwickelt.
Bis 1993 hatte ich noch einen 286er, darauf lief alles, nur das meiste hinterher zu langsam...
Hab ich noch nie drüber nachgedacht.
Da sollte man sich einfach mal für nen Moment die ganze Welt wegdenken und das Zeugs einfach für
sich selber machen. Und wenn man dafür nicht motiviert genug ist, sollte man es vielleicht besser sein lassen.
Wenn man keinen Spass an der Sache hat und nur der Anerkennung bzw. dem "mein Werk ist überall in der
Welt beliebt"-Prinzip entgegenfiebert.
Ich mache z.B. Musik und es ist mir völlig schnurz, ob das ausser mir noch jemand gut findet.
Und wenn sich dann ein paar Leutchen finden, die es gut finden, dann ist das umso besonderer.
Zu der Sache mit dem Unreal-Mode:
Das ist einfach etwas völlig neues für mich.
Eigentlich will ich nur da weitermachen, wo ich vor 15 Jahren Dank Windows aufgehört habe.
Ein Spiel wie "Giana Sisters Twisted Dreams", und ich denke soetwas muss es heute sein
damit das überhaupt wer bemerkt, soetwas kriege ich beim besten Willen nicht hin und
ich will das aber auch überhaupt nicht.
Mein technischer Stand ist 320x200x256, Soundblaster, Real Mode.
Darin fühle ich mich wohl, da bin ich zu Hause.
Gegen Ende meiner "Karriere" hatte ich mir den XMS erschlossen, aber nur mit so ein
paar Routinen die ich nur irgendwo rauskopiert habe, wie eine schnellere Festplatte benutzt,
blockweises Laden von großen Datenmengen in einen Puffer im RAM für die weitere Verwendung.
Ich denke Grafik, wo man die Pixel sehen kann, also sowas wie 320x200, ist
heute verpönt. Dabei möchte ich hier einwerfen, dass Pixelgrafik und hochauflösende
Grafik eigentlich nicht vergleichbar sind. Klar kann man sagen, niedrige Auflösung ist
sch**sse, aber mal anders gesehen birgt pixlige Grafik auch eine ganz andere Ästhetik.
Gutes Beispiel hier, "The Incredible Machine", die hatte ja 640x350 (oder 480?) wenn ich
nicht irre, und da war ich enttäuscht, weil diese gläsern wirkenden Anti-Aliasing-Pixel
und Farbverläufe nicht da waren. Grafisch umgehauen hat mich damals vor allem
Monkey Island II. Alles aus so schönen kleinen durchsichtigen Würfeln zusammengesetzt.
Kann das noch jemand nachvollziehen?
1995 habe ich mein letztes größeres Spieleprojekt abgeschlossen.
Damals noch in QBASIC (aber mit Compiler), und ohne eigene Sprite-Routinen, habe
einfach PUT benutzt, hatte somit keine Transparenz und alles was sich bewegte
musste das auf schwarzem Hintergrund tun, selbstlöschend durch schwarzen Rahmen,
1 Pixel breit. Damit erübrigte sich auch die Sache mit dem Screenbuffering, es gab keins.
Dann meine ich, war man in QBASIC auf 128K beschränkt, 64 für Code, 64 für Daten.
Somit habe ich zu dem Zeitpunkt schon lernen müssen, wie man mit wenig Speicher
auskommt, und beim Umstieg auf Pascal mit theoretisch 640K kam mir das als eine
riesige Erleichterung vor, wie der Umzug aus Studentenwohnung in ein Schloss.
Man kann QBASIC sicher pimpen ohne Ende, aber dann kann man irgendwann
auch einen eigenen Compiler schreiben.
Es hängt davon ab wie ernst mir ein Spieleprojekt wäre. Wenn ich etwas wirklich
großes vor habe, von dem ich denke dass man es auch trotz der Tatsache dass
es DOS ist heute noch spielen wird, dann wäre ich bereit im großen Stil neue
Programmiertechniken zu lernen. Wenn es aber nur so eine kleine Sache aus
Spass an der Freud sein soll, dann reicht mir der Real Mode und meine bisherigen
Kenntnisse, um ein Spiel im reinen 16 Bit Stil zu machen, und das meiste
aus diesem beschränkten Modus rausholen. Und irgendwie brauche ich ja erst
gar nicht versuchen, mit heutigen Spielen mitzuhalten. Warum dann nicht
einfach richtig retro.
Das wird's wohl sein, erst in den 90ern haben sich 32 Bit Rechner erstlangsam durchgesetzt, so wurden Spiele erst ab Mitte der 90er vorwiegend
im Protected Mode oder anderen nicht-Real-Modes entwickelt.
Bis 1993 hatte ich noch einen 286er, darauf lief alles, nur das meiste hinterher zu langsam...
Hab ich noch nie drüber nachgedacht.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
-
drzeissler
- DOS-Gott
- Beiträge: 3336
- Registriert: Mo 8. Feb 2010, 16:59
Re: Entscheidung was man für ein Spiel kreieren könnte
Richtig schöne Grafik war zumeist 320x200x16. die 256er Modi fand ich gar nicht so toll.
Im direkten Vergleich gefällt mir SQ3 (16F) grafisch besser als MI2 (256F), aber das ist
wie immer Geschmackssache.
Ich finde gerade den 640x350x16 Modus sehr geil (alt EGA), leider gibt es nur ganz wenige
Games dafür (F-16 Falcon Enhanced war in diesem Modus)
Doc
Im direkten Vergleich gefällt mir SQ3 (16F) grafisch besser als MI2 (256F), aber das ist
wie immer Geschmackssache.
Ich finde gerade den 640x350x16 Modus sehr geil (alt EGA), leider gibt es nur ganz wenige
Games dafür (F-16 Falcon Enhanced war in diesem Modus)
Doc
CPU: 486 DX2/66 MOBO: SNI-D882 RAM: 3x16MB - FDD: 3,5" 1,44MB HDD: 6,4GB Seagate ISA(1): Audican32Plus PCI(1): 3com TX 905 OS: MsDos622 - Win95a - WinNT 3.51
Re: Entscheidung was man für ein Spiel kreieren könnte
Es kommt auch darauf an was man programmieren möchte.DOSferatu hat geschrieben:Eigentlich sind die Computer nicht zu langsam.
Bei Spielen wird ja gewöhnlich nur der von vorne sichtbare Teil berechnet, weil der Rechenaufwand sonst schon zu gross wird. Zwar können die GPUs die meiste Arbeit zur Darstellung schon übernehmen und die CPU entlasten, aber selbst die GPUs sind schnell damit überlastet.
Es mag ja sein das bei so einen gescripteten Code in einer virtuellen Umgebung etwas Rechenzeit verloren geht, aber selbt wenn so etwas nur halb so performant wäre, würde ja bestenfalls maximal nur eine Verdopplelung der Geschwindigkeit möglich sein und das reicht bei weitem nicht aus.Die Programmierer sind nur faul geworden.
Zur Berechnung eines einzigen unbewegten Bildes mit POVRAY mit einer Auflösung von 1280x1024 mit 24 Bit Farben haben wir mal einen 80386 zwei Tage lang berechenen lassen bis das Bild dann endlich fertig berechent war. Heute kann man dann so ein Bild wohl schon in ein paar Minuten ausrechnen lassen. Aber eben nur ein einziges unbewegtes Bild und nur der von vorne sichtbare Teil und nichts anderes dazu. 23 Bilder in Echtzeit mit Raytracing zu berechnen überfordert schon unsere Hardware und wenn noch etwas Physikberechnungen hinzu kommt, dann beschränkt die sich doch nur darauf optischen Effekte realistisch aussehen zu lassen, so das der Eindruck vorgetäuscht werden kann es wäre realistisch. Schon alleine die Tatsache das heute die GPU einige Berechnungen für die CPU erledigt zeigt doch schon wie langsam unsere CPUs sind und das die Entwicklung eher stagniert, sonst wären die GPUs, die ja ursprünglich nur zu Berechnung des Bildes entwickelt wurden, nicht dafür geeignet Aufgaben der CPU schneller als die CPU zu berechnen.
Doch hier wird auch nur das Verhältniss zwischen CPU und GPU sichtbar. Nicht aber das beide auch zusammen nicht wirklich schnell sind und eben nur mit Täuschungen gearbeitet werden muss, weil es sonst viel zu langsam wird.
Von einer wissenschaftlichen Simulation physikalischen und biologischer Abläufe in der Natur von nur einem einzigen Quadratmeter Erde mit einigen milliarden dort enthaltenen Microorganismen sind wir noch gewaltige Grössenordnungen weit entfernt, was die Leitunfsfähigkeit unserer Hardware anbelangt. Sie taugt eben nur zum Spielen und zum Vortäuschen und Herumtricksen, oder man muss eben Jahrzente lang warten bis etwas Aufwendigeres fertig berechnet ist.
Mit der Skalierbarkeit mehrerer CPUs die für eine Aufgabe zuammenarbeiten sollen, da stößt man auch sehr schnell an die Grenzen, so dass ab einer gewissen Anzahl von CPUs, eine Leitungssteigerung von weiteren CPUs nicht mehr sonderlich ins Gewicht fällt und dann keinen wirklichen Sinn mehr macht. So bekommen wir auch nicht diese Berechnungen schneller berechnet. Die Grössenordnung an Leistung die uns noch fehlt kann man sich vieleicht bildlich als Unterschied zwischen einem Microorganismuss und einem Dinoraurier von 30 meter Höhe vorstellen. Und da macht es eben kaum einen Unterschied ob wir die Leistung der CPU durch eine performantere Routine in Assembler vordoppeln können, wenn unser Micro-Organismus dadurch immer noch nicht ohne ein Microskop zu sehen ist. Dann ist unser Micro-Organismus eben immer noch mikroskopisch klein und für uns nahezu unsichtbar. Wenn die Entwicklung so langsam wie bisher weiter geht, dann können wir vieleicht noch gefühlte 20.000 Jahre auf wirklich schnell Rechner warten.
Es geht wohl eher nur um die Macht von einigen wenigen Famileinclans. Weil so ein Schuld-Geld kann ja beliebig viel von deren Bänkstern gedruckt, bzw. als reine virtueller Wert verbucht werden und hat sonst eigentlich gar keinen realen Wert. Ausser eben das Vertrauen, das wir diesem Schuld-Geld andichten und beimessen, aber ohne das "Betrugs"-System dahinter zu verstehen, weil wir nur linear denken können und es uns schwer fällt exponentiell zu denken.Und natürlich spielt auch Geld eine Rolle.
Hier sind Videos die unser Schuld-Geldsystem einmal etwas näher erlautern:
Grundprobleme des Geldsystems - Dirk Müller(Mr. Dax) & Prof. Dr. Franz Hörmann (Länge: 13:59):
http://www.youtube.com/watch?v=4CVkQUAp1q0
Andreas Popp - über Geld und und vieles mehr das uns alle betrifft (Länge: 2:08:48):
http://www.youtube.com/watch?v=3A5HSOac5ik
Alternativ der gleiche Beitrag(identische Länge) mit einer anderen Überschrift.
Andreas Popp - Ihr lernt das, was Ihr wissen dürft, und nicht das, was Ihr nicht wissen solltet:
http://www.youtube.com/watch?v=1rvPPxnITzU
Ja genau das sind einige der noch harmloseren Folgen unseres Wirtschafts-Betrugssystems. Auf der anderen Seite verhungern bald schon über eine milliarde an Menschen deswegen. Ich selber finde diese Situation unerträglich und schon lange nicht mehr moralisch vertretbar, es ist grausam, babarisch und diese Worte sind dafür noch gar nicht aussgekräftig genug, um das Ausmass dieser bestialischen Ausprägung gerecht werden zu können.Wenn ein Publisher mehr Geld damit verdienen kann, daß er ein zusammengeschustertes Teil verkauft, das die 10-20fache Rechenleistung/Speicher-etc. verbraucht als nötig wäre und das danach noch 1 Jahr Patches ziehen muß, wird er es trotzdem tun, wenn er dafür (aufgrund der weniger aufwendigen Programmierung) billigere Programmierer und systemfernes Skripting benutzen kann.
Desweiteren kommt hinzu, daß je systemferner etwas programmiert ist, umso weniger performt es (ganz normal, weil Besonderheiten/Stärken/Schwächen einzelner Systeme nicht mehr berücksichtigt werden können) - ABER: Man kann es auf mehr verschiedenen Systemen anbieten ohne zusätzliche Programmierung (da im günstigsten Fall einfach crosscompiliert werden kann).
Daß das Ganze nicht so sehr dem Nutzer, sondern eher dem Publisher nützt, ist bekannt. Denn es bewirkt ja nicht, daß durch die durch die oben erwähnten Dinge gewonnene Ersparnis an Aufwand die Software billiger wird - sondern nur, daß sich die Gewinnspanne des Publishers vergrößert.
Das interessiert aber heutzutage kaum noch jemanden. Muß es ja auch nicht. Wenn es sowieso ALLE machen, ist es ohnehin alternativlos - also nimmt man es hin.
Dann frage ich mich aber ernthaft, wer hier wirklich dämlicher ist. All jene Menschen die diese Treiben erkannt haben und es versuchen mit ihren bescheidenen Mittel sich dagegen zu stellen und dafür auf einem enormen Widerstand stossen, oder jene Menschen die weiterhin die verheerenden Folgen ignorieren und so tun als wenn es sie selber niemals schlimmer treffen könnte und die immer noch von einem Wirtschafts-Wunder träumen.(Oder eben nicht - und dann ist man eben so ein dämlicher kleiner Privatkrauter (wie ich), der sein Zeug selber aus Bits zusammenschraubt und IRGENDWANN mal IRGENDWAS fertigkriegt, was dann VIELLEICHT noch IRGENDWEN interessiert, SEHR WAHRSCHEINLICH aber eher nicht.)
Dirk
Re: Entscheidung was man für ein Spiel kreieren könnte
Ich denke auch das eine Erwartungshaltung eine breite Anerkennung zu finden schon etwas demotivierend sein kann.zatzen hat geschrieben:Das ist wohl das Los eines Indie-Kreativen, dass man Dinge bastelt, die kaum jemanden interessieren.
Da sollte man sich einfach mal für nen Moment die ganze Welt wegdenken und das Zeugs einfach für
sich selber machen. Und wenn man dafür nicht motiviert genug ist, sollte man es vielleicht besser sein lassen.
Wenn man keinen Spass an der Sache hat und nur der Anerkennung bzw. dem "mein Werk ist überall in der
Welt beliebt"-Prinzip entgegenfiebert.
Ich mache z.B. Musik und es ist mir völlig schnurz, ob das ausser mir noch jemand gut findet.
Und wenn sich dann ein paar Leutchen finden, die es gut finden, dann ist das umso besonderer.
Ich meine der Unreal-Mode unterscheidet sich kaum von RM, wenn man für seine RM-Anwendung auch schon 32 Bit-Register und einen 80386 verwendet hat. Nur das der Adressraum im Unreal-Mode für unsere Daten grösser geworden ist und wir nun damit 32 Bit Adressen für unsere Daten verwenden können und damit zusätzlich der linare Framebuffer auch unter DOS verwendet werden kann.Zu der Sache mit dem Unreal-Mode:
Das ist einfach etwas völlig neues für mich.
Eigentlich will ich nur da weitermachen, wo ich vor 15 Jahren Dank Windows aufgehört habe.
Ok.Ein Spiel wie "Giana Sisters Twisted Dreams", und ich denke soetwas muss es heute sein
damit das überhaupt wer bemerkt, soetwas kriege ich beim besten Willen nicht hin und
ich will das aber auch überhaupt nicht.
Auf meinen 28" LCD mit nativer Auflösung in 1920x1200 wird ein Videomode von 320x200 aber leider nur interpoliert und relativ unscharf und verwaschen angezeigt und das sieht dann auf einem 14" CRT einfach noch besser aus.Mein technischer Stand ist 320x200x256, Soundblaster, Real Mode.
Darin fühle ich mich wohl, da bin ich zu Hause.
Gegen Ende meiner "Karriere" hatte ich mir den XMS erschlossen, aber nur mit so ein
paar Routinen die ich nur irgendwo rauskopiert habe, wie eine schnellere Festplatte benutzt,
blockweises Laden von großen Datenmengen in einen Puffer im RAM für die weitere Verwendung.
Ich denke Grafik, wo man die Pixel sehen kann, also sowas wie 320x200, ist
heute verpönt. Dabei möchte ich hier einwerfen, dass Pixelgrafik und hochauflösende
Grafik eigentlich nicht vergleichbar sind. Klar kann man sagen, niedrige Auflösung ist
sch**sse, aber mal anders gesehen birgt pixlige Grafik auch eine ganz andere Ästhetik.
Aus diesem Grund empfielt es sich immer nur die native Auflösung eines verwendeten LCDs zu verwenden.
Na klar, solche vergleichbaren Erlebnisse kenne ich auch.Gutes Beispiel hier, "The Incredible Machine", die hatte ja 640x350 (oder 480?) wenn ich
nicht irre, und da war ich enttäuscht, weil diese gläsern wirkenden Anti-Aliasing-Pixel
und Farbverläufe nicht da waren. Grafisch umgehauen hat mich damals vor allem
Monkey Island II. Alles aus so schönen kleinen durchsichtigen Würfeln zusammengesetzt.
Kann das noch jemand nachvollziehen?
Aber was ich damals noch als berauschend schön empfand, das sieht heute für mich ziemlich schlicht aus, so das ich heute es gar nicht mehr so empfinden kann wie damals noch.
Ich habe mich mit 16 Bit nicht sehr lange aufgehalten und bin von einem 80286 ziemlich schnell auf einem 80386 ungestiegen und habe dann auch 32 Bit-Register gleich mit unter DOS verwendet.1995 habe ich mein letztes größeres Spieleprojekt abgeschlossen.
Damals noch in QBASIC (aber mit Compiler), und ohne eigene Sprite-Routinen, habe
einfach PUT benutzt, hatte somit keine Transparenz und alles was sich bewegte
musste das auf schwarzem Hintergrund tun, selbstlöschend durch schwarzen Rahmen,
1 Pixel breit. Damit erübrigte sich auch die Sache mit dem Screenbuffering, es gab keins.
Dann meine ich, war man in QBASIC auf 128K beschränkt, 64 für Code, 64 für Daten.
Somit habe ich zu dem Zeitpunkt schon lernen müssen, wie man mit wenig Speicher
auskommt, und beim Umstieg auf Pascal mit theoretisch 640K kam mir das als eine
riesige Erleichterung vor, wie der Umzug aus Studentenwohnung in ein Schloss.
Man kann QBASIC sicher pimpen ohne Ende, aber dann kann man irgendwann
auch einen eigenen Compiler schreiben.
Es hängt davon ab wie ernst mir ein Spieleprojekt wäre. Wenn ich etwas wirklich
großes vor habe, von dem ich denke dass man es auch trotz der Tatsache dass
es DOS ist heute noch spielen wird, dann wäre ich bereit im großen Stil neue
Programmiertechniken zu lernen. Wenn es aber nur so eine kleine Sache aus
Spass an der Freud sein soll, dann reicht mir der Real Mode und meine bisherigen
Kenntnisse, um ein Spiel im reinen 16 Bit Stil zu machen, und das meiste
aus diesem beschränkten Modus rausholen.
Ich habe auch sehr schnell erkannt das ich da nicht mithalten kann, weil der Umfang einfach zu gross wird und noch bevor man etwas gelernt hat, es schon wieder von neueren Entwicklungen abgelöst wurde und viele Dinge die man lernen kann einfach zu kurzlebig sind und dann nahezu wieder bedeutungslos werden.Und irgendwie brauche ich ja erst
gar nicht versuchen, mit heutigen Spielen mitzuhalten.
Weil mir Monitore die kleiner als 28 zoll gross sind schon zu klein geworden sind und ich mich nicht mal mehr an einen 24"er LCD richtig gewöhnen könnte. Nächstes Mal werde ich wohl eine noch grössere Bildfläche brauchen und dann wohl aus kostengründen vieleicht einen grossen TV-Bildschirm als Monitor-Ersatz. Aber auch weil noch grössere Monitore noch viel höhere Auflösungen mitbringen und für solche hohen Auflösungen(wie 2560x2048) dann wieder CPU+GPU nicht leistungsfähig genug sind, um spielbaren Framrate zu berechnen und solche hohen Auflösungen von älteren Spielen auch nicht angeboten werden, womit dann wieder interpoliert werden muss, was man auf jeden Fall vermeiden möchte.Warum dann nicht einfach richtig retro.
Bei älteren Spielen kann man schon froh sein, mit einem Patch eine Auflösung von 1920x1200 zum Spielen zu bekommen.
Oft ist nur 1600x1200(4:3) möglich, aber kein Widescreen in 1920x1200(16:10), oder in 1920x1080(16:9).
Einen 286er hatte ich damals nur wenige Monate lang zusammen mit MSDOS 5 verwendet.
langsam durchgesetzt, so wurden Spiele erst ab Mitte der 90er vorwiegend
im Protected Mode oder anderen nicht-Real-Modes entwickelt.
Bis 1993 hatte ich noch einen 286er, darauf lief alles, nur das meiste hinterher zu langsam...
Hab ich noch nie drüber nachgedacht.
Dort habe ich aber nur mit debug und assembler herumexperimentiert, um den Umstieg vom C64er zum PC aus Sicht der CPU und der PC-Speicherlanschaft kennen zu lernen. Besonders oft habe ich nie DOS-Spiele gespielt, auch später nicht. Erst als Windows 98 rauskam habe ich auch mal Windows-Spiele ausprobiert.
Dirk
Re: Entscheidung was man für ein Spiel kreieren könnte
Das liegt vermutlich daran, das bei Grafik-Modi mit 4 Bit-Farben für jeden Pixel ein Portzugriff nötig ist und Portzugriffe realtiv langsam sind und alle anderen Grafik-Modi mit 8 Bit und mehr Farben sind auch viel einfacher zu verwenden.drzeissler hat geschrieben: Ich finde gerade den 640x350x16 Modus sehr geil (alt EGA), leider gibt es nur ganz wenige
Games dafür (F-16 Falcon Enhanced war in diesem Modus)
Es ist aber auch damit möglich auf Farben zu verzichten, wenn man es möchte und dann wird man wohl keinen Unterschied mehr sehen können, wenn es sonst bei der gleichen horizontalen und vertikalen Auflöung und Anzal der Pixel bleibt.
Dirk
Re: Entscheidung was man für ein Spiel kreieren könnte
Hmm, ich will ja auch das mit dem Unreal Mode nicht strikt von mir weisen.
Assembler hab ich, bis auf wenige Ausnahmen pur, bisher nur innerhalb BP70 verwendet.
Ist schon 15 Jahre her dass ich sowas gemacht habe, daher weiss ich gar nicht mehr genau
ob der ASM in Pascal auch 32 Bit erlaubt, ohne dass es kryptisch wird.
Also, wenn es keine großen Umstände macht, würde ich mir das mal ansehen,
ansonsten hab ich aber eigentlich auch keinen Bedarf mehr an zeitgemäßen
Speicherkapazitäten, seit ich mir klar gemacht hab dass es witzlos ist, heute
noch etwas DOS-mäßiges in großem Stil zu programmieren.
Die Geschwindigkeitsvorteile im Unreal könnten hilfreich sein, aber wenn ich auch so
klarkomme wäre der Realmode schlüssiger, in Anbetracht sparsam abgelegter
Daten. Sonst ist das wie einen Einkaufskorb im sonst leeren LKW zu transportieren,
wo auch ein Fahrrad genügen würde.
Lieber lade ich run-length 4 Bit Sprites und Trackermusik rein, als BMP's und MP3.
Macht sonst keinen Spass, ein bisschen technische Frickelei muss sein.
Assembler hab ich, bis auf wenige Ausnahmen pur, bisher nur innerhalb BP70 verwendet.
Ist schon 15 Jahre her dass ich sowas gemacht habe, daher weiss ich gar nicht mehr genau
ob der ASM in Pascal auch 32 Bit erlaubt, ohne dass es kryptisch wird.
Also, wenn es keine großen Umstände macht, würde ich mir das mal ansehen,
ansonsten hab ich aber eigentlich auch keinen Bedarf mehr an zeitgemäßen
Speicherkapazitäten, seit ich mir klar gemacht hab dass es witzlos ist, heute
noch etwas DOS-mäßiges in großem Stil zu programmieren.
Die Geschwindigkeitsvorteile im Unreal könnten hilfreich sein, aber wenn ich auch so
klarkomme wäre der Realmode schlüssiger, in Anbetracht sparsam abgelegter
Daten. Sonst ist das wie einen Einkaufskorb im sonst leeren LKW zu transportieren,
wo auch ein Fahrrad genügen würde.
Lieber lade ich run-length 4 Bit Sprites und Trackermusik rein, als BMP's und MP3.
Macht sonst keinen Spass, ein bisschen technische Frickelei muss sein.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Entscheidung was man für ein Spiel kreieren könnte
Ich zitiere mich an dieser Stelle einmal selbst:
Das interessiert aber heutzutage kaum noch jemanden. Muß es ja auch nicht. Wenn es sowieso ALLE machen, ist es ohnehin alternativlos - also nimmt man es hin.
(Oder eben nicht - und dann ist man eben so ein dämlicher kleiner Privatkrauter (wie ich), der sein Zeug selber aus Bits zusammenschraubt und IRGENDWANN mal IRGENDWAS fertigkriegt, was dann VIELLEICHT noch IRGENDWEN interessiert, SEHR WAHRSCHEINLICH aber eher nicht.)
Mit diesem Abschnitt wollte ich NICHT ausdrücken, daß es mir darauf ankäme, daß das was ich tue - oder was man als kleiner Krauter tut - irgendjemanden interessieren muß oder daß ich (oder jemand) es der Anerkennung wegen tut oder tun sollte.
Ich mache das Ganze nur für mich selbst - weil es ein Hobby ist und mir Spaß macht und die "neuen" Sachen, die mit Computern gemacht werden, reizen mich eben nicht mehr so sehr. Ich habe mit Computern damals angefangen, WEIL mich direkte, systemnahe Programmierung und "das ganze Mathezeug" so interessiert haben - und weil es mir immer um die Programmierung an sich ging. (Der "der Weg ist das Ziel" Effekt.)
Falls es andere Leute interessiert / anderen Leuten gefällt, was ich so bastle, ist das zwar nett. Aber das war es dann auch schon. Ich will kein Geld und keine sonstige Beweihräucherung dafür haben - und ich bin mir dessen bewußt, daß die durch die heutigen schnellen Computer und exorbitanten Grafikfähigkeiten moderner Grafikkarten und damit produzierte Grafikblender-Spiele verwöhnten Computernutzer den Kram, den ICH so herstelle, nicht mehr richtig ernstnehmen können. Und sie brauchen auch nicht so zu tun, nur weil sie wissen, wieviel Mühe ich in den Kram reinstecke, den ich mache. Wenn sie es Mist finden, ist es völlig OK, wenn sie das auch genau so sagen. Ich erwarte dafür keinen "Retro-Bonus" oder "Selbstgemacht-Bonus" oder ähnliches. Ein Scheißspiel ist auch dann Scheiße, wenn es von jemandem gemacht wurde, den man persönlich kennt...
Das einzige, was ich erwarte (und auch meine, erwarten zu dürfen), ist, daß man mich nicht damit nerven soll, "moderne" Programmiermethoden, "moderne" Systeme und "moderne" Konzepte zu benutzen, weil das ja "Stand der Dinge" ist. Diese Dinge finde ich uninteressant, sie machen mir keinen Spaß und als Hobby und in meiner Freizeit will ich keine Dinge machen, die mir keinen Spaß machen, nur damit ich für irgendjemanden ein "moderner Computerfreak" bin...
Das interessiert aber heutzutage kaum noch jemanden. Muß es ja auch nicht. Wenn es sowieso ALLE machen, ist es ohnehin alternativlos - also nimmt man es hin.
(Oder eben nicht - und dann ist man eben so ein dämlicher kleiner Privatkrauter (wie ich), der sein Zeug selber aus Bits zusammenschraubt und IRGENDWANN mal IRGENDWAS fertigkriegt, was dann VIELLEICHT noch IRGENDWEN interessiert, SEHR WAHRSCHEINLICH aber eher nicht.)
Mit diesem Abschnitt wollte ich NICHT ausdrücken, daß es mir darauf ankäme, daß das was ich tue - oder was man als kleiner Krauter tut - irgendjemanden interessieren muß oder daß ich (oder jemand) es der Anerkennung wegen tut oder tun sollte.
Ich mache das Ganze nur für mich selbst - weil es ein Hobby ist und mir Spaß macht und die "neuen" Sachen, die mit Computern gemacht werden, reizen mich eben nicht mehr so sehr. Ich habe mit Computern damals angefangen, WEIL mich direkte, systemnahe Programmierung und "das ganze Mathezeug" so interessiert haben - und weil es mir immer um die Programmierung an sich ging. (Der "der Weg ist das Ziel" Effekt.)
Falls es andere Leute interessiert / anderen Leuten gefällt, was ich so bastle, ist das zwar nett. Aber das war es dann auch schon. Ich will kein Geld und keine sonstige Beweihräucherung dafür haben - und ich bin mir dessen bewußt, daß die durch die heutigen schnellen Computer und exorbitanten Grafikfähigkeiten moderner Grafikkarten und damit produzierte Grafikblender-Spiele verwöhnten Computernutzer den Kram, den ICH so herstelle, nicht mehr richtig ernstnehmen können. Und sie brauchen auch nicht so zu tun, nur weil sie wissen, wieviel Mühe ich in den Kram reinstecke, den ich mache. Wenn sie es Mist finden, ist es völlig OK, wenn sie das auch genau so sagen. Ich erwarte dafür keinen "Retro-Bonus" oder "Selbstgemacht-Bonus" oder ähnliches. Ein Scheißspiel ist auch dann Scheiße, wenn es von jemandem gemacht wurde, den man persönlich kennt...
Das einzige, was ich erwarte (und auch meine, erwarten zu dürfen), ist, daß man mich nicht damit nerven soll, "moderne" Programmiermethoden, "moderne" Systeme und "moderne" Konzepte zu benutzen, weil das ja "Stand der Dinge" ist. Diese Dinge finde ich uninteressant, sie machen mir keinen Spaß und als Hobby und in meiner Freizeit will ich keine Dinge machen, die mir keinen Spaß machen, nur damit ich für irgendjemanden ein "moderner Computerfreak" bin...
Re: Entscheidung was man für ein Spiel kreieren könnte
Kleine Zusatzinfo: Mein 2D-Spieleditor ist mittlerweile so gut wie fertig. Es sind noch einige Schönheitsfehler und Bugs zu beseitigen. VIelleicht optimiere ich hier und da noch etwas, um Speicher zu sparen (damit umso mehr Speicher für die erstellten Daten zur Verfügung steht - also für den Nutzer). Und ich habe die englische Hilfe so ca. zu 70% fertig geschrieben, und die deutsche zu vielleicht 3%. (Das ganze DIng erhält eine zweisprachige Hilfe.) und die muß ich noch vervollständigen - es ist immerhin ein unfangreiches Tool, und einige Dinge der Bedienung sollten dann schon erklärt werden.
Re: Entscheidung was man für ein Spiel kreieren könnte
Grafik-Blendung fängt ja schon bei sowas wie Flash an. Da gibt es eine Hülle und Fülle von online-Spielen,
und jedes einzelne stellt jedes DOS-Spiel Grafik-technisch (technisch zumindest!) in den Schatten.
"Smoothe" Grafiken im Comic Stil, perfekt fliessend animiert.
Sowas kann mir auch gut gefallen.
Aber irgendwie komme ich immer noch auf die "guten alten" DOS Klassiker zurück, oder auch
Amiga, die beiden waren ja in den 90ern irgendwann vergleichbar.
Wenn ich mir auf Youtube so ein "Let's Play" ansehe, dann ist das meistens ein DOS oder
Amiga Spiel. Oder Nintendo, vielleicht auch mal C64.
Irgendetwas müssen diese verstaubten Dinger also an sich haben, was sie zumindest für mich
attraktiver macht als moderner Kram.
Vielleicht ist es der allgemeine Zeitgeist, bei Musik geht mir das nämlich auch so, seitdem
die Mitter der 90er überschritten ist gab es für mich kaum noch neue interessante Musik
"auf dem Markt".
Es ist auch eine verrückte Zeit dank Internet. Meine Güte, mit 9 hatten wir den ersten PC
mit einer Handvoll spielen drauf. Ich habe ALLES gespielt als Kind. Was wäre jetzt gewesen
wenn ich in Zeiten von Internet geboren worden wäre mit täglichem Sofortzugriff auf
millionen Spiele??
Eigentlich was solls. Ich weiss doch was ich will. Ich stelle mir die Herausforderung, ein
Spiel das Spass macht zu spielen (nach meinem Empfinden) im Real Mode umzusetzen.
Wenn es dann irgendwie zu langsam wird kann ichs ja noch umschreiben für Unreal.
Vielleicht würden sich hier einige freuen wenn ich eines Tages mit ner Beta Version
von nem eigenen Spiel hier ankomme. Egal ob ich da jetzt 640 KB oder 4 MB oder wieviel Speicher habe.
So, mal eine Überlegung, was hat mich überhaupt motiviert, ein eigenes Trackerformat zu "erfinden",
was ausser mir wohl keiner verwenden will...
Es hängt damit zusammen dass ich eigentlich selten programmiere. Und wenn ich es dann doch mal
tue, so als Nebenhobby, dann will ich nach Möglichkeit auch den ganzen Code selber geschrieben haben.
Was anderes wäre das, wenn ich mit jemandem zusammenarbeite, wenn es Teamarbeit ist, und
das Ziel viel mehr wiegt als der Weg, wenn einem am Ende die Programmiererfahrung egal ist,
man am Ende nicht weiss woraus das Ding jetzt überhaupt im Detail besteht, Hauptsache die
Idee ist realisiert.
Okay, aber wenn ich etwas ganz alleine mache dann will ich den Überblick.
Ich neige sogar dazu, eigene TPUs von mir selbst nicht zu verwenden, wenn
ich nicht mehr weiss wie sie funktionieren.
Mit dem eigenen Trackerformat verhält es sich so, dass ich zurückblickend sagen kann,
ich verwende sehr selten Vibrato, Arpeggio usw. , im Prinzip nur Lautstärkebefehle
und ab und zu Tonhöhenänderungen ohne das Sample von vorn zu spielen.
Daher will ich für die Player-Routine nicht 80% Code reinpacken der sowieso nie
zum Einsatz kommt. Entsprechend einfacher kann das Format gehalten werden, das
ermöglicht kleinere Patterndaten, die Samples mache ich auf 4 Bit mit blockweiser
Skalierung auf 8 Bit, somit rückt zumindest das Speicherproblem bei moderaten Ansprüchen
in den Hintergrund.
Man hat mich schon mehrmals gescholten ich würde das Rad neu erfinden wollen.
Mit anderen Worten, ich soll mir doch lieber bei anderen abgucken wie man etwas macht.
Das mache ich aber nicht so gerne, weil man dabei diese Sache die man abguckt nicht
so gut verstehen lernt, als wenn man selber drauf gekommen ist!
Also:
Ich mache nicht so gerne Lernsprünge, bin ein Autodidakt der seinen Weg gehen muss.
Ökomisch, "professionell" programmieren nach aller Vernunft und Zeitgeist: Ohne mich, das können andere besser...
1998 Wurde ich ungeduldig, da habe ich irgendwo auf einer Programmierer-CDROM Routinen für das Kopieren
in und aus dem XMS gefunden, einfach in meine Programme rein, dekadente unkomprimierte Datenmengen,
8 MB waren ja reichlich. Dabei sind aber auch nur ein paar Spassprojekte rausgekommen. Irgendwie kann
man mit so einer Haltung, mit so einer "aufgesetzten" Erweiterung, nicht ernsthaft bei der Sache bleiben.
Warum muss ich jetzt nur an Windows Programmierung denken...
Mir war es schon zuwider, fertige TPUs zum abspielen von MODs zu verwenden, ich baue nicht gerne
Code in meine Programme ein, zu dem ich erst die Anleitung lesen muss, und von dem ich 90% eigentlich
gar nicht brauche.
und jedes einzelne stellt jedes DOS-Spiel Grafik-technisch (technisch zumindest!) in den Schatten.
"Smoothe" Grafiken im Comic Stil, perfekt fliessend animiert.
Sowas kann mir auch gut gefallen.
Aber irgendwie komme ich immer noch auf die "guten alten" DOS Klassiker zurück, oder auch
Amiga, die beiden waren ja in den 90ern irgendwann vergleichbar.
Wenn ich mir auf Youtube so ein "Let's Play" ansehe, dann ist das meistens ein DOS oder
Amiga Spiel. Oder Nintendo, vielleicht auch mal C64.
Irgendetwas müssen diese verstaubten Dinger also an sich haben, was sie zumindest für mich
attraktiver macht als moderner Kram.
Vielleicht ist es der allgemeine Zeitgeist, bei Musik geht mir das nämlich auch so, seitdem
die Mitter der 90er überschritten ist gab es für mich kaum noch neue interessante Musik
"auf dem Markt".
Es ist auch eine verrückte Zeit dank Internet. Meine Güte, mit 9 hatten wir den ersten PC
mit einer Handvoll spielen drauf. Ich habe ALLES gespielt als Kind. Was wäre jetzt gewesen
wenn ich in Zeiten von Internet geboren worden wäre mit täglichem Sofortzugriff auf
millionen Spiele??
Eigentlich was solls. Ich weiss doch was ich will. Ich stelle mir die Herausforderung, ein
Spiel das Spass macht zu spielen (nach meinem Empfinden) im Real Mode umzusetzen.
Wenn es dann irgendwie zu langsam wird kann ichs ja noch umschreiben für Unreal.
Vielleicht würden sich hier einige freuen wenn ich eines Tages mit ner Beta Version
von nem eigenen Spiel hier ankomme. Egal ob ich da jetzt 640 KB oder 4 MB oder wieviel Speicher habe.
So, mal eine Überlegung, was hat mich überhaupt motiviert, ein eigenes Trackerformat zu "erfinden",
was ausser mir wohl keiner verwenden will...
Es hängt damit zusammen dass ich eigentlich selten programmiere. Und wenn ich es dann doch mal
tue, so als Nebenhobby, dann will ich nach Möglichkeit auch den ganzen Code selber geschrieben haben.
Was anderes wäre das, wenn ich mit jemandem zusammenarbeite, wenn es Teamarbeit ist, und
das Ziel viel mehr wiegt als der Weg, wenn einem am Ende die Programmiererfahrung egal ist,
man am Ende nicht weiss woraus das Ding jetzt überhaupt im Detail besteht, Hauptsache die
Idee ist realisiert.
Okay, aber wenn ich etwas ganz alleine mache dann will ich den Überblick.
Ich neige sogar dazu, eigene TPUs von mir selbst nicht zu verwenden, wenn
ich nicht mehr weiss wie sie funktionieren.
Mit dem eigenen Trackerformat verhält es sich so, dass ich zurückblickend sagen kann,
ich verwende sehr selten Vibrato, Arpeggio usw. , im Prinzip nur Lautstärkebefehle
und ab und zu Tonhöhenänderungen ohne das Sample von vorn zu spielen.
Daher will ich für die Player-Routine nicht 80% Code reinpacken der sowieso nie
zum Einsatz kommt. Entsprechend einfacher kann das Format gehalten werden, das
ermöglicht kleinere Patterndaten, die Samples mache ich auf 4 Bit mit blockweiser
Skalierung auf 8 Bit, somit rückt zumindest das Speicherproblem bei moderaten Ansprüchen
in den Hintergrund.
Man hat mich schon mehrmals gescholten ich würde das Rad neu erfinden wollen.
Mit anderen Worten, ich soll mir doch lieber bei anderen abgucken wie man etwas macht.
Das mache ich aber nicht so gerne, weil man dabei diese Sache die man abguckt nicht
so gut verstehen lernt, als wenn man selber drauf gekommen ist!
Also:
Ich mache nicht so gerne Lernsprünge, bin ein Autodidakt der seinen Weg gehen muss.
Ökomisch, "professionell" programmieren nach aller Vernunft und Zeitgeist: Ohne mich, das können andere besser...
1998 Wurde ich ungeduldig, da habe ich irgendwo auf einer Programmierer-CDROM Routinen für das Kopieren
in und aus dem XMS gefunden, einfach in meine Programme rein, dekadente unkomprimierte Datenmengen,
8 MB waren ja reichlich. Dabei sind aber auch nur ein paar Spassprojekte rausgekommen. Irgendwie kann
man mit so einer Haltung, mit so einer "aufgesetzten" Erweiterung, nicht ernsthaft bei der Sache bleiben.
Warum muss ich jetzt nur an Windows Programmierung denken...
Mir war es schon zuwider, fertige TPUs zum abspielen von MODs zu verwenden, ich baue nicht gerne
Code in meine Programme ein, zu dem ich erst die Anleitung lesen muss, und von dem ich 90% eigentlich
gar nicht brauche.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Entscheidung was man für ein Spiel kreieren könnte
Zum Umschalten in den Unrealmode habe ich hier eine Subroutine dafür.zatzen hat geschrieben:Hmm, ich will ja auch das mit dem Unreal Mode nicht strikt von mir weisen.
Assembler hab ich, bis auf wenige Ausnahmen pur, bisher nur innerhalb BP70 verwendet.
Ist schon 15 Jahre her dass ich sowas gemacht habe, daher weiss ich gar nicht mehr genau
ob der ASM in Pascal auch 32 Bit erlaubt, ohne dass es kryptisch wird.
Also, wenn es keine großen Umstände macht, würde ich mir das mal ansehen,
ansonsten hab ich aber eigentlich auch keinen Bedarf mehr an zeitgemäßen
Speicherkapazitäten, seit ich mir klar gemacht hab dass es witzlos ist, heute
noch etwas DOS-mäßiges in großem Stil zu programmieren.
Aber noch bevor diese Sub-Routine(ESEG) mit einen call-Befehl aufgerufen wird müssen vorher die Interrupts deaktiviert werden und danach wieder aktiviert werden.
Danach folgt eine GDT und dann die Subroutine.
Code: Alles auswählen
cli ; Software-Interrupts ausschalten
in al, 70h ; Über CMOS-Baustein auch
or al, 80h ; die NMIS abschalten
out 70h, al
in al, 71h
call ESEG ; Unrealmode einschalten
in al, 70h ; NMIs wieder einschalten
and al, 7Fh
out 70h, al
in al, 71h
sti ; Software-Interrupts einschalten
; Nun sind wir im Unrealmode und an dieser Stelle kann ein Zugriff auf den oberen Speicherbereich erfolgen.
;────────────────────────────────────────────────────────────────────────────
; GDT für den Protected Mode
;────────────────────────────────────────────────────────────────────────────
GDTZEIGER DW ? ; Länge der GDT
DW ? ; Adresse low -Word:SEGMENTE
DW ? ; Adresse high-Word:SEGMENTE
DW 0 ; reserviert
SEGMENTE DW 0 ; Bits: 0-15 Seg.länge(Bit0-15)
DW 0 ; Bits: 0-15 Basis-Adresse Deskriptor-Table
DB 0 ; Bits:16-23 Basis-Adresse Deskriptor-Table
DB 0 ; Bits: 0- 7 Zugriffsrechte
DB 0 ; Bits: 0- 3 Seg.länge(Bit16-19)/Bit7:1=4KByte/0=1Byte
DB 0 ; Bits:24-31 Basis-Adresse Deskriptor-Table
;-------------------------------------------- Selektor Segmente
DW 0FFFFh ; Segmentlänge Bits: 0-15 ┬──────┬ ┬─────────┬
DW 0 ; Adresse low Bits: 0-15 │ 08h │ │Code (CS)│
DB 0 ; Adresse high Bits:16-23 └──────┘ └─────────┘
DB 9Ah ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Seg.Adresse Bits:24-31
;--------------------------------------------- Selektor Segmente
DW 0FFFFh ; Segmentlänge Bits: 0-15 ┬──────┬ ┬──────────┬
DW 0 ; Adresse low Bits: 0-15 │ 10h │ │Stack (SS)│
DB 0 ; Adresse high Bits:16-23 └──────┘ └──────────┘
DB 92h ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Seg.Adresse Bits:24-31
;--------------------------------------------- Selektor Segmente
DW 0FFFFh ; Segmentlänge Bits: 0-15 ┬──────┬ ┬─────────────┬
DW 0 ; Seg.Adresse Bits: 0-15 │ 18h │ │(DS,ES,FS,GS)│
DB 0 ; Seg.Adresse Bits:16-23 └──────┘ └─────────────┘
DB 92h ; Zugriffsrechte
DB 0FFh ; Seg.Länge Bits:16-19 im Bit0-3//Bit7:1=4KByte/0=1Byte
DB 0FFh ; Seg.Adresse Bits:24-31
;---------------------------------------------------
SEGMENTE_END label WORD
Gdt_Groesse equ (OFFSET SEGMENTE_END - SEGMENTE -1)
;────────────────────────────────────────────────────────────────────────────
; Setzt für das DS(,ES,FS,GS)-Register eine neue Segmentlänge von 00FFFFFFh.
; Dazu wird in den Protected Mode umgeschaltet.
;────────────────────────────────────────────────────────────────────────────
ESEG: xor eax, eax
mov ax, cs
mov ds, ax
shl eax, 4 ; EAX ist nun physikalische
mov ebx, eax ; Segmentstartadresse
mov WORD PTR[SEGMENTE+0Ah], ax ; in den Deskriptoren
mov WORD PTR[SEGMENTE+12h], ax ; für CS
ror eax, 10h ; und SS in der
mov BYTE PTR[SEGMENTE+0Ch], al ; GDT abspeichern
mov BYTE PTR[SEGMENTE+14h], al
xor eax, eax ; EAX auf null
mov ax, OFFSET SEGMENTE ; 16-Bit-Offset
add ebx, eax ; GDT-Adresse im
mov WORD PTR[GDTZEIGER], Gdt_Groesse ; GDT-Deskriptor
mov DWORD PTR[GDTZEIGER+2], ebx
pushf ; Flags retten
lgdt FWORD PTR[GDTZEIGER] ; GDT laden
mov dx, ss ; SS retten
mov eax, cr0 ; Steuerwort 0 nach EAX
or al, 1 ; Protected Mode ein
mov cr0, eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; die folgenden Zeilen
DW (OFFSET PMODE) ; erzeugen:
DW 8 ; JMP FAR CS:PMODE
;------------------------------------------------
PMODE: mov ax, 10h ; SS-Selektor auf 64
mov ss, ax ; KByte begrenzen
mov ax, 18h
mov ds, ax ; DS,ES,FS,GS-Selektoren erweitern
; mov es, ax
; mov fs, ax
; mov gs, ax
mov eax, cr0 ; Steuerwort 0 nach EAX
and eax, not 1 ; Protected Mode aus
mov cr0, eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; Die folgenden Zeilen er-
DW (OFFSET RMODE) ; zeugen das Kommando
AKTSEG DW (SEG RMODE) ; JMP FAR CS:RMODE
;------------------------------------------------
RMODE: mov ss, dx ; SS zurueck
popf ; Flags holen
;----------------------------------------------------------------------------
; Schaltet das 21. Adreßbit des Prozessors ein.
;----------------------------------------------------------------------------
BIT_FREI: call W_8042 ; Warte auf 8042
jnz BACK
mov al, 0D1h ; Kommando schreiben
out 64h, al
call W_8042 ; fertig zum Emnpfang ?
jnz BACK
mov al, 0DFh ; ja,Leitung 20 freischalten
out 60h, al
;------------------------------------------------------------
; Wartet darauf, bis der 8042 bereit ist.
;------------------------------------------------------------
W_8042: xor cx, cx ; CX=0
STATUS: in al, 64h ; Status lesen
and al, 2 ; Puffer voll ?
loopnz STATUS ; bis nein oder Timeout
BACK: ret
Wenn man auch die anderen Segmentregister erweitern möchte, dann muss man einfach die Semikolons vor diesen Befehlen entfernen.
; mov es, ax
; mov fs, ax
; mov gs, ax
Dirk
Re: Entscheidung was man für ein Spiel kreieren könnte
Gruß,
zum Unreal Mode:
Was ist mit Memmorymanagern (EMM386)?, funktioniert das zusammen mit dem V86 Modus?
Wie kann ich die Speicherbelegung ermitteln (um z.b. den Festplattencache nicht zu überschreiben)?
zum Unreal Mode:
Was ist mit Memmorymanagern (EMM386)?, funktioniert das zusammen mit dem V86 Modus?
Wie kann ich die Speicherbelegung ermitteln (um z.b. den Festplattencache nicht zu überschreiben)?
Re: Entscheidung was man für ein Spiel kreieren könnte
Das Problem ist, daß der Unreal Mode allgemein NICHT zusammen mit dem V86-Mode funktioniert.
(Das war für mich bisher einer der Hauptgründe, auf den Unreal Mode zu verzichten.)
Der Grund dafür ist, daß man, um in den "Unreal" zu schalten, ja kurz den PM anschalten muß und gewisse Modifikationen machen muß, die nur im IOPL=0 (Input/Output-Privilege Level 0 / "Ring" 0) möglich sind, aber wenn der V86 aktiv ist, steht die CPU bereits auf IOPL=3. Ein IOPL hat umso höhere Priorität, je niedriger seine Nummer ist (0 bis 3, da 2 Bits in FLAGS Register dafür genutzt werden). Man kann aus einem IOPL mit niedrigerer Priorität nichts machen, was höhere erfordert (nur umgekehrt). Daher (und wegen anderer Dinge) heißt es auch Protected Mode - wegen dieser ganzen Schutzfunktionen.
OK, das ganze ist vielleicht nicht GANZ richtig: Man KANN noch aus dem V86 in den PM wechseln - schließlich tun es "DOS-Extender" wie DOS4GW und PMODE (von TRAN) ja auch. Aber ich glaube, da muß eine Menge beachtet werden, um die bereits vorher in V86-Mode genutzten Dinge nicht abzuschießen - bzw es könnte sein, daß diese dann im PM nicht nutzbar sind...
Auf jeden Fall ist meine Info, daß V86 und Unrealmode nicht zusammen funktionieren - was auch der Grund ist, wieso für manche Demos/Spiele immer mit einer extra Config gebootet werden mußte, ohne EMM386 usw.
(Das war für mich bisher einer der Hauptgründe, auf den Unreal Mode zu verzichten.)
Der Grund dafür ist, daß man, um in den "Unreal" zu schalten, ja kurz den PM anschalten muß und gewisse Modifikationen machen muß, die nur im IOPL=0 (Input/Output-Privilege Level 0 / "Ring" 0) möglich sind, aber wenn der V86 aktiv ist, steht die CPU bereits auf IOPL=3. Ein IOPL hat umso höhere Priorität, je niedriger seine Nummer ist (0 bis 3, da 2 Bits in FLAGS Register dafür genutzt werden). Man kann aus einem IOPL mit niedrigerer Priorität nichts machen, was höhere erfordert (nur umgekehrt). Daher (und wegen anderer Dinge) heißt es auch Protected Mode - wegen dieser ganzen Schutzfunktionen.
OK, das ganze ist vielleicht nicht GANZ richtig: Man KANN noch aus dem V86 in den PM wechseln - schließlich tun es "DOS-Extender" wie DOS4GW und PMODE (von TRAN) ja auch. Aber ich glaube, da muß eine Menge beachtet werden, um die bereits vorher in V86-Mode genutzten Dinge nicht abzuschießen - bzw es könnte sein, daß diese dann im PM nicht nutzbar sind...
Auf jeden Fall ist meine Info, daß V86 und Unrealmode nicht zusammen funktionieren - was auch der Grund ist, wieso für manche Demos/Spiele immer mit einer extra Config gebootet werden mußte, ohne EMM386 usw.
Re: Entscheidung was man für ein Spiel kreieren könnte
Ich war grade in youtube unterwegs und habe neuen Stoff zum aufregen, aber auch mal für eine Bilanz.
Da präsentiert jemand (okay, er schien der Stimme nach zu urteilen vielleicht 12-13 zu sein)
Ein Spiel mit einem kleinen Ball der nur eine Handvoll Ebenen und Hindernisse zu überwinden
hat. Sagt, er hat es in Blender "programmiert".
Habs mir mal so dateninteressemäßig runtergeladen. Erstmal, ca. 40 DLLs dabei.
EXE selbst 150 MB groß.
Dann noch ein Unterverzeichnis mit unzähligen .PY Dateien, keine Ahnung was das ist.
Komprimiert war das Ding 80 MB, entpackt kommt es auf 200 MB.
So viel also für ein Spiel, das man ohne Anspruch auf solche simplen 3D Objekte
einfachst in 2K unterbringen könnte. Abgesehen davon dass man beim Titelscreen dann
keine tolle Hardtrance Musik von MP3 (oder WAV, hätte mich auch nicht gewurdert) verwenden könnte.
Mal die harten Fakten über Systeme wie DOSferatu sie nutzt und was den Kiddies heute
so zur Verfügung steht.
Früher, optimal für DOS: 486er mit meinetwegen 200 MB Platte, 50 MHz
Heute: Quadcore was weiss ich, 4 GHz., 1TB PLatte.
Verhältnisse:
Rechnenleistung (da die 64 Bit Rechner mit jedem Takt ja noch viel mehr Daten schaufeln kommt
da nochmal wenigstens Faktor 2 mit rein), also:
50 MHz vs. "virtuell" 8 GHz (Faktor 160)
Plattenspeicher:
200 MB vs. 1 TB. Lassen wir es unten ruhig mal 500 MB sein ist nicht so abwegig.
Kommt dann der Faktor 2000 raus.
Real-Mode Speicherplatz: max. 640 KB
Heutiger Speicher der Windows-Rechner: 8 GB
Faktor: ca. 13.421.772
Mit andere Worten: Speicher gibts heute wie Sand am Meer, kost nix,
also immer rein da mit Redundanten Riesendaten.
Oder mal diplomatisch: Übermäßig Viel RAM macht halt sind für Multitasking und Multimedia-Programme
Wenn meine Auflistung so stimmt sehen wir ganz klar, gegenüber Real Mode
hat Windows viel mehr RAM.
Gefolgt von den Festplatten, die 2000 mal so groß sind wie damals mittlerweile.
Am wenigsten hat sich tatsächlich an der Leistung etwas getan, "lediglich" 160x so schnell.
Es ist schwer, die Möglichkeiten eines heutigen PCs voll auszureizen. Aber Leute die keinen Einblick
in die System- und Datenarchitektur haben basteln dann eben so popelige Jump&Runs zusammen,
die am Ende die Größe von weltklasse Egoshootern der 90er an Systemvoraussetzungen übertreffen.
Nicht wenige haben also den Drang, selbst ein Computerspiel zu machen.
Da sollten Leute wie wir froh sein, dass wir wenigstens vernünftig programmieren
können, und Ergebnisse rausbringen würden, wo jedes Bit an seinem Platz ist
und nichts dekadent verschwendet wird. Das ist eine Faszination und Sache
für sich.
Ich könnte mir vorstellen so einen GAME-MAKER mal aus Spass zu benutzen und das hirnrissigste
Jump&Blöd der Weltgeschichte zusammenklicken, und es dann schön auf DVD ausliefern, obwohl
es auf eine Diskette gepasst hätte, wenn ichs in DOS realisiert hätte.
In diesem Sinne,
Guten Abend
Da präsentiert jemand (okay, er schien der Stimme nach zu urteilen vielleicht 12-13 zu sein)
Ein Spiel mit einem kleinen Ball der nur eine Handvoll Ebenen und Hindernisse zu überwinden
hat. Sagt, er hat es in Blender "programmiert".
Habs mir mal so dateninteressemäßig runtergeladen. Erstmal, ca. 40 DLLs dabei.
EXE selbst 150 MB groß.
Dann noch ein Unterverzeichnis mit unzähligen .PY Dateien, keine Ahnung was das ist.
Komprimiert war das Ding 80 MB, entpackt kommt es auf 200 MB.
So viel also für ein Spiel, das man ohne Anspruch auf solche simplen 3D Objekte
einfachst in 2K unterbringen könnte. Abgesehen davon dass man beim Titelscreen dann
keine tolle Hardtrance Musik von MP3 (oder WAV, hätte mich auch nicht gewurdert) verwenden könnte.
Mal die harten Fakten über Systeme wie DOSferatu sie nutzt und was den Kiddies heute
so zur Verfügung steht.
Früher, optimal für DOS: 486er mit meinetwegen 200 MB Platte, 50 MHz
Heute: Quadcore was weiss ich, 4 GHz., 1TB PLatte.
Verhältnisse:
Rechnenleistung (da die 64 Bit Rechner mit jedem Takt ja noch viel mehr Daten schaufeln kommt
da nochmal wenigstens Faktor 2 mit rein), also:
50 MHz vs. "virtuell" 8 GHz (Faktor 160)
Plattenspeicher:
200 MB vs. 1 TB. Lassen wir es unten ruhig mal 500 MB sein ist nicht so abwegig.
Kommt dann der Faktor 2000 raus.
Real-Mode Speicherplatz: max. 640 KB
Heutiger Speicher der Windows-Rechner: 8 GB
Faktor: ca. 13.421.772
Mit andere Worten: Speicher gibts heute wie Sand am Meer, kost nix,
also immer rein da mit Redundanten Riesendaten.
Oder mal diplomatisch: Übermäßig Viel RAM macht halt sind für Multitasking und Multimedia-Programme
Wenn meine Auflistung so stimmt sehen wir ganz klar, gegenüber Real Mode
hat Windows viel mehr RAM.
Gefolgt von den Festplatten, die 2000 mal so groß sind wie damals mittlerweile.
Am wenigsten hat sich tatsächlich an der Leistung etwas getan, "lediglich" 160x so schnell.
Es ist schwer, die Möglichkeiten eines heutigen PCs voll auszureizen. Aber Leute die keinen Einblick
in die System- und Datenarchitektur haben basteln dann eben so popelige Jump&Runs zusammen,
die am Ende die Größe von weltklasse Egoshootern der 90er an Systemvoraussetzungen übertreffen.
Nicht wenige haben also den Drang, selbst ein Computerspiel zu machen.
Da sollten Leute wie wir froh sein, dass wir wenigstens vernünftig programmieren
können, und Ergebnisse rausbringen würden, wo jedes Bit an seinem Platz ist
und nichts dekadent verschwendet wird. Das ist eine Faszination und Sache
für sich.
Ich könnte mir vorstellen so einen GAME-MAKER mal aus Spass zu benutzen und das hirnrissigste
Jump&Blöd der Weltgeschichte zusammenklicken, und es dann schön auf DVD ausliefern, obwohl
es auf eine Diskette gepasst hätte, wenn ichs in DOS realisiert hätte.
In diesem Sinne,
Guten Abend
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Entscheidung was man für ein Spiel kreieren könnte
Dieses Thema hatten wir schon einmal hier etwas näher beleuchtet:Dosenware hat geschrieben:Gruß,
zum Unreal Mode:
Was ist mit Memmorymanagern (EMM386)?, funktioniert das zusammen mit dem V86 Modus?
Wie kann ich die Speicherbelegung ermitteln (um z.b. den Festplattencache nicht zu überschreiben)?
http://www.dosforum.de/viewtopic.php?f=15&t=6763
Dirk