Eigenes Videoformat

DOSferatu
DOS-Übermensch
Beiträge: 1196
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Eigenes Videoformat

Beitrag von DOSferatu »

zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich plane schon länger, mal einen Inline-Assembler direkt für Pascal-Sourcen zu coden, der alle Befehle assembliert, aber nur, wenn er erkennt, daß es >=386er Befehle sind, diese dann "inlined" (als Bytes/Words/DWords) hinschreibt und dahinter auskommentiert {...} den vorher eingegebenen ("echten") Befehl.
Exakt die Idee hatte ich auch, aber wenn Du das machst überlasse ich das Dir, ich traue Dir da mehr zu.
Naja, zuviel der Ehre. Schauen wir erstmal, wie es wird. Obwohl ich wirklich sagen muß, daß ich so Parser-Zeug inzwischen im Halbschlaf mache. Muß bloß mal genug Zeit+Lust finden. Aber inzwischen ist es eben auch für mich so, daß ich immer mehr von dem 32bit-Zeug benutze und da wäre es auch für mich selbst weniger aufwendig, statt immer das Mod-R/M-Byte manuell hinzumurksen, das mal zu automatisieren. Wofür hat man schließlich 'n Computer?
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, die ASM86FAQ sollte man unbedingt immer griffbereit haben. Unverzichtbares Werk, IMO.
Benutzt Du da auch, so wie ich, meine FAQREAD.EXE?
Gut, im EGA-Modus zieht der FAQREAD gleich auf. Bisher war vor allem die Wortsuche im simplen Windows-Editor blitzschnell, und man kann nach oben wie nach unten suchen.
Bemerkungen dazu:
Wenn man im FAQREAD einfach irgendwelche Buchstaben- oder Zifferntasten drückt, geht automatisch die Eingabe für die Suchfunktion an, mit dem Zeichen als erstem Zeichen drin. Mit Leerzeichen auch, aber da steht dann die letzte Sucheingabe drin.

Als Somderfunktion extra drin: Wenn man mind. bei diesem ersten Zeichen Shift gedrückt hält, wird automatisch die senkrechte Linie (ASCII 179) und ein Leerzeichen davor gesetzt und dann erst das Zeichen. Das dient dazu, schneller die Befehle zu finden, weil die ja immer in so Rahmen stehen. (Bei den bedingten Sprüngen muß man nach JCC suchen, weil der das in ASM86FAQ zusammengefaßt hat für alle.)

Wenn man nur Enter drückt, wird die letzte Suche ab aktueller Stelle wiederholt, d.h. fortgesetzt.

Und ja, man kann nicht rückwärts suchen, aber: Wenn man Pos1 drückt, wird an den Anfang des "aktuellen" Textes gewechselt (also wenn man z.B. eine Sektion ausgewählt hat, dann an diese Sektion. Um an den Anfang des GANZEN Textes zu wechseln, muß man Strg+Pos1 drücken.

Beispiel, wenn man in der Befehlssatz-Sektion drin ist (wo die ganzen ASM-Befehle drin stehen:
Pos1 Shift+MOV Enter
Und er geht an die Stelle, wo | MOV steht.

FAQREAD ist ja, im Gegensatz zu anderen Viewern/Editoren direkt an ASM86FAQ.TXT angepaßt und hat deshalb entsprechende "Sonderfunktionen".

Na egal. Ich will Dir das nicht aufdrängen - wollte es nur erwähnt haben.
zatzen hat geschrieben:Aber der korrekten Ascii-Darstellung halber und auch um mir die Kapitel mal ordentlich gegliedert anzusehen, werde ich auch mal mit der FAQREAD arbeiten. Bloß wenn man nur mal eben schnell nochmal nachgucken will, wievel Zyklen ein Befehl wie und wann braucht, dann ist das einfach in meinem Fall über den simplen Windows-Editor direkter.
Ja, wie gesagt - siehe oben.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich kriege schon immer die Krätze von 0f531h -Hexzahlen, weil ich seit jeher die $f531 -Nethode gewöhnt bin... Da seh ich dann 'ne Zahl... und erst am Ende: Achso, ein h, also hex...
Das kann ich nachvollziehen, ich schreibe beim Programmieren z.B. auch alles klein und bin irritiert sobald jemand Großbuchstaben verwendet. Das macht es für mich irgendwie auch unleserlicher. Bei Assembler schreibe ich lieber so, wie es offiziell Standard ist mit den Hex-Werten, auch wenn es innerhalb Pascal ist. 0x???? ist wohl auch Standard (in Pascal wohl nicht), aber das finde ich wiederum hässlich und unleserlich.
Großbuchstaben - ja, die verwende ich oft für Register, um sie von allem anderen abzugrenzen. Und ich bin eher irritiert von diesem "alles kleinschreiben"... Für mich ist das so 90er-Jahre-Mist: Als "das Internet/WWW" so bekannt/beliebt wurde und man die URLs eingegeben hat (und immer alles klein), wurde das so "modern": Plötzlich hatte jeder Verein/jede Firma und jeder Hanswurst irgendwelche Firmennamen/Logos, die alles kleingeschrieben haben, weil "internetmäßig" und damit "cool". Ich fand das damals schon lächerlich und daran hat sich nichts geändert. Sogar beim Chatten achte ich auf Großschreibung und Grammatik. Ist bei mir so drin.

Zum "Hex-Standard":
Also erstens gibt es nicht *EINEN* offiziellen Standard für Angabe von Hex-Werten - und zweitens ist die $-Methode MINDESTENS so alt wie die andere - denn die ganzen 8-Bit-Kisten benutzen $.

Falls es Dich interessiert: 0x???? ist übrigens die Notation, die in C und Verwandte benutzt wird - und in allem, was seine Syntax von C ableitet. Und ja, ich finde diese ebenfalls häßlich. (Außerdem: Gleich ZWEI Zeichen, um das auszudrücken... Nerv.)
zatzen hat geschrieben:Wie Taktefressend das Markieren der Spritebereiche wird werde ich erst erfahren wenn ich mich um die Programmierung davon kümmere.
Klar, vorher kann man bei so komplexen Dingen sowieso keine gültige Aussage treffen. Bewiesen ist, was auf der Maschine funktioniert.
zatzen hat geschrieben:Erstmal bange ich um die Daten meiner wichtigsten Festplatte, weil so ein Billigstromkabel abgeschmort ist. Kurzschluss zum Glück im Kabel und nicht in der Platte, das macht Hoffnung.
Ui! Ich hoffe, es ist nichts Schlimmes? Ich hätte auch gerne noch ein paar Ersatz-Festplatten in Größe 8 GB - aber schätze, durch die derzeitige Retro-Welle sind die schwer zu kriegen, weil: Welcher DOS-Fan würde die nicht selber haben wollen?
zatzen hat geschrieben:
DOSferatu hat geschrieben:Du mußt natürlich trotzdem den restlichen Offset mit einbeziehen, auch wenn Du die unteren 16 Bytes davon ignorierst! Richtig ist:

Code: Alles auswählen

inc(blkinfo_seg,succ(blkinfo_ofs shr 4)); blkinfo_ofs:=0;
Danke! Aber 16 Byte mehr alloziieren ist korrekt, oder reichen auch weniger? Sorry falls die Frage dumm ist, aber ich meinte Du sagtest mal sowas.
Naja, wenn man genau drüber nachdenkt, würden 15 Bytes mehr reichen, nicht wahr? Nur, dann wäre der Code etwas komplizierter, da macht das eine Byte auch keinen Unterschied. Denn, wenn man mit nur 15 Bytes mehr reserviert, könnte man ja Glück haben und es landet auf einer ganzen 16er Adresse und braucht nicht "adden". Dafür würde der Code also dann lauten:

Code: Alles auswählen

inc(blkinfo_seg,(blkinfo_ofs shr 4)+ord(blkinfo_ofs<>0)); blkinfo_ofs:=0;
Nur, wie ich ja immer erwähne: Wir haben Von-Neumann-Computer. Code und Daten benutzen denselben Speicher. Wenn man 10 Bytes mehr Code benutzt, um an anderer Stelle 1 Byte Daten zu sparen, das klingt nicht nur sinnlos, das IST es auch. Relativ häufig ist mir in den letzten Jahren aufgefallen, daß man mitunter mit der simpelsten Lösung den meisten Speicher UND Performance einspart. Klingt komisch, ist aber so. Manchmal wurstelt man ewig rum, hat am Ende eine dicke komplexe Routine, die riesengroß ist, also keinen RAM spart und auch noch langsam ist, also keine Rechenzeit spart. Da fragt man sich am Ende: Wozu brauch ich die dann...

Zu GetMem und "16 Bytes mehr reservieren":
Allerdings habe ich mal irgendwo gelesen, daß Pascal bei GetMem immer nur in 8er-Schritten Speicher reserviert, so daß untere 4bit des Offset also nur 0 oder 8 sein könnten. Weiß aber nicht, ob das stimmt. Ich verlasse mich da auf nichts - und mit 8er-Offset kann man ja genausowenig anfangen wie mit den restlichen außer 0, wenn man ganze Segmentanfänge braucht.

Und beim Reservieren für "speziellen RAM" (Du weißt schon: Den für den DMA-Puffer für den Soundblaster) muß man sowieso noch etwas kreativer vorgehen, um nicht genau in die Arschritze des Speichers zu fallen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Man kann auch FS und GS direkt (mit Speicher) laden, da muß man auch nicht über Register gehen.
Das weiss ich, ich konnte nur dem Online Assembler keine konkreten Speicheradressen der Variablen übergeben...
Nur mal so für Dich

Code: Alles auswählen

db $8E,$26;dw Segment1 {=mov FS,Segment1}
db $8E,$2E;dw Segment2 {=mov GS,Segment2}
Gilt natürlich nur, wenn Segment1 und Segment2 globale Variablen sind (also an DS). Aber man kann ja auch hier den Segment Override Präfix nutzen, wenn der Kram woanders liegt. Naja, vielleicht bau ich wirklich mal diesen Pascal-Inline-Assembler, dann stellen sich diese Fragen nicht mehr.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, die Idee klingt zwar nett - aber ich wage blasphemischerweise zu glauben, daß man damit (gegenüber der "Einzelprüfung") nicht viel spart, weil der "kompliziertere" Test den Speedgewinn wieder auffrißt. Muß man sehen...
Ja, ich fand es erst gut, mit JCXZ mit 2 Takten direkt 2 Blöcke abfangen zu können, aber in der Praxis wird man stets mehr inaktive Blöcke haben als aktive, und daher sollte die Prüfung so ausgelegt sein, dass sie vor allem für den Fall "nichts tun" schnell ist.
Ja, immer auf den häufigeren Fall optimieren.
(Und ja, JCXZ kann zwar nützlich sein - aber weil es nur Short Jumps kann, muß man da manchmal zu viel Code "umbauen", um nicht außerhalb des Abstands zu geraten. Da muß man dann abwägen, ob etwas anderes an der Stelle praktischer ist.)

Wenn z.B. ein Fall selten genug passiert, kann sogar ein Raus-und-zurück-Springen (obwohl es 2 Sprünge sind) im Ganzen immer noch mehr performen als ein "Übersprung". Hatte ich ja schonmal erwähnt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Aber an der Stelle LEA, wo steht {obere 16 bit egal}... Egal sind die nicht. Im 16bit-Mode müssen bei so Adressierungen die oberen 16bit der Zieladresse =0 sein, sonst rastet die Maschine aus.
Wenn ich aber doch adressiere mit mit z.B. "mov eax, fs:[si+bp]", ist es dann nicht egal wie die oberen 16 Bit von ESI und EBP sind? Wenn doch, stünde das etwas konträr dazu dass Du z.B. sagtest, man könnte durch Rotation sogar einen zweiten Stack haben. Oder überhaupt, wenn ich mich jetzt nicht total irre, habe ich in meinem ZSM Player EBP verwendet als 16 Bit Adressierung, und die oberen 16 Bit für den Carry-Trick.
Wenn ich natürlich ein 32 Bit-Konstrukt habe wie "mov eax, fs:[ebx*8 + ebp]", dann ist das was anderes.
Ja, aber ich glaube, ich hatte das in Bezug auf eine Stelle in Deinem Text geschrieben, wo Du genau so eine ebx*8-Geschichte benutzt hast und dahinter als Kommentar {obere 16bit=egal} oder sowas. Wenn man natürlich normale 16-Bit-Adressierung benutzt, SIND die oberen 16bit egal (denn sonst würde der erwähnte "Carry-Trick" ja keinen Sinn machen, weil man den ja für "zählende" Register benutzt und die "zählen" ja meist deshalb, weil sie irgendwas indizieren sollen.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, Du optimierst immer ausgehend vom 486er, oder?
Ja. Das hat zum einen damit zu tun, dass ein 386er zu langsam für meine Vorhaben wäre, ein Pentium dagegen so schnell dass man praktisch fast auch ohne Assembler auskäme. Und Dosbox spielt mit rein, weil heutige Rechner und wohl sogar Smartphones in der Lage sind, einen 486er zu emulieren. Bei Smartphones bin ich mir aber nicht sicher.
Ach, was interessieren mich Smartphones... Und: So'n 486er ist 'ne ziemliche Powermaschine - wenn man da bis an die Ecken optimiert, ist es echt erstaunlich, was diese alten Kisten können!
zatzen hat geschrieben:
DOSferatu hat geschrieben:Naja, es gibt außer Performance noch andere Eckdaten, die ein Programm haben kann. Selbstredend könnte man auch 16000x mov EAX,ES:[xxx];mov DS:[xxx],EAX; machen und so - die totale Oberklasse des "kopiere 320x200 Screen" - aber, wie ich immer so sage: Trade-Off (Speicher/Performance)...
Das wäre Irrsinn bzw. gar nicht möglich. So ein unrolled Block für einen 8x8-Block, das sind 192 Bytes Kompilat, das mal 1000 und es passt überhaupt gar nicht mehr in ein Segment, und ein Drittel des ganzen Speichers ist futsch, wenn es denn möglich wäre.
Natürlich wäre das Irrsinn - Dir ist ja hoffentlich aufgefallen, daß ich obige Aussage nur gebracht habe, um zu verdeutlichen, daß man es, bei aller Optimiererei, auch bis zum völligen Blödsinn übertreiben kann. D.h. ich WOLLTE, daß auffällt, was das für ein Unfug wäre.
Um z.B. 20-100 Zyklen außerhalb einer Schleife zu sparen (die sich also nicht "vermultiplizieren" würden, weil nicht in Schleife), würde ich z.B. nicht mehrere kB Speicher opfern. Das meinte ich mit "Trade-Off Speicher/Performance)".
zatzen hat geschrieben:
DOSferatu hat geschrieben:OK, jetzt hast Du es wohl ENDLICH selbst mal gemerkt, wie wenig DOSbox als Benchmark geeignet ist.
Ja allerdings. Ich habe nur leider keinen 486, könnte nur einen Pentium wieder fit machen, aber das hilft mir dann auch in dem Fall nicht viel. Ich kann nur versuchen, möglichst performant zu programmieren, auch wenn ich es nicht sicher überprüfen kann. Es kann mir aber helfen, Feedback z.B. von Dir zu bekommen, wie geschehen bei ZSMplay oder dem ollen ZVID(1).
Ja, immer gern. Kein Problem. Wie gesagt: Ich will damit nicht nerven und keinesfalls DOSbox schlechtreden! DOSbox ist ein großartiges Programm, um damit DOS-Zeug überall laufen lassen zu können! Es ist eben nur, weil Emulator, auch optimiert und daher für Benchmarking zum Vergleichen mit echten Maschinen nicht so geeignet. Aber DOSbox ist ja auch kein Benchmark-Tool und soll es auch nicht sein.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Also: Zugriff auf RAM ist *kein* gleich-schneller Ersatz für Arbeit mit Registern. Punkt.
Was auf ne Weise ja eher erfreulich ist, dann fühlt sich die Arbeit mit Registern direkt wieder viel sinnvoller an.
Ja, und das gilt für JEDEN Rechner und JEDE CPU: Immer Register gegenüber RAM bevorzugen! RAM-Zugriffe sind IMMER langsamer als CPU-internes Zeug.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn man sowohl sowas will als auch Unroll-Performance, wäre es wohl am besten, so eine Art "Darstellungs-Skript" zu erfinden, wo die Sachen quasi von einem externen Tool in so ein Format "vorberechnet" werden und von einer simplen aber superschnellen Routine nur noch hingeballert werden müssen.
Das klingt interessant. Aber Du meinst nicht etwa dass Assembler-Code erzeugt wird?
Also naja: Man könnte irgendeinen Bytecode erzeugen, der dann interpretiert wird. Aber echte ASM-Opcodes wäre natürlich die Königsklasse. Nur sollte das Programm, das diese Daten/Code erzeugt natürlich keinen Mist bauen. Und es sollte "wissen", welche Register es zu benutzen hat - sonst könnte man das ja kaum irgendwo einbauen.

Will sagen: Echte Opcodes sind ja auch bloß Bytes. Da ist keine Magie drin - auch wenn es sich oft so anfühlt, wenn man sieht, wie die Kiste abgeht, sobald man mal mit Assembler draufhaut...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Immer diese quadratischen Pixel. Was ist daran so wichtig?
Unter anderem wären die auch praktisch wenn man mal was z.B. auf Youtube zeigen will. Entweder muss man dann die Aspect Ratio über Bord werfen oder man handelt sich bei niedrigeren Auflösungen ziemliche Unschärfen ein. Die heutige "Computerwelt" hat nunmal quadratische Pixel, deshalb wäre es einfach praktisch.
"Die heutige Computerwelt" kann mich mal kreuzweise. Ich baue mein Zeug für VGA/VESA/SB auf 486er. Wenn "die heutige Computerwelt" es nicht schafft, das gescheit darzustellen, ist mir das ja sowas von egal. Die fühlen sich doch immer so toll mit ihrem Windows und ihren Gigahertz/Terabyte-Kisten. Dann sollten sie doch kein Problem damit haben, Zeug von 30 Jahre alter Technik darzustellen... Wenn sie das nicht können, d.h. nichtmal eine simple Skalierung hinbekommen, dann sollten sie ihre Nasen etwas weniger hoch tragen.
zatzen hat geschrieben:So wichtig ist es mir aber gar nicht, sonst würde ich mich aufs emsigste mit Mode-X beschäftigen. WENN ich dann mal ein Video von nem Spiel auf Youtube hochladen will darf ich dann eben nicht vergessen, die 320x200 auf z.B. 1440x1080 zu resamplen. Das klingt nach Verschwendung, aber auf Youtube kursieren längst Videos mit 4K und höher. Und es gibt da auch so Leute die 320x200 Spiele mit KI auf HD "upscalen". Ganz interessant.
Naja, das ist ja nur nötig, weil keine CRTs mehr benutzt werden, die das alleine so darstellen wie es muß, sondern diese TFTs und so Zeug, wo jede niedrigere als die Maximalauflösung immer irgendwie scheiße aussieht und man deshalb da software- (oder mittlerweile auch hardware-) mäßig interpolieren muß, um die Abscheulichkeit etwas abzumildern.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Also, wenn Du *DAS* schon schöne Grafik findest, hast Du, was Grafik angeht, wirklich außerordentlich niedrige Ansprüche.
Kommt immer drauf an. Ich hab viel am C64 gesehen was dagegen lieblos wirkte.
Naja, ich hab mir schon Mühe gegeben, damals (vor 27 Jahren!). Aber ich bin nunmal kein talentierter Grafiker und da hab ich schon wesentlich besseres gesehen - auch am C64.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Hab Zelda nie gespielt.
Ein Blätterer. Ich war fasziniert weil es das erste Spiel war das mir untergekommen war, wo man in alle vier Himmelsrichtungen die Welt erkunden konnte. Da war ich aber falsch motiviert, denn es ist ein Action-Spiel und es sowas kostet mich nerven. Hätte ich mal lieber direkt Point & Click Adventures entdeckt, aber sowas gab es lange auf dem NES nicht. Das erste dort war wohl Maniac Mansion.
Ach, ich hab nichts gegen Actionspiele. Nur diese sog. "rundenbasierten Kampfsysteme" und allgemein so Rollenspiel-Kram geht mir so richtig aufn Keks. Aber, auch wenn ich's nicht gespielt habe, weiß ich natürlich, wie Zelda aussieht.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[TheGame3-GUI]Ich könnt's Dir ja mal schicken, damit Du siehst, wie es aussieht und ob Du damit arbeiten könntest/würdest. Aber ich vermute, Du würdest das sowieso nicht anfassen.
Ich kann es mir gerne ansehen. Nur würde ich nicht anfangen wollen damit etwas zu basteln. Das wäre anders wenn ich nur möglichst bald ein Spiel machen wollen würde egal wie, und ohne meine eigenen Techniken.
Naja, die Daten die das Ding auswirft, könnt man ja auch konvertieren, falls man das anders braucht. Ich bin sowieso immer mehr ein Freund von externen Konvertern geworden - weil, wenn man in ein Tool quasi so "eierlegende Wollmilchsau"-mäßig das alles einbaut, dann wird das Ding groß und langsam und belegt für seinen Code viel Speicher, den man lieber gern mit Daten belegen würde.

Aber ich muß da vielleicht nochmal dran - inzwischen mag ich das Ausgabeformat auch nur noch so halb, weil ich ja diese flexibleren Levels will (hatte das mal erwähnt).
Aber ich hau das einfach mal rein:
http://www.imperial-games.de/z/thegame3.zip
zatzen hat geschrieben:Du kennst vielleicht auch AGS (zum Point & Click Adventures machen). Das Ding hat ne dicke Anleitung, da muss man sich richtig reinknien. Ich hatte mich schonmal drangesetzt weil ich wirklich mal dachte, ich mache ein Adventure, hauptsache das Spiel wird fertig.
Kenn ich nicht. Habe aber mal selber sowas angefangen damals, das hieß naheliegenderweise auch AGS (=Adventure Game System). Ich sag's mal so: Ein Adventure-Bau-System könnt ich heutzutage noch leichter bauen als das, was ich derzeit so mache. Ich wüßte genau, wie ich ein Point&Click Adventure technisch bauen würde. Vielleicht mach ich auch mal irgendwann ein Adventure. Eine Idee dafür hab ich auch schon seit fast 30 Jahren.
zatzen hat geschrieben:Aber dann hab ich mir gedacht, bevor ich jetzt Wochen damit zubringe, dieses Programm zu lernen, da programmiere ich lieber selber von Grund auf.
Klar - ich bau auch lieber mein eigenes Zeug. Mir geht's ja (genau wie Dir) nicht nur darum, mit allen Mitteln Hauptsache ein Spiel fertig zu kriegen, sondern natürlich auch, das alles selbst zu machen, um sich dabei zu entwickeln und zu lernen. Immer nur fertiggemachtes Zeug zu benutzen - das ist was für Nicht-Coder...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Deshalb jetzt also - standesgemäß für'n echten DOS-Fan! - ein Texteditor im 80x25-Zeichen-Textmode!
Könnte natürlich auch für mich praktisch sein, trotz Emulator. Kommt nur drauf an, wie man den Text reinbringt, auf den man antworten will. Ich kopiere direkt aus dem Forum in den Editor, muss dann aber alle Tags per Hand schreiben.
Naja, im Forum gehe ich auf zitierte Antwort und kopiere dann aus dem Eingabefeld das raus - dann sind die Tags drin. Und den Text editiere ich dann extern in meinem Editor und dann überschreibe ich das aus dem Eingabefeld später mit dem selbsteditierten Text.

Habe natürlich Hotkeys hier drin, um automatisch diese Fett/Unterstrichen/Kursiv zu setzen und auch Code und Quote. Der merkt sich beim Einlesen auch den ersten Quote-Tag (der dann auch den Nick enthält und so), so daß man den immer wieder benutzen kann... Weiß nicht, ob ich es gut genug erklären kann.

Na jedenfalls färbt er, farbig aufsteigend, gequoteten Text ein, so daß man gleich sieht, ob man irgendwo vergessen hat, einen quote oder anderes Tag zu schließen usw.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Sobald Du dann auch mal einen 4000000000 Zeichen langen Text damit tippst, gebe ich zu, daß das nützlich ist.
Darauf komme ich gerne in etwa 5000 Jahren zurück.
Ich kann natürlich nicht in die Zukunft sehen, aber basierend auf statistischen Daten vermute mal, daß ich dann tot sein werde.
zatzen hat geschrieben:Vielen Dank für Deinen 0-255 begrenz- bzw. saturier- Code. Da wäre ich wohl so nicht drauf gekommen.
Immer wieder gern. Ich freue mich ja auch, wenn jemand mal *richtig* programmiert - also nicht in irgendwelchem Interpreter- und/oder Skriptmist.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Kleiner Tip: Alles, was wie NEG zwei oder mehr Register setzt, kann man danach z.B. mit LAHF abfangen:
SIGN ist Bit7, Zero ist Bit 6, Bit5 ist immer=0... Nur mal so:

Code: Alles auswählen

lahf
mov BX,AX
shr BX,13
mov/and/or/xor irgendwas,CS:[@TABLE+BX]...
Wie findst'n das?
Und wenn man nach lahf noch ror ah,1 macht, hat man Bit7=Carry, Bit6=Sign, Bit5=Zero, Bit4=0... Und kann danach mit 'nem indizierten Sprung oder so per Entscheidungstabelle quasi 'ne Menge Kram abdecken...
(Anm.: Hatte mich da übrigens verschrieben, meinte natürlich Flags. Aber Du hast ja verstanden, was ich meinte.)
zatzen hat geschrieben:Das werde ich in Zukunft berücksichtigen, da ergeben sich ja wirklich neue Möglichkeiten, mit Flags direkt in eine Tabelle reinzugehen. Nur konkret für die Blockprüfung geht es wohl nicht schneller als ein Word einzulesen und dann auf sign/carry und parity zu prüfen.
Ja, selbstverständlich muß man immer den konkreten Fall berücksichtigen. Wenn man eine an sich coole Idee hat, dadurch aber nichts gewinnt oder spart, ist die Idee vielleicht trotzdem cool - nur für den aktuellen Fall nicht brauchbar.
zatzen hat geschrieben:Aber man lernt immer noch dazu von Dir. Gerade eben wurde auch mir klar, dass "jmp CS:[@TABLE+BX]" wohl auch gültig ist.
Ja, in Pascal muß man da "jmp CS:word ptr[@TABLE+BX]" schreiben. Man muß da öfter mal "word ptr" oder "byte ptr" schreiben, auch wenn es eigentlich klar ist, daß es selbsterklärend ist, weil es im aktuellen Fall für gar keine andere Wortbreite definiert ist. Aber irgendwann gewöhnt man sich's eben an...
zatzen hat geschrieben:Würdest Du sagen dass es besser ist einen Tabellensprung so zu formulieren anstatt erst ein Register mit "CS:[@TABLE+BX]" zu beladen und dann "jmp REG"? Man könnte ja meinen man spart einen Zyklus und braucht kein extra-Register bzw. kann BX hier auf seinem Wert belassen.
Da würde ich nie eine generelle Aussage dazu treffen, sondern: Hängt immer vom Fall ab. Beispiel: Man braucht den Sprung nur einmal. Dann natürlich gleich springen, ohne vorher noch ein Register laden und normal jumpen. Anders sieht's dann wieder aus, wenn man den gleichen Sprung öfter/mehrmals braucht. Da macht's natürlich Sinn, den Ergebniswert gleich in einem Register liegen zu haben. Kommt dann aber auch wieder drauf an, ob man noch ein Register übrig hat.

Und Du kennst mich ja: Wenn mir die Register ausgehen, fang ich an, selbstmodifizierenden Code zu fabrizieren. "Multitasker" sehen das aus naheliegenden Gründen gar nicht gerne und finden das "unsauber". Aber was interessieren die mich?
zatzen hat geschrieben:
DOSferatu hat geschrieben:Vor 'ner Weile (letztes Jahr, kurz bevor das alte Coding-Board geschlossen wurde), hatten die mal so Wettbewerb, mit möglichst kompliziertem undurchsichtigem Code irgendwas zu machen, z.B. "HELLO WORLD" auszugeben. Mein Beitrag war in 100% Assembler. Falls Interesse, kann ich das ja, inkl. Source, mal hochladen...
Ja, warum nicht. Vielleicht blicke ich ja doch ein klein wenig durch und kann noch was lernen. Was man so im Netz an Assembler findet ist meistens so trivial und ineffektiv wie meine ersten Assembler Programme Ende der 90er.
Naja, der Witz dran sollte ja sein, daß der Code möglichst undurchsichtig und aufwendig ist. Da ist 'ne Menge unnötiges Voodoo drin und manches absichtlich ineffizient gemacht, damit man schwerer durchschaut, was es macht...

Na, ich häng's mal an. Kannst es Dir ja compilieren und sehen, was es tut. Und dann den Kram auseinandernehmen um zu sehen, was es macht, um das zu tun. Ich sag's nur vorher: Falls Du keine Lust hast, von kryptischem Code genervt zu sein, dann tu es Dir nicht an.
http://www.imperial-games.de/z/hello.zip
Benutzeravatar
zatzen
DOS-Kenner
Beiträge: 476
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Eigenes Videoformat

Beitrag von zatzen »

Sorry dass so viel Zeit vergangen ist.
Ich war noch beschäftigt mit neuen (naja, Hardware von 2013) Computer fit machen und dann habe ich für einen Freund noch ein Tool in Freepascal gemacht.
DOSferatu hat geschrieben:Obwohl ich wirklich sagen muß, daß ich so Parser-Zeug inzwischen im Halbschlaf mache.
Vielleicht kannst Du mir ein paar kleine Tipps geben, wie man am elegantesten eine XML parst. Im oben genannten Tool verarbeite ich .NIF Dateien, die enthalten Rohgrafiken und Definitionen für 3D Objekte, und es scheint so als wären die ähnlich wie XMLs, nur Binär. Scheinbar keine Längenangaben zu den Chunks, dafür sind die Chunknamen deutlich länger als 4 Bytes, so dass es unwahrscheinlicher wird dass sie zufällig entstehen.
DOSferatu hat geschrieben:[FAQREAD]Na egal. Ich will Dir das nicht aufdrängen - wollte es nur erwähnt haben.
Ja, es ist ein tolles Tool das ich auf einem reinen DOS-Rechner sicher benutzen würde. In einer Windows-Umgebung wo ich zwei Dos-Box'en laufen haben müsste um in einem Fenster programmieren zu können und im anderen das FAQREAD zu haben setzt sich pragmatisch dann doch eher der simple Editor als Betrachter durch. Das wäre anders wenn Windows noch 16 Bit Code unterstützen würde.
Ich denke es ist keine Schande wenn ich gestehe dass ich die Nutzung von Multitasking während der Softwareentwicklung praktikabel finde. Ich kann einen guten Hex-Editor (z.B. HxD) geöffnet haben und er updatet automatisch die geöffneten Dateien in die mein Programm schreibt, so kann ich sehr bequem debuggen ohne Programme ständig umschalten, beenden oder starten zu müssen. Und selbst wenn ich in Freepascal programmiere kann ich mir parallel ein Konsolenfenster (cmd) öffnen und bei einem Programm mit Parametern diese einfach dort eintippen (mit dem Komfort der Kommandozeile), und muss das nicht umständlich in der IDE tun.
Die Lösung was FAQREAD betrifft wäre eine 32 Bit Windows Version, evtl. mit Freepascal gemacht. Aber natürlich können wir uns einig darüber sein, dass tatsächlich Windows bzw. die Prozessorentwickler die Übeltäter sind, weil sie keine 16 Bit mehr unterstützen. Mutmaßlich hat das aber auch technische bzw. Performance-Gründe, und nicht nur verkaufspolitische.
DOSferatu hat geschrieben:Großbuchstaben - ja, die verwende ich oft für Register, um sie von allem anderen abzugrenzen. Und ich bin eher irritiert von diesem "alles kleinschreiben"...
Es ist alles Gewöhnung, zumindest bei mir. Ich habe angefangen mit QBASIC, und als ich auf Pascal umgestiegen bin fand ich es erstmal komisch dass Schlüsselwörter nicht komplett aus Großbuchstaben bestehen müssen. Ich habe wohl letztlich in Pascal aus Bequemlichkeit alles klein geschrieben und mich dann an dieses Schriftbild gewöhnt. Ein Grund ist bei mir auch noch, dass ich lieber alles klein schreibe als dass ich hinterher aus Flüchtigkeit etwas mal klein und mal groß schreibe, was den Compiler nicht kümmert , aber die optische Konsistenz des Codes beeinträchtigt. Und da lege ich schon Wert drauf dass ich mich da auch später noch zurechtfinde, deshalb rücke ich auch ein - mir hilft sowas.
DOSferatu hat geschrieben:Sogar beim Chatten achte ich auf Großschreibung und Grammatik.
Mach ich seit einiger Zeit auch so. Nur beim Programmieren lieber klein. Es gibt ja so gesehen keine Rechtschreibregeln für Code.

Hex-Werte ich Assembler-Blöcken schreibe ich ganz gerne als 0????h. Das unterstreicht für mich dass ich mich sozusagen nicht in einem Pascal-Teil befinde. Das ist vielleicht bei mir so durchgerieselt weil ich ein Assembler-Buch habe wo das so empfohlen wurde.
DOSferatu hat geschrieben:Falls es Dich interessiert: 0x???? ist übrigens die Notation, die in C und Verwandte benutzt wird - und in allem, was seine Syntax von C ableitet. Und ja, ich finde diese ebenfalls häßlich. (Außerdem: Gleich ZWEI Zeichen, um das auszudrücken... Nerv.)
C muss man mögen. Es ist wohl schnell zu schreiben, aber würde bei mir wiederum Gewöhnung erforden. Ich bin früher mal in die Situation gekommen etwas in C zu programmieren, besonders angenehm fand ich das nicht.
DOSferatu hat geschrieben:[FestplattenStromSteckerSchmor]Ui! Ich hoffe, es ist nichts Schlimmes?
Zum Glück hat die Platte keinen Schaden genommen.
DOSferatu hat geschrieben:Nur, wie ich ja immer erwähne: Wir haben Von-Neumann-Computer. Code und Daten benutzen denselben Speicher. Wenn man 10 Bytes mehr Code benutzt, um an anderer Stelle 1 Byte Daten zu sparen, das klingt nicht nur sinnlos, das IST es auch.
Guter Punkt. Man sollte immer auch die Größe des Programms im Hinterkopf haben wenn man überlegt ein paar Bytes in irgendwelchen Datenfeldern sparen zu wollen.
DOSferatu hat geschrieben:

Code: Alles auswählen

db $8E,$26;dw Segment1 {=mov FS,Segment1}
db $8E,$2E;dw Segment2 {=mov GS,Segment2}
Danke! Das Wissen könnte mir der Online-Assembler natürlich nicht vermitteln.
DOSferatu hat geschrieben:Wenn z.B. ein Fall selten genug passiert, kann sogar ein Raus-und-zurück-Springen (obwohl es 2 Sprünge sind) im Ganzen immer noch mehr performen als ein "Übersprung". Hatte ich ja schonmal erwähnt.
Ich kann es ja nicht anders angehen. Die Blöcke werden geprüft, für den Fall Block inaktiv wird zum nächsten Prüfschritt einfach ohne was zu tun weitergegangen, wenn ein Block aktiv ist muss dann aber zu einem speziellen Punkt gesprungen werden, der Parameter und Rücksprungadresse setzt, dann wird zu Blockanzeigeroutine gesprungen, und die springt zurück über die Rücksprungadresse zum nächsten Blockprüfschritt.
DOSferatu hat geschrieben:Also naja: Man könnte irgendeinen Bytecode erzeugen, der dann interpretiert wird. Aber echte ASM-Opcodes wäre natürlich die Königsklasse. Nur sollte das Programm, das diese Daten/Code erzeugt natürlich keinen Mist bauen. Und es sollte "wissen", welche Register es zu benutzen hat - sonst könnte man das ja kaum irgendwo einbauen.
Das mit den Registern könnte man ja klären, angenommen diese erzeugten Codes sind "Unterprogramme" von z.B. den Blockanzeigeroutinen. Also müsste man dann im Code eine gewisse Menge an Speicher freihalten, wo man dann den speziellen Code reinkopiert und dann ausführt. Aber ob das dann wirklich Geschwindigkeitszuwachs bringt? Jedenfalls eine interessante Sache, so könnte man eben halbwegs intelligent optimierten Code erzeugen, der die Bilddaten direkt in sich trägt und formuliert anstatt sie von A nach B zu kopieren. Wie das genau geht, ob man vom Heap ins Codesegment kopieren kann, weiss ich nicht.
DOSferatu hat geschrieben:[hochskalieren]Naja, das ist ja nur nötig, weil keine CRTs mehr benutzt werden, die das alleine so darstellen wie es muß, sondern diese TFTs und so Zeug, wo jede niedrigere als die Maximalauflösung immer irgendwie scheiße aussieht und man deshalb da software- (oder mittlerweile auch hardware-) mäßig interpolieren muß, um die Abscheulichkeit etwas abzumildern.
Ja, einfaches Interpolieren ist das eine, mit KI hochskalieren etwas anderes.
https://youtu.be/HUwi6HnkH9I
Davon kann man halten was man will, aber auf eine Weise interessant ist es schon. Wobei ich sagen muss dass ich ein Fan von 320x200 (oder x240) Pixelgrafik bin und nicht das Bedürfnis nach "remaster" Editionen habe.
DOSferatu hat geschrieben:Ach, ich hab nichts gegen Actionspiele.
Ich auch nicht. Nur einige von Nintendo waren mir irgendwie zu stressig. Commander Keen auf den PC ist zum Beispiel sehr gemütlich.

TheGame3:
Da stehe ich erstmal natürlich nur wie ein dummer User davor und verstehe nicht viel. Da könnte ich mich auch erst richtig reinknien wenn es ernst wird, ich also damit wirklich ein Spiel machen wollte. Auf jeden Fall ein in seinem Umfang beeindruckendes Programm, aber das einzige was ich bisher konnte (auch klar, ohne jegliche Grafikdaten) war "PlayLevel" - wiederum beindruckend das scheinbar beliebig große Level, scrollend in alle vier Himmelsrichtungen.
Bei meinem ollen Kotzman II war der Level-Editor sehr simpel, über wenige Shortcuts bedienbar und nur auf die Levels zugeschnitten. Es war nur die (auch sehr simple) Spielengine, alles hardgecodet, schnell um eine Editierfunktion ergänzt, die dann im Spiel nicht mehr drin war.

Kryptisches "Hello World":
Also bevor ich mir den Code näher ansehe, müsste ich da erstmal sehr viele Zeilenumbrüche einfügen... Und wenn ich da einfach mal die ersten Befehle lese, wird deutlich dass man sich wohl Notizen über die Registerinhalte machen muss um das ganze verfolgen zu können.
Interessant finde ich aber auch das Resultat, wenn ich das richtig interpretiere ist das im standard Textmodus gehalten mit modifiziertem Zeichensatz, und man merkt es zuerst eigentlich gar nicht.
DOSferatu
DOS-Übermensch
Beiträge: 1196
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Eigenes Videoformat

Beitrag von DOSferatu »

zatzen hat geschrieben: Fr 4. Sep 2020, 23:43 Sorry dass so viel Zeit vergangen ist.
Ich war noch beschäftigt mit neuen (naja, Hardware von 2013) Computer fit machen und dann habe ich für einen Freund noch ein Tool in Freepascal gemacht.
Ja, das Restleben. Wobei "Tool in Freepascal machen" ja nicht Restleben ist. Das ist ja wertige Zeit.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Obwohl ich wirklich sagen muß, daß ich so Parser-Zeug inzwischen im Halbschlaf mache.
Vielleicht kannst Du mir ein paar kleine Tipps geben, wie man am elegantesten eine XML parst. Im oben genannten Tool verarbeite ich .NIF Dateien, die enthalten Rohgrafiken und Definitionen für 3D Objekte, und es scheint so als wären die ähnlich wie XMLs, nur Binär. Scheinbar keine Längenangaben zu den Chunks, dafür sind die Chunknamen deutlich länger als 4 Bytes, so dass es unwahrscheinlicher wird dass sie zufällig entstehen.
Ich kenne keine .NIF Dateien. Wenn Du da etwas konkreter wirst oder mir ein Beispiel schickst, kann ich mal sehen, ob ich da was machen kann - aber versprich Dir da mal nicht zu viel. BINÄRE Files zu analysieren ist natürlich etwas aufwendiger als textbasiertes Zeug (wie z.B. Sourcecodes). Bei Binärfiles muß man oft mal "raten" und kann natürlich nicht voraussehen, ob es da bestimmte Optionen gibt, die nur in dem Beispielfile nicht vorkommen, aber theoretisch vorkommen könnten.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[FAQREAD]Na egal. Ich will Dir das nicht aufdrängen - wollte es nur erwähnt haben.
Ja, es ist ein tolles Tool das ich auf einem reinen DOS-Rechner sicher benutzen würde. In einer Windows-Umgebung wo ich zwei Dos-Box'en laufen haben müsste um in einem Fenster programmieren zu können und im anderen das FAQREAD zu haben setzt sich pragmatisch dann doch eher der simple Editor als Betrachter durch. Das wäre anders wenn Windows noch 16 Bit Code unterstützen würde.
Ja, schon klar.
zatzen hat geschrieben:Ich denke es ist keine Schande wenn ich gestehe dass ich die Nutzung von Multitasking während der Softwareentwicklung praktikabel finde.
Doch! Schande! Häresie! ...
Ach, mir doch egal, wie Du das machst. Wenn's Dir hilft...
zatzen hat geschrieben:Ich kann einen guten Hex-Editor (z.B. HxD) geöffnet haben und er updatet automatisch die geöffneten Dateien in die mein Programm schreibt, so kann ich sehr bequem debuggen ohne Programme ständig umschalten, beenden oder starten zu müssen. Und selbst wenn ich in Freepascal programmiere kann ich mir parallel ein Konsolenfenster (cmd) öffnen und bei einem Programm mit Parametern diese einfach dort eintippen (mit dem Komfort der Kommandozeile), und muss das nicht umständlich in der IDE tun.
Ach, ich bau mir da meist einfache BAT-Files zum Testen, die das Ding mit so Testparametern aufrufen. WINDOWS und das ganze Zeug habe ich beim Programmieren wirklich noch nie vermißt.
zatzen hat geschrieben:Die Lösung was FAQREAD betrifft wäre eine 32 Bit Windows Version, evtl. mit Freepascal gemacht.
Ach, mir ist es ja egal, wer mein Zeug benutzt - war ja nur eine Anmerkung. Wer den Kram nicht benutzen kann, weil er keine DOS-Programme (mehr) ausführen kann, benutzt eben Alternativen. Es ist ja nicht so, daß die Grütze, die ich hier baue die softwaremäßige Traumerfüllung ist.
zatzen hat geschrieben:Aber natürlich können wir uns einig darüber sein, dass tatsächlich Windows bzw. die Prozessorentwickler die Übeltäter sind, weil sie keine 16 Bit mehr unterstützen. Mutmaßlich hat das aber auch technische bzw. Performance-Gründe, und nicht nur verkaufspolitische.
ICH denke, es sind NUR verkaufspolitische Gründe und künstliche Obsolität.
286er: (fast) 100% abwärtskompatibel zu 8086+186
386er: (fast) 100% abwärtskompatibel zu 8086+186+286
486er: (fast) 100% abwärtskompatibel zu 8086+186+286+386
Pentium... usw...
Jahrelang haben die es hinbekommen. Aber HEUTE, wo Prozessoren im GHz-Bereich agieren und schon 8 Kerne haben usw., soll das nicht mehr möglich sein?

Ich kann Dir sagen, woran es liegt: Inzwischen lassen sich die Prozessorhersteller von den Dumpfbacken bei Microsoft gängeln. Intel hatte den Protected Mode erfunden, der Speicherzugriff auf den Gesamtspeicher (bis 4GB) ermöglichte und zusätzlich Speicherschutzfunktionen usw. Und irgendwann war MS das zu kompliziert und die benutzen jetzt nur noch so ein "Flat Memory Model" - ja, im Prinzip sowas, was die DOS-Typen damals mit diesem Flat-4G-Mode gemacht haben. Das hebelt natürlich jeden hardwaremäßigen Speicherschutz aus, also supporten die neueren Windows nur noch CPUs, die dieses NX-Bit haben ("NX="Not eXecute") um trotzdem noch eine Art Speicherschutz zu haben, weil sie ZU FAUL sind, den abwärtskompatiblen Protected Mode zu supporten. Und so einen Flat-Mode kann man natürlich nicht mehr 100% kompatibel zum Real-Mode kriegen...
D.h. man könnte es schon: Die CPUs sind so schnell, daß die sogar hardwaremäßig in irgendeiner Ecke der CPU eine alte 286/386/486 "emulieren" könnten. Aber da haben MS und Konsorten ja wieder Angst, daß irgendwelche Virenschreiber das exploiten könnten. D.h. die neuen Modes sind an Dummheit und Faulheit angepaßt - mit Performance hat das nichts zu tun.

Ginge es um Performance, hätte man ja irgendwann mal den Eindruck, daß ein Windows auch mal schneller werden würde. Ich muß auf Arbeit diesen Windows 10 Dreck benutzen und es ist die reine Pest.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Großbuchstaben - ja, die verwende ich oft für Register, um sie von allem anderen abzugrenzen. Und ich bin eher irritiert von diesem "alles kleinschreiben"...
Es ist alles Gewöhnung, zumindest bei mir.
Natürlich ist es Gewöhnung - aber an sowas Häßliches WILL ich mich gar nicht gewöhnen.
zatzen hat geschrieben: Ich habe angefangen mit QBASIC,
Ich habe mit BASIC auf Ostcomputern (DDR) KC85/1, KC85/4 angefangen. Da war auch alles großgeschrieben, aber das war irgendwie normal bei diesen 8bit-Kisten. Auch beim C64, der kam bei mir nach den Ostrechnern.
zatzen hat geschrieben: und als ich auf Pascal umgestiegen bin fand ich es erstmal komisch dass Schlüsselwörter nicht komplett aus Großbuchstaben bestehen müssen.
Als ich auf Pascal kam, gab es erstmal eine MENGE, was ich komisch fand. Aber ich mochte schon auf Anhieb, daß es compiliert und war froh, von diesem Interpreter-Scheiß weg zu sein und seitdem will ich nichts mehr mit Interpreter-Zeug zu tun haben.
zatzen hat geschrieben:Ich habe wohl letztlich in Pascal aus Bequemlichkeit alles klein geschrieben und mich dann an dieses Schriftbild gewöhnt. Ein Grund ist bei mir auch noch, dass ich lieber alles klein schreibe als dass ich hinterher aus Flüchtigkeit etwas mal klein und mal groß schreibe, was den Compiler nicht kümmert , aber die optische Konsistenz des Codes beeinträchtigt.
Das ist einer der Gründe, wieso ich mit C nicht so klarkäme: Da muß man Variablen/Konstanten immer GENAU SO schreiben, wie man sie bei der Deklaration geschrieben hat, das ist Case-Sensitiv, da sind a und A unterschiedliche Variablen...
Bei Variablen schreib ich die mal so, mal so, je nachdem wo ich sie gerade benutze, weil ich mir damit manchmal bestimmte "Merkpunkte" mache.
zatzen hat geschrieben:Und da lege ich schon Wert drauf dass ich mich da auch später noch zurechtfinde, deshalb rücke ich auch ein - mir hilft sowas.
Ja, hilft vielen.
Mir nicht. Für mich ist "schicker Code" nur Zeitverschwendung. Wenn ich grade "im Flow" bin, knalle ich alles hin... Bei größeren verschachtelten Schleifen rück ich auch schonmal ein - aber eben nicht IMMER. Wenn ich alles "einzeilig und eingerückt" schreiben würde, zieht das zusämmenhängenden Code über etliche Zeilen... und ich habe einen Algorithmus oder Routine immer lieber auf einen Blick.

In Assembler bin ich z.B. froh über diese Borland-Turbo-Pascal Eigenart, daß man da die Befehle, genau wie in Pascal, mit Semikolon trennen kann und NICHT jeden Befehl auf eine Zeile schreiben muß. Mein Assembler-Zeug sind immer eher so Klötze. Ein einzelner Opcode für sich allein macht ja SO WENIG, und wenn ich da alles untereinander schreibe, hab ich so 20 Opcodes aufm Bildschirm, das reicht nicht, um Übersicht über eine komplexe Routine zu haben - da müßte ich dann ständig hin- und her scrollen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Sogar beim Chatten achte ich auf Großschreibung und Grammatik.
Mach ich seit einiger Zeit auch so. Nur beim Programmieren lieber klein. Es gibt ja so gesehen keine Rechtschreibregeln für Code.
Naja, Richtig schreiben muß man's schon. Nur Groß-/Kleinschreibung nicht.
Wie gesagt: Außer bei C und seinen Derivaten: Da GIBT es diese Regeln - d.h. da ist es wichtig, was man groß-/kleinschreibt.
zatzen hat geschrieben:Hex-Werte ich Assembler-Blöcken schreibe ich ganz gerne als 0????h. Das unterstreicht für mich dass ich mich sozusagen nicht in einem Pascal-Teil befinde. Das ist vielleicht bei mir so durchgerieselt weil ich ein Assembler-Buch habe wo das so empfohlen wurde.
Ach, ich bin das $ so gewöhnt. Außerdem seh ich dann viel deutlicher, daß es Hex ist, weil das Zeichen nirgendwo sonst vorkommt:
bach = Variable Namens bach
0bach = Hex-Wert für dezimal 2988
Da ist mir $bac lieber.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Falls es Dich interessiert: 0x???? ist übrigens die Notation, die in C und Verwandte benutzt wird - und in allem, was seine Syntax von C ableitet. Und ja, ich finde diese ebenfalls häßlich. (Außerdem: Gleich ZWEI Zeichen, um das auszudrücken... Nerv.)
C muss man mögen. Es ist wohl schnell zu schreiben, aber würde bei mir wiederum Gewöhnung erforden. Ich bin früher mal in die Situation gekommen etwas in C zu programmieren, besonders angenehm fand ich das nicht.
Ja, ging mir genauso. Habe für den einen Kumpel mal so Ding in C geschrieben. Fand das meiste total umständlich. Als erstes hatte ich mir vernünftige Stringbefehle mit pascal-artigen Strings dafür gebaut. Nullterminierte Strings gehen für mich gar nicht. Und in C kann man keine Prozedures/Functions ineinander verschachteln. Das ist total arm!
zatzen hat geschrieben:
DOSferatu hat geschrieben:[FestplattenStromSteckerSchmor]Ui! Ich hoffe, es ist nichts Schlimmes?
Zum Glück hat die Platte keinen Schaden genommen.
Yeah! Es wäre schade um jedes Stück Technik - und NOCH MEHR um die Daten darauf!
zatzen hat geschrieben:
DOSferatu hat geschrieben:Nur, wie ich ja immer erwähne: Wir haben Von-Neumann-Computer. Code und Daten benutzen denselben Speicher. Wenn man 10 Bytes mehr Code benutzt, um an anderer Stelle 1 Byte Daten zu sparen, das klingt nicht nur sinnlos, das IST es auch.
Guter Punkt. Man sollte immer auch die Größe des Programms im Hinterkopf haben wenn man überlegt ein paar Bytes in irgendwelchen Datenfeldern sparen zu wollen.
Das sage ich ja schon die ganze Zeit. DAS meine ich ja mit: Wenn man eine komplexe Packroutine baut, die am Ende größer ist als das, was man beim Packen spart, hat man nichts gewonnen, weil ja alles im gleichen Speicher liegt. Dann hat man nur eine Routine, die zusätzlich Rechenzeit braucht und keinen Nutzen bringt. Es ist eben hier so, daß der Code nicht "irgendwo anders draußen" ist und nicht berücksichtigt werden muß. Beim Abschätzen von Speicherplatz müssen wir "Von-Neumann-Coder" immer berücksichtigen, daß nicht nur DATEN, sondern auch CODE Platz braucht. In unserer besonderen Situation (Real Mode) kommt noch dazu: DATEN können wir, wenn's eng wird, "nach oben" (XMS) auslagern - Code aber nicht! Code kann im Real Mode nur im Heap ausgeführt werden. (Wobei XMS natürlich ebenfalls nur ein "Lagerplatz" ist für uns, weil wir den auch nur indirekt benutzen können.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:Also naja: Man könnte irgendeinen Bytecode erzeugen, der dann interpretiert wird. Aber echte ASM-Opcodes wäre natürlich die Königsklasse. Nur sollte das Programm, das diese Daten/Code erzeugt natürlich keinen Mist bauen. Und es sollte "wissen", welche Register es zu benutzen hat - sonst könnte man das ja kaum irgendwo einbauen.
Das mit den Registern könnte man ja klären, angenommen diese erzeugten Codes sind "Unterprogramme" von z.B. den Blockanzeigeroutinen. Also müsste man dann im Code eine gewisse Menge an Speicher freihalten, wo man dann den speziellen Code reinkopiert und dann ausführt. Aber ob das dann wirklich Geschwindigkeitszuwachs bringt? Jedenfalls eine interessante Sache, so könnte man eben halbwegs intelligent optimierten Code erzeugen, der die Bilddaten direkt in sich trägt und formuliert anstatt sie von A nach B zu kopieren. Wie das genau geht, ob man vom Heap ins Codesegment kopieren kann, weiss ich nicht.
Klar kann man das. Wie im letzten Abschnitt erwähnt, ist das ja alles der gleiche Speicher. Und weil wir im Real Mode (nicht Protected Mode) sind, gibts hier keinen Speicherschutz/Segmentschutz. Das Codesegment ist nur dadurch definiert, wo wir CS hinlegen. Ginge es nicht, ins Codesegment zu kopieren, ginge ja auch kein selbstmodifizierender Code (was ich so oft mache, wenn ich keine Register mehr habe bzw für die Register anderweitig bessere Verwendung habe.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:[hochskalieren]Naja, das ist ja nur nötig, weil keine CRTs mehr benutzt werden, die das alleine so darstellen wie es muß, sondern diese TFTs und so Zeug, wo jede niedrigere als die Maximalauflösung immer irgendwie scheiße aussieht und man deshalb da software- (oder mittlerweile auch hardware-) mäßig interpolieren muß, um die Abscheulichkeit etwas abzumildern.
Ja, einfaches Interpolieren ist das eine, mit KI hochskalieren etwas anderes.https://youtu.be/HUwi6HnkH9I
Hab's mir mal angesehen... Naja. Es macht es nur hochauflösender, aber nicht "besser". Erklärung ist ganz einfach: Jemand, der 320x200 Grafik macht, läßt natürlich zu kleine Details weg, die vielleicht nur noch ein Pixelmatsch wären. Wenn mand das hochskaliert, wirkt dann immer alles leer und steril - weil natürlich keine Details dazukommen, sondern nur Algorithmen Pixeltreppen glätten und die besseren auch Rundungen erkennen.
Also ja: Interessante Technik - verfälscht aber den Grundeindruck.
Von einigen Lucas-Adventures soll es inzwischen aber echte reemasterte Versionen geben, die WIRKLICH dem Begriff "remastert" entsprechen: D.h. die benutzen "das Master". Gemeint ist: Die Zeichnungen (Hintergründe), die damals in 320x200 eingescannt/runtergerechnet wurden, wurden NEU eingescannt, mit höhrer Auflösung. Das ist dann natürlich etwas anderes als ein "Hochskalieren" eines bereits detailreduzierten Pixelbilds.
zatzen hat geschrieben:Davon kann man halten was man will, aber auf eine Weise interessant ist es schon. Wobei ich sagen muss dass ich ein Fan von 320x200 (oder x240) Pixelgrafik bin und nicht das Bedürfnis nach "remaster" Editionen habe.
Ja, wie gesagt: Es gibt inzwischen ECHTE Remaster-Versionen, die wirklich ausgehend vom Originalmaterial neu gemacht wurden, NICHT von den Pixelbildern "hochgezogen".
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ach, ich hab nichts gegen Actionspiele.
Ich auch nicht. Nur einige von Nintendo waren mir irgendwie zu stressig. Commander Keen auf den PC ist zum Beispiel sehr gemütlich.
Ja, ich z.B. kam nie mit Sonic the Hedgehog klar. Die Figur ist quasi nicht mehr steuerbar, sobald sie rennt. Man knallt ständig irgendwo gegen und verliert Ringe und Leben.
zatzen hat geschrieben:TheGame3:
Da stehe ich erstmal natürlich nur wie ein dummer User davor und verstehe nicht viel. Da könnte ich mich auch erst richtig reinknien wenn es ernst wird, ich also damit wirklich ein Spiel machen wollte.
Naja, der Kram hat eine zweisprachige "Online-Hilfe". Man kann an jedem beliebigen Zeitpunkt F1 drücken und die Hilfsseite(n) geht auf. Natürlich muß man erstmal trotzdem das allgemeine Bedienkonzept des ganzen Dings durchschauen. Das habe ich zwar auch erklärt (auf den ersten Hilfsseiten), aber ich weiß nicht, wie gut das jemand außer mir (der ja weiß, was gemeint ist) versteht.
zatzen hat geschrieben:Auf jeden Fall ein in seinem Umfang beeindruckendes Programm,
Naja, das Geheimnis ist, daß das komplette Menüsystem in einem Skript gebaut ist und jeweils einzeln aus dem Overlay nachgeladen wird, wenn es gebraucht wird. Aber das ist alles noch Pascal und hat auch gewisse Schwächen. Ich habe inzwischen ein ähnlich funktionierendes NEUES skriptbasiertes Menüsystem gebaut, nur daß das neue in 100% Assembler gemacht ist. Das wird aber nicht in TheGame3 benutzt - das Programm ist ja auch schon wieder einige Jahre alt.
zatzen hat geschrieben:aber das einzige was ich bisher konnte (auch klar, ohne jegliche Grafikdaten) war "PlayLevel" - wiederum beindruckend das scheinbar beliebig große Level, scrollend in alle vier Himmelsrichtungen.
Naja, das hat nichts mit TheGame3 zu tun. Das liegt an meiner ARCADE01-Unit, die da auch mit eingebaut ist. Die Levels (entweder nur 1 Ebene oder die Routine, die bis zu 4 Ebenen kann) sind direkt mit "Wraparound" vorgesehen, d.h. wenn eine Ebene an ihrem Ende angekommen ist, fängt sie wieder von vorn an (sowohl horizontal als auch vertikal). Vor allem für Hintergrund-Ebenen ist das ganz brauchbar, wenn man diese nur zur "Stimmung" haben will, damit es schöner ist und einen Himmel oder Skyline oder sowas machen will. Die Geschwindigkeit, bzwmit. das Geschwindigkeits-Verhältnis, mit dem sich die Ebenen zueinander bewegen, ist frei wählbar.
zatzen hat geschrieben:Bei meinem ollen Kotzman II war der Level-Editor sehr simpel, über wenige Shortcuts bedienbar und nur auf die Levels zugeschnitten. Es war nur die (auch sehr simple) Spielengine, alles hardgecodet, schnell um eine Editierfunktion ergänzt, die dann im Spiel nicht mehr drin war.
In Xpyderz ist ein Level-Editor direkt eingebaut. (Xpyderz hat ja auch so ein Skript-Menüsystem.) Sieht man nicht in der Pre-Pre-Release (da ist das auskommentiert). Vielleicht sollte ich mal die Xpyderz-Version MIT Level-Editor Online stellen, dann können "Fans" mal Levels bauen und dann kann man vielleicht mal eine Vollversion von Xpyderz rausbringen. Andererseits ist es auch eine steinkalte Schande, daß Xpyderz keinen Sound hat...

Andererseits ist die letzte Version 12 Jahre alt. Vielleicht sollte ich mal, mit meinen neuen Engines ein neues Xpyderz machen, das gleich von Anfang an die ganzen neuen Dinge benutzt: Das 100%-ASM Menüsystem, neue Darstellungsroutinen und natürlich auch ISM und so. Aber Xpyderz war damals eigentlich nur ein Experiment meinerseits. Das Spielprinzip ist ja nicht gerade der Brüller.
zatzen hat geschrieben:Kryptisches "Hello World":
Also bevor ich mir den Code näher ansehe, müsste ich da erstmal sehr viele Zeilenumbrüche einfügen... Und wenn ich da einfach mal die ersten Befehle lese, wird deutlich dass man sich wohl Notizen über die Registerinhalte machen muss um das ganze verfolgen zu können.
Ja, das ist ja Absicht, es SOLLTE ja etwas schwerer erkennbar sein, was das macht. Falls es dazu Fragen gibt, kann ich das gern erklären.
zatzen hat geschrieben:Interessant finde ich aber auch das Resultat, wenn ich das richtig interpretiere ist das im standard Textmodus gehalten mit modifiziertem Zeichensatz, und man merkt es zuerst eigentlich gar nicht.
Es ist NICHT modifizierter Zeichensatz. Ich "modifiziere" nur 1 Zeichen - das Zeichen 221 - und zwar nur für den Fall, daß jemand schändlicherweise NICHT den Zeichensatz Codepage 437 benutzt, wo das Zeichen das senkrechte Halbzeichen ist.

Der Rest der "Magie" funktioniert, indem man die Anzahl Zeilen, die die Zeichen haben können, in der Grafikkarte auf 2 Zeilen stellt. Der Textmode ist ja quasi 720x400 Pixel - und so erhält man quasi einen 160x200 "Pseudo-Grafik" Mode:
Es sind 80 Zeichen, die aber aus zwei Hälften bestehen: Vordergrund- und Hintergrundfarbe sind jeweils der linke und rechte Pixel. Und man sieht nur die ersten 2 Zeilen des Zeichens, dann kommt die nächste Zeichenzeile.

Am Ende, nach der Ausgabe, wird ja die Anzahl Zeichenzeilen wieder in einer Schleife hochgezählt, dadurch werden dann die ersten 25 "Pixelzeilen" wieder auf das ganze Bild hochgestreckt.

Der Rest ist eigentlich nichts weiter als "Pixelroutinen", die an diesen komischen "Pseudomodus" 160x200x16 angepaßt sind. Und dann Linien-Zieh-Routinen, die diese Pixelroutinen benutzen und noch etwas "Magic", um diesen Schachbrettboden hinzubekommen, mit Schatten und aus Linien gemachten Buchstaben.

Mit DOSbox kann man recht gut sehen, was das Ding macht: Wenn man die Zyklen auf einen sehr geringen Wert stellt, sieht man, wie der das ganze Bild aufbaut. Das ist NICHT irgendeine Grafik, die der da irgendwo hin"kopiert". Der "malt" das Bild wirklich.

Und da denk ich immer: Die heutigen Hoch-/Skriptsprachen-Trottel, die für alles nur immer ihre riesigen Frameworks benutzen und noch nie mal Binär-Arithmetik gemacht haben, ob die wohl selber (und in ASM) so 'ne Linienziehroutine bauen könnten...

Das Ding zeichnet übrigens auch jedesmal, wenn man es aufruft, die Buchstaben etwas anders - andere Farben, leicht anders gezerrte Form. Weil nämlich auch ein (16-bit)-Pseudozufallsgenerator drin ist. Kannst ja mal raten, woher der seinen Anfangswert (seinen "Seed") bekommt. Ist ja nicht schwer.

Soviel erstmal dazu.
Benutzeravatar
zatzen
DOS-Kenner
Beiträge: 476
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Eigenes Videoformat

Beitrag von zatzen »

DOSferatu hat geschrieben:[parsen]Ich kenne keine .NIF Dateien. Wenn Du da etwas konkreter wirst oder mir ein Beispiel schickst, kann ich mal sehen, ob ich da was machen kann - aber versprich Dir da mal nicht zu viel. BINÄRE Files zu analysieren ist natürlich etwas aufwendiger als textbasiertes Zeug (wie z.B. Sourcecodes). Bei Binärfiles muß man oft mal "raten" und kann natürlich nicht voraussehen, ob es da bestimmte Optionen gibt, die nur in dem Beispielfile nicht vorkommen, aber theoretisch vorkommen könnten.
(22. September):
Es geht eher allgemein ums Parsen, konkret müsste ich bald mal an XMLs ran. Ich werd das schon hinkriegen, aber es könnte ja sein dass Du da gute Tipps hast wo ich so spontan einfach nicht drauf komme.
Dazu hier mal ein Ausschnitt aus einer Renoise Tracker XML, wie dort eine Patternspur codiert ist:

Code: Alles auswählen

      <Pattern>  
        <NumberOfLines>32</NumberOfLines>
        <Tracks>
          <PatternTrack type="PatternTrack">
            <SelectedPresetName>Init</SelectedPresetName>
            <SelectedPresetLibrary>Bundled Content</SelectedPresetLibrary>
            <SelectedPresetIsModified>true</SelectedPresetIsModified>
            <Lines>
              <Line index="0">
                <NoteColumns>
                  <NoteColumn/>
                  <NoteColumn/>
                  <NoteColumn>
                    <Note>C-4</Note>
                    <Instrument>00</Instrument>
                  </NoteColumn>
                </NoteColumns>
                <EffectColumns>
                  <EffectColumn>
                    <Value>37</Value>
                    <Number>0A</Number>
                  </EffectColumn>
                  <EffectColumn>
                    <Number>0V</Number>
                  </EffectColumn>
                  <EffectColumn>
                    <Number>0D</Number>
                  </EffectColumn>
                  <EffectColumn>
                    <Number>0G</Number>
                  </EffectColumn>
                </EffectColumns>
              </Line>

[...]

            </Lines>
            <AliasPatternIndex>-1</AliasPatternIndex>
            <ColorEnabled>false</ColorEnabled>
            <Color>0,0,0</Color>
          </PatternTrack>

[...]

        </Tracks>
      </Pattern>
Es geht natürlich jetzt nicht darum, was da konkret passiert, sondern einfach nur um ein Beispiel, wie die Daten in XML aussehen, die man auch binär halten könnte.
Ich denke mir, ich werde diese XML Daten parsen in binäre Datenfelder hinein, dann modifizieren um anschliessend wieder XML zu generieren. Oder wie würdest Du das machen?

(20. Oktober):
Ich habe zwischenzeitlich meine Tools schon geschrieben, also wieder meine Zeit sinnvoll im Unreal-Life verbracht. Das XML habe ich vielleicht etwas unelegant geparst, modifiziert und wieder generiert, aber es funktioniert. Trotzdem, falls Du da eine quasi optimale Vorgehensweise hast, lass es mich wissen, evtl. muss ich nämlich noch mehr Tools schreiben oder das vorhandene erweitern.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Aber natürlich können wir uns einig darüber sein, dass tatsächlich Windows bzw. die Prozessorentwickler die Übeltäter sind, weil sie keine 16 Bit mehr unterstützen. Mutmaßlich hat das aber auch technische bzw. Performance-Gründe, und nicht nur verkaufspolitische.
ICH denke, es sind NUR verkaufspolitische Gründe und künstliche Obsolität.
286er: (fast) 100% abwärtskompatibel zu 8086+186
386er: (fast) 100% abwärtskompatibel zu 8086+186+286
486er: (fast) 100% abwärtskompatibel zu 8086+186+286+386
Pentium... usw...
Jahrelang haben die es hinbekommen. Aber HEUTE, wo Prozessoren im GHz-Bereich agieren und schon 8 Kerne haben usw., soll das nicht mehr möglich sein?
Man wollte wohl einen Schnitt machen. Ja, so isses eben, man will neues verkaufen, oder denkt sich einfach, wozu etwas weiter unterstützen wonach 99% der Leute nicht mehr krähen. In der Medienwelt läuft das ja auch so, aber da scheinen die Leute es ja gerne zu haben, mit der Zeit zu gehen. Ich bevorzuge im Zweifelsfall auch digitale Medien einer VHS-Kassette. Und ähnlich wie die bis vor einigen Jahren weit verbreitete DVD von der BlueRay verdrängt wird, wird die CD vom Streaming verdrängt (das gefällt mir überhaupt nicht) - wie wohl alle physischen Medienträger überhaupt eigentlich. Wenn es etwas neues gibt werden alte Formate fallengelassen. Die Vinyl-Schallplatte ist eine Ausnahme und scheint mittlerweile beliebter als die CD zu sein, obwohl sie wissenschaftlich gesehen von letzterer komplett in den Sack gesteckt wird was Klangtreue (und Komfort) angeht. Will heissen: Überspielt man eine Schallplatte mit guten Wandlern auf eine CD klingt die genauso wie die Schallplatte. Macht man von einer CD eine Schallplatte klingt es NICHT genauso. Und kaum habe ich mich damit abgefunden, dass die neueren Computer keine Diskettenlaufwerke mehr haben, sind auch schon CD/DVD Laufwerke wieder aus der Mode. Objektiv ja auch irgendwie verständlich, angesichts von mickrigen 512 GB fassenden USB-Sticks welche die Datenmenge einer DVD innerhalb einer handvoll Sekunden transferieren.
Aber es war "damals" schon irgendwie immer ein gutes Gefühl, seine Daten auf ROM-Datenträgern archivieren zu können, dann ist man vor irrtümlichem Löschen oder sonstigem sicher. Wenn da nicht einige dabeigewesen wären, die über die Jahre unlesbar geworden sind, wäre es perfekt gewesen. Jammerschade also dieses wahrscheinliche Aussterben der CD, von den technischen Eckwerten her ist sie auch heute noch völlig ausreichend, man könnte sie höchstens mittels Blu-Ray Technologie auf Münzgröße schrumpfen, das wäre doch mal was, die Mikro-Disc (µD).
DOSferatu hat geschrieben:Als ich auf Pascal kam, gab es erstmal eine MENGE, was ich komisch fand. Aber ich mochte schon auf Anhieb, daß es compiliert und war froh, von diesem Interpreter-Scheiß weg zu sein und seitdem will ich nichts mehr mit Interpreter-Zeug zu tun haben.
QuickBASIC hatte einen Compiler. Allerdings separat - die Testläufe machte ein Interpreter wenn ich nicht irre. Und der konnte meistens mehr Speicher fassen als der Compiler, deswegen war das oft ärgerlich wenn man sein Programm am Ende zurechtstutzen musste. Hatte ich schonmal erwähnt. Weil ich nur QBasic kannte, bei dem in der IDE die "SUBs" separat angezeigt wurden, fand ich erst unübersichlich dass man bei Pascal alle Routinen auf einmal sieht.


Einrücken etc.:
Das Programmieren macht mir ein kleines bisschen mehr Spaß wenn der Code auch eine gewisse leserliche Form hat. Aber alles einzeilig ist es bei mir auch nicht. Auch gerade bei meinen Blockdingensroutinen mache ich in Assembler viel Gebrauch von mehreren Befehlen pro Zeile. Und zuletzt habe ich auch gefallen dran gefunden alles etwas kompakter zu gestalten, gerade bei Routinen die nicht sonderlich extravagant sind und wo man im Verlauf nichts mehr dran ändern muss.

DOSferatu hat geschrieben:Ach, ich bin das $ so gewöhnt. Außerdem seh ich dann viel deutlicher, daß es Hex ist, weil das Zeichen nirgendwo sonst vorkommt:
bach = Variable Namens bach
0bach = Hex-Wert für dezimal 2988
Da ist mir $bac lieber.
Ich habe wohl verinnerlicht, dass Variablen nicht mit Ziffern beginnen dürfen. Ich hatte bisher keine Probleme. Aber jeder wie er will eben. :)
Aber tatsächlich gibt auch Freepascal bei einem RTE die Adresse mit einem $ vorne aus.

DOSferatu hat geschrieben:Und in C kann man keine Prozedures/Functions ineinander verschachteln. Das ist total arm!
Ich hab das bisher in Pascal auch nur sehr selten gemacht, ich dachte dabei immer das gäbe zu viel Stack-Beanspruchung.
DOSferatu hat geschrieben:Wenn man eine komplexe Packroutine baut, die am Ende größer ist als das, was man beim Packen spart, hat man nichts gewonnen, weil ja alles im gleichen Speicher liegt.
Es ist wahrscheinlich nichts neues wenn ich sage, dass die vielleicht 2K mehr Code (wobei, da ist ja auch noch ne Tabelle dabei, mit 512 Byte aber kaum nennenswert), bei ZSM sich lohnen, sobald man eben mehr als 2K komprimierte Samples hat. Ähnlich denke ich über ZVID2: Ich möchte da vielleicht um die 300K (gepackt) an Grafik reinklatschen, die Routinen werden sicherlich auch ziemlich klein sein. Übrigens an dieser Stelle nochmal das brenzlige Thema Hintergrundgrafik-Kompression bei der Blocksache: Wenn mein primäres Ziel nicht das Erreichen von möglichst hoher Performance ist, sondern möglichst viel Grafik im Speicher halten im Vordergrund steht: Dann ist es meines Erachtens sogar höchst sinnvoll, diese Kombination gepackter Hintergrund und nur teilweise restaurieren, denn: Wenn ich die Hintergründe faktisch definitiv packen will, dann schlägt der Performanceboost durch nur teilweises Restaurieren umso stärker zu Buche, im Vergleich dazu als wenn ich jedes mal ein Vollbild entpacken würde.
DOSferatu hat geschrieben:[vom Heap ins Codesegment kopieren]Klar kann man das. Wie im letzten Abschnitt erwähnt, ist das ja alles der gleiche Speicher. Und weil wir im Real Mode (nicht Protected Mode) sind, gibts hier keinen Speicherschutz/Segmentschutz. Das Codesegment ist nur dadurch definiert, wo wir CS hinlegen. Ginge es nicht, ins Codesegment zu kopieren, ginge ja auch kein selbstmodifizierender Code (was ich so oft mache, wenn ich keine Register mehr habe bzw für die Register anderweitig bessere Verwendung habe.)
Das wäre ja dann selbmodifizierend, im großen Stil sozusagen. Ein kleiner Performance-Haken könnte dann sein, dass das Kopieren den Codes auch eine kleine Weile dauert.

DOSferatu hat geschrieben:
zatzen hat geschrieben:[KI upscaling]Davon kann man halten was man will, aber auf eine Weise interessant ist es schon. Wobei ich sagen muss dass ich ein Fan von 320x200 (oder x240) Pixelgrafik bin und nicht das Bedürfnis nach "remaster" Editionen habe.
Ja, wie gesagt: Es gibt inzwischen ECHTE Remaster-Versionen, die wirklich ausgehend vom Originalmaterial neu gemacht wurden, NICHT von den Pixelbildern "hochgezogen".
Aber auch hier bin ich so geprägt, dass 320x200 zu einem stimmungsvollen Spielerlebnis beitragen kann. Die Hintergrundgrafiken von Monkey Island II sind kunstvoll mit Filzstift gemalt, durch die niedrige Grafikauflösung werden sie etwas pixelig-unschärfer und wirken dadurch paradoxerweise fotorealistischer. Wenn diese nun hochauflösend zu sehen sind sehen sie wieder mehr nach Zeichnungen aus. Bei der Special Edition wurden die Grafiken scheinbar auch nochmals stilisiert, weiter weg vom Original, das hat auf mich wieder zu sehr den Effekt "Hintergründe nur gemalt, Figuren wie aus Knete gemacht". - Oder vielmehr, alles wie aus Holz geschnitzt und angemalt. Das mag ja vielen gefallen, Monkey Island II als Holzpuppentheater, aber ich bevorzuge die pixelige Version die Raum zur Interpretation lässt und somit letztlich realistischer wirkt.

DOSferatu hat geschrieben:Vielleicht sollte ich mal, mit meinen neuen Engines ein neues Xpyderz machen, das gleich von Anfang an die ganzen neuen Dinge benutzt: Das 100%-ASM Menüsystem, neue Darstellungsroutinen und natürlich auch ISM und so. Aber Xpyderz war damals eigentlich nur ein Experiment meinerseits. Das Spielprinzip ist ja nicht gerade der Brüller.
4-Wege Scrolling hätte mich zumindest als Kind begeistert, eine große Welt erkunden und so. Deswegen hab ich ja auch Zelda gespielt. Oder Cauldron II auf dem C64 fand ich auch toll. Mein Einstieg in die Computerspielewelt war im Prinzip Super Mario Bros. und da konnte man ja immer nur von links nach rechts laufen, aber niemals zurück.

Hello World:
DOSferatu hat geschrieben:Der Rest der "Magie" funktioniert, indem man die Anzahl Zeilen, die die Zeichen haben können, in der Grafikkarte auf 2 Zeilen stellt. Der Textmode ist ja quasi 720x400 Pixel
War mir gar nicht so bewusst, diese Auflösung. Also hat ein Buchstabenblock komische 9x16 Pixel. Es ist schon ne Weile her dass ich mal nen eigenen Zeichensatz gemacht habe... Trotzdem messe ich die Breite Deiner Pixel gleichmäßig mit jeweils 4 "echten" Pixeln. Irgendwo stimmt da was in meinem Verständnis nicht. Vielleicht ist der Textmodus ja doch nur 640x400, die Ascii-Zeichen sind jedenfalls 8x16, gerade nochmal nachgesehen.
DOSferatu hat geschrieben: - und so erhält man quasi einen 160x200 "Pseudo-Grafik" Mode:
Es sind 80 Zeichen, die aber aus zwei Hälften bestehen: Vordergrund- und Hintergrundfarbe sind jeweils der linke und rechte Pixel. Und man sieht nur die ersten 2 Zeilen des Zeichens, dann kommt die nächste Zeichenzeile.
Auch sehr interessant. Hätte dieser Modus gewisse Vorteile gegenüber einem EGA 160x200, oder waren Spiele wie die ersten von Sierra in Wirklichkeit vielleicht sogar in diesem Modus gehalten? Aber ich sehe gerade, dass die Grafik selbst dort zwar auf 160x200 beschränkt ist, die Textausgaben aber in 320x200 aufgelöst sind. Dann ist es wohl insgesamt 320x200 Grafikmodus, und man wollte bei der Grafik einfach sparen. Oder einfach ein komischer Modus der zwar 320x200 Text aber nur 160x200 Grafik kann?
DOSferatu hat geschrieben:Mit DOSbox kann man recht gut sehen, was das Ding macht: Wenn man die Zyklen auf einen sehr geringen Wert stellt, sieht man, wie der das ganze Bild aufbaut. Das ist NICHT irgendeine Grafik, die der da irgendwo hin"kopiert". Der "malt" das Bild wirklich.

Und da denk ich immer: Die heutigen Hoch-/Skriptsprachen-Trottel, die für alles nur immer ihre riesigen Frameworks benutzen und noch nie mal Binär-Arithmetik gemacht haben, ob die wohl selber (und in ASM) so 'ne Linienziehroutine bauen könnten...
Jeder hat eben sein Spezialgebiet, und wer objektorientiert an künstlicher Intelligenz bastelt wird nicht viel mit Linienalgorithmen zu tun haben. Wobei eine allgemeine Programmiererfahrung auf jedem Gebiet sicherlich nicht schädlich ist.
DOSferatu hat geschrieben:[Zufallsgenerator]Kannst ja mal raten, woher der seinen Anfangswert (seinen "Seed") bekommt. Ist ja nicht schwer.
Timer? Ist ja die übliche Methode.
Antworten