Entscheidung was man für ein Spiel kreieren könnte

[Brueggi]

Zustimmen tu ich an dem Punkt mit den Bibliotheken: Wenn für irgendein System schon fertige DLLs usw. existieren, und ich nur noch die dort enthaltenen Funktionen verwenden muss - dann schafft man jede Aufgabe *ratz fatz*. Nur ändert das nix dran, dass die eigentliche Anwendung dann lahm läuft.

Ich kenne Java nur von Argumenten einiger Programmierer (Hauptberuflich!), die da meinen, alles andere sei unwirtschaftlich - und gottseidank seien die elendigen Assembler-Zeiten vorbei, schließlich sei jeder aldi-PC stark genug für Java.

Ich kenne auch IT-Studenten, die ASM nur mal so kurz angeschnitten haben während des Studiums - getreu dem Motto "Das ist es - können muss es keiner, ist scheiße, aufwendig und kostet einer Firma zu viel Geld". Sowas finde ich zum Kotzen - ich stelle mir gerade vor, die Möglichkeiten hätte es damals schon gegeben... Dann hätte man wahrscheinlich am Amiga 1200 Spiele mit 1:1 Spectrum-Grafik ohne Scrolling, mit Beeper-Musik vom PC.... Und jeder würde Bauklötze staunen, wenn jemand mal ein 256-Farb-AGA-Bild laden kann.

[freecrac]

NIEMANDEN interessiert, wenn Rechenleistung durch abartige Programmiermethoden wie z.B. der Verwendung dieses unsäglichen ".NET" Mülls exorbitant verbraten wird.

Das ist -- entschuldige -- der größte Schwachsinn aller Zeiten...

1. Ist .net oft schneller als nativer Code, weil der JIT-Compiler wesentlich besser optimieren kann, und dies auch direkt für die Zielarchitektur.
2. Kann die Sprache nichts dafür, wenn die Programmierer nicht programmieren können.

Das .net Framework ist eine wunderbare Möglichkeit, viel Arbeit einzusparen.
Ich möchte dich sehen, wie du innerhalb von 2 Tagen eine komplette Datenbankverwaltung samt MySQL Anbindung und TCP-Verbindung zum Datenaustausch mit dem Hauptrechner in C oder ähnlichem entwickelst.

Gruß,
Tobias

Mir ist nur nicht ganz klar was eine Datenbankverwaltung samt MySQL in einem Spiel zu suchen hat, welche Spiele-Daten müssen denn dort so aufwendig verwaltet werden, um diese Datenbankverwaltung samt MySQL dafür überhaupt rechtfertigen zu können?

Für mich hört sich das eher so an wie ein Ostfriesenwitz, wo eine einzige Glühbirne eingeschraubt werden soll und wo einer unserer beliebten Ostfriesen auf einem Stuhl mit der Glübirne in der Hand steht und wo drei weitere Ostfriesen den Stuhl hochheben und den mit dem darauf sich befinden Ostfiriesen im Kreis herum drehen. Weil es könnte ja sein das mehr als nur eine Glübirne in die einzige Lampenfassung eingeschraubt werden müsste und falls dieser Fall eintreten sollte, dann bräuchte man ja anderfalls noch weitere Ostfriesen dafür. Ist doch logisch oder?

Dirk

[zatzen]

Zwischenzeitlich habe ich nocheinmal daran gedacht, ein Spiel zu programmieren.

Allerdings würde ich das dann nach dem Modulprinzip machen, d.h. ich erfinde
ein Format wo man allerlei definieren kann was in Variablen abgelegt wird
(script mag ich nicht so) und die Grafik sollte sich aus Einzelteilen zusammen-
setzen, beim Animieren von Figuren dann so, als würde man sich aus Pappe
einem Hampelmann basteln.

Dann hätte man das Spiel am Ende komplett definiert und man braucht nur
noch eine Engine die es zum Leben erweckt. Die kann ich dann ersteinmal
selber in DOS schreiben, und wenn dann wirklich keiner heutzutage sich
noch bemüht irgendwie DOS für das Spiel fit zu machen, kann man drüber
nachdenken, eine Engine auch für andere Systeme zu schreiben.

Damit hätte ich gleichzeitig das erreicht was ich am liebsten will, denn
ich programmiere eigentlich gar nicht so gerne sondern baue lieber
Dateiformate. Merke ich auch daran, dass ich fast am liebsten Converter
schreibe.

Eins bleibt jedoch, wenn man das ganze so systemübergreifend sieht,
dann mag einem auffallen, dass Flash als Engine meine Idee total in
die Tasche steckt und wohl niemand ausser mir dieses Format nutzen
wird. Aber das macht ja auch nichts, hauptsache ich komme voran.

Aber als Besonderheit sollte das Spielformat sich selbst um die ganze Physik
"kümmern", d.h. man kann bei Objekten definieren wie schwer sie sein
sollen usw... Überhaupt, das ganze sollte letztlich wie ein so einfach
wie möglich zu bedienendes Self-Made-Game-Tool sein, wobei es
es schon ruhig komplexer sein darf.
Frisst dann sicher viel Rechenpower und könnte somit kein Spiel anno
1992 sein, aber mal sehen... Falls ich mal Lust hab...
Erstmal das Format defininieren und mit Daten füttern und dann
zusehen, dass es lebendig wird.

[zatzen]

Wichtig wäre mir dabei der Aspekt der Zeitlosigkeit.
Das ist mein Weg damit umzugehen, dass ich mich programmiermäßig in DOS
wohl fühle, aber schon zur Kenntnis nehme, dass heutzutage 99% der Menschen
kein DOS mehr benutzen.

Die Grafiken sollten im Spiel-"Modul" hochauflösend abgelegt werden (können),
tendentiell könnte man sogar sagen als Postscript.

Die Engine würde sich dann bspw. vor dem Spiel alle benötigen gedrehten
Bilder der Grafikteile schön mit Antialiasing vorbereiten.

Alles erstmal nur so Gedanken.

[Brueggi]

Ich denke, so etwas wie das Vorbereiten/Umrechnen von Bildern in verschiedenen formaten bzw. in Post-Script ist für einen typischen DOS-Rechner (und damit meine ich z. B. einen 386) zu viel des Guten. Dann eher den Weg von Populous 2 gehen: 2 Verzeichnisse mit Grafiken, eins für Lo-, eins für Hi-Res. Je nach Setup des Users wird dann einer der beiden Grafik-Sätze verwendet.

Das spart nebenbei auch noch eine Menge Platz auf der Platte (denn nicht jeder hat xy GB, es gibt auch noch Rechner - ohne Patch - die nur 500 MB können)

[zatzen]

Du siehst, ich hätte gern einen modernen Computer, aber mit DOS.

Das müsste dann wohl einer sein, der noch 16 Bit Code kann, aber Zugriff
auf sagen mir mal mind. 64 MB RAM haben könnte. Sowas hatte ich ja bis
vor 2000 noch, Windows98 hatte ja einen echten DOS Modus.
Liediglich waren die Rechner noch nicht sooo leistungsfähig.

Ich verstehe, dass DOS in seiner Form die Möglichkeiten eines Modernen
PCs nicht voll ausschöpfen kann, zumindest nicht in der Art wie ich es
gelernt habe.

Aber Freepascal kommt mir sehr gelegen, lediglich kann ich darin nur
son Converterkram schreiben, und die Dekadenz mal einen ein 200 MB
Array definieren zu können ist praktisch.
Aber ich hab echt keine Lust auf Grafik über DLL und sowas.

[zatzen]

Du siehst, ich hätte gern einen modernen Computer, aber mit DOS.

Das müsste dann wohl einer sein, der noch 16 Bit Code kann, aber Zugriff
auf sagen mir mal mind. 64 MB RAM haben könnte. Sowas hatte ich ja bis
vor 2000 noch, Windows98 hatte ja einen echten DOS Modus.
Lediglich waren die Rechner noch nicht sooo leistungsfähig.
Aber das war eine tolle Zeit, da war ich auf dem Olymp meiner
Programmiertätigkeiten. Hatten da die Computerhersteller gesagt,
näää, IBM PC ist uncool, jetzt machen wir nur noch Commodore,
dann wäre der 1998er PC Standard zu einer Legende geworden.

Ich verstehe, dass DOS in seiner Form die Möglichkeiten eines Modernen
PCs nicht voll ausschöpfen kann, zumindest nicht in der Art wie ich es
gelernt habe.

Aber Freepascal kommt mir sehr gelegen, lediglich kann ich darin nur
son Converterkram schreiben, und die Dekadenz mal eben ein 200 MB
Array definieren zu können ist praktisch.
Aber ich hab echt keine Lust auf Grafik über DLL und sowas.

[freecrac]

Du siehst, ich hätte gern einen modernen Computer, aber mit DOS.

Das müsste dann wohl einer sein, der noch 16 Bit Code kann, aber Zugriff
auf sagen mir mal mind. 64 MB RAM haben könnte.

Alle modernen x86-64 und/oder als x64 bezeichnete CPU können immer noch einen 16 Bit Code ausführen.
Je nach RAM-Bestückung kann man damit bis zu 4 GB an Speicher adressieren (ggf. im 16 Bit PM oder im 16 Bit Unrealmode) und den freien Speicher davon ermitteln und beliebig verwenden.

Mit einem Mainboard mit (U)EFI-Bios wird die CPU allerdings schon vom BIOS selber in den 64Bit-Mode versetzt.
Aber über die Auswahl des „Compatibility Support Module“ (CSM) kann man trotzdem ein altes BIOS verwenden und damit wie gewohnt im 16 Bit RM starten, insofern so ein CSM mit integiert wurde und vorhanden ist. (Ich selber habe aber immer noch kein (U)EFI-Bios ausprobiert.)

Ich verwende zum Booten von MSDOS 6.22 und auch MSDOS 7 einen Intel Core2quad mit 2.83 ghz und boote entweder von einem 2 GB USB-Sick, oder von CD-ROM. SATA-Treiber für DOS habe ich selber noch nicht verwendet. Mein ASUS Striker2 formula-Mainboard unterstützt aber auch noch IDE-Laufwerke, wovon ich selber aber noch keinen Gebrauch gemacht habe. Das Board ist mit 8 GB-DDR2 bestückt die man auch unter DOS verwenden kann, wenn man von einer Anwendung selber in den 64Bit-Mode schaltet.

...

DOS-Spiele habe ich aber noch nicht mit so einem schnellen Rechner ausprobiert. Wenn man allerdings selber ein DOS-Spiel programmieren möchte, dann sollte die hohe Ausführungs-Geschwindigkeit der CPU eigentlich keine Probleme machen, weil zeitkritische Routinen können ja über den Timer gesteuert werden und damit einen gleichbleibend schnellen Ablauf garantieren und sicherstellen.

Dirk

[zatzen]

Das hört sich ja sehr gut an!

Könnte man also tatsächlich einen modernen PC für echtes DOS nutzen!

Eigentlich auch klar, bevor Windows 7 konnte ich meine eigenen Programme,
abgesehen vom Sound, noch in der Konsole laufen lassen.

Entschuldigung, dass ich Windows 7 benutze: Ich nutze den PC hauptsächlich
für Audio-Bearbeitung, und da ist es wirklich besser wenn man mit der Zeit geht,
Multitasking, Maus, alles sehr sinnvoll in dem Bereich, und bestimmte Programme erfordern Windows 7.
Ist zwar Marketing, aber was will man machen. Ich hab ja noch meine alten Rechner.

Okay, dann noch ne andere kleine Sache: Ich komm grad von der Evoke, vielleicht
kennt das ja jemand, und da waren auch ein paar Entries im Bereich Interactive
für GBA und Amiga, also kleine Spiele.
Da hab ich mir gedacht, wenn heute immer noch z.B. für Amiga 500(!) programmiert wird,
den zumindest ich in etwa von der Leistungsfähigkeit mit einem PC Mitte der 90er
vergleichen würde (dickes Kompliment an Amiga, der 10 Jahre Vorsprung hatte...),
dann betrachte ich einfach mal PC Ende 90er als zeitlose Plattform, und ich verwerfe
meine Idee der Plattformübergreifenden "Engine". Der Amiga entwickelte sich
immerhin auch weiter, aber der 500 ist Standard geblieben.

Vielleicht könnte man einen PC-DOS-Standard auch anhand der Definition "16 Bit Code" abstecken.

Ich weiss auch nicht, wie geht es euch, ich kenne Windows oder Java oder was
auch immer für Programmierung nicht, ich hab nur so die Ahnung dass man
da sehr "hoch" codet. Könnte mir denken dass es heute z.B. schon obsolet wird,
die Bitbreite von Variablen passend zu defininieren, weil 64 Bit alles kann und
sowieso auf 64 Bit Rechnern in einem Takt gefressen wird.
8 Byte für nen Boolean oder so, das ist krank

Ich möchte möglichst viel direkten Einfluss auf CPU und Speicher haben, beim Programmieren
nachvollziehen was der Rechner macht, und nicht Plattformübergreifend alles nur
so Scripting-mäßig definieren, was dann jedes System anders interpretiert und ausführt.

Das ist so wie ein elektronisches Gerät selber bauen, ich möchte die Platinen selber
löten (und entwerfen) und nicht nen halbfertigen Bausatz kaufen den man nur noch in
fünf Minuten zusammensteckt und dann die meiste Zeit mit dem Gestalten des Gehäuses zubringt.

Detail halt. An die Hardware angepasst. BIOS Funktionen nehm ich aber gerne, da ist meine Grenze.

Dann brauch ich jetzt nur noch ne Idee, und seh dann mal was man alles in ca. 500K
reinbekommt. Protected Mode - Ich weiss nicht. Mit Real Mode hab ich Erfahrung.
Und es ist ein nettes Knobeln, Daten effizient zu speichern, ich guck auch schonmal
gerne was im Hexeditor an, da lesen sich kleine Strukturen schöner als Redundante
Datenmengen.

[freecrac]

Ich würde vorschlagen den 16 Bit Unrealmode zu verwenden, weil man damit wie im RM unter DOS arbeiten kann und zusätzlich den Speicher über ein MB adressieren kann. Dafür wird nur kurz in den PM geschaltet und die (erweiterten) Segmente über die GDT geladen und danach wieder zurückgeschaltet und dann noch die 21.Adressleitung zugeschaltet.

Danach kann der gesamte 32 Bit-Adressraum über ein 32 Bit-Adressregister und zusammen mit dem DS-Segmentrtegister linear adressiert werden. Unser DS-Segmentregister kann dabei auch weiterhin auf den Datenbereich unserer Anwendung zeigen. Von einer bestimmten lineare Adresse oberhalb des ersten MB kann man dann die 4 Bits nach links geshiftete Segmentadresse vom DS-Segmentregister abziehen, so dass man über DS:REG32 unsere gewünschte Adresse erreichen kann.

Als kleinsten gemeinsamen Nenner könnte man CPUs mit MMX verwenden. Solche Befehle haben einen sehr schnellen Zugriff auf den Speicher und man kann damit 64 bit auf einmal kopieren und auch schnelle Rechenoperationen ausführen.

Dirk

[Brueggi]

@Freecrac:

Wenn ich das richtig im Kopf habe, dann lädt man - während man kurz in den PM schaltet - ein normal nicht benutztes Register (z. B. FS) mit dem "großen" Segment-Deskriptor und switcht dann wieder zurück in den RM.
Gibt das nicht Probleme, wenn ich DS nehme? Oder ist die CPU so clever, den "verdeckten" Teil von DS nicht zu ändern, wenn ein Programm DS auf ein anderes Segment setzt?

Im Unreal-Mode fallen dann aber auch alle REP-Befehle weg? Oder sind die dann wie immer auf nur 64K beschränkt?

Wenn ich beispielsweise FS mit dem "großen Segment" oberhalb von 1 MB lade - jetzt möchte ich das in ES und DS haben - reicht dann ein PUSH FS - POP DS oder sollte man dann über E/AX gehen? ICh habe diesen Modus bisher nie benutzt - würde es aber gerne mal tun für eine bessere RAM-Verwaltung inkl. schnelleren Zugriff auf Speicher > 1 MB.

[freecrac]

@Freecrac:

Wenn ich das richtig im Kopf habe, dann lädt man - während man kurz in den PM schaltet - ein normal nicht benutztes Register (z. B. FS) mit dem "großen" Segment-Deskriptor und switcht dann wieder zurück in den RM.
Gibt das nicht Probleme, wenn ich DS nehme? Oder ist die CPU so clever, den "verdeckten" Teil von DS nicht zu ändern, wenn ein Programm DS auf ein anderes Segment setzt?

Es gibt Schattenregister für jedes Segmentregister und dort ist auch die Segmentgrösse mit enthalten.
Mit der Segmentgrösse wird bestimmt wie ein Adresszugriff mit Segment-Anteil und Offset-Anteil erfolgen kann.
Der Inhalt eines Segmentregisters ist dabei selber völlig irrelevant, da hier immer nur eine 16 Bit-Segmentadresse verwendet wird. Wurde die Segmentgrösse noch nicht verändert, dann haben die Segmente eine Grösse von 64KB.
Wird dann für die Adressierung ein Segmentregister zusammen mit einem 32 Bit-Offset-Register verwendet, dann gehe ich davon aus, dass der obere Teil des 32 Bit-Offset-Registers einfach ignoriert und nur die untern 16 Bit als Offset verwendet wird.

Durch das Beschreiben eines Segmetregisters wird die Segmentgrösse selber nicht geändert, obwohl das so in den zugesicherten Eigenschaften bei Intel zu lesen ist. Erst wenn erneut ein Segment-Deskriptor geladen wird, erst dann wird der Einträge für die Segment-Grösse von dort verwendet und das Schattenregister welches auch im RM seine Inhalt behählt, entsprechend mit verändert.

Ich sehe keinen zwingenden Grund dafür nicht das DS-Segmentregister zu verwenden.
Aber wenn man das FS-Segmentregister verwendet, dann wird auch immer ein zusätzliches Segment-Overide-Prefix-Byte benötigt. Default beziehen sich sonst die meisten Offsetregister auf das Daten-Segment ohne das DS als Segment-Overide-Prefix mit angegeben werden muss (Ausnahme: (e)sp und (e)bp als Adressregister werden defaultmässig dem Stack-Segment zugeordnet). Einen klitzekleinen Vorteil hat es, wenn man ein weniger benutztes FS-Register verwendet. Man kann die Segmentadresse auf Null stellen und nur noch den Inhalt des Offset-Anteils als lineare Flat-Adresse verwenden, wodurch die Berechnung der linaren Adresse im anderen Fall, wenn unsere Segmentregisten ungleich null ist, dann wegfällt, weil dann unsere lienare Adresse mit "FS:REG32" identisch ist.

Im Unreal-Mode fallen dann aber auch alle REP-Befehle weg? Oder sind die dann wie immer auf nur 64K beschränkt?

Wenn ich beispielsweise FS mit dem "großen Segment" oberhalb von 1 MB lade - jetzt möchte ich das in ES und DS haben - reicht dann ein PUSH FS - POP DS oder sollte man dann über E/AX gehen? ICh habe diesen Modus bisher nie benutzt - würde es aber gerne mal tun für eine bessere RAM-Verwaltung inkl. schnelleren Zugriff auf Speicher > 1 MB.

Der obere Adress-Antei ist aber gar nicht im Segmentregister enhalten, sondern nur im Offset der eben 32 Bit gross ist und zsammen mit der Segmentstartadresse + Offset-Adresse zusammengerechnet wird eine hohe Adresse ergibt.

Dieses Beispiel geht davon aus, dass die Segmentgrösse von DS bereits erweitert wurde und wir uns schon im 16 Bit Unrealmode befinden:

Code: Alles auswählen

xor eax, eax                   ; EAX wird gelöscht
mov ax, @Data                  ; Segmentadresse vom Datenbereich nach AX
mov ds, ax                     ; Inhalt von AX nach DS

mov edi, 00100000h  * 64       ; lineare Adrese vom 65.Megabyte
shl eax,  4                    ; aus der Segmentadress eine lineare Adresse machen
sub edi, eax                   ; diesen Anteil abziehen

mov si, OFFSET BLA             ; Offsetadresse laden
mov eax, [si]                  ; Inhalt der Adresse von DS:SI nach eax
mov [edi], eax                 ; Inhalt von EAX zur Adresse in DS:EDI schreiben

.Data
BLA DB "blub"

Unabhängig davon wo sich unser Datenbereich im untersten MB befindet wenn wir unser DS-Register damit laden, kann über das DS-Register + einem 32 Bit-Offsetregister jede hohe Adresse über dem ersten MB damit erreicht werden.
Ich hoffe es wird damit verständlich.

Stringbefehle (mit, oder ohne REP-Prefix) habe ich zusammen mit hohen Adressen selber noch gar nicht ausprobiert im Unrealmode. Damit es schneller geht habe ich bisher immer MXX-Register zum Kopieren von Daten verwendet.
Ich vermute das diese SIMD-Befehle eine schnellere Anbindung zum Speicher haben als Stringbefehle. (Das ist aber nur eine Vermutung von mir.)

Dirk

[zatzen]

Nur mal überflogen kommt mir das jetzt eher kompliziert vor.

Zudem macht es mir gerade Spass, Daten sehr kompakt zu halten.

Wäre natürlich praktisch für Projekte mit minutenlanger, ständig parat
sein müssender Sprachausgabe, und mehreren Bildschirmen breiten gescannten Hintergründen.

Aber zu viel Freiheit, zu viel Rechenpower, zu viel Speicherkapazität
lässt das ganze langweilig werden, man wird nicht gefordert, die
Daten wohlüberlegt zu strukturieren oder ASM richtig einzusetzen.

Ich bin jetzt nicht soo der Guru dass ich versuche, aus DOS das gleiche
rauszuholen wie aus nem Windows PC mit OpenGL und allem.

Mich haben vor allem Spiele geprägt (um 1993), die wirklich nur im Real-Mode
und innerhalb 640K liefen. Lediglich würde ich Features wie Tracker-Musik
einbauen statt AdLib, was mit meinem Speicherplatz-sparenden simplen
Formätchen mit ein bisschen mehr Rechenleistung auch gut möglich ist.

Und ich möchte wenigstens eine Kompatibilität(!) mit DosBox, für den flexibleren
Umgang auf nicht-DOS-Plattformen. Das schliesst ja nicht aus, dass es
auch auf echten DOS-Systemen funktioniert.

Bleibt die Frage, wie der Unreal-Mode sich auf die Programmierung auf der
Hochsprachenebene (Pascal) auswirkt. Anlegen von Arrays, Pointern usw.
Und eben inwieweit es mit DosBox kompatibel wäre. Real-Mode scheint
darin problemlos zu funktionieren, "erweiterte" Modi eher nicht.

[freecrac]

Nur mal überflogen kommt mir das jetzt eher kompliziert vor.

So kompliziert ist der Unrealmode selber aber gar nicht. Für DOS bleibt er unbemerkt.
Nur unsere Anwendung kann nun zusätzlich zusammen mit 32 Bit-Adressen den gesamten 32 Bit-Adressraum erreichen.

Zudem macht es mir gerade Spass, Daten sehr kompakt zu halten.

Wäre natürlich praktisch für Projekte mit minutenlanger Sprachausgabe
und mehreren Bildschirmen breiten gescannten Hintergründen.

Ein wesentlicher Vorteil vom Unrealmode gegenüber dem RM ist auch die Möglichkeit den linearen Framebuffer, der sich im 4. GB einblendet, zu verwenden. Damit braucht man dann nicht mehr die banked Bildmodi mit 64 kb grossen Banken in 0A000:0 zu verwenden, wo man für jede Bank umschalten muss und dafür minstesstens ein Portzugriff benötigt.
Der lineare Framebuffer ist in seiner vollen länge quasi in einem Stück vorhanden und unmittelbar beschreibbar.

So macht es auch mehr Sinn z.B. das VBE hardware triple buffering damit zu verwenden, womit sich der zu beschreibende Bildbereich dann auch noch verdreifacht. Für Bewegungen grosser bildschirmfüllender Bildbereiche ist es die einzige Möglichkeit so etwas flimmenfrei und ohne ein Tearing hinzubekommen. Selber nur den Staus-Port 3DAh vom Rasterstrahl dafür abzufragen reicht dafür bei weiten nicht mehr aus. Nur relativ kleine Objekte wie ein Mousezeiger lassen sich damit noch flimmerfrei bewegen, viel mehr aber auch nicht.

Aber zu viel Freiheit, zu viel Rechenpower, zu viel Speicherkapazität
lässt das ganze langweilig werden, man wird nicht gefordert, die
Daten wohlüberlegt zu strukturieren oder ASM richtig einzusetzen.

Das "viel" realtiviert sich sehr schnell und wird danach gar nicht mehr so empfunden.

Ich finde eigentlich jeden bezahlbaren Rechner ist immer noch viel zu langsam und ich bin eher darüber enttäuscht wie langsam alle Rechner immer noch sind. Gerne dürfte meine CPU 10.000 mal schneller werden und nicht nur wenige Prozentchen schneller mit jeder neuen Architektur. Mir geht die gesamte Entwiklung viel zu langsam und ich vermute das die Forschung schon sehr viel weiter ist und auch noch viel weiter sein könnte und nur der Raubtierkapitalismuss wieder einmal unseren gesamten Fortschritt massiv blockiert und behindert und der gesamte Wettbewerb sich eher kontraproduktiv für unsere Entwicklung auswirkt und viel zu viel Zeit und Resourcen mit diesem Blödsinn billigsten Schrott zu vermarkten vergeudet und geopfert wird.

Ich glaube ich brauche eine Quantenrechner mit verschränkten Bits, wo alle Daten ohne einen Zweitverlust sich durch das ganze Universum verteilen können. Weil Lichtgeschwindigkeit ist mir doch noch zu langsam. Henri Poincaré hat sich mit seiner Gleichung "m = E/c²" und der darauf beruhenden Wechselwirkung von Aktion und Reaktion vieleicht ja doch etwas verechnet.

Ich bin jetzt nicht soo der Guru dass ich versuche, aus DOS das gleiche
rauszuholen wie aus nem Windows PC mit OpenGL und allem.

Von AMD habe ich mir dafür zwar einige "Register Reference Guides" verschiedener GPUs herunter geladen, aber vermutlich werde ich es auch nicht ausprobieren so etwas zu programmieren.

Mich haben vor allem Spiele geprägt (um 1990), die wirklich nur im Real-Mode
und innerhalb 640K liefen.

Ich möchte wenigstens eine Kompatibilität(!) mit DosBox, für den flexibleren
Umgang auf nicht-DOS-Plattformen. Das schliesst ja nicht aus, dass es
auch auf echten DOS-Systemen funktioniert.

Bleibt die Frage, wie der Unreal-Mode sich auf die Programmierung auf der
Hochsprachenebene (Pascal) auswirkt. Anlegen von Arrays, Pointern usw.

Da ich Pascal selber noch nie verwendet habe kann ich darüber auch nur spekulieren.

Dirk

[freecrac]

Moin.
Für mich wäre es dann auch wichtig es zu erfahren ob der gesamte Themen-Komplex (z.B. Unrealmode mit Adressierung vom linearer Framebuffer) als ganzes zu kompliziert ist, oder welcher Part Sück für Stück davon am schwersten zu verstehen ist.

...

Es muss auch nicht unbedingt ein anderer Speicherplatz zusätzlich, ausser eben der lineare Framebuffer mit Daten befüllt werden. Also nur das eine kleine Routine an einer von uns gewünschten Position die Farbwerte beliebig ändert.
Der Wunsch mit einer möglichst kleinen Routine gewaltige Mengen an Daten zu dirigieren ohne zu verschwenderisch mit den Speicherrplatz umzugehen kann weiterhin verfolgt und beibehalten werden.

Dirk