Meine Geschichte:

[FPU_]

Zu meiner Person:
Bin Baujahr 1982 und wohne in der Nähe von Stuttgart.
Irgendwann als ich zwischen 6 und 10 Jahren alt war, bin ich mit dem ersten Computer in Kontakt gekommen.
Ab 16 habe ich angefangen zu programmieren.
Erster eigener PC kam irgendwann ca. 1995/96 (Pentium 166).


Zu meiner Dos Kiste:
Der erste "Familien PC" war ein 80286 16 Mhz mit 2 MB Ram und anfänglich einem 14" SW Monitor, 2 Festplatten (~160 und ~40 MB).
Den Rechner gibt es heute noch. Nur habe ich ihn "etwas" aufgebohrt.
Der Ram wurde auf 4 MB aufgestockt, eine Soundblaster 16 spendiert, bessere Grafikkarte, Netzwerkkarte (3Com 3c509b Combo).
Als Betriebssystem läuft DR-Dos (ich hoffe damit kann ich mich hier blicken lassen) und Windows 3.1 for workgroups darauf.
Compilertechnisch TurboC++ 1.0 und irgendeine Turbo Pascal Version.

Momentan habe ich die Kiste weil ich Urlaub habe wieder ausgegraben und spiele damit etwas herum.
Er hängt an meinem 22" Breitbild TFT - wenn das mal nicht dekadent ist ;)
Hab das Netzwerk unter Windows zum laufen gebracht und tausche gerade einige Daten aus (Backups der beiden Festplatten).
Arbeite auch momentan an nem kleinen Spiel - aber eigentlich mehr zu Testzwecken. Hoffentlich läufts auf der alten Mühle ;)
Leider fehlt noch ein 80287 zum vollkommenen Glück :( (also wenn einer einen übrig hat... hab auch viel altes Zeug zum tauschen)


Meinem ersten eigenen Computer war leider kein so rosiges Schicksal vergönnt.
Anfängliche Ausstattung: Windows 95, Pentium 166 Mhz, 16 MB Ram, 2 MB Graka, 1,6 GB HD, 8x CD.
Hab zu der Zeit noch einige Dos Spiele darauf im Dos Modus gespielt und drufte mich mit dem 640 kb Limit herumärgern *fg*.
Der Rechner flog vor ein paar Jahren nachdem er mir zwei Festplatten gegrillt hatte und ausgeschlachtet war auf den Müll. Aber bis dahin hatte er mir lange Jahre treue Dienste geleistet.


Danach endete auch so langsam die Dos Zeit. Der nächste Computer hatte anfangs noch Windows ME drauf, aber das konnte mich nicht überzeugen.
Nach einigen Abstechern zurück auf ein Windows 98 kam dann Windows 2k drauf und aus war es mit reinem Dos.

[ChrisR3tro]

Hallo FPU und willkommen im Forum!

Danke für die nette Vorstellung. Deinen Account habe ich schonmal freigeschaltet.

Was für Spiele programmierst Du denn?

Gruß,
locutus

[FPU]

Ich programmiere nur eines ;)
Wird ein Vertikalscroller ähnlich Raptor.

[DOSferatu]

Cool. endlich mal 'n Spieleprogrammierer hier. Dacht schon, ich wär der einzige.
Herzlich Willkommen im DOSforum, FPU!

[FPU]

Jetzt fehlen nur noch ein paar Grafiker und Musiker und wir könnten anfangen

[ChrisR3tro]

Jetzt fehlen nur noch ein paar Grafiker und Musiker und wir könnten anfangen :wink:

Das ist eigentlich immer das Problem oder? :-)

[SharpClaw]

hawooo!! ^^

hehe, genau wie beim RPG-Maker ;)

Was soll denn letztendlich bei herauskommen?

[FPU]

Das ist eigentlich immer das Problem oder?

Ja. Der Code schreibt sich ja fast von selbst - aber der Rest? :(

Was soll denn letztendlich bei herauskommen?

Optimal wäre es, wenn es ein Spiel dabei rauskommen würde

Um etwas genauer zu werden:
Soll ein kleiner Shooter mit Stunteinlagen und Wirtschafts-/Rollenspielelementen werden.
Man fährt mit einem Luftkissenfahrzeug über eine Vertikal Scrollende Landschaft voller Hindernisse und Gegner (zu Lande, zu Wasser und in der Luft).
Nach jedem Level schwebt mir ein Boss Level vor, in dem ein besonders dicker Gegner erledigt werden muss.
Anschließend kann man sein "Boot" in der Werkstatt mit verschiedenen Waffensystemen aufrüsten und sich auf die nächste Mission vorbereiten.
Sollte es so etwas bereits geben, dann sind Parallelen rein zufällig.
Ich dachte mir, so wäre es mal was anderes als der tausendste Raptor Clon.

So weit die Theorie. In der Praxis gibt es noch einiges zu tun. ^.^°
Bis jetzt habe ich nen kleinen minimalistischen Prototypen zum testen der Engine mit hässlichen Testgrafiken und nen Leveleditor im Rohbau.

Ein wenig was zur Technik:
VGA (Int13), 320x200, 256 Farben, Pixelweises Scrolling (im Editor Tileweise), Textausgabefunktion, eigene Palette kann geladen werden, Triple Buffering, nur Standard C Bibliotheken bis jetzt in Benutzung (kein Allegro, kein SDL, kein nix).
Tilegröße: 32x32 Pixel. Tiles müssen im RAW Format vorliegen (1 kb je Tile).
Bis jetzt sind es etwa 550 Zeilen eigener Code.
Dateigröße der Spiel-Exe bis jetzt: 24 kb.

Die ToDo Liste ist im Prinzip noch länger als die "done" Liste.
Es fehlen: Grafiken, Musik, Sounds, Menüs, Gegner, KI, Map Format, Level, Timing routine, Tools, Bugfixing, Optimierungen etc.
Mein Ziel ist es das Spiel bis zum 7.1. wenigstens halbwegs fertig zu bringen. (Ab 7.1. muss ich wieder arbeiten ;) )

Performance:
Als das ganze noch mit Double Buffering und VSync lief, hatte ich auf meinem Athlon XP2500+ unter Windoof 50-60 FPS (stark ruckelnd). Auf meinem 286er mit 16 Mhz unter Dos 11 FPS.
Mittlerweile habe ich die Engine stark umgestrickt (u.a. Triple Buffering) und erreiche nun ohne VSync ruckelfreie 350-400 FPS auf dem Athlon. Auf dem 286er habe ich es bis jetzt noch nicht getestet.
(Die Hauptroutinen für die Grafik sind alle (noch) in C.)

Naja... mal schauen wie weit ich komme.
Was mein ihr dazu?

[ChrisR3tro]

Ich habe ein wenig Erfahrung mit SDL und Allegro, so systemnah wie du habe ich aber noch nicht programmiert, jedenfalls nicht was Grafikprogrammierung unter DOS angeht. Dafür lief mein "Spiel" dann aber unter Windows, DOS und Linux! Plattformunabhängigkeit alleine machte dann aber auch keinen Spaß. ;)

Den Zeitrahmen den Du Dir setzt halte ich übrigens für unglaublich sportlich. :-)

Ich hätte ja durchaus Spaß daran, mich programmiertechnisch zu beteiligen oder mich auch in einer der anderen Disziplinen zu versuchen und dabei was zu lernen (ganz wichtig!).

Allerdings habe ich wie immer die Befürchtung, daß aus solchen Foren-Projekten nichts wird, es sei denn man ernennt zunächst mal einen Projektleiter, der (auch kreativ) sagt wo's lang geht und Ordnung ins Chaos bringt. Ansonsten macht schnell jeder was er will und das ganze driftet unkontrolliert in alle Richtungen und das Spiel ist am Ende eine Mischung aus RPG, Scroller, Arcade, Action-Adventure, 3D-Simulation und Mario Smash Brothers Brawl mit Final Fantasy- und Pinball-Elementen. :-(

Zweitens braucht so ein Projekt Leute, die alle unterschiedliche Skills mitbringen, sodaß möglichst alle Disziplinen abgedeckt sind die Du angesprochen hast.

Und dann wäre da noch die Motivation und das Durchhaltevermögen, denn Spieleprogrammierung ist harte Arbeit. Das wird häufig unterschätzt.

Wenn das alles nicht gegeben ist, hat man als einzelner meiner Meinung nach mehr Chancen. Das soll jetzt nicht demotivierend wirken, aber die Erfahrung, daß in Foren sehr viel geredet wird und am Ende alles im Sand verläuft habe ich nun schon öfter gemacht. Ansonsten hätte ich aber schon Interesse. :)

So... genug schwarzgemalt.

[DOSferatu]

Achja, @FPU. Falls Interesse: (und ohne hier rumlabern zu wollen) Kannst Dir ja mal mein Game Xpyderz anschauen. (http://www.imperial-games.de/html/prea1.htm)
Halt nur so zur Information.

[FPU]

@Locutus: Ja... das jeder etwas anderes will hat schon so manches Projekt zu Fall gebracht.
Wie wäre es, anstelle eines ganzen Spiels eine Bibliothek für die Erstellung von Spielen zu machen? Ok, man könnte dafür auch Allegro nehmen... ^.^° Das wäre dann auch portabel.
Aber gibt es nicht eh schon alles x-mal? Und selbermachen macht immer noch am meisten Spaß.

@DOSferatu: Habs mir mal reingezogen. Beeindruckend was du da gebastelt hast. Hast du irgendne Bibliothek dafür verwendet, oder alles selbst gemacht?
Das Spiel ist nur etwas zu bunt und zu wuselig für meinen Geschmack. ^.^°

Mein Spiel wurde nun durch Tagelange Debug- und Problemsuchsessions aufgehalten. Nun klappt aber alles so weit.
Werd nächste Woche noch drei Tage Urlaub nehmen - hab also noch etwas mehr Zeit ;). Und nein ich nehme nicht extra Urlaub um an dem Spiel zu basteln... auch wenn es sich geradezu anbietet ;D

[DOSferatu]

@Locutus: Ja... das jeder etwas anderes will hat schon so manches Projekt zu Fall gebracht.

Ja, oder wenn man das Problem hat, daß es da verschiedene Arten von Leuten gibt:
1.) Will mitmachen, hat aber nie Zeit. (bzw sein Interesse hält nur 3 Tage an)
2.) Will mitmachen, denkt aber, ein Spiel, das man in 2 Stunden durchspielt, dauert auch nur 2 Stunden zu entwickeln.
3.) Will mitmachen, hat aber so wenig Ahnung von Rechnern, daß man ihm praktisch keine einzige Aufgabe geben kann, weil man ihm sogar erklären müßte, wie 'n Malprogramm oder 'ne Textverarbeitung funktioniert.
4.) Will mitmachen, hat aber horrende Vorstellungen, wie z.B. daß alles und jedes in 1600x1200 sein muß, mit 16 Mio Farben. (Auch ein Sprite, das 12*9 Pixel groß ist, soll dann die Möglichkeit für 24bit Farben kriegen - was, wenn man drüber nachdenkt, einigermaßen sinnlos ist.)
5.) Will mitmachen, aber nur für Geld. Und am besten mit gesicherter Garantie für Geld - oder für Geld im voraus.
6.) Und wahrscheinlich hätte man heutzutage auch das Problem, daß, wenn die zusätzlich am Projekt beteiligten Personen männlich sind, eine gewisse Wahrscheinlichkeit besteht, daß die alle nur wieder so'n blödes Kriegsspiel machen wollen - möglichst mit realistischen Waffen und Gegnern... Nerv!

Wie wäre es, anstelle eines ganzen Spiels eine Bibliothek für die Erstellung von Spielen zu machen?

Tja, mein Problem ist: Ich HABE schon etliche solcher "Bibliotheken" gemacht, das einzige, was ich noch für ein vollständiges 2D-Spiel jeder Art machen müßte, wäre die SoundUnit. Außerdem ist - im Gegensatz zur bisherigen Arbeitsweise - eine Art VM (in 100% ASM) schon geplant und konzeptioniert - die dann zur Steuerung der Figuren (Spieler, Gegner, "Schüsse", Boni, Level, etc) dient. Bisher wurde das direkt programmierrt. Diese Steuerung wird dann in einem einfachen Basic-Dialekt programmiert und das Ganze wird tokensiert...

Meine Probleme dabei sind halt:
a) Ich programmiere unter DOS. (Mein Zeug läuft zwar auch unter Windows bis Windows XP, ist aber reines DOS-Zeug.) Das sollte aber in diesem Forum hier wohl OK sein, oder?
b) Ich programmiere in Pascal und Assembler. Vor allem der Pascal-Teil dürfte manche Leute stören, denn viele Leute programmieren heutzutage eben lieber in C oder einem seiner Ableger.
c) Mein Zeug läuft (leider) nicht mehr auf 286ern, ich setze mindestens 386er voraus. Grund ist, daß ich die erweiterten Register (FS,GS), sowie die 32-Bit-Register ganz gut gebrauchen kann, um damit sehr nützliche Dinge zu tun - die auch das Ganze schneller machen und für weniger Speicherverbrauch sorgen.

@DOSferatu: Habs mir mal reingezogen. Beeindruckend was du da gebastelt hast. Hast du irgendne Bibliothek dafür verwendet, oder alles selbst gemacht?

Alles selbstgemacht. Die "Bibliotheken" (Pascal-Units mit ASM-Anteil) habe ich auch alle selbst programmiert.

Das Spiel ist nur etwas zu bunt und zu wuselig für meinen Geschmack.

Das war Absicht. Es sollte aussehen, sich anfühlen und spielen wie ein altes Arcade-Spiel. Und es sollte NICHT irgendwie aussehen wie diese ganzen Kriegs-/Terroristen-/Weltkriegs-Spiele/Simulationen. Sowas kann ich nicht ausstehen - und gerade zur Zeit wird das ganze Kriegs- und (Anti-)Terror-Thema so gehyped, daß es nicht mehr zum Aushalten ist.
(Und wenn ich ein besserer Grafikpixler wäre, wäre das Ganze wohl noch bunter und schicker. Achja... Wenn ich Leute hätte, die richtig gute Grafiken pixeln können oder Interesse dran hätten, Levels zu bauen, hätte ich einen extremen DOS-Spiele-Output. Ich habe so viele Ideen, so viele Konzepte und so viele Bibliotheken hier rumliegen - aber wenn ich z.B. ein Spiel in der Art wie Turrican machen wollen würde, würde mir die Programmierung überhaupt nichts ausmachen, aber die ganzen Levels und Grafiken (und Musiken/SoundFX) zu machen macht dermaßen viel Arbeit, daß man das alleine kaum in endlicher Zeit schafft.)

Mein Spiel wurde nun durch Tagelange Debug- und Problemsuchsessions aufgehalten. Nun klappt aber alles so weit.

Ja, Debugging nervt wie Seuche. Oder, wie es in "Murphy's Computergesetze" steht:
"Wenn Debuggen der Vorgang ist, Fehler aus Programmen auszubauen, dann ist Programmieren der Vorgang, welche einzubauen."
Und wenn man dann ein grafisches Spiel macht und "Echtzeit Debugging" will (also sehen, was während des Ablaufs passiert), dann baut man noch extra für das Debugging zusätzliche Ausgabefenster und sowas ein, selbst wenn das Spiel so etwas selber gar nicht hat. Die andere Methode, nämlich alle Prozesse in ein File zu loggen, bremst dann manchmal den Spielablauf und außerdem macht's ja auch immer einen Riesenspaß, in mehreren MB großen Logfiles den Fehler zu finden...

@FPU:
Anmerkung:
Die Unit, die die Xpyderz-Level darstellt (sicher schon gemerkt, auch 32x32 Tiles, wie bei Dir), braucht für jedes Tile nur 512 Bytes (0,5 kB) plus 16 Bytes. Früher war es auch 1kB. Der Grund ist, daß jedes Tile nur 16 aus 256 Farben benutzt und mit einer 16er Farb-Umsetzungs-Palette arbeitet, so daß ein Pixel nur 4 Bit braucht. Genau nach demselben Prinzip sind auch die Sprites aufgebaut. Die Sprite-Unit erlaubt aber, daß ein Sprite wahlweise eben 4bit- oder 8bit-Pixel hat.
Früher hatte ich das Level in jeder Stufe skalierbar gemacht, aber das sieht einfach nicht gut aus, weil dann beim Scrollen immer Pixel verschwinden und auftauchen. Jetzt kann das Level auf 100%, 50%, 25% und 12,5% skaliert werden, also 1, 1/2, 1/4 und 1/8. Und es hat eine Option für "Low-Res" (wie bei DOOM), so daß man statt 2 nebeneinanderliegenden Pixeln nur einen Pixel darstellt, der doppelt breit ist. Das dient dazu, die Framerate auf langsamen Rechnern zu erhöhen (indem man die Besonderheiten des Mode-X ausnutzt).

Du benutzt also Mode 13h 320x200 (nicht Mode-X) und pufferst im Speicher, oder?
('schuldigung, mich interessiert's halt, wenn ich auch mal 'n anderen Programmierer treffe, der ebenfalls in DOS und ebenfalls grafische Spiele programmiert.)

[FPU]

Tja, mein Problem ist: Ich HABE schon etliche solcher "Bibliotheken" gemacht, das einzige, was ich noch für ein vollständiges 2D-Spiel jeder Art machen müßte, wäre die SoundUnit. Außerdem ist - im Gegensatz zur bisherigen Arbeitsweise - eine Art VM (in 100% ASM) schon geplant und konzeptioniert - die dann zur Steuerung der Figuren (Spieler, Gegner, "Schüsse", Boni, Level, etc) dient. Bisher wurde das direkt programmierrt. Diese Steuerung wird dann in einem einfachen Basic-Dialekt programmiert und das Ganze wird tokensiert...

Deine Probleme möcht ich auch haben ;)

Eine VM ist gut (sofern der Zielrechner genügend Rechenkapazität aufweist).
Viele Dinge sind einfach viel zu trivial um mit der Pascal/C/ASM Keule draufzuhauen. Hinterher hat man nur nen Haufen Fehler im Programm für eine minimale Funktion die man mit einer Skriptspache im Handumdrehen erreicht hätte.
Ich mache unter Windows vieles gerne mit Skripten ;)
Willst du die Sprache selbst basteln oder was fertiges anpassen?

Das höchste der Gefühle im Bereich Sound waren bei mir früher immer nervige Töne aus dem eingebauten Lautsprecher äh Piepser auf der Hauptplatine.
Aber besser solche Töne als gar keine.

Meine Probleme dabei sind halt:
a) Ich programmiere unter DOS. (Mein Zeug läuft zwar auch unter Windows bis Windows XP, ist aber reines DOS-Zeug.) Das sollte aber in diesem Forum hier wohl OK sein, oder?

Ist von mir aus genemigt ;)

b) Ich programmiere in Pascal und Assembler. Vor allem der Pascal-Teil dürfte manche Leute stören, denn viele Leute programmieren heutzutage eben lieber in C oder einem seiner Ableger.

Wobei ich nicht weiss was die Leute an C und C++ so toll finden. ^.^°
Die kreativen Fehler die man dadurch in seine Programme einbauen kann werden es wohl nicht sein.
Hab früher auch in Pascal programmiert, bis ich armer Irrer den Rückschritt auf C gewagt habe.

c) Mein Zeug läuft (leider) nicht mehr auf 286ern, ich setze mindestens 386er voraus. Grund ist, daß ich die erweiterten Register (FS,GS), sowie die 32-Bit-Register ganz gut gebrauchen kann, um damit sehr nützliche Dinge zu tun - die auch das Ganze schneller machen und für weniger Speicherverbrauch sorgen.

Naja... man nimmt halt was man kriegen kann.
Und irgendwie scheint alle Welt einen 386er als Minimum heranzuziehen.
Wäre meine langsamste Kiste nicht ein 286er sondern mein Pentium der im Router steckt, dann würde ich den als Mindestmaß vorraussetzen.
Leistung und Prozessorfeatures kann man schließlich nie genug haben.
Aber man sollte auch lernen mit wenig auszukommen und sich in Bescheidenheit zu üben.
Nicht umsonst wird bei modernen Spielen so viel geskriptet, um die ganzen Ghz auslasten zu können ;)

Naja... wäre schön wenn es heutzutage eine ernst zu nehmende gut konstruierte Alternative zu x86 gäbe.

@DOSferatu: Habs mir mal reingezogen. Beeindruckend was du da gebastelt hast. Hast du irgendne Bibliothek dafür verwendet, oder alles selbst gemacht?

Alles selbstgemacht. Die "Bibliotheken" (Pascal-Units mit ASM-Anteil) habe ich auch alle selbst programmiert.

Respekt. *hut zieht*

Das Spiel ist nur etwas zu bunt und zu wuselig für meinen Geschmack.

Das war Absicht. Es sollte aussehen, sich anfühlen und spielen wie ein altes Arcade-Spiel. Und es sollte NICHT irgendwie aussehen wie diese ganzen Kriegs-/Terroristen-/Weltkriegs-Spiele/Simulationen. Sowas kann ich nicht ausstehen - und gerade zur Zeit wird das ganze Kriegs- und (Anti-)Terror-Thema so gehyped, daß es nicht mehr zum Aushalten ist.

Was sollen die Firmen denn herstellen wenn überall im Fernsehen nur noch Gewalt, Mord, Krieg und Totschlag zu sehen sind?
Da macht man halt den tausendsten Shooter und trifft garantiert den Geschmack der Zielgruppe. Eigene Ideen braucht man dazu dann nicht mehr - man macht einfach die Glotze an.
Mal von Nintendo mit der Wii und ein paar anderen Ausnahmen abgesehen, die mit neuen Spielideen versuchen andere Zielgruppen anzufixen.

(Und wenn ich ein besserer Grafikpixler wäre, wäre das Ganze wohl noch bunter und schicker. Achja... Wenn ich Leute hätte, die richtig gute Grafiken pixeln können oder Interesse dran hätten, Levels zu bauen, hätte ich einen extremen DOS-Spiele-Output. Ich habe so viele Ideen, so viele Konzepte und so viele Bibliotheken hier rumliegen

Das ist wohl das Schicksal das du mit vielen kreativen Köpfen teilst. ^.^°
Da wird noch so manch gute Idee im dunkeln verschwinden und nie verwirklicht.
Wobei ich deine Grafiken selbst gar nicht so schlecht finde.
Hätte ich auch nicht besser hinbekommen.

Mein Spiel wurde nun durch Tagelange Debug- und Problemsuchsessions aufgehalten. Nun klappt aber alles so weit.

Ja, Debugging nervt wie Seuche. Oder, wie es in "Murphy's Computergesetze" steht:
"Wenn Debuggen der Vorgang ist, Fehler aus Programmen auszubauen, dann ist Programmieren der Vorgang, welche einzubauen."
Und wenn man dann ein grafisches Spiel macht und "Echtzeit Debugging" will (also sehen, was während des Ablaufs passiert), dann baut man noch extra für das Debugging zusätzliche Ausgabefenster und sowas ein, selbst wenn das Spiel so etwas selber gar nicht hat. Die andere Methode, nämlich alle Prozesse in ein File zu loggen, bremst dann manchmal den Spielablauf und außerdem macht's ja auch immer einen Riesenspaß, in mehreren MB großen Logfiles den Fehler zu finden...

Jaja... und nachher hat man für das Spiel mehr Hilfsfunktionen und mehr Fehlerbehandlungsroutinen geschrieben als normalen Spielcode. (Und den eigentlichen Fehler dann vielleicht erst nicht gefunden)
Und was besonders schön ist: wenn man eine oder mehrer
Zeilen Code auskommentiert oder neu hinzufügt und der Fehler dadurch verschwindet, sich anders äußert oder ein ganz anderer wird... das is ja soooo lustig :/

@FPU:
Anmerkung:
Die Unit, die die Xpyderz-Level darstellt (sicher schon gemerkt, auch 32x32 Tiles, wie bei Dir), braucht für jedes Tile nur 512 Bytes (0,5 kB) plus 16 Bytes. Früher war es auch 1kB. Der Grund ist, daß jedes Tile nur 16 aus 256 Farben benutzt und mit einer 16er Farb-Umsetzungs-Palette arbeitet, so daß ein Pixel nur 4 Bit braucht. Genau nach demselben Prinzip sind auch die Sprites aufgebaut. Die Sprite-Unit erlaubt aber, daß ein Sprite wahlweise eben 4bit- oder 8bit-Pixel hat.

Also benutzt du für die Sprites und Tiles quasi nur einen Ausschnitt aus einer 256er Farbpalette und musst den Grafiken nur noch mit auf den Weg geben welchen Teil der Palette sie benutzen sollen?
Und wie erstellst du die Grafiken hierfür? Doch sicher nicht mit Standardprogrammen ;)

Du benutzt also Mode 13h 320x200 (nicht Mode-X) und pufferst im Speicher, oder?

Ja. Wollte lieber erstmal klein anfangen. ^.^°
Die Grafiken werden im Hauptspeicher erstellt/gescrollt und dann in den Grafikspeicher kopiert.
Bei zwei Puffern für den Bildschirm verbrate ich dadurch 128 kbyte an Dos Speicher. Nicht schön aber es funktioniert.
Ne Hardwarebeschleunigte sauber dokumentierte und offizielle genormte Lösung wäre mir aber ehrlich gesagt lieber als das Gefrickel.
Aber sowas scheint man in der PC Welt vergeblich zu suchen ;)

[DOSferatu]

(wegen meiner Units...)

Deine Probleme möcht ich auch haben ;)

Ich meine eher: Ich habe das ganze Zeug - und am Programmieren liegt's bei mir wirklich nicht, warum ich nicht 1 bis 3 größere Spiele (oder mehr) pro Jahr rausbringen könnte. Eher an den restlichen Dingen.

Eine VM ist gut (sofern der Zielrechner genügend Rechenkapazität aufweist).

Auch hier ist der minimale Rechner wieder 386er. Die VM ist ja dann nicht so'n Scheiß wie Javascript. Das wird "tokensiert" und der Token-Code sieht dann aus wie eine Art Pseudo-Maschinencode. Die VM selber soll auch nicht das ganze Spiel machen, sondern nur für die Figurensteuerung zuständig sein und um Figuren an-/auszuschalten usw. Da alle Figuren sowieso in so Art mehrfach aufeinander zuweisende "Datenbanken" bei mir liegen, wird das nicht so ein Rechenaufwand. Oder anders ausgedrückt: Den Rechenaufwand macht ein externes Programm, BEVOR das Zeug in's Spiel einbaut wird und das Spiel selber muß dann nur noch aufbereitete Daten abarbeiten. Kann man jetzt schlecht erklären, wenn man dabei möglichst theoretisch bleiben will.

Viele Dinge sind einfach viel zu trivial um mit der Pascal/C/ASM Keule draufzuhauen. Hinterher hat man nur nen Haufen Fehler im Programm für eine minimale Funktion die man mit einer Skriptspache im Handumdrehen erreicht hätte.

Wie gesagt, es wird keine Skriptsprache und sowas würde ich auch für ein Spiel nie verwenden. Das "Pseudo-Basic" kommt im Spiel selbst gar nicht vor und ich würde in einem Spiel auch niemals mit 'nem Parser rumfuhrwerken! Ich meinte: Das Pseudo-Basic dient der Vereinfacherung der Eingabe, damit man nicht in dem Pseudo-ASM-Code rummurksen muß (was man auch könnte).

Ich mache unter Windows vieles gerne mit Skripten

Ich mache gar nichts unter Windows. Wenn mein DOS-Zeug auch unter Windows läuft - OK. Wenn nicht - Pech gehabt.

Willst du die Sprache selbst basteln oder was fertiges anpassen?

Ich habe schon mehrere solcher Sprachen gebastelt und werde das auch hier wieder tun, ja. Ist alles schon konzeptioniert.
Also, um das nicht falsch zu verstehen: Es dient dazu, die Bewegung und das Verhalten (und Kollisionsabfragen) der Figuren in einem kleinen ASM-ähnlichen Pseudocode darstellen zu können. Denn das ist immer noch schneller als wenn man's in reinem Pascal oder schlimmerem tut. Es hat auch den Zweck, daß man die Figuren - zusammen mit ihrem "Verhaltensprogramm" einzeln nachladen kann, statt das alles in einem festen (Pascal-compilierten) Code in der EXE mit rumzuschleppen. Spart übrigens auch Speicher.

Das höchste der Gefühle im Bereich Sound waren bei mir früher immer nervige Töne aus dem eingebauten Lautsprecher äh Piepser auf der Hauptplatine.

Habe ich auch schon gemacht. Mein Spiel "4 Gewinnt" (auf meiner Webseite) ist ein Beispiel dafür. Habe da - mit demselben Trick, den Xenon 2 anwendet - Mehrstimmigkeit simuliert. In Xpyderz wird auf dem PC-Speaker sogar digitale Musik abgespielt - habe nur noch nicht die Sounddaten-Erzeugungs-Unit geschrieben. Aber wenn man Xpyderz unter DOS startet und als Parameter eine WAV-Datei angibt, wird diese während des Spiels auf dem PC-Speaker digital abgespielt.

(ich programmiere unter DOS)

Ist von mir aus genemigt

(Ich programmiere in Pascal und Assembler, statt C)

Wobei ich nicht weiss was die Leute an C und C++ so toll finden.

Ich auch nicht. Habe auch schon (im Auftrag für'n Kumpel) in C programmiert. Ich hab's hingekriegt - aber meine Fresse, nervt das!

Hab früher auch in Pascal programmiert, bis ich armer Irrer den Rückschritt auf C gewagt habe.

Jedem das Seine. Ich verurteile keinen für die Programmiersprache, die er verwendet. Ich find's gut, daß es überhaupt noch Leute gibt, die in richtigen Programmiersprachen coden (statt diese Pseudo-Programmierer, die denken, XML wäre Programmieren...)

(Mein Zeug läuft (leider) nicht mehr auf 286ern, ich setze mindestens 386er voraus.)

Naja... man nimmt halt was man kriegen kann.
Und irgendwie scheint alle Welt einen 386er als Minimum heranzuziehen.
[...]
Aber man sollte auch lernen mit wenig auszukommen und sich in Bescheidenheit zu üben.

Genau das tue ich ja. Manche meiner Games sind auch 286er. Aber bei manchen Dingen (4-Ebenen-Parallax-Scrolling) ist es von Vorteil, ein paar mehr Segment-Register oder 32-Bit Register zu haben, weil z.B. der ständige Wechsel des Segment-Registers ziemlich an der Rechenzeit zerrt.
Also ich bin der letzte, der es auf sich bezieht, Gigantomanie zu betreiben oder Systemrechenzeit zu verschwenden, indem er ultraharte Systeme benutzt. Mein Entwicklungsrechner ist ein 486er mit 133 MHz. Und obwohl ich einen 486er habe und an einigen Stellen mit 486er-ASM-Befehlen ein, zwei Zyklen hätte herausholen können, verwende ich weiterhin nur maximal 386er ASM-Befehle.

Nicht umsonst wird bei modernen Spielen so viel geskriptet, um die ganzen Ghz auslasten zu können

Tja, mit so einem Müll kann ich auch nicht viel anfangen. Ich benutze die vorhandene Rechenleistung, ich verschwende sie nicht. In manchem Skript-Mist wird über 90% der Rechenleistung dazu benutzt, den Skript-Parser/Interpreter zu betreiben und unter 10% zur Ausführung das eigentlichen Problems. Damit kann ich nichts anfangen. Und wenn man GHz-Kisten nur dazu baut, damit Coder (oder was sich für Coder hält) beschissener programmieren können, hab ich dafür auch kein Verständnis.

Naja... wäre schön wenn es heutzutage eine ernst zu nehmende gut konstruierte Alternative zu x86 gäbe.

Das gibt es wohl einiges. Das Problem ist weniger, daß es das nicht geben würde, sondern, daß x86er-PCs dermaßen populär sind und fast jeder einen hat und es daher - gerade als Spielprogrammierer - keinen Sinn macht, auf 'nem System mit einer toll konzipierten, aber total seltenen (und seltsamen) CPU ein Spiel zu coden, das dann keiner außer einem selber spielen kann, weil keiner sonst diese Kiste hat. Das ist wohl der wahre Grund. Und daß die x86-CPU wie Stückwerk aussieht, liegt daran, daß sie auch genau das ist. Man hat die halt über die Jahre/Jahrzehnte weiterentwickelt, mit der Vorgabe, weiterhin abwärtskompatibel bis 8086 zu sein. Und dadurch wurde dann immer irgendwas irgendwo "drangebaut", das nicht das stören darf, was schon vorher dran war...

(Alles selbstgemacht. Die "Bibliotheken" (Pascal-Units mit ASM-Anteil) habe ich auch alle selbst programmiert.)

Respekt. *hut zieht*

*rot werd* - Danke. Naja, ich programmiere eben dauernd so'n komisches Zeug - andere Leute nicht, aber die haben dafür 'ne Freundin oder 'n Auto oder irgendne Art von Sozialleben...

(...und gerade zur Zeit wird das ganze Kriegs- und (Anti-)Terror-Thema so gehyped, daß es nicht mehr zum Aushalten ist.)

Was sollen die Firmen denn herstellen wenn überall im Fernsehen nur noch Gewalt, Mord, Krieg und Totschlag zu sehen sind?

Das mag sein, aber deswegen muß ich's ja nicht mögen. Oder am Ende auch noch den Mist unterstützen, indem ich selber auf diesen Zug aufspringe.
Eins meiner nächsten Spiele soll zwar ein Raumschiffshooter werden - aber eher so SciFi-Arcade, ohne irgendeine Art von Kriegshintergrund.

Mal von Nintendo mit der Wii und ein paar anderen Ausnahmen abgesehen, die mit neuen Spielideen versuchen andere Zielgruppen anzufixen.

Naja, OK, Nintendo macht ja in letzter Zeit so dermaßen "familienfreundliches" Zeug, daß es mir schon ein ganz klein wenig ZU Kindergarten ist, was die da machen. Das spielen dann wirklich nur noch Pappis, Mammis und kleine Kinder und ich gehöre leider zu keiner dieser 3 Gruppen.

(...Ich habe so viele Ideen, so viele Konzepte und so viele Bibliotheken hier rumliegen)

Das ist wohl das Schicksal das du mit vielen kreativen Köpfen teilst. Da wird noch so manch gute Idee im dunkeln verschwinden und nie verwirklicht.

Tja, seufz...

Wobei ich deine Grafiken selbst gar nicht so schlecht finde. Hätte ich auch nicht besser hinbekommen.

*noch roter werd* - Danke abermals.
(Hm... ja, ich weiß: rot, roter, am rotesten...)

(... wegen des Debuggings)

Jaja... und nachher hat man für das Spiel mehr Hilfsfunktionen und mehr Fehlerbehandlungsroutinen geschrieben als normalen Spielcode. (Und den eigentlichen Fehler dann vielleicht erst nicht gefunden)
Und was besonders schön ist: wenn man eine oder mehrer
Zeilen Code auskommentiert oder neu hinzufügt und der Fehler dadurch verschwindet, sich anders äußert oder ein ganz anderer wird... das is ja soooo lustig

Ja, ne? Ist so lustig, man lacht sich den Arsch ab.
(wenn manche Leute wüßten, welche Mühe selbst ziemlich einfache Spiele schon machen... - OK, sollte man denen vielleicht auch lieber nicht erzählen - dann hat am Ende überhaupt keiner mehr Lust, mal an einem Spielprojekt mitzumachen....)

Also benutzt du für die Sprites und Tiles quasi nur einen Ausschnitt aus einer 256er Farbpalette und musst den Grafiken nur noch mit auf den Weg geben welchen Teil der Palette sie benutzen sollen?

Nö, nicht einen Ausschnitt.
Sondern, das Tile oder Sprite benutzt 16 Farben der vorhandenen 256. Dazu referiert es auf eine Tabelle, die 16 Bytes groß ist und diese Bytes entsprechen den Farbnummern in der echten 256er Palette.

Und wie erstellst du die Grafiken hierfür? Doch sicher nicht mit Standardprogrammen

Natürlich nicht. Die Sprites und Tiles pixle ich in einem selbstgeschriebenen Malprogramm. Das müßte ich zwar nicht, aber die Malprogramme, die es so gibt, nerven mich. Vor allem, weil ich es hasse, mit der Maus pixeln zu müssen. Das ist mir zu ungenau. Und außerdem ist mein Malprogramm 8bit-Palettenbasiert, d.h. man kann eine Palette definieren und damit dann malen.
Aber für die Spiele habe ich dann ein weiteres Programm, das Sprites oder Tiles aus einer Vollgrafik ausschneidet und in das gewünschte Format gleich wandelt. Dabei bekommen die Sprites und Tiles eine spezielle Anordnung im Speicher, damit sie auf die effizienteste Art per Assembler verarbeitet werden können. Haben Sprites z.B. dasselbe Aussehen und unterscheiden sich nur dadurch, daß sie gedreht oder gespiegelt sind, erhalten sie dasselbe Image und ein Dreh/Spiegel-Flag. Dasselbe gilt, wenn sie sich dann noch in den Farben unterscheiden, aber von der Farb-Anordnung gleich sind. Dann wird ebenfalls das gleiche Image benutzt, und lediglich eine zusätzliche Farbpalette generiert. Wenn es eine Palette gibt, die schon passend ist, wird diese benutzt. Und so weiter. D.h. ich habe hier Konverter programmiert, die vorhandenes Zeug in für mich besser verarbeitbare Daten konvertieren.

(Du benutzt also Mode 13h 320x200 (nicht Mode-X) und pufferst im Speicher, oder?)

Ja. Wollte lieber erstmal klein anfangen.
Die Grafiken werden im Hauptspeicher erstellt/gescrollt und dann in den Grafikspeicher kopiert.
Bei zwei Puffern für den Bildschirm verbrate ich dadurch 128 kbyte an Dos Speicher. Nicht schön aber es funktioniert.

Ja, ich könnte das nicht mehr, weil ich einfach keine 128kB zur Verfügung stellen kann. Die Vollversion von Xpyderz enthält ja auch das Menüsystem, einen im Spiel integrierten Leveleditor und einen vollständigen TCP/IP-Stack auf 3 verschiedenen "Plattformen": PPP, Netzwerkkarte (mit Crynwr Treiber) und eine speziell für Anbindung ans Windows-Internet (wenn unter Windows) gedachte "Schnittstelle". (Außerdem noch ARP, DNS und HTTP Request/Reply.) Irgendwann reichen dann die etwas über 600 kByte einfach nicht mehr aus...

Ne Hardwarebeschleunigte sauber dokumentierte und offizielle genormte Lösung wäre mir aber ehrlich gesagt lieber als das Gefrickel.

Aber sowas scheint man in der PC Welt vergeblich zu suchen.[/quote]
Tja. Jede verdammte Firma erfindet 'ne eigene "Norm"/"Standard". Dokumentiert wird natürlich nix - oder erst, wenn das Zeug nirgends mehr offiziell verkauft wird (also so veraltet ist, daß es keiner mehr hat). Und um diesem Mist Herr zu werden, wurden dann "Treiber" erfunden. Und das Lustige an Treiber ist eben, daß die dann (aus Kostengründen) von diesen Firmen nur für das System geschrieben werden, das gerade das populärste ist - also im Klartext für die aktuellste Version von MS-Windows oder wenn man Glück hat auch noch für die vorhergehende.
Ohne Treiber ist heutige Hardware entweder so nützlich wie ein unheimlich teurer Briefbeschwerer oder sie hat, wenn man Glück hat, wenigstens noch ihre Grundfunktionen ohne Treiber verfügbar - funktioniert dann also auf dem technischen Stand von ungefähr 1993 oder früher, wenn man sie ohne Treiber benutzt.
(Treiber - also Softwareschnittstellen - machen das Ganze übrigens langsamer als direkte Zugriffe. Naja, stört wahrscheinlich keinen, der sich alle 4-6 Monate den neuesten Rechner kaufen kann...)

Ich weiß auch nicht - vielleicht bin ich ja auch bescheuert - aber:
Fortschritt sieht für mich irgendwie anders aus...

[FPU]

Eine VM ist gut (sofern der Zielrechner genügend Rechenkapazität aufweist).

Auch hier ist der minimale Rechner wieder 386er. Die VM ist ja dann nicht so'n Scheiß wie Javascript.

Das hätte ich von Dir jetzt auch nicht erwartet ;)

Das wird "tokensiert" und der Token-Code sieht dann aus wie eine Art Pseudo-Maschinencode.

Also Bytecode(?)

Ich mache unter Windows vieles gerne mit Skripten

Ich mache gar nichts unter Windows. Wenn mein DOS-Zeug auch unter Windows läuft - OK. Wenn nicht - Pech gehabt.

^.^° Jaja... ich sollte hier nicht von Windows und anderer Konkurenz reden.
Hab übrigens mit QBasic angefangen... im Prinzip auch ne Skriptsprache...

Wobei ich nicht weiss was die Leute an C und C++ so toll finden.

Ich auch nicht. Habe auch schon (im Auftrag für'n Kumpel) in C programmiert. Ich hab's hingekriegt - aber meine Fresse, nervt das!

Mein Trost: es wird mich sicher Geistig fitt halten. Oder ich sterbe vorzeitig an Bluthochdruck.
Aber meine Produktivität hat nach dem Umstieg schon ganz schön gelitten.

Hab früher auch in Pascal programmiert, bis ich armer Irrer den Rückschritt auf C gewagt habe.

Jedem das Seine. Ich verurteile keinen für die Programmiersprache, die er verwendet. Ich find's gut, daß es überhaupt noch Leute gibt, die in richtigen Programmiersprachen coden (statt diese Pseudo-Programmierer, die denken, XML wäre Programmieren...)

Oder HTML *wääääääh*.
Und wehe man zeigt ihnen irgendwas in HTML, dann halten sie einen für den Oberprogrammierer...

Nicht umsonst wird bei modernen Spielen so viel geskriptet, um die ganzen Ghz auslasten zu können

Tja, mit so einem Müll kann ich auch nicht viel anfangen. Ich benutze die vorhandene Rechenleistung, ich verschwende sie nicht. In manchem Skript-Mist wird über 90% der Rechenleistung dazu benutzt, den Skript-Parser/Interpreter zu betreiben und unter 10% zur Ausführung das eigentlichen Problems. Damit kann ich nichts anfangen. Und wenn man GHz-Kisten nur dazu baut, damit Coder (oder was sich für Coder hält) beschissener programmieren können, hab ich dafür auch kein Verständnis.

Mittlerweile gibt es zahlreiche 3D und Spieleengines, die wahlweise mit Hochsprachen oder Skriptsprachen programmierbar sind... aber die Hersteller/Entwickler solcher Frickeldinger raten immer zu Skriptsprachen, weil es mit einer Hochsprache zu kompliziert wäre...
Das ist in etwa so effizient, wie als wenn man Biosprit in Verbrennungsmotoren verwendet.

Naja... wäre schön wenn es heutzutage eine ernst zu nehmende gut konstruierte Alternative zu x86 gäbe.

Das gibt es wohl einiges. Das Problem ist weniger, daß es das nicht geben würde, sondern, daß x86er-PCs dermaßen populär sind und fast jeder einen hat und es daher - gerade als Spielprogrammierer - keinen Sinn macht, auf 'nem System mit einer toll konzipierten, aber total seltenen (und seltsamen) CPU ein Spiel zu coden, das dann keiner außer einem selber spielen kann, weil keiner sonst diese Kiste hat. Das ist wohl der wahre Grund. Und daß die x86-CPU wie Stückwerk aussieht, liegt daran, daß sie auch genau das ist. Man hat die halt über die Jahre/Jahrzehnte weiterentwickelt, mit der Vorgabe, weiterhin abwärtskompatibel bis 8086 zu sein. Und dadurch wurde dann immer irgendwas irgendwo "drangebaut", das nicht das stören darf, was schon vorher dran war...

Jaja... es hat sich halt mal wieder nicht das beste System durchgesetzt, sondern durch eine Verkettung unglücklicher Umstände so ziemlich das schlechteste ;)
Aber tröstlich und beruhigend das wir auch heute noch unserer guten alten 8086er Programme verwenden könnten... wenn denn das OS und der ganze Rest noch mitspielen würde und wir solche Software noch hätten.
Schade auch, das Apple auf den x86 Zug aufgesprungen ist. Die Power PC CPU wäre für mich der einzigste Grund für einen Mac gewesen. (wobei ich nicht weiss inwieweit der Flickwerk gewesen wäre)

Respekt. *hut zieht*

*rot werd* - Danke. Naja, ich programmiere eben dauernd so'n komisches Zeug - andere Leute nicht, aber die haben dafür 'ne Freundin oder 'n Auto oder irgendne Art von Sozialleben...

Naja... man muss sich halt entscheiden... Spaß mit Autos, Frauen oder Code? XD

Eins meiner nächsten Spiele soll zwar ein Raumschiffshooter werden - aber eher so SciFi-Arcade, ohne irgendeine Art von Kriegshintergrund.

Wir müssen wohl leider akzeptieren, das es in der Natur der Menschen liegt sich gegenseitig aus nichtigen Gründen umzubringen. :(
Wie wärs mit mehr Spielen, in denen man mit Gewalt nicht weiter kommt sondern eher verliert?
Gibt da leider sehr viele Negativbeispiele für Spiele, wo man mit Gewalt weiter kommt...

Mal von Nintendo mit der Wii und ein paar anderen Ausnahmen abgesehen, die mit neuen Spielideen versuchen andere Zielgruppen anzufixen.

Naja, OK, Nintendo macht ja in letzter Zeit so dermaßen "familienfreundliches" Zeug, daß es mir schon ein ganz klein wenig ZU Kindergarten ist, was die da machen. Das spielen dann wirklich nur noch Pappis, Mammis und kleine Kinder und ich gehöre leider zu keiner dieser 3 Gruppen.

Geht mir auch zu weit.
Aber was soll die arme Industrie machen, wenn jeder im normalen Zockeralter schon alles mit Consolen vollstehen hat, oder die Teenies von einst langsam erwachsen werden?
Da muss man neue Zielgruppen erschließen.

Jaja... und nachher hat man für das Spiel mehr Hilfsfunktionen und mehr Fehlerbehandlungsroutinen geschrieben als normalen Spielcode. (Und den eigentlichen Fehler dann vielleicht erst nicht gefunden)
Und was besonders schön ist: wenn man eine oder mehrer
Zeilen Code auskommentiert oder neu hinzufügt und der Fehler dadurch verschwindet, sich anders äußert oder ein ganz anderer wird... das is ja soooo lustig

Ja, ne? Ist so lustig, man lacht sich den Arsch ab.

Ja... nach mehreren Tagen Frust hat man das lachen dann auch wirklich nötig :/

(wenn manche Leute wüßten, welche Mühe selbst ziemlich einfache Spiele schon machen... - OK, sollte man denen vielleicht auch lieber nicht erzählen - dann hat am Ende überhaupt keiner mehr Lust, mal an einem Spielprojekt mitzumachen....)

Lieber nur wenige aber gute, als lauter Pseudos, oder?
Die Pseudos werden sonst später alle mal "HTML-" oder "XML-Programmierer" oder Skripten den x-Teil irgendeines bekannten stinklangweiligen Shooters (sponsered by Intel).

Also benutzt du für die Sprites und Tiles quasi nur einen Ausschnitt aus einer 256er Farbpalette und musst den Grafiken nur noch mit auf den Weg geben welchen Teil der Palette sie benutzen sollen?

Nö, nicht einen Ausschnitt.
Sondern, das Tile oder Sprite benutzt 16 Farben der vorhandenen 256. Dazu referiert es auf eine Tabelle, die 16 Bytes groß ist und diese Bytes entsprechen den Farbnummern in der echten 256er Palette.

Oder so ^.^°

Und wie erstellst du die Grafiken hierfür? Doch sicher nicht mit Standardprogrammen

Natürlich nicht. Die Sprites und Tiles pixle ich in einem selbstgeschriebenen Malprogramm. Das müßte ich zwar nicht, aber die Malprogramme, die es so gibt, nerven mich. Vor allem, weil ich es hasse, mit der Maus pixeln zu müssen. Das ist mir zu ungenau. Und außerdem ist mein Malprogramm 8bit-Palettenbasiert, d.h. man kann eine Palette definieren und damit dann malen.

... und kein Programm hat all die Funktionen die man bräuchte oder will.
Hab auch mal zu Pascal Zeiten eines gebastelt mit diversen Features und einer gefälligen Optik.

Aber für die Spiele habe ich dann ein weiteres Programm, das Sprites oder Tiles aus einer Vollgrafik ausschneidet und in das gewünschte Format gleich wandelt. Dabei bekommen die Sprites und Tiles eine spezielle Anordnung im Speicher, damit sie auf die effizienteste Art per Assembler verarbeitet werden können. Haben Sprites z.B. dasselbe Aussehen und unterscheiden sich nur dadurch, daß sie gedreht oder gespiegelt sind, erhalten sie dasselbe Image und ein Dreh/Spiegel-Flag. Dasselbe gilt, wenn sie sich dann noch in den Farben unterscheiden, aber von der Farb-Anordnung gleich sind. Dann wird ebenfalls das gleiche Image benutzt, und lediglich eine zusätzliche Farbpalette generiert. Wenn es eine Palette gibt, die schon passend ist, wird diese benutzt. Und so weiter. D.h. ich habe hier Konverter programmiert, die vorhandenes Zeug in für mich besser verarbeitbare Daten konvertieren.

Was tut man nicht alles für mehr Effizienz? ;)
Ganz so weit ist mein Zeug hier noch nicht. Das mit den Drehungen und Spiegelungen werd ich demnächst auch noch einbauen.
Verwendest du für deine Daten auch noch eine Kompression?
Die Größe meiner Bilddaten würden sich damit auf ca. 30% der Ursprungsgröße reduzieren lassen.
Oder hast du die Daten so zusammengedampft, das eine Kompressions nichts mehr bringt?

Ja. Wollte lieber erstmal klein anfangen.
Die Grafiken werden im Hauptspeicher erstellt/gescrollt und dann in den Grafikspeicher kopiert.
Bei zwei Puffern für den Bildschirm verbrate ich dadurch 128 kbyte an Dos Speicher. Nicht schön aber es funktioniert.

Ja, ich könnte das nicht mehr, weil ich einfach keine 128kB zur Verfügung stellen kann. Die Vollversion von Xpyderz enthält ja auch das Menüsystem, einen im Spiel integrierten Leveleditor und einen vollständigen TCP/IP-Stack auf 3 verschiedenen "Plattformen": PPP, Netzwerkkarte (mit Crynwr Treiber) und eine speziell für Anbindung ans Windows-Internet (wenn unter Windows) gedachte "Schnittstelle". (Außerdem noch ARP, DNS und HTTP Request/Reply.) Irgendwann reichen dann die etwas über 600 kByte einfach nicht mehr aus...

Ich lass einfach dich mein Spiel machen - ich bin nun demotiviert. ;)

Ne Hardwarebeschleunigte sauber dokumentierte und offizielle genormte Lösung wäre mir aber ehrlich gesagt lieber als das Gefrickel.
Aber sowas scheint man in der PC Welt vergeblich zu suchen.

Tja. Jede verdammte Firma erfindet ... Ohne Treiber ist heutige Hardware entweder so nützlich wie ein unheimlich teurer Briefbeschwerer oder sie hat, wenn man Glück hat, wenigstens noch ihre Grundfunktionen ohne Treiber verfügbar - funktioniert dann also auf dem technischen Stand von ungefähr 1993 oder früher, wenn man sie ohne Treiber benutzt.
(Treiber - also Softwareschnittstellen - machen das Ganze übrigens langsamer als direkte Zugriffe. Naja, stört wahrscheinlich keinen, der sich alle 4-6 Monate den neuesten Rechner kaufen kann...)
Ich weiß auch nicht - vielleicht bin ich ja auch bescheuert - aber:
Fortschritt sieht für mich irgendwie anders aus...

Jaja... wir stammen halt noch aus dem vorigen Jahrtausend.
Heute ist Kompatibilität bis zum Erbrechen wichtiger als Geschwindigkeit und Effizienz.
Ich fänds unheimlich knuffig wenn man z.B. moderne 3D Karten ohne die ganzen Zwischenschichten direkt ansprechen könnte... mehr Speed ginge nicht.
So ein rotierender texturierter Hardwarebeschleunigter Würfel in 3D unter Dos (Realmode)... das hätte was.

Durfte mich auch schon oft genug mit Treiberproblemen herumärgern, weil ich gerade nicht das passende OS zur Hardware hatte.
Und dann ist die ehemals teuer gekaufte Hardware halt entweder ein Briefbeschwerer oder ein Staubfänger (wenn du groß oder zu leicht für nen Briefbeschwerer).
Echt traurig wenn man Hardware wegschmeißen muss oder alte Rechner vorhalten müsste um so Zeug benutzen zu können.

Bei dem 286er waren noch zwei dicke Ordner dabei. In einem standen Details über die Hardware und die Programmierung drin. Sowas kriegt man heute nimmer!
Mit den Jahren sind ein paar dünne Heftchen und Flugblätter draus geworden die einem gerade noch zeigen wo man welchen stecker einstecken muss.