Verfasst: Mo 5. Jan 2009, 20:29
(Das wird "tokensiert" und der Token-Code sieht dann aus wie eine Art Pseudo-Maschinencode.)
Ich erklär' mal kurz, wie das Ding so aufgebaut ist, falls Interesse:
Es sieht sogar dem x86-Maschinencode etwas ähnlich. Jeder Befehl weiß selber, wieviele Parameterbytes er hat. Ein Befehl ist entweder ein Byte (ohne Parameter) oder 2+x Bytes. Wenn 2+x Bytes, ist das 2. Byte entweder selbst ein Parameter (z.B. bei relativen - teils "bedingten" Sprüngen) oder es ist ein Bitmuster, das für 2 Parameter erklärt, welche Größe sie haben (1-4 Byte) und aus welchem "Bereich" sie stammen (z.B. ob sie direkt sind, aus dem VariablenSpeicher, aus dem Spezialspeicher (Figuren-Werte) oder aus einer indizierten Tabelle). Danach folgen evtl Parameter (z.B. wenn es direkte Parameter sind).
Das ganze Ding arbeitet nur mit Integers (1-4 Byte Zahlen), ob sie als Integer oder Festkomma, vorzeichenbehaftet oder nicht benutzt werden, bestimmt die Art, wie man sie verwendet. Meine Sprites haben z.B. 24bit Koordinaten im Level. 16 Bit Vorkomma, 8 bit Nachkomma. Die Nachkommabits spielen bei der Anzeige der Sprites keine Rolle, sie werden nur zur Erhöhung der Genauigkeit (z.B. bei schrägen oder kreisförmigen oder ähnlichen Bewegungen) benutzt. (Sprites können bei mir auf 2 Arten bewegt werden: Entweder sie haben einen X- und Y-Addierwert für die Koordinaten (natürlich vorzeichenbehaftet) oder sie haben einen Winkel und eine Geschwindigkeit (also eine Art Bewegungsvektor). Diesen Modus kann man mit nem Bit umstellen...
Jede Figur kann sich, bei Initialisierung einen Stackbereich (natürlich selbstgebauter Stack, weil's ja soviele Stacks wie Figuren geben muß) reservieren. Dieser ist für Unterprogramme oder Sichern von Werten gedacht und in ihm werden auch lokale Variablen der Figuren abgelegt.
Naja, und so weiter. Will das nicht weiter auswalzen.
(wegen C)
(Nullterminierte Strings sind das letzte! Wenn ich die Länge von nem nullterminierten String wissen will, muß ich den abzählen, bis ich ne Null finde. Jedesmal. Und wenn da überhaupt keine Null ist, muß man noch ne zusätzliche Abbruchbedingung einbauen, damit er nicht irgendwoanders im Speicher rumgurkt... - Nur mal eine meiner Anmerkungen. Achja, und daß es nur ein mathematisches aber kein boolesches XOR gibt, find ich auch nervig.)
(Eins meiner nächsten Spiele soll zwar ein Raumschiffshooter werden - aber eher so SciFi-Arcade, ohne irgendeine Art von Kriegshintergrund.)
Steuere Raumschiff mit irgendwelchen 4 Richtungstasten. Wenn Feind in Sicht, hacke auf die Feuertaste, bis Feind weg. Wenn Feind zu stark und/oder zurückschießt, weiche aus. Steuere nicht an die Levelaufbauten. Und wenn irgendwas sich nicht bewegt und wie'n Bonus aussieht, fliege drüber und es ist Deiner... Dadurch macht es so'n Spaß, weil man eben nach spätestens 2 Minuten kapiert hat, wie das Spiel funktioniert. Es ist wie mit Tetris: Einfach zu begreifendes Spielprinzip und trotzdem stundenlang Freude - und selbst heute wird noch Tetris gespielt. (Ich hab übrigens auch schon eins gecodet...)
Ich geb's ehrlich zu - ich spiele auch ab und zu mal DOOM (einziger 3D-Shooter, der mir etwas Spaß macht). Aber ich spiel das nur mal zwischendurch. Und ich nehme es nicht so ernst wie andere Leute so 3D-Shooter ernstnehmen. Außerdem bin ich Programmierer. Und schon alleine, weil es Software-3D-Programmierung ist, interessiert es mich.
(Übrigens: Hab mal selber ein Testprogramm gemacht, mit dem ich auch solche 3D-Levels darstellen kann. Habe da testweise mal die DOOM-Levels geladen und es funktioniert damit.)
Obwohl man sagen muß, daß es eher nicht an den Programmierern der Kommerzsoft liegt, warum da manchmal nicht ausreichend optimiert wird, sondern eher an den Firmen, für die die arbeiten. Da steht dann z.B. Weihnachten vor der Tür und die wollen das Game unbedingt raushaben, da sitzt dann die Zeit im Nacken und die geben das Teil raus, obwohl es noch nicht richtig debugged ist und obwohl die Coder da sicher noch optimiert hätten. Aber wenn man ein geldgeiler Produzent ist, interessiert einen nur die Kohle. Ich wette, die Publisher spielen nie selber Computerspiele. Denen ist es egal, ob das Ding gut oder weniger gut ist - Hauptsache, es sieht von außen gut aus und sie sind die ersten aufm Markt, die 'n neues Programm/Spiel raushauen. Hauptsache halt, die haben was zum Verkaufen.
Also das "Packen" beschränkt sich darauf, daß ich eben die Pixel 4bit habe, so daß 1 Byte 2 Pixel enthält. Meine File-Unit kann während des Speicherns packen und während des Ladens entpacken. Man stellt einfach den Pack-Modus ein. Man kann statt Pack- auch Verschlüsselungs-Modi einstellen.
Deswegen will man auch nicht, daß Leute in irgendner vernünftigen Sprache coden lernen. Dann müssen sie nämlich immer teure Software kaufen - und nicht, wie ein Computerfreak es machen würde, sich 'n kleines Tool mal eben schnell selber coden können.
Aber was soll's. Es hilft auch nichts, darüber zu lamentieren. Man muß eben einfach durch eigene Taten beweisen, daß es noch Leute auf der Welt gibt, die nicht für jede Art Programm/Spiel 'n Rechner mit exorbitanter Hardware brauchen. Ich find's nämlich auch seltsam, daß 2D-Arcade-Spiele schon aufm alten Nintendo und aufm C64 gingen und man heute für Spiele, die kaum besser aussehen, irgendwas im GHz-Bereich braucht - nur, weil man sie eben in irgendwelchen Skripten basteln muß...
Also Bytecode(!)FPU hat geschrieben:Also Bytecode(?)
Ich erklär' mal kurz, wie das Ding so aufgebaut ist, falls Interesse:
Es sieht sogar dem x86-Maschinencode etwas ähnlich. Jeder Befehl weiß selber, wieviele Parameterbytes er hat. Ein Befehl ist entweder ein Byte (ohne Parameter) oder 2+x Bytes. Wenn 2+x Bytes, ist das 2. Byte entweder selbst ein Parameter (z.B. bei relativen - teils "bedingten" Sprüngen) oder es ist ein Bitmuster, das für 2 Parameter erklärt, welche Größe sie haben (1-4 Byte) und aus welchem "Bereich" sie stammen (z.B. ob sie direkt sind, aus dem VariablenSpeicher, aus dem Spezialspeicher (Figuren-Werte) oder aus einer indizierten Tabelle). Danach folgen evtl Parameter (z.B. wenn es direkte Parameter sind).
Das ganze Ding arbeitet nur mit Integers (1-4 Byte Zahlen), ob sie als Integer oder Festkomma, vorzeichenbehaftet oder nicht benutzt werden, bestimmt die Art, wie man sie verwendet. Meine Sprites haben z.B. 24bit Koordinaten im Level. 16 Bit Vorkomma, 8 bit Nachkomma. Die Nachkommabits spielen bei der Anzeige der Sprites keine Rolle, sie werden nur zur Erhöhung der Genauigkeit (z.B. bei schrägen oder kreisförmigen oder ähnlichen Bewegungen) benutzt. (Sprites können bei mir auf 2 Arten bewegt werden: Entweder sie haben einen X- und Y-Addierwert für die Koordinaten (natürlich vorzeichenbehaftet) oder sie haben einen Winkel und eine Geschwindigkeit (also eine Art Bewegungsvektor). Diesen Modus kann man mit nem Bit umstellen...
Jede Figur kann sich, bei Initialisierung einen Stackbereich (natürlich selbstgebauter Stack, weil's ja soviele Stacks wie Figuren geben muß) reservieren. Dieser ist für Unterprogramme oder Sichern von Werten gedacht und in ihm werden auch lokale Variablen der Figuren abgelegt.
Naja, und so weiter. Will das nicht weiter auswalzen.
Naja, so schlimm isses nun auch wieder nicht. Man kann das ruhig erwähnen. Nicht erwünscht sind hier wohl eher, wenn jemand dauernd Fragen zu und über Windows stellt oder ständig erzählt, was er alles unter Windows macht. Das meinen die hier nicht böse - aber es gibt schon genug Windows-Foren oder "Allgemeines Laberzeug" Foren und die Betreiber hier wollen lobenswerterweise, daß dies hier ein DOS-Forum ist und bleibt. Sonst würden die ganzen DOS-Fans nämlich wahrscheinlich auch irgendwann abhauen.FPU hat geschrieben:Jaja... ich sollte hier nicht von Windows und anderer Konkurenz reden.
Naja, es ist eine Interpretersprache, ja. Hab noch nie in QBasic programmiert, muß ich sagen. Auf PC hatte ich direkt mit Pascal angefangen.FPU hat geschrieben:Hab übrigens mit QBasic angefangen... im Prinzip auch ne Skriptsprache...
(wegen C)
Ja, es gibt da manche Dinge in C, die man ganz schön um die Ecke programmieren muß. Das erste, was ich in C gemacht hatte, war, mir erstmal so Dinge wie 'n vernünftiges String-Handling zu coden und n paar andere Sachen, von denen ich nicht glauben konnte, daß sowas nicht per Standard dabei ist.FPU hat geschrieben: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.
(Nullterminierte Strings sind das letzte! Wenn ich die Länge von nem nullterminierten String wissen will, muß ich den abzählen, bis ich ne Null finde. Jedesmal. Und wenn da überhaupt keine Null ist, muß man noch ne zusätzliche Abbruchbedingung einbauen, damit er nicht irgendwoanders im Speicher rumgurkt... - Nur mal eine meiner Anmerkungen. Achja, und daß es nur ein mathematisches aber kein boolesches XOR gibt, find ich auch nervig.)
Ich hab ja nichts gegen HTML- oder XML-Leute. Auch sowas wird sicher gebraucht. (Hab meine Webseite auch selber gemacht.) Aber mit HTML kann man eben keine Programme schreiben, das ist nur so eine Art Darstellungs-Skript, um so'ne Art "Text deluxe - mit Bildern verziert" darstellen zu können. Weil aber das Befehlsformat von HTML dem eines Programms recht ähnlich sieht (Befehle, Parameter...), halten es manche für eine Programmiersprache. Mein Kumpel sagt zu solchen Leuten immer: "Wenn Du HTML für'ne Programmiersprache hältst, dann programmier doch mal eine Schleife damit." (Ist ja immerhin eine der Grundfunktionen einer Programmiersprache - bedingte und unbedingte Verzweigungen/Sprünge.)FPU hat geschrieben:Oder HTML *wääääääh*.
Und wehe man zeigt ihnen irgendwas in HTML, dann halten sie einen für den Oberprogrammierer...
Tja, mit irgendwas muß man es ja schließlich rechtfertigen, daß man sich alle halbe Jahre 'n neuen Rechner kaufen soll...FPU hat geschrieben: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.
Ja, ich weiß. Aber nun kann man nichts mehr dran ändern. Ich bin ja schon froh, daß die x86 wenigstens abwärtskompatibel sind und einigermaßen brauchbare Register haben. Aber die 68xxx (was auch die Power CPU eine ist) haben meines Wissens Register, wo man wirklich fast jedes mit jedem verketten kann, fast jedes als Indexregister benutzen, und so weiter. Das wäre natürlich cool, wenn das auf x86 auch so wäre - was könnte man für cooles Zeug damit machen... Naja. Die Leute, die noch nie Assembler programmiert haben, können wahrscheinlich gar nicht nachvollziehen, wovon wir hier quatschen...FPU hat geschrieben:Jaja... es hat sich halt mal wieder nicht das beste System durchgesetzt, sondern durch eine Verkettung unglücklicher Umstände so ziemlich das schlechteste
(Eins meiner nächsten Spiele soll zwar ein Raumschiffshooter werden - aber eher so SciFi-Arcade, ohne irgendeine Art von Kriegshintergrund.)
Naja, so Aracde Shooter sind einfach... praktisch. So Raumschiffshooter zu bedienen kapiert halt eben jeder:FPU hat geschrieben:Wir müssen wohl leider akzeptieren, das es in der Natur der Menschen liegt sich gegenseitig aus nichtigen Gründen umzubringen.
Steuere Raumschiff mit irgendwelchen 4 Richtungstasten. Wenn Feind in Sicht, hacke auf die Feuertaste, bis Feind weg. Wenn Feind zu stark und/oder zurückschießt, weiche aus. Steuere nicht an die Levelaufbauten. Und wenn irgendwas sich nicht bewegt und wie'n Bonus aussieht, fliege drüber und es ist Deiner... Dadurch macht es so'n Spaß, weil man eben nach spätestens 2 Minuten kapiert hat, wie das Spiel funktioniert. Es ist wie mit Tetris: Einfach zu begreifendes Spielprinzip und trotzdem stundenlang Freude - und selbst heute wird noch Tetris gespielt. (Ich hab übrigens auch schon eins gecodet...)
Naja. Bei Adventures muß man eher denken. Und mir gefiel z.B. Tomb Raider. (Hab nur 1. Teil, weil der noch für DOS ist.) Da muß man eben nicht nur ballern, sondern manchmal auch auf die Ballerei verzichten und wegrennen. Man kann es wahrscheinlich auch spielen, indem man unheimlich wenig ballert. Außerdem erfordert es Geschicklichkeit - z.B. für die komplizierten Sprünge. Und es erfordert Nachdenken - für die ganzen Fallen und Rätsel. Da hat sich wirklich mal einer Gedanken gemacht und ein neues Prinzip für 3D-Spiele erfunden. Und ehrlich gesagt: Die Ische da (Lara) is mir total egal, die is sowieso nicht mein Typ - aber das Spielprinzip bewies, daß man 3D eben auch intelligent machen kann.FPU hat geschrieben:Wie wärs mit mehr Spielen, in denen man mit Gewalt nicht weiter kommt sondern eher verliert?
Ich geb's ehrlich zu - ich spiele auch ab und zu mal DOOM (einziger 3D-Shooter, der mir etwas Spaß macht). Aber ich spiel das nur mal zwischendurch. Und ich nehme es nicht so ernst wie andere Leute so 3D-Shooter ernstnehmen. Außerdem bin ich Programmierer. Und schon alleine, weil es Software-3D-Programmierung ist, interessiert es mich.
(Übrigens: Hab mal selber ein Testprogramm gemacht, mit dem ich auch solche 3D-Levels darstellen kann. Habe da testweise mal die DOOM-Levels geladen und es funktioniert damit.)
Ja, die sind eben lebensnah...FPU hat geschrieben:Gibt da leider sehr viele Negativbeispiele für Spiele, wo man mit Gewalt weiter kommt...
Mir egal, was die Pseudos machen. Sollen die sich auf ihren Sch... doch einen runterh... Solange es auch noch gescheite Leute gibt, für die "Performance" nicht nur ist: "Wenn Programm zu langsam, kauf' Dir 'n schnelleren Rechner, weil ich zu faul zum Optimieren bin."FPU hat geschrieben: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).
Obwohl man sagen muß, daß es eher nicht an den Programmierern der Kommerzsoft liegt, warum da manchmal nicht ausreichend optimiert wird, sondern eher an den Firmen, für die die arbeiten. Da steht dann z.B. Weihnachten vor der Tür und die wollen das Game unbedingt raushaben, da sitzt dann die Zeit im Nacken und die geben das Teil raus, obwohl es noch nicht richtig debugged ist und obwohl die Coder da sicher noch optimiert hätten. Aber wenn man ein geldgeiler Produzent ist, interessiert einen nur die Kohle. Ich wette, die Publisher spielen nie selber Computerspiele. Denen ist es egal, ob das Ding gut oder weniger gut ist - Hauptsache, es sieht von außen gut aus und sie sind die ersten aufm Markt, die 'n neues Programm/Spiel raushauen. Hauptsache halt, die haben was zum Verkaufen.
Gefällige Optik ist mir meistens eher egal. Ich bin so Coder-Freak, ich stehe drauf, daß das Teil schnell ist und auch schnell bedienbar. Ich will Hotkeys, damit ich damit schnell arbeiten kann. Ein "Normaluser" müßte sich wohl erst an diese unkonventionelle Art, auf die meine (privaten) Tools funktionieren, einstellen. Schätze, 'n richtiger Freak hätte damit kein Problem.FPU hat geschrieben:... 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.
Alles, was man kann. Und was man (noch) nicht kann, versucht man, zu erlernen.FPU hat geschrieben:Was tut man nicht alles für mehr Effizienz?
Meine Sprites können gespiegelt, in 65536 Stufen vergrößert/verkleinert werden (Beispiel: 256 = normal, 64 = 1/4, 512 = 2fach). Sie können gespiegelt werden (x und y). Und sie können in 256 "Winkeln" gedreht werden. (Sieht man ja bei Xpyderz.)FPU hat geschrieben:Ganz so weit ist mein Zeug hier noch nicht. Das mit den Drehungen und Spiegelungen werd ich demnächst auch noch einbauen.
Im abgespeicherten Zustand werden sie leicht komprimiert. Im Speicher liegen sie unkomprimiert - live entpacken würde das Ganze Ding ja wahnwitzig lahm werden lassen.FPU hat geschrieben:Verwendest du für deine Daten auch noch eine Kompression?
Also das "Packen" beschränkt sich darauf, daß ich eben die Pixel 4bit habe, so daß 1 Byte 2 Pixel enthält. Meine File-Unit kann während des Speicherns packen und während des Ladens entpacken. Man stellt einfach den Pack-Modus ein. Man kann statt Pack- auch Verschlüsselungs-Modi einstellen.
Naja, wie gesagt, ich verwende leichte Kompression, meist kaum mehr als eine Art Lauflängenkodierung. Mein "DBM" Format ist ein "Bildformat" für "durchsichtige" Logos, das hat eine etwas stärkere Kompression und wird live entpackt und angezeigt. (Das ist z.B. das Format, in dem das Xpyderz-Logo vorliegt.)FPU hat geschrieben:Oder hast du die Daten so zusammengedampft, das eine Kompressions nichts mehr bringt?
Das war nicht meine Absicht! Hör' bloß nicht auf zu coden! Bin froh, daß es noch 'n anderen gibt, der DOS-Spiele schreibt. Würden wir dieselbe Programmiersprache benutzen, könnten wir uns gegenseitig Codeschnipsel geben... Aber C und Pascal sind ja nicht kompatibel... (Obwohl ich schon Pascal-Zeug - von Hand - in C umgesetzt habe.)FPU hat geschrieben:Ich lass einfach dich mein Spiel machen - ich bin nun demotiviert.
Tja, leider. Aber ich seh es so: Ein Game, das sowieso nur für'n PC gedacht ist, braucht man nicht systemübergreifend coden. Das verringert nur die Ausführungsgeschwindigkeit und erhöht den Ressourcenverbrauch (Speicher, Leistung) - ohne wirklichen Nutzen.FPU hat geschrieben:Jaja... wir stammen halt noch aus dem vorigen Jahrtausend.
Heute ist Kompatibilität bis zum Erbrechen wichtiger als Geschwindigkeit und Effizienz.
Tja, frag mal, wer noch.FPU hat geschrieben:Ich fänds unheimlich knuffig wenn man z.B. moderne 3D Karten ohne die ganzen Zwischenschichten direkt ansprechen könnte... mehr Speed ginge nicht.
Naja, sowas code ich Dir auch ohne Hardware-3D-Grafikkarte. (Hab ich im Prinzip schon.)FPU hat geschrieben:So ein rotierender texturierter Hardwarebeschleunigter Würfel in 3D unter Dos (Realmode)... das hätte was.
Man will nicht, daß die Leute selber Ahnung haben. Man will, daß die Leute blöd sind und sich alles sagen lassen. Dann kann man sie nämlich auch viel leichter verarschen...FPU hat geschrieben: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.
Deswegen will man auch nicht, daß Leute in irgendner vernünftigen Sprache coden lernen. Dann müssen sie nämlich immer teure Software kaufen - und nicht, wie ein Computerfreak es machen würde, sich 'n kleines Tool mal eben schnell selber coden können.
Aber was soll's. Es hilft auch nichts, darüber zu lamentieren. Man muß eben einfach durch eigene Taten beweisen, daß es noch Leute auf der Welt gibt, die nicht für jede Art Programm/Spiel 'n Rechner mit exorbitanter Hardware brauchen. Ich find's nämlich auch seltsam, daß 2D-Arcade-Spiele schon aufm alten Nintendo und aufm C64 gingen und man heute für Spiele, die kaum besser aussehen, irgendwas im GHz-Bereich braucht - nur, weil man sie eben in irgendwelchen Skripten basteln muß...