Trackermodul-Engine (sehr einfach)

Diskussion zum Thema Programmierung unter DOS (Intel x86)
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

zatzen hat geschrieben:
DOSferatu hat geschrieben:Was meinst Du eigentlich immer mit "Album"? Gibt's CDs von Dir zu kaufen?
Ja, wer welche haben will gerne. Aber im Selbstvertrieb und zum Selbstkostenpreis, so viel Massenerfolg dass ich einen Plattenvertrag hätte und reich werden könnte habe ich nicht. Bis vor ca. 15 Jahren bin ich auch einige CDs losgeworden, aber mittlerweile sind CDs wegen MP3, FLAC und Streaming ja out, während Vinyl wieder durchstartet, trotz der klanglichen Einschränkungen welche die CD nicht hat...
Ahja. d.h. es gibt keine gepreßten CDs von Dir zu kaufen, aber gebrannte. Machste da auch ein Case drum mit nem Inlay/Booklet? Oder verschickst Du die in 'ner Plastiktüte?
zatzen hat geschrieben:[wegen XML...]Bei heutigen Programmen (oder gehen wir ganz mit der Zeit und sagen direkt "Apps") die unter mehreren Megabyte an EXE-Größe gar nicht erst anfangen fällt es wohl wirklich kaum noch ins Gewicht wenn so viel Aufwand betrieben wird. Abartig große Codeklumpen relativieren sich dann...
Ja, das ist die Erklärung - aber eben keine Entschuldigung für so einen Scheiß.

Achja, zum Thema "App". Ja, es ist eigentlich die Abkürzung für "Applikation"/"application", also auch nur eine pseudocoole neue Bezeichnung für "auf Betriebssystem ausführbares Programm". Aber es ist schon irgendwie bezeichnend, daß ausgerechnet die Firma APPLE den Begriff APP dafür so populär gemacht hat... Ein Schelm, wer Böses dabei denkt...

Für mich ist also jeder, der ein Programm (Spiel/Tool) als "App" bezeichnet ein verkappter Apple-Fanboy... Und was ich von denen halte, habe ich ja etwas weiter unten noch etwas dargelegt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich weiß nicht, ob sich irgend ein Spieler bei DOOM oder Monkey Island oder den unzähligen anderen 320x200-DOS-Spielen jemals drüber aufgeregt hat "daß die Pixel nicht 100% quadratisch sind"...
Nein, ich selber ja auch keineswegs. Die Sache ist rein pragmatischer Natur und hat einfach nur der Kompatibilität mit den heutigen Anzeigestandards zu tun. Sicherlich, wer im Emulator die Aspect Ratio nicht korrekt einstellt (bei Dosbox ist diese per Default NICHT aktiviert) mag selber Schuld sein.
Naja, wie ich immer sage: Ich mache das unter/für "alte" Rechner und DOS. Wenn das jemand auf anderen (sog. "modernen") Systemen benutzen will, muß sich an mich anpassen (bzw. an das Zeug). ICH werd' mich bei der Entwicklung meines Zeugs nicht einschränken/umbiegen lassen, damit das Zeug auf irgendwelchen "Anzeigestandards" von heute toll ist.

Zum Beispiel: 16:9, 21:9, 22:9 und all diese Formate finde ich absolut gräßlich. Für mich ist die einzig gültige und gescheite Bildratio 4:3. Manche Leute meinen, 16:9 wäre näher am menschlichen Blickfeld - Augen nebeneinander und so. Aber ich sage: Stimmt nicht. Denn: Die Blickfelder beider Augen überlagern sich zu mind. 2/3 - sonst könnte man nämlich garnicht räumlich sehen. Und damit ist 4:3 dem menschlichen Blickfeld weitaus näher als dieser ganze 16:9-Blödsinn.

Der 16:9-Blödsinn ergab sich damals aus finanziellen Gründen: Man brauchte Kinos nicht so hoch bauen, um mehr Leute nebeneinander zu setzen UND diese Schmalfilm- auf Breitbild-Projektion diente ebenfalls zum Sparen - von Zelluloid.

Aber wenn alle Leute 4:3 Fernseher haben, die irgendwann auch nicht mehr dauernd kaputtgehen, kann man ja keine neuen mehr verkaufen - was macht man also? Erfindet ständig neue Formate (16:9, dann HD-Ready, HD, HDMI, Ultra... und wasweißich) und jedes Mal soll man sich 'ne neue Kiste kaufen. Denn sonst müßten so Hersteller ja irgendwann ihre Bude zumachen. Und damit hat man dann dieses "Oh guck mal: 16:9! Genau wie Kino - jetzt zu Hause!"

Ja, genauso Scheiße, wie es im Kino aussieht, soll man das jetzt zu Hause auch haben... - Denn wenn die Leute in so "breitem" Film im Kino sitzen kann der, der ganz links sitzt, dem der ganz rechts sitzt, am besten mitm Handy die ganze Zeit erzählen, was auf der linken Seite vom Bild grade passiert. Und der andere umgekehrt...

Auch toll: Menschen sind ja insgesamt eher hochformatig (höher als breit) und auch Köpfe/Gesichter sind das. Je breiter das Bild, umso mehr muß man also das Gesicht/Kopf abschneiden, um mal eine "Totale" eines Darstellers zu haben. Sieht ja super aus, diese abgeschnittenen Stirnen bei 16:9...

Na gut, genug darüber abgerantet....
zatzen hat geschrieben:Einschränkend wird das ganze aber dann, wenn man Grafiken für ein Spiel machen will. Dann ist man entweder auf eine Dos-Software angewiesen,
Du sagst das so, als wäre DOS-Software etwas schlechtes.
zatzen hat geschrieben:oder man hat Glück und kann irgendwie seine Systemauflösung so "verstellen", dass alles "korrekt" verzerrt ist. Du magst sagen, wofür für die Grafik etwas anderes als Dos nutzen.
Genau das sage ich.
zatzen hat geschrieben:Aber gerade bei Grafik kann Windows-Software von Vorteil sein.
Windows ist die Pest. Für nichts "von Vorteil". Alles nur groß und langsam. Es ist ein notwendiges Übel, weil Microsoft es hingekriegt hat, alles andere totzumachen, so daß man nun quasi alternativlos dasteht. Da zeigt ja auch schon, daß die selber wissen, was Windows für'ne Grütze ist: Wären sie überzeugt davon, daß sich Qualität von selbst durchsetzt, müßten sie nicht jede mögliche Konkurrenz aufkaufen und vernichten.

Microsoft hatte 2 gute Ideen - und beide haben sie geklaut:
1. BASIC als Code für 6502/Z80 etc. für alle 8-Bit Systeme zu entwickeln. Dadurch konnten sich Computer auch für den Heimbereich entwickeln und Leute haben gemerkt, daß man damit mehr machen kann als nur "User sein".
2. DOS. Tom Patterson hatte da dieses QDOS gebaut, weil's kein gescheites OS für x86 gab und MS hat es übernommen (und auch den Patterson) und weiterentwickelt. DOS macht genau das, was ein OS machen muß: Nicht mehr und nicht weniger.

Und basierend auf ihrer Vormachtstellung (und damit Geld) was sie wegen DOS eingenommen haben, konnten sie dann diesen Windows-Mist entwickeln, der bis heute immer noch uninspirierter, konzeptloser lahmer Scheiß ist (obwohl sie das schon seit 25 Jahren als "brauchbares" OS anbieten). Nach DOS haben die aufgehört, cool zu sein. Sind nur noch eine dumme Krake, die alles vernichtet, was nicht Windows ist, damit sie das weiterverbreiten können.

Jetzt könnte ja jemand sagen: Warum dann nicht Apple? Weil Apple noch schlimmer ist - und noch eher damit angefangen haben, so zu sein, wie MS später auch. Apple ist stolz drauf, Leuten Zeug anzubieten, das es von der Konkurrenz in gleicher oder besserer Qualität zum Drittel des Preises gibt - und Apple-User sind auch noch stolz drauf, sich so verarschen zu lassen: Nur weil der blöde Apfel da drauf ist, kann man angeben, daß "man es sich leisten kann", das 3-fache zu bezahlen. Und dafür weniger zu kriegen: Zeug, das nur für User geeignet ist - alles verbarrikadiert, so daß man nichts selber entwickeln und was dabei lernen könnte. Alles dafür ausgelegt, blöder User zu SEIN und zu BLEIBEN. Weil Apple ja alles mit seinen i-Produkten (iMac, iPod, iPhone, iPad...) macht, hat sich da mal dieser schicke Witz etabliert: Apple-User mit 5 Buchstaben? iDiot.

Dann könnte man ja fragen: Warum nicht Linux? Linux ist frei. Linux ist "freakig", Linux geht auch ohne Oberfläche...
Naja, Gründe:
1. Linux behandelt alles als "Files", sogar Grafikdaten und sowas. Das ganze Konzept dieses OS ist so "alles mit allem" machen zu können. Aber genau sowas braucht auch immer einen ziemlichen Speicher- und Leistungs-Overhead, damit das funktioniert.

2. Linux ist zu nix kompatibel - und dabei leider nichtmal 100% zu sich selbst. Bedingt durch diese "Offenheit" des OS kann jeder quasi ein eigenes zurechtcompiliertes Linux haben. Klingt ja erstmal cool. Aber: Wenn man ein Entwickler ist, ist das doch die Hölle. Da ist nicht nur (wie beim PC ja sowieso schon) die *Hardware* nicht vorhersehbar, weil jeder in seine Kiste etwas anderes einbaut - sondern zusätzlich auch noch die *Software* - weil man sich, auch wenn es "Linux" ist, nicht darauf verlassen kann, was es kann und was nicht, weil man nicht wissen kann, was da eincompiliert wurde. Ist ja bestimmt super, dafür ein Spiel zu schreiben und dann einem Gamer 3 Seiten Systemanforderungen - nicht der Hardware, sondern FÜR DAS OS mitzugeben, damit der weiß, wie der "sein Linux" konfigurieren muß, damit das Zeug läuft.

Also das, was bei Apple "ZU SEHR benutzerfreundlich ist" ist bei Linux genau das Gegenteil. Da weiß ich auch nicht, ob ich das - sowohl aus Entwicklersicht, als auch aus Anwendersicht - irgendwie cool finden kann.

Bei DOS ist es eben so: Wenn man noch irgendwelchen Firlefanz (eine GUI, irgendwelche TSRs, wasweißich) haben will, kann man die eben zusätzlich starten und die belegen dann Speicher und Rechenzeit. Und wenn nicht, ist man nicht gezwungen, den Kram zu haben. Bei Windows hat man keine Wahl. Selbst alles, was man nie benutzt, liegt da groß und fett im Speicher. Und eine Menge rennt aktiv "im Hintergrund" und verbraucht Rechenpower - egal, ob man will oder nicht.

Meine Begeisterung für sog. "moderne Systeme" hält sich echt in Grenzen.

Ich kann da nur den coolen Typen Niklaus Wirth (ja, genau der, der PASCAL erfunden hat!) zitieren, der schon vor ca. 30 Jahren (über Software) gesagt hat:
"Die Software wird schneller langsamer als die Computer schneller werden."

Und das trifft heutzutage leider immer mehr zu: Man hat irgendwelche GHz-Kisten, die C:-Festplatte ist eine SSD (Solid-State-Drive, also eigentlich 'ne Art RAM) und trotzdem hat man nicht das Gefühl, als wenn sich in den letzten 25 Jahren Performance-mäßig irgendwas bewegt hat. Und wenn die Computer immer schneller, die Speicher immer größer und schneller (vom Zugriff) werden und das Zeug was darauf läuft, trotzdem performt wie 1995, könnte man ja schon mal vermuten, daß es nicht an zu schlechter Hardware liegt.

Wie ich das immer hasse, wenn Leute, wenn irgendwas nicht performt, als erstes immer sagen: "Der Computer ist zu langsam." - aber fast nie: "Die Software ist zu beschissen programmiert." - obwohl letzteres viel öfter zutrifft.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Außer Dir kenne ich keinen, der sich jemals über die nicht ganz quadratischen Pixel in 320x200 ereifert hätte.
Es geht ja nicht um die Form der Pixel, sondern darum dass am Ende das Bild zu breitgezogen ist und Ellipsen statt Kreise dargestellt werden. Sobald man nicht mehr mit nativem DOS arbeitet sondern es mit Emulationen zu tun bekommt, ist das alles eben nicht mehr idiotensicher. 320x240 wäre auch im Emulator idiotensicher, solange man nicht absichtlich rumpfuscht.
Naja, wie ich schon sagte: Ich entwickle nicht für den Emulator, sondern für die echte Maschine. Und selbst wenn - realistisch betrachtet - mein Zeug wahrscheinlich (wenn's überhaupt einen interessiert) auf 'nem Emulator (DOSbox o.ä.) heutzutage laufen dürfte als auf einer echten Maschine, so ist für mich beim Entwickeln trotzdem die echte Maschine die Referenz - und nicht irgendein Emulator oder "moderne Anzeige" oder ähnliches.

Übrigens: Ein Kreis ist ein Spezialfall der Ellipse. Wenn man sich nur eine Ellipsenroutine baut, kann man damit Kreise und Ellipsen zeichnen. Und: Man kann das Verhältnis der Radien zueinander genau reziprok zum Verhältnis der Abweichung (von 1:1) vorberechnen und schon kann man auch in komischen Auflösungen Kreise zeichnen, die keine Eier sind. Meine Sprite-Routinen haben so einen optionalen Korrekturfaktor, den man für diese Zwecke benutzen kann. Er wird "NACH" der Drehung eines Sprites angewendet, so daß selbst gedrehte Sprites sich NICHT zerren/stauchen beim Drehen, wenn man ungewöhliche Pixel-/Bildverhältnisse hat.

Zu Emulatoren nochmal:
Ein Emulator hat ja für sich den Anspruch, Software und Hardware eines realen Systems möglichst wirklichkeitsnah abzuspielen/darzustellen. Wenn der Emulator das nur unzureichend hinbekommt (entweder von sich selbst aus oder wegen schlechter Usereinstellungen), dann ist der User/der Emulator schuld, nicht die Originalhardware/-software.
zatzen hat geschrieben:Aber ich kann schon verstehen dass das alles keine Argumente sind, wenn man Emulatoren sowieso verabscheut.
Ach, von Verabscheuen kann nicht die Rede sein. Aber ich finde es eben sinnlos, einen Emulator eines alten Systems als Referenz zu benutzen, wenn man den Emulator als höher/"relevanter" einstuft als das echte System. Wenn es einem nur darum geht, könnte man auch eine beliebige moderne VM benutzen und darin entwickeln - und damit wahrscheinlich sogar bessere/performantere Ergebnisse erzeugen, weil die VM (im Gegensatz zu einem System-Emulator) nicht an irgendwelche Hardware-Befindlichkeiten/-Beschränkungen o.ä. eines alten Systems gebunden wäre.

Was ich eigentlich damit sagen will, ist: Wenn man etwas so entwickelt, daß es auf einem Emulator gut, aber auf dem echten System schlecht performt oder auf dem Emulator funktioniert, aber auf dem echten System nicht, dann entwickelt man für den Emulator - und das macht keinen Sinn, weil der ja nicht dafür gedacht ist, "für sich selbst als System" zu stehen.
zatzen hat geschrieben:Wahrscheinlich werde ich mich irgendwann mal bequemen, mir wieder ein echtes DOS-System zuzulegen. Programmieren würde ich aber bis auf weiteres trotzdem im Emulator. Manchmal passieren derart brutale Abstürze - die möchte ich lieber nicht auf ein echtes System loslassen.
Achnaja, wie ich schonmal sagte:
Erstens: Mein DOS-Rechner bootet auch nach einem Absturz recht schnell.
Zweitens: Diese kurze Boot-Zeit nach einem Absturz ist ganz gut, um "runterzukommen", und in sich zu geben beim Überlegen, was man falsch gemacht hat.
Drittens: Wenn man weiß, daß es bei schlampiger Programmierung abstürzen kann (was ja etwas nervt), erzieht einen das dazu, weniger schlampig zu programmieren, um das zu vermeiden.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ach naja - mein Zeug braucht auch alles wohl schnellen 486er. Durch Vorhandensein einer solchen Kiste wird man irgendwie versaut. Wenn ich auf 386er entwickeln würde und sehen würde, wo es bremst, wäre ich wohl ganz anders beim Optimieren.
So schlecht Dosbox sich für Benchmarks eignet - immerhin kann man da so ganz grob etwas abschätzen weil man ganz bequem die Geschwindigkeit jederzeit ändern kann. Deswegen hatten sich da bei mir diese 20000 Cycles etabliert, mit denen z.B. das XPYDERZ-Preview etwas ruckelig aber durchaus spielbar läuft, und mein Kram wie er soll, mit Luft nach oben.
Naja, ich weiß, daß XPYDERZ besser performen könnte bei besserer Programmierung. Der Code für die Darstellung der Levels und Sprites ist 16 Jahre alt und besteht noch zu mind. 40% aus Pascal-Anteil. Damals hatte ich noch lange nicht die ganzen Tricks drauf, die ich heute in ASM so benutze. Aber weil mein Zeug so modular ist (schon alleine, weil in Units), kann man auch entwickeln und später schlechte Routinen durch bessere ersetzen, ohne am restlichen Programm etwas zu ändern. Vielleicht mach' ich das sogar mal.
zatzen hat geschrieben:Natürlich passiert bei XPYDERZ wesentlich mehr als selbst bei einem 16 spurigen vollausgelasteten ZSM, mal als Beispiel.
Da bin ich mir noch nicht mal so sicher, ob das so ist.
zatzen hat geschrieben:Aber diese Cycles Einstellung habe ich bisher als Richtschnur genommen, davon ausgehend dass es von der Performance einen 486er nicht übersteigen wird.
Was ist für Dich denn ein 486er? Ich meine: Die gab es mit 25, 33, 50, 66, 75, 100, 120, 133 und (selten) 150 MHz (und dann auch noch SX und DX). Das ist eine enorme Spanne von Leistung, was das abbildet und es steht ja wohl außer Frage, daß z.B. ein 486er 133 MHz *VIERMAL* so schnell ist wie ein 486er 33 MHz - und das ist ja schon ein Unterschied wie Tag und Nacht. Selbst wenn man mal die Grafikkarte/Speicherzugriffe außen vor läßt, sondern von reiner Grafik-/Soundberechnung der CPU ausgeht, ist das wie der Unterschied zwischen 10 FPS und 40 FPS oder wie der Unterschied zwischen 11 kHz und 44 kHz.

Mit anderen Worten: Was (welche Kiste) referenzieren denn diese 20000 Cycles?
zatzen hat geschrieben:Und ja, so wie Du befürchtest dass Dein leistungsstarker Computer Performance-Engpässe verschleiert, hatte ich einen Pentium bevor ich mich überhaupt mit effizienter Programmierung auseinandergesetzt hatte.
Naja, beim Pentium kommen ja noch andere Dinge hinzu, wie das ganze Pipelining, mit dem man nochmal ganz andere Performancesprünge machen kann, wenn man daraufhin optimiert oder, gerade was Berechnung von so Metadaten wie Grafik und Sound angeht, wahrscheinlich - wenn man Ahnung hat - unheimlich von Zeug wie MMX profitieren könnte, was ja erst ab Pentium verfügbar war.

Also beim Pentium ist es nicht nur die nominale Taktrate, die man quasi auch nicht höher stellen konnte als beim 486er (die ersten Pentiums hatte ungefähr die gleichen Taktfrequenzen einstellbar wie die obengenannten 486er (nur eben nichts mehr unter 75 Mhz) - d.h. die ersten Pentiums waren mit 75 und 90 MHz getaktet (und hatten noch diesen lustigen FDIV-Bug in der Fließkomma-Einheit).

Aber was den Pentium so schnell macht (quasi fast doppelt so schnell wie den 486er bei gleicher Taktfrequenz) war, daß er, bei gescheiter Programmierung, 2 Befehle *GLEICHZEITIG* ausführen konnte, d.h. wenn jeder der beiden Befehle 1 Taktzyklus brauchte und sie "pairable" waren, konnten sie gleichzeitig ausgeführt werden und haben ZUSAMMEN nur 1 Taktzyklus gebraucht. Das ist wie, wenn jeder nur 0,5 Takte braucht - oder wie wenn einer 1 Takt und einer 0 Takte braucht.

Aber für Pentium optimieren ist noch mal 'ne ganz andere Schiene als 386er oder 486er. Meister Röhrich würde sagen: "Das ist eine Wissenschaft für sich - da kann nicht jeder mit um." Im ASM86FAQ wird das mit dem Pairing ja auch bei den Befehlen angegeben und etwas thematisiert - aber wenn man nicht weiß, was die da meinen, kann man damit natürlich nichts anfangen.

Ich selbst weiß zwar, was die meinen - aber ich bin schon froh, ein bißchen für 486er optimieren zu können. Pentium-optimierten Code habe ich noch nie (bewußt) gebaut.

Heutige "moderne" CPUs haben ja eingebaute Code-Vorhersage und optimieren Code schon selbst, stellen die Reihenfolge um, wenn es paßt usw. Das heißt: Das was ICH hier "optimiere" für 386er/486er und da Vorteile bringt (Befehlsreihenfolge, selbstmodifizierender Code, usw.) ist quasi für moderne CPUs eher totale Antiperformance und eher schädlich. Leichtverständliches Beispiel: Eine moderne CPU mit Code-Prediction profitiert nicht von selbstmodifizierendem Code, sondern sogar eher im Gegenteil.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich kann mir nicht vorstellen, daß ein Zocker 2 Spiele sieht/spielt und das eine performt mehr (FPS) als das andere und der findet das andere besser - und zwar, weil, es die komplexeren internen Routinen hat.
Natürlich. Der ganze "Konflikt" ist ja auch nur da, weil ich mich entschieden habe, nur 640K zu nutzen und keinen XMS. Mit XMS habe ich schonmal rumgespielt auf meinem Pentium, macht auch Spaß. Erst gar keine Trackermusik, sondern einfach nen längeren Sound-Loop. Und einfach ein riesiges Hintergrundbild. Alles einfach aus dem XMS. Und ein Pentium frisst sich rasend da durch.
Kannst Du hier sehen: https://youtu.be/jqx08ubMIps
Ja, kenne das schon, hab's glaub an anderer Stelle mal angeguckt, glaub damals auf Deiner Website. Allerdings bin ich davon nur so Semi-begeistert:
1. Wenn Figur und Hintergrund so unterschiedlich sind von der Art der Grafik (Hintergrund: Foto, Figur: Handgepixelt) wirkt das immer etwas blöd.
2. Foto-Hintergründe (als Vollbild) ist für mich nicht das, was ein 8-/16bit-Spiel für mich ausmacht. Das ist immer eher wie eine Demo als ein Spiel für mich.
zatzen hat geschrieben:Ist mit Dosbox aufgenommen, auf einem Windows System mit einem Intel i5, sowas dürfte heute jeder (Windows-User) haben. Wenn ich also nur unbedingt ein Spiel machen wollen würde, dann so. Ich würde Pentium als Grundvoraussetzung vorgeben mit XMS, und gut.
Naja, um jeden Preis ein Spiel zu machen, nur indem ich abartige Systemvoraussetzungen voraussetze, um mit billigsten Möglichkeiten irgendwas zu machen, das wär mir zu doof. Und wie ich es aus dem Subtext lese: Dir wohl auch.
zatzen hat geschrieben:Wenn es mir nur darum geht, den Spieler am Ende glücklich zu machen, sollte ich das vielleicht wieder aufgreifen, denn der hat weder von einer Beschränkung auf 640K etwas, noch etwas davon, wenn man versucht mit einem 486er auszukommen - vorausgesetzt er hat nen Pentium mit XMS, oder ein Windows-System und Dosbox.
Es gab Zeiten, da gab es eben diese Beschränkungen - und die Leute haben trotzdem coole Spiele gemacht und die Spieler waren glücklich. Also muß es möglich sein. Und zu glauben, daß JEDER Spieler immer nur auf höher-schneller-weiter steht, halte ich auch für voreingenommen. Es gibt Leute, die LIEBEN diesen Chiptune-Sound und pixelige Spielgrafik - gerade momentan, wo "retro" (wie es heute zusammengefaßt wird) ja wieder "in" ist, braucht man sich nicht zu schämen, ein Spiel rauszubringen, das den technischen Standards von 1992 entspricht.

Einen Vollgrafikstreifen in XMS zu legen, und den live ins Bild zu kopieren, mit Voraussetzung einer Maschine, bei der selbst die billigste Kopierroutine noch schnell genug wäre... Keine Ahnung - da wär mir die intellektuelle Herausforderung zu gering. Außerdem: So abfotografierte und runtergerechnete Hintergründe haben mir noch nie sonderlich gefallen - auch damals in alten DOS-Spielen nicht.
zatzen hat geschrieben:Diese Spieldemo ist eines der wenigen Ergebnisse der Projektwoche an unserer Schule, Projekt "Spiel programmieren". Du kannst Dir denken dass die meisten ihre Zeit nicht mit Spiel programmieren sondern Spiele spielen verbrachten.
Klar kann ich mir das denken. Hatte das denn Konsequenzen? Ich meine: Haben die Leute, die nix abgeliefert hatten (weil nur gedaddelt) wenigstens 'ne 6 für nicht erbrachte Leistung bekommen?

Anm.: Wir hatten im "Informatik"-Unterricht (1993-1995) auch unter anderem so Projektaufgabe. Konnten wir uns selbst aussuchen. Mein Projekt war ein Raumschiffscooter (in Textmode). Klein und häßlich - aber hat funktioniert. Hab das sogar noch hier. War aber damals ungetimed. (Wir hatten da 286er.) Naja - ich kam vom C64: Daß PCs unterschiedlich schnell sein können, hat mir damals keiner gesagt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Die anderen sehen nur das Endergebnis - nicht den Code und auch nicht die Zeit+Mühe, die es gekostet hat.
Absolut. Das impliziert aber auch, dass überhaupt jemand sich mit dem Endergebnis beschäftigen wird. Und da ich da nicht von sonderlich viel Resonanz ausgehe, mache ich das lieber so dass ich mich selbst einfach daran erfreuen kann, wenn ich weiss was da im Hintergrund heimlich alles passiert.
Ja, schon klar.
Wenn kompliziertere Routinen mindestens Speicher sparen ODER Rechenzeit sparen (oder im Idealfall eben beides), sind sie sinnvoll. Wenn Routinen aber mehr Speicher selbst mit Code belegen, als sie mit Datenreduktion sparen oder wenn die benötigte Zusatzleistung in keinem realistischen Verhältnis mehr zu gespartem Speicher (oder die Speicherersparnis in keinem Verhältnis zur verminderten Geschwindigkeit) steht, dann ent-kompliziere ich da auch schon gerne mal wieder. Ich baue zwar auch ganz gerne mal kompliziertes Zeug und freue mich, wenn es trotz aller Komplexität das tut, was es soll. Aber wenn ich merke, daß ich damit weder Performance noch Speicher gewinne, dann lege ich es unter "Experimente" ab und benutze es nicht in realen Projekten.

will sagen: Wenn weder der eine noch der andere Nutzen gegeben ist, behalte ich das Zeug mit den Routinen für mich, zum Herumspielen/Experimentieren - aber für das Spiel oder irgendein anderes ersthaftes Projekt würde ich dann etwas anderes nehmen.

Wichtig: Das sind alles nur allgemeine theoretische Überlegungen. Es geht dabei weder konkret um ZVID1/2 oder um meine Arcade-Routinen oder sonstiges. Wie sehr etwas spart/nützt/performt, muß erstmal festgestellt werden.
zatzen hat geschrieben:Sonst eben, wie oben beschrieben, kann man mit XMS und einem Pentium ziemlich einfach einiges reissen. Und der Großteil der "anderen", auch diejenigen die auf "Retro" stehen, dürften mindestens einen solchen Pentium ihr eigen nennen, oder eben ein aktuelles Windows/Mac System mit Dosbox besitzen.
Für mich völlig unwichtig. Nicht meine Referenz. Nicht meine Zielgruppe.
zatzen hat geschrieben:Aber meine Wahl ist ja erstmal nach wie vor 486er mit 640K. Die langsamen Sprite-Routinen namens ZVID2 halte ich für sinnvoll, weil ich das Spiel auch soundmäßig eher üppig ausstatten möchte. Wie gewichtig ZVID2 zu Buche schlagen wird muss sich dann noch zeigen.
Ob die ZVID2-Spriteroutinen langsam sind oder nicht, weiß ich ja nichtmal. Ich hatte nur aus meiner subjektiven Erfahrung heraus erwähnt, daß zu dichtes/komplexes Packen eventuell im Verhältnis weniger Speicher spart als es die verringerte Performace wert ist - aber wie oben erwähnt: Das muß man dann alles in der Praxis sehen. Es muß ja gar nicht so sein, daß die Spriteroutinen langsam / zu langsam sind. Kann ja sein, der Speed reicht aus. Kann auch sein, daß sogar die Performance erhöht wird, weil durch die vorbereiteten Daten die nötigen Grafikkarten-Zugriffe verringert werden. Wer weiß. Wie gesagt: Alles nur theoretische Überlegungen - wie gut es wirklich ist, kann nur die Praxis zeigen.
zatzen hat geschrieben:Die Anzahl der Sprites auf einem Bildschirm wird nicht sehr groß sein, aber trotzdem sollen in einem Level viele verschiedene Dinge existieren und die Animationen ausführlich sein. Deshalb die Kompression. Wenn die Grafik Cartoon-artig wird könnte man sehen ob einfaches RLE effektiver und performanter ist.Generell gefällt mir aber auch einfach die Idee eines im Grunde unniversell einsetzbaren Grafikformates, welches effiziente Kompression bietet, auch bei so Sachen wie Dithering, wo RLE versagen würde.
Schon klar. Bei mir selbst wird sich Animation wahrscheinlich meist eher in Grenzen halten: Ich bin schon kein guter Grafiker - und Animator erst recht nicht.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[ZSM 4 Bit Delta]Naja, hier hat der einseitige Performanceverlust ja eindeutig einen anderseitigen Gewinn: Files auf weniger als die halbe Größe (Samples) zu kriegen und Daten noch kleiner - und das, ohne daß das Endergebnis wirklich dermaßen reduziert klingt, wie es bei dieser Ersparnis eigentlich müßte - das ermöglicht mehr Platz für mehr Sound, Levels, Grafiken... Das ist also nicht "umsonst".
Bei ZVID2 ist die Ersparnis ja noch größer. Das wäre also auch nicht umsonst. Es sei denn, man hätte unkomprimiert nur z.B. 32K Sprite-Daten.
Kommt dann wieder ganz auf's Spiel und auch Spielprinzip an, würde ich sagen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[Mode Q]Der Modus erzeugt ja auch kein quadratisches, sondern ein 4:3-Bild! Und sieht dann genau so geil "8-Bit-konsolen-mäßig" aus, wie man denken würde!
Daß er bei Dir quadratisch aussieht, liegt daran, daß Du einen Emulator benutzt UND (aus Performancegründen?) die Ratio ausgeschaltet hast.
Habe ich nicht. Mich würde es ja ankotzen wenn ich bei MCGA immer Breitbild im Emulator hätte. Aber vielleicht muss ich noch irgendwas einstellen um so einen extremen Modus richtig darzustellen. Oder der Code mit dem ich das getestet habe tweakt nicht richtig. Es ist der hier: http://swag.outpostbbs.net/EGAVGA/0175.PAS.html
Hab's mir mal angeguckt - und ja: Das ist auch bei mir quadratisch - liegt aber daran, daß der das so getweaked hat - halt großen Overscan-Bereich usw.
Meine Routinen sind alle darauf ausgelegt, daß egal welches Pixelverhältnis die Auflösung hat, alles auf 4:3 gezogen ist. Die geringste Auflösung, die ich da habe, ist 128x150 (ja, Pixel groß wie Suppentassen), die höchste ist 512x512.
(512x512 auf reinem VGA ist natürlich schon 'ne Nummer! Hat dann aber nur 1 Bildseite, weil, mehr als 256 kByte unterstützt VGA nunmal nicht.)

Auf Emulator oder auf einem TFT (was ja auch quasi auch ein Emulator ist, der VGA und Rasterstrahl emuliert) paßt das natürlich gleich. Auf einem echten CRT-Monitor muß man da bei komischen Auflösungen immer nachregeln, damit die passen - weil man die Grafikkarte nicht für ALLE Monitore anpassen kann und man daher für die Pixel-Timing und Overscan- etc. Werte so allgemein brauchbare Mittelwerte nimmt, die noch ein darstellbares Bild erzeugen.

Genauer gesagt: Je "komischer" ein Modus ist, umso mehr kann es z.B. passieren, daß das Bild nicht genau zentriert ist (d.h. der Rand oben/unten/links/rechts nicht überall gleich ist) und man nachregeln muß. Das ist normal und hat nichts mit der Programmierung zu tun, sondern mit der Hardware, die für sowas besser oder schlechter vor-ausgestattet sein kann.
zatzen hat geschrieben:[Quadratische Pixel...]
Um Dich nicht weiter zu nerven schliessen wir das Thema mit einer letzten Erklärung ab:
Es geht wie gesagt nicht um die Form der Pixel sondern um die Verzerrung des Bildes wenn irgendein System das ganze interpretiert. Bei 320x200 fällt dem ungeschulten Auge erstmal kein Fehler auf, im Gegenteil, man freut sich wohl eher noch, dass das Bild breiter ist.
Naja, nicht jeder freut sich über ein breites Bild. Wie schon erwähnt, ist 16:9 für mich keine Augenweide.
zatzen hat geschrieben:Bei 256x256 würde man aber tutzig, da ein quadratisches Bild höchst ungewöhnlich ist.Ich finde 256x256 mit 4:3 Pixeln allein vom Prinzip her interessant, da Röhrenfernseher auch so aufgebaut sind. Zudem wird der Modus wohl hochauflösender wirken wegen 256 Zeilen, auch wenn man horizontal dann weniger hat.
Ja, wie gesagt: Meine Unit macht das so. Ein Bild irgendwo in die Bildmitte zu klatschen, damit auch bei komischen Auflösungen die Pixel quadratisch bleiben, war nie so meins.
zatzen hat geschrieben:Ja, gerne würde ich Deine Unit testen. Die bessere Adressierbarkeit des Mode Q könnte sich auch positiv auf das Block-Gedöns auswirken.
Naja, erstmal wäre es nur mal das Testprogramm mit der Anzeige der 172 Modi (die man aus dieser Tabelle auswählen und anzeigen kann - damit Du erstmal siehst, wie das aussieht und "was so geht".
Hier ist es:
http://www.imperial-games.de/z/ta.zip

Mit Cursortasten den Mode auswählen, Spalten in der Tabelle sind die Breiten, Zeilen die Höhen. Es gibt immer nebeneinander X und M (für Mode-X und MCGA). Was grün (oder orange) ist, ist darstellbar, was rot ist, nicht (weil Breite*Höhe>262144). Man kann mit Tasten 1 bis 0 festlegen, daß nur alles grün hinterlegt sein soll, was mindestens 1 bis 10 Bildseiten ermöglicht (standardmäßig ist 1 eingestellt). Wenn andere gewählt, sind die, die noch darstellbar, aber mit weniger Bildseiten sind, orange.

Wenn man da drauf steht (blinkendes X oder M) und Enter drückt, wird der Modus angezeigt als Grafik. Mit +/- kann man die Bildseiten wechseln, damit man sieht, daß es wirklich so viele sind. Da sind auch noch viele andere Tasten für ein paar "Experimente" möglich, z.B. diese Pixel-Halbierung (wo sich die X-Auflösung verdoppelt, man aber nur noch 16 statt 256 Farben hat) usw. Die Tasten hab ich nicht mehr alle im Kopf. Bei Interesse guck ich da nochmal nach, glaube O, P und X sind gute Kandidaten.

Mit nochmal Enter geht man wieder zurück zur Tabelle - naja, nehme an, Du kriegst das schon raus, ist keine Raketenwissenschaft.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[8 Bit LPT DAC]Ja, den Schaltplan für so Ding hab ich schon gesehen und eigentlich wär's kein Hexenwerk. Aber Ich hab eben noch nie gelötet.
Vielleicht hab ich ja nochmal Lust so einen zu basteln. Könnte ich Dir dann zukommen lassen. Das bringt mich gerade auch auf die Idee, ZSMPLAY darauf zu erweitern.
Da ich ja so Speaker-Ansteuerung schon mache (per schnellem Ticker und Direktzugriff auf Port), wäre Anpassung der Routinen für LPT für mich eine reine Fingerübung, weil Prinzip das gleiche ist, nur daß man sich, im Gegensatz zum Speakerport, die "Reduktionstabelle" sparen könnte, weil man bei jeder Tickerfrequenz die vollen 8 Bit hat.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn man einerseits Sound-zu-Framegenaue Perfektion anstrebt, es einem aber andererseits egal ist, ob komplizierte Routinen die FPS runterziehen - dann ist das irgendwie ein Gegensatz - zu dem mir keine gescheiten Programmiertips mehr einfallen.
Notgedrungen fällt mir da kein besseres Vorgehen ein. Die Soundroutinen füllen den Puffer und brauchen dafür ihre Zeit. Währrenddessen macht die CPU nichts anderes.
Ist bei mir ja genauso.
zatzen hat geschrieben:Außer wie oben erwähnt per Interrupt den schon fertig berechneten Puffer über den LPT auszugeben fällt mir da nichts ein was "parallel" passieren könnte. Ich will Dich mit diesem Problem nicht weiter belästigen und versuche es erstmal so.
Naja, ich mach's auch nicht anders. Nur setze ich kein "Warten" ein, um auf den nächsten Retrace zu warten, wenn ich sowieso weniger als die maximalen FPS erzielen kann. Sobald ermittelt wird, daß der sowieso nicht die volle (Bildschirmfrequenz ODER Spiel(-Schritt-)frequenz)- Rate schaffen würde, warte ich an KEINER Stelle, sondern ballere alles raus, was das Ding kann. Wieso sollte ich auch, wenn ich nichtmal die volle Framerate schaffe, das noch mehr reduzieren, indem ich auch noch Retrace-Warteschleifen einbaue? Kann ja jeder anders sehen, aber: Macht für mich keinen Sinn.

Erklärung: Wenn man nicht die volle Framerate schafft, ruckelt es sowieso - egal, ob man es GENAU auf die halbe, drittel, viertel oder wasweißich Rate setzt oder ob die Rate eben sowas Krummes wie 37,43196 FPS wäre. Da hab ich lieber die krumme, aber höhere Rate als noch zusätzlich auf irgendwas zu warten. Die einzige Möglichkeit, mit so genauen "geradzahligen Teilern" ohne Ruckeln auszukommen, wäre, wenn z.B. bei halber Framerate auch das Spiel nur noch genau halb so schnell laufen würde und bei drittel entsprechend. Das wär mir ehrlich gesagt zu doof. Das Spielerlebnis basiert ja auch auf der Geschwindigkeit des Spiels (der Gegner, der eigenen Schüsse, dem eigenen Reaktionsvermögen). Ein cooles, actionreiches Spiel, das aber mit 50% Geschwindigkeit abgespielt wird, wirkt dann wie lahmer Kindergarten-Kram.
zatzen hat geschrieben:Fraglich ist, ob ZVID2 effektiv langsamer sein wird als Deine Sprite-Routinen,
Vielleicht, vielleicht auch nicht. Muß die Praxis zeigen. Meine Spriteroutinen sind 16 Jahre alt, nicht 100% ASM (sondern noch einiges an Pascal drin) und aus heutiger Sicht könnte da viel optimiert werden, was mir damals nicht eingefallen ist.

Ich sag's mal so: Kann gut sein, daß Deine Spriteroutinen mehr Performance haben UND mehr Speicher sparen. Aber nehmen wir mal an, so Sprites währen für ein 2D-Spiel, mit Seitenansicht (z.B. Jump'n'run) : Wenn die Sprite-Routinen kein X-spiegeln können, braucht man für das gleiche Männchen die doppelte Anzahl Sprites an Lauf-Animationsbildern als bei einer Routine, die spiegeln kann. Da ist eine Nicht-Spiegel-Routine dann -speichermäßig- nur dann besser, wenn sie mehr als 50% packt.

Zusätzlich: Wenn so Männchen max. 15 Farben hat "packt" sowas wie meine Arcade-Routine das Ding ja schon quasi fast auf 50%, weil nur noch 4bit pro Pixel (fast, weil noch 16 Bytes Metapalette benötigt), behält dabei aber trotzdem freien Zugriff zu jeder Zeit auf jeden Pixel (ohne andere Pixel vorher zu lesen/entpacken), kann dabei also weiterhin clippen, drehen, skalieren, spiegeln, dithern...

Aber natürlich bedeutet all das trotzdem, daß nominal meine alten Arcade-Sprites durchaus langsamer sein können als Deine neuen ZVID2-Sprites.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn Du a) Verzögerungen im einstelligen Millisekundenbereich hörst und b) das für Dich unerträglich ist[...]
Damit wir uns nicht falsch verstehen: Ich meine hier nicht Divergenzen zwischen Bild und Ton, sondern Soundlücken. Die können schon nervig sein wenn man die Puffer dann einzeln nacheinander gestückelt hört.
Achso. Ja, sowas tät mich natürlich auch nerven.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Die Generierung des neuen Sounds gleich im IRQ. Da weiß ich noch nicht, ob ich das mag. Eigentlich find ich's Mist.
Das fände ich auch etwas "gruselig". Ich bin ja noch Anfänger und halte Interrupts lieber klein. Bei ZSMPLAY müssten dann je nachdem auch Patterndaten nachgelesen werden, also ein ganzer Haufen Pascal-Unterprogramme usw.
Ja, ich murks zwar auch schon in Interrupts ziemlich rum: Interrupts, die sich selber unterbrechen und so - z.B. der schnelle Ticker, der ja gleichzeitig auch das "normale" Zeug enthält (der also wie ein kombinierter schneller und langsamer Ticker funktioniert), der kann sich selber auch mit schnellen Ticks unterbrechenm, damit, wenn er grad den langsameren Teil ausführt, trotzdem noch schnelle Ticks passieren können - damit weiterhin diese Speaker-Ausgabe problemlos geht. Weil die langsameren Teile ja seltener vorkommen, macht das auch Sinn und kaskadiert den Stack nicht - aber man muß da natürlich trotzdem ein bißchen kreativ rangehen, damit sich das nicht "selbst zerledert"...
Also ja: Es wäre auch möglich, die Neuberechnung der Sounddaten in den SB-IRQ zu verlegen. Aber da muß man eben trotzdem aufpassen, daß der Rest seine Ordnung behält.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ach naja - mein Zeug braucht auch alles wohl schnellen 486er. Durch Vorhandensein einer solchen Kiste wird man irgendwie versaut.[...]Manchmal schäme ich mich für mein lames Zeug. Aber zum Glück interessiert sich kaum jemand für den Müll.
Ich habe den Wettbewerb mit den besten der besten (die sich u.a. bei Szenepartys mit Demos oder Musik Wettbewerbe liefern) längst aufgegeben und habe einfach Spaß an meinem persönlichen Vorankommen.
Ich hatte nie so einen Wettbewerb überhaupt angefangen oder in Erwägung gezogen - nicht einmal, als ich noch jünger und dümmer war. Ich bin einfach nicht eingebildet genug, um ernsthaft zu glauben, ich mit meinen popeligen Fähigkeiten wäre irgendwie in der Lage, Dinge von Future Crew oder id-Software zu toppen.

Natürlich versucht man immer, sich irgendwie weiterzuentwickeln. Aber dabei eine realistische Selbstbetrachtung zu bewahren, ist dabei auch Voraussetzung, um immer noch überhaupt eine Entwicklung zu machen. Ab dem Punkt, wo man sich selbst für den Größten hält, hat's keinen Sinn mehr. Die richtig Guten halten sich nie für den Größten - und das ist ja auch das ganze Geheimnis, um immer besser zu werden. Das und eben die Mühe und Bereitschaft, dazuzulernen.
zatzen hat geschrieben:Ich werde im Leben nicht an die "Genialität" von Leuten herankommen, die meinetwegen 50% ihrer Lebenszeit dem Programmieren widmen und dort auch noch "hochbegabt" sind und mit ihren Sachen die Leute zum Staunen bringen.
Achnaja, Begabung ist nur ein kleiner Teil des Ganzen. Das meiste ist einfach viel Zeit, Mühe und Elan. Wenn man das alles auf Begabung schiebt, ist das ja so, als würde man sich selbst irgendwie ein Behindertenzeugnis ausstellen im Sinne von "bin genetisch nicht veranlagt". Klar - es gibt immer Leute, die für Dinge mehr oder weniger Talent haben. Allerdings kann man auch mit genügend wirklichem Interesse (wirklich = auch Bereitschaft, dafür zu arbeiten) eine Menge erreichen.

Ich sage ja immer, daß ich kein talentierter Grafiker/Musiker bin. Das liegt aber auch daran, weil meine Interessen woanders liegen und ich diesen Interessen mehr Lebenszeit widme. Wenn ich grafisch oder musikalisch mehr "üben" würde, würde ich da sicher auch besser werden können. Aber Interesse kann man eben nicht vortäuschen... Damit meine ich: Anderen gegenüber vielleicht schon. Aber SICH SELBST kann man Interesse nicht vortäuschen. Man kann sich nicht selbst einreden, sich für etwas mehr zu interessieren, als man es tut. - DAS ist wohl das Problem dabei.

Will sagen: Ja, ich interessiere mich auch für Grafik. Aber eher aus der programmiererischen Sicht heraus, d.h. wie ich es technisch schaffe, bestimmte Dinge grafisch zu ermöglichen. Ich pixle auch ganz gerne - aber code eben noch lieber.

Und was Töne angeht: Ich habe relativ spät überhaupt auf JEDEM System angefangen, mich für Klangerzeugung zu interessieren und mich näher damit zu befassen. ISM ist ehrlich gesagt nur entstanden, weil ich es irgendwie für nötig erachtete, daß so ein Spiel vielleicht mal irgend eine Hintergrundmusik haben sollte (weil das bei Spielen eben so ist / sein sollte) und daß es bei bestimmte Dingen, die im Spiel passieren, es etwas cooler machen würde, wenn zusätzlich zur grafischen Darstellung es auch 'n bißchen Krachbumm machen würde.

Anders ausgedrückt: ISM ist *NICHT* entstanden, weil ich der Welt unbedingt meine kompositorischen Fähigkeiten darbringen wollte oder etwa ein Füllhorn toller Musikideen hätte, die auf ihre Realisierung warten würden.

Ehrlich gesagt habe ich eher so wenige musikalische Ideen, daß ich immer, wenn mir zwischendurch etwas einfällt, ich das kurz ins Mikro singe und aufnehme, damit ich's da hab, wenn ich mal 'n Stück Musik brauche. Inzwischen habe ich mir (vor ein paar Jahren) mal dazu ein Diktiergerät zugelegt, damit ich das auch machen kann, falls mir unterwegs mal etwas einfällt.
zatzen hat geschrieben:Ich habe in diesem Zusammenhang aber etwas interesssantes gefunden, eine Game-Engine im Mode-X, die, wie unter dem Video steht, auf einem 8086 PC (also < 286) mit 8 MHz performt: https://youtu.be/9vdsRD3oI3c
Hab ich mir angeguckt: Sehr nett UND sehr beeindruckend - vor allem, wenn man das Zielsystem bedenkt. Soviel zum Thema "geht nicht"... - Es scheint eine ganze Menge zu gehen, selbst mit dem langsamst-möglichen PC. (Ich hatte ja auch mal den "8-Bit Guy" erwähnt, der sein "Planet X3" ebenfalls für langsamste PCs gebaut hat und trotzdem recht Beeindruckendes geleistet hat.)

Dann also nochmal die rhetorische Frage meinerseits: Wenn DAS (siehe oben) auf 80-86 geht (mit 'ner alten VGA, ohne Hardwarebeschleunigung und fast 40 Jahre alter Hardware) man aber heute mind. sowas wie einen 80-1286 hat, mit 4 Kernen und je 4 GHz, mit Terabyte Festplatte und Gigabyte Solid-State-Drives, und sogar die Grafikkarten standardmäßig 2D- und 3D-Hardwarebeschleunigung haben: WIESO passiert dann in Windows trotzdem *NICHTS* auch nur annähernd in Echtzeit - nichtmal dieses normale blöde, reine 2D-Fenster-GUI-Zeugs? Wie wir ja gerade gesehen haben, kann es NICHT an der Hardware liegen... und da bleiben ja dann nicht mehr viele mögliche Antwort-Optionen übrig.
zatzen hat geschrieben:Was auffällt ist natürlich, dass nur wenige Sprites unterwegs sind, und dass es bis auf Bodenkollision in dieser Version keinerlei Kollisionsabfragen gibt, zudem auch keine komplexeren Ebenen, sondern immer nur ein Hintergrundbild.
Tja, schon. Aber für diese Art spiel reicht eine Hintergrundebene ja aus. Und: Die ruckelt nicht, die Sprites (oder der Sprite) flimmert nicht - alles sieht aus als könnt man meinen, das passiert alles in Hardware. Also: Super Ding. Respekt an die Entwickler!
zatzen hat geschrieben:Es kommt einfach auf die Vorstellungen und Ideale an, die man hat. Wenn ich mir zum Ziel setze, dass genau das hier die Herausforderung sein soll, auf einem "schwachen" System etwas möglichst attraktives zu zaubern, dann ist es interessant, sogar auf 386+ Befehle zu verzichten, und auf Zeugs wie ZVID2, da die Bild- bzw. Spritedaten sowieso winzig sind.
Tja, so ist es.
zatzen hat geschrieben:Wenn ich aber ein Spiel mit üppigem "Multimedia" auf Amiga-Niveau haben will, dann werde ich nicht um 386er oder 486er herumkommen, da ich ja Hardware wie den Soundchip emulieren muss. Das wäre mit einer 8086 CPU unvereinbar.
Mag sein. Allerdings weise ich an dieser Stelle wieder mal auf dieses Strategiespiel "Planet X3" von "The 8-Bit Guy" hin, der da dieses Ding fast im Alleingang (und 100% ASM!) gebaut hat. Für DOS, läuft auf unterstem 8086er, braucht nur 256 kB RAM, trotz großer Level und Adlib-Musik/SFX.

Wenn man sich Mühe gibt (und die Zeit und Kraft hat), geht eine ganze Menge. Mit Aussagen wie "geht nicht" und "System zu langsam/unzureichend" werde ich immer vorsichtiger, weil man immer wieder sieht, was wirklich so alles geht.

Wenn die eigenen Fähigkeiten (noch) nicht ausreichen, um bestimmte Dinge zu tun, sollte man fairerweise trotzdem nicht der Hardware die Schuld geben, sondern das Problem IMMER zuerst bei sich selbst suchen.

Ich selber bin auch nicht gut genug, um viele Dinge, die ich mache für unterhalb 486er performant genug hinzukriegen. Das bedeutet für mich aber nicht, daß ein 386er zu langsam ist, sondern, daß ICH noch zu schlecht bin als Coder! Zur Erinnerung: Doom läuft auf 386 - und nicht mal schlecht. Und Doom ist "3D" - in 100% Software. Also kann man sich nicht einfach hinstellen etwas behaupten im Sinne von "sobald 2D etwas aufwendiger wird, geht nichts unterhalb 486er".
zatzen hat geschrieben:Kaum hab ich das geschrieben, habe ich ein weiteres Video entdeckt, woraus hervorgeht dass auch die Gravis Ultrasound unterstützt wird, die quasi das PC-Pendant zum Soundchip des Amiga ist. Trotzdem wird hier offenbar AdLib verwendet. Falls es Dich noch weiter interessiert, hier das besagte Video auch mit ein paar Erklärungen https://youtu.be/RctvPO8WkCs
Wobei man ja sagen muß, daß die GUS zu benutzen, aus Coder-Sicht eher "cheaten" ist: Da die GUS Dinge wie Samples in verschiedener Höhe abspielen und mehrstimmig mixen schon in Hardware tut, die man bei SB-Coden selber in Software machen muß, nimmt sie dem Coder UND der CPU ja eher Arbeit ab.

Ich selber kann zwar nicht GUS coden (weil ich die Specs nicht habe) - aber trotzdem ist für mich der der versiertere/coolere Coder, der die Dinge selber softwaremäßig hinkriegt als der, der sich darauf verläßt, daß die Hardware es alleine macht. (Nur meine persönliche Meinung.)

Außerdem: Die GUS ist zwar die beliebteste "DOS-Soundkarte" für Soundfetischisten - allerdings sind SoundBlaster (2.0) (und AdLib) wohl eher der "Quasi-Stamdard" für alles, was unter DOS lief. Damals war die GUS schon eine größere Anschaffung und die hat nicht jeder einfach so getätigt. Dementsprechend haben natürlich auch die Entwickler reagiert und primär die Haupthardware supportet. Wenn jemand ein Spiel herausgebracht hätte, das, um Musik und Sound zu haben, zwingend eine GUS gebraucht hätte, und ohne GUS komplett stumm gewesen wäre - das Ding hätte er einfach nicht verkaufen können.
zatzen hat geschrieben:Diese minimal-anfordernden Projekte haben immer ihren Charme, trotzdem bieten nach meinem Empfinden Spiele mit ausführlicherer Grafik und evtl. Sample-Sound einen höheren Unterhaltungswert.
Naja, klingt für mich nach: Schon zu versaut von modernen Medien. Kann ein Spiel bzw. Medium nur genießen, wenn die technischen Parameter entsprechend hoch sind. Diese Attitüde hatte ich nie. Und ich habe schon so einige Spiele gesehen mit viel Sound und vielen Farben und hoher Auflösung, aber dafür lahmen Spielprinzip - deren Unterhaltungswert trotz technischem Gigantismus geringer war als der so manchen pixeligen 16- oder 4-farb-Spiels mit Speakersound.

So Spiele, die ihre lahme/einfallslose Spielidee mit Haufen überkandidelter Grafik/Sound aufpimpen, nannte man irgendwann "Grafikblender". Und irgendwann haben Leute (zumindest der intelligentere Teil der Spieler) damit aufgehört, auf Grafikblender reinzufallen.
Das war ein herber Schlag für manche Spielebuden und Publisher, als plötzlich "Hauptsache 3D und Ego-Geballer" irgendwann NICHT mehr als Verkaufsargument ausgereicht hat.

Und - oh Wunder! Plötzlich sind die jahrelang als "verkauft sich nicht" und "will sowieso keiner" titulierten handgezeichneten 2D-Point&Click-Adventures wieder beliebt wie "seinerzeit"! Plötzlich spielen Auflösung, Farbtiefe oder nicht-vorhandenes 3D keine Rolle mehr... Tja: Weil ein gutes Spiel oder hoher Unterhaltungswert sich eben NICHT nur an technischen Parametern messen lassen kann...
zatzen hat geschrieben:EDIT: Ich habe einmal ein Bild auf 256x256 resamplet und auf 4:3 gezogen. Im Vergleich mit 320x200 zeigt sich zwar eine deutlich höhere vertikale Auflösung, aber diese rechtfertigt sich für mich nicht wenn man die horizontale Einschränkung betrachtet. Insgesamt wirkt ein 256x256 Screen weniger hoch auflösend.
Ja, wie gesagt: Hochauflösend ist nicht alles und - zumindest für mich - nicht der magische Weg zum Seelenheil.

Ich LIEBE z.B. diesen 8-Bit-Konsolenlook und daß es etwas pixeliger ist, ist für mich kein Nachteil.

Ulkigerweise gibt es z.B. sogar schon Spiele wie "Shantae and the Pirate's Curse" (=Shantae 3), die zwar auf dem Hostsystem auf 1024er Auflösung laufen, dessen Grafik und Sprites aber ABSICHTLICH so pixelig gemacht werden daß es wie 320x200 oder so aussieht - und die Leute LIEBEN es!
(Bei Hostsystemen wie Win7 und drüber kann ein Programm nicht die Screenauflösung des OS ändern.)

Jedenfalls scheine ich wohl nicht der Einzige zu sein, den "Pixeligkeit" nicht nur "nicht stört", sondern der sogar Wert darauf legt.
zatzen hat geschrieben: Daraus ziehe ich nun den Schluss dass ich für mein Spiel wohl bei 320x200 bleibe. Auch weil ich die Grafik in Deluxe Paint machen werde, und das Programm bietet keinen 256x256 Modus an.
...was wohl unter anderem auch daran liegen mag, daß WINDOWS keinen 256x256 Modus anbietet... :)
zatzen hat geschrieben: Wer dann im Emulator Eier statt Kreise hat - meinetwegen selber schuld.
Anmkerung dazu: Um die Verwandlung von Kreisen zu Ellipsen zu kompensieren, ist ja eine Methode vorhanden: Man zeichnet einfach Ellipsen mit angepaßter Ausdehnung in die jeweils andere Richtung - und schon sind's wieder Kreise. (Hatte ich oben schon erwähnt.)

Meine Arcade-Sprite-Routinen haben, wie eräwhnt, eine Option, einen Korrekturwert hinzuzufügen, um eine abweichende Ratio auszugleichen (selbst einstellbar). Diese wird erst NACH der Drehung hinzugefügt (bzw. so hinzugefügt, daß es nach der Drehung wirksam ist): Nämlich, daß wenn ein Sprite sich dreht, es sich trotzdem kreisförmig dreht/ausdehnt, auch wenn die Ratio etwas komisch ist. Normalerweise benutze ich das nicht mal, weil ich die Abweichung bei 320x200 nicht gerade überwältigend schlimm finde - aber es ist eben vorhanden - vor allem, weil ich auch unter anderem (durch die möglichen Breite/Höhe Kombinationen) recht schräge Auflösungen (128x512 oder 512x150 gehen ja schließlich auch!) supporte und damit kein Bedenkenträger da wegen der nicht ratio-skalierbaren Sprites jammert.
zatzen hat geschrieben:Deine Modi-Demo wäre nach wie vor interessant, ist aber nicht von entscheidender Bedeutung für mein Spiel.
Ich bin nie davon ausgegangen, daß irgendeins meiner Programme oder Entwicklungen von entscheidender Bedeutung für Dein Spiel/Deine Entwicklungen sind oder sein müßten.

Und ja, der Link für das Ding ist ja in diesem Text enthalten.

Und, falls es Dich interessiert: Ich habe hier noch etwas gebastelt, daran habe ich in den letzten Wochen (waren so 3 Wochenenden, netto 5 Tage, mit kranheitsbedingter Unterbrechung) so experimentiermäßig herumgebaut. Vielleicht gefällt's Dir ja. Zeigt auch mal, was so ein 486er wirklich kann. (Also: DOSbox auf 486er-Speed stellen!)
http://www.imperial-games.de/z/486power.zip
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

DOSferatu hat geschrieben:Ahja. d.h. es gibt keine gepreßten CDs von Dir zu kaufen, aber gebrannte. Machste da auch ein Case drum mit nem Inlay/Booklet? Oder verschickst Du die in 'ner Plastiktüte?
Pressen macht nicht viel Sinn, dann hab ich hier hinterher über 200 CDs rumliegen die keiner haben will. Wäre natürlich mal was und könnte ich mir vorbehalten um einmal im Leben eigene gepresste CDs zu haben, aber gerade in der heutigen Zeit wäre das unvernünftig, weil kaum noch jemand CDs haben will. Aber Case/Inlay/Booklet ja, und das kann man sich auch professionell drucken lassen in kleinen Mengen, ebenso bedruckte Rohlinge.
DOSferatu hat geschrieben:Für mich ist also jeder, der ein Programm (Spiel/Tool) als "App" bezeichnet ein verkappter Apple-Fanboy...
Hmm, Windows 10 macht das auch...
DOSferatu hat geschrieben:ICH werd' mich bei der Entwicklung meines Zeugs nicht einschränken/umbiegen lassen, damit das Zeug auf irgendwelchen "Anzeigestandards" von heute toll ist.
Ich bin da ein bisschen zweigleisiger eingestellt. Vielleicht auch weil ich nicht so der überflieger als Programmierer bin und eher bei Standard-Modi und sowas bleibe. Ich finde es als Bonus ganz nett, wenn meine Software auch in DosBox einwandfrei genießbar ist, so dass auch die dazu Zugang haben, die kein natives DOS-System mehr bereitstehen haben. Wie könnte ich auch anders, ich gehöre ja selber zu denen...
DOSferatu hat geschrieben:Zum Beispiel: 16:9, 21:9, 22:9 und all diese Formate finde ich absolut gräßlich. Für mich ist die einzig gültige und gescheite Bildratio 4:3. Manche Leute meinen, 16:9 wäre näher am menschlichen Blickfeld - Augen nebeneinander und so. Aber ich sage: Stimmt nicht. Denn: Die Blickfelder beider Augen überlagern sich zu mind. 2/3 - sonst könnte man nämlich garnicht räumlich sehen. Und damit ist 4:3 dem menschlichen Blickfeld weitaus näher als dieser ganze 16:9-Blödsinn.
4:3 Für den Arbeitsbildschirm, da gebe ich Dir absolut recht. Der Bereich in dem man halbwegs scharf sieht ergibt eher ein 4:3 Verhältnis. Vielleicht sogar eher einen Kreis, weil das wirklich scharfe Sichtfeld ja sehr klein ist und die Augen beide einen Punkt fokussieren.
Die komplette Wahrnehmung, um die unscharfen Bereiche links und rechts erweitert, lässt sich aber besser mit 16:9 abdecken. Für Filme kann das sinnvoll sein für ein besseres Erlebnis, denn während man in den Randgebieten des Sichtfelds unklar sieht, reagiert man dort besonders empfindlich auf Bewegungen. So kann man z.B. das Flimmern eines 50 Hz Röhrenfernsehers besonders gut sehen wenn man ihn im Sichtfeld ganz außen platziert.

Was natürlich auch Nerven kann, ist "Letterbox". Das reduziert ja direkt die Auflösung. Hatte man ja früher oft bei Filmen auf nem 4:3, mittlerweile gibt es sowas auch bei 16:9 Bildschirmen, dass das ganze dann eher 8:3 wird...

Seien wir mal froh dass wir keine Pferde sind. Sonst hätten wir 360° Kinos.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Einschränkend wird das ganze aber dann, wenn man Grafiken für ein Spiel machen will. Dann ist man entweder auf eine Dos-Software angewiesen,
Du sagst das so, als wäre DOS-Software etwas schlechtes.
Das sage ich nicht direkt, aber es gibt sehr praktische Grafiksoftware unter Windows.

Das einzige was mich an Windows bislang stört ist die Programmierung, weil man da nicht einfach so "from scratch" loslegen kann und Ton und Grafik ausgeben kann. Deswegen ist für mich DOS attraktiver für etwas das Bild und Ton ausgibt, und dass das momentan hier alles in der Box läuft stört mich erstmal nicht.
DOSferatu hat geschrieben:Meine Begeisterung für sog. "moderne Systeme" hält sich echt in Grenzen.
Ich nutze mein modernes System praktisch nur als kreative Bearbeitungsmaschine. Da sind manche Dinge dabei die vor 25 Jahren in DOS noch nicht möglich waren, und auf der damaligen Hardware auch heute nicht möglich wären. Das ist natürlich für Dich irrelevant da Du es weder mit zig-spurigen Tonabmischungen in Studioqualität mit Software-Emulation komplexer Studiogeräte noch mit rechenintensiver Bearbeitung von HD Videos zu tun hast. Aber das sind eigentlich meine größeren Hobbys hier, zumindest das mit dem Ton, das hat mich wesentlich dazu bewogen, mir alle 5-7 Jahre einen neuen Rechner anzuschaffen, weil zumindest die bestehende Software dann besser performt. Programmieren ist nebenbei immer mal schön, um sich rein rational zu beschäftigen. Aber wenn es nur das wäre, DOS-Anwendungen, dann würde mir in der Tat wohl auch ein 486er genügen.

Mein aktueller Rechner, i5, 3.4 GHz, C: 250 GB SSD, Windows 10, bootet in weniger als 10 Sekunden (vom Zeitpunkt des Power-Knopf-Drückens). Ich kann mich da nicht beklagen.
Ich habe mich lange gegen Windows 10 gewehrt, so wie ich mich gegen Windows 7 gewehrt habe, aber ich gewöhne mich dran und finde es nicht schlecht. Aber naja, vielleicht sollten wir hier nicht so viel über Windows reden. Faktisch bin ich ein vermeintlich schäbiger Windows-User, aber mit langer DOS-Vorgeschichte, vor allem was Programmieren angeht, und dem klar ist was im Computer unter der "klickibunti"-Haube wirklich passiert, wobei das bei Windows eine sehr, ich sag mal einfach, unübersichtliche Sache ist. Tausende Systemdateien, zig Prozesse laufen die ganze Zeit über...
DOSferatu hat geschrieben:Wenn man etwas so entwickelt, daß es auf einem Emulator gut, aber auf dem echten System schlecht performt oder auf dem Emulator funktioniert, aber auf dem echten System nicht, dann entwickelt man für den Emulator - und das macht keinen Sinn, weil der ja nicht dafür gedacht ist, "für sich selbst als System" zu stehen.
Das ist auch nicht meine Absicht. Ich habe bislang wohl Glück gehabt, das bisher alles, was ich in der Emulatorumgebung programmiert habe, auch auf einem echten System funktioniert und performt hat. Möglicherweise ist es eher so, dass was im Emulator funktioniert, auch auf Hardware funktioniert, aber nicht umgekehrt. Was die Performance angeht sind die 20000 Cycles ja von mir absichtlich bescheiden gewählt (ist mir klar dass das auch kein Benchmark ist, aber so "über den Daumen gepeilt" verhindert es, dass man als Hardware einen Pentium braucht).
DOSferatu hat geschrieben:Was ist für Dich denn ein 486er? Ich meine: Die gab es mit 25, 33, 50, 66, 75, 100, 120, 133 und (selten) 150 MHz (und dann auch noch SX und DX).
Sagen wir mal so, dass 100 Mhz für meine Projekte reichen. Laut DosBox-wiki entsprechen 26800 Cycles grob einem 486 mit 66 Mhz. Wenn mein Kram mit 20000 Cycles funktioniert, dürfte eine 100 MHz Maschine das hinkriegen, vielleicht auch eine mit 50.
DOSferatu hat geschrieben:1. Wenn Figur und Hintergrund so unterschiedlich sind von der Art der Grafik (Hintergrund: Foto, Figur: Handgepixelt) wirkt das immer etwas blöd.
2. Foto-Hintergründe (als Vollbild) ist für mich nicht das, was ein 8-/16bit-Spiel für mich ausmacht. Das ist immer eher wie eine Demo als ein Spiel für mich.
Ja. Tatsächlich ist es ja auch nur eine Demo. Der Witz an dem Hintergrundbild war zum einen, dass es für mich eine Neuheit war, megabyteweise Grafiken aus dem XMS zu holen. Und dann war für uns noch eine Sache, dass diese Häuserlandschaft jene ist, die in der Nähe des Schulgebäudes entlang des dortigen kleinen Flusses verläuft. Ich hatte mich mit meiner Unbegabheit lange genug an der Spielerfigur mit pixeln aufgehalten, da war am Ende der fünf Tage keine Motivation und Phantasie mehr für gepixelte Hintergründe übrig.
DOSferatu hat geschrieben:Naja, um jeden Preis ein Spiel zu machen, nur indem ich abartige Systemvoraussetzungen voraussetze, um mit billigsten Möglichkeiten irgendwas zu machen, das wär mir zu doof. Und wie ich es aus dem Subtext lese: Dir wohl auch.
Richtig. Aber damals mit dieser Demo war ich auf dem Weg dahin. Das lag aber auch ein bisschen daran dass ich von der Duke Nukem 3D Engine inspiriert war, die scheinbar keine Speichereinschränkungen kannte. Wir haben das Spiel öfters mal modifiziert und z.B. ewig lange Sounds da reingebaut.
DOSferatu hat geschrieben:Es gab Zeiten, da gab es eben diese Beschränkungen - und die Leute haben trotzdem coole Spiele gemacht und die Spieler waren glücklich. Also muß es möglich sein. Und zu glauben, daß JEDER Spieler immer nur auf höher-schneller-weiter steht, halte ich auch für voreingenommen.
Klar, so um 1989 habe ich die Spiele auf unserem 286er bestaunt. Sowas wie Captain Comic oder etwas später Commander Keen 4, das funktionierte auch noch meine ich. Aber als mir dann weitere coole Spiele unterkamen die zwar liefen, aber mit ner Framerate von 3 oder so, enstand schon immer mehr der Druck auf einen neuen Rechner. Später waren es dann wie oben erwähnt keine Spiele mehr weshalb ich neue Computer wollte (zu der Zeit wo ich spielte reichte ein 486er eigentlich) sondern kreative Anwendungen, die mit mehr Leistung und Speicherkapazitäten einfach schneller und stabiler liefen.
DOSferatu hat geschrieben:Es gibt Leute, die LIEBEN diesen Chiptune-Sound und pixelige Spielgrafik - gerade momentan, wo "retro" (wie es heute zusammengefaßt wird) ja wieder "in" ist, braucht man sich nicht zu schämen, ein Spiel rauszubringen, das den technischen Standards von 1992 entspricht.
Sehe ich genauso. Man kann nur von den "Neo-Retros" nicht unbedingt verlangen dass sie nen Dos-Rechner haben, geschweige denn überhaupt wissen was z.B. "8 Bit" überhaupt bedeutet. Der Begriff fällt, sobald man bei der Grafik Pixel sehen kann... Aber es besteht kein Zweifel, dass neue Spiele nach 1992er Standard gut ankommen werden. Zumindest bei denen, die nicht alles in 4K haben wollen. Aber wohl:
DOSferatu hat geschrieben:Nicht meine Referenz. Nicht meine Zielgruppe.
DOSferatu hat geschrieben:Haben die Leute, die nix abgeliefert hatten (weil nur gedaddelt) wenigstens 'ne 6 für nicht erbrachte Leistung bekommen?
Diese Projektwochen sind unabhängig von Zensuren und werden von Lehrern höchstens betreut aber nicht bewertet. Normalerweise gibt es einen Präsentationstag, aber den hatten wir irgendwie nicht.
DOSferatu hat geschrieben:Wenn kompliziertere Routinen mindestens Speicher sparen ODER Rechenzeit sparen (oder im Idealfall eben beides), sind sie sinnvoll.[...]Aber wenn ich merke, daß ich damit weder Performance noch Speicher gewinne, dann lege ich es unter "Experimente" ab und benutze es nicht in realen Projekten.
Was ZSM angeht mache ich speichermäßig auf jeden Fall etwas sinnvolles, denn 640K bzw. was noch frei ist, sind mit Sound schnell voll. Performancemäßig ist es ein Kompromiss, der hier wegen der Speicherersparnis aber tragbar scheint. ZVID2 könnte grenzfällig werden. Wenn die Speicherersparnis nicht vonnöten ist, wäre es nur Performanceverlust. Allerdings überlege ich auch schon an einer Art Adventure mit großen, eher wenigfarbigen Grafiken (d.h. Comic-artig). Da kommt das zum tragen und wäre nötig, um wiederum die 640 K nicht zu sprengen. Bei einem Adventure kommt dazu dass man da keine 50 fps braucht... Bei allen Performanceeinbußen kann ich mir überlegen: Was ist mir wichtiger, dass es auf einem 25 SX läuft ohne meine "Tricks" oder auf einem DX 66 mit meinen Tricks...
DOSferatu hat geschrieben:Je "komischer" ein Modus ist, umso mehr kann es z.B. passieren, daß das Bild nicht genau zentriert ist (d.h. der Rand oben/unten/links/rechts nicht überall gleich ist) und man nachregeln muß.
Das würde ja dafür sprechen, dass man lieber bei den gängigen Grafikmodi bleibt, gerade wenn es für reale Systeme sein soll.
DOSferatu hat geschrieben:[...]Testprogramm mit der Anzeige der 172 Modi[...]
Danke! Sehr interessant, das alles mal vergleichen zu können. Und es funktioniert sogar alles in DosBox - halbwegs. Das beachtliche 512x512 wird breiter als 4:3. Für mich kämen aber erstmal auch nur die wenigen MCGA-Modi in Frage, und da würde ich mich lieber noch mit Dir abstimmen wollen ob man dann mit einem echten System nicht immer am Bildschirm drehen muss. Nebenbei: 160x200 auf vollen 4:3 Bildschirm ist wohl ein EGA-Mode. Hatten ja früher u.a. Sierra Spiele.
DOSferatu hat geschrieben:Wenn die Sprite-Routinen kein X-spiegeln können, braucht man für das gleiche Männchen die doppelte Anzahl Sprites an Lauf-Animationsbildern als bei einer Routine, die spiegeln kann.
Spiegeln ist ja kein Ding. Das konnten nur die ollen PUT-Routinen in QBASIC nicht. Wie auch keine Transparenz.
DOSferatu hat geschrieben:Zusätzlich: Wenn so Männchen max. 15 Farben hat "packt" sowas wie meine Arcade-Routine das Ding ja schon quasi fast auf 50%, weil nur noch 4bit pro Pixel (fast, weil noch 16 Bytes Metapalette benötigt), behält dabei aber trotzdem freien Zugriff zu jeder Zeit auf jeden Pixel (ohne andere Pixel vorher zu lesen/entpacken), kann dabei also weiterhin clippen, drehen, skalieren, spiegeln, dithern...
Ja, da ich mich nie mit der Programmierung von Drehen oder Skalieren (in "Echtzeit") beschäftigt habe, kommt das bisher für mich auch nicht in Frage und daher brauche ich keinen "random access" auf die Pixel und kann mir erlauben sie in 4x4 Blöcken seriell zu entpacken. So gesehen opfere ich hier wegen Kompression großartige Möglichkeiten, allerdings würden skalierte oder gedrehte Sprites mein Konzept der Grafik im Spiel stören. Ich fand auch die Skalierung in Monkey Island I nicht so schön. Wenn die gesamte Spielgrafik wohlüberlegt gepixelt ist und dann etwas "lieblos" (auch ohne Anti-Aliasing) runterskaliert wird ist das für mich ein Stilbruch. Das muss aber nicht bei jedem Spiel so sein. Bei XPYDERZ finde ich das gut, es hängt damit zusammen wie die Grafik insgesamt gehalten ist.
DOSferatu hat geschrieben:Natürlich versucht man immer, sich irgendwie weiterzuentwickeln. Aber dabei eine realistische Selbstbetrachtung zu bewahren, ist dabei auch Voraussetzung, um immer noch überhaupt eine Entwicklung zu machen. Ab dem Punkt, wo man sich selbst für den Größten hält, hat's keinen Sinn mehr.
Das war bei mir beim Programmieren auch nie der Fall, da ist es ja auch relativ leicht, zu kapieren, dass man niemals so gut sein wird wie dieser oder jene Spielentwickler, oder eine Demogruppe. Etwas wagemutiger war ich im Bereich der Tracker-Musik, und da kann man auf Szene-Partys an Musikwettbewerben teilnehmen. Das erste mal als ich das gemacht habe war ich nicht auf dem letzten Platz, das zweite mal schon, und dafür hatte ich extra ein Stück gemäß den Wettbewerbsvorgaben gemacht... Das hat mich etwas negativ beeindruckt und da habe ich beschlossen an keinen Wettbewerben mehr teilzunehmen, egal was.
Das klingt ein bisschen resignierend, der Grund ist aber plausibel: Der sportliche Wettbewerbsgedanke schränkt mich in meiner freien Kreativität ein.
DOSferatu hat geschrieben:Klar - es gibt immer Leute, die für Dinge mehr oder weniger Talent haben. Allerdings kann man auch mit genügend wirklichem Interesse (wirklich = auch Bereitschaft, dafür zu arbeiten) eine Menge erreichen.

Ich sage ja immer, daß ich kein talentierter Grafiker/Musiker bin. Das liegt aber auch daran, weil meine Interessen woanders liegen und ich diesen Interessen mehr Lebenszeit widme. Wenn ich grafisch oder musikalisch mehr "üben" würde, würde ich da sicher auch besser werden können.
Ich habe ein gewisses musikalisches Talent - bin aber zu faul ein richtiger Musiker zu werden mit allem drum und dran. Deswegen beschränke ich mich darauf, musikalische Ideen sofort einzutrackern anstatt Instrumente zu erlernen und das ganze darauf zu zelebrieren. Was "dem Musiker" das Erlebnis der Performance ist, ist mir das schaffen von Klangwelten, die ich gemütlich am Computer wie ein Gemälde ausgestalte. Grafik - mittelmäßig vielleicht, in Kunst war ich immer gut, und als ich jünger war hat mich das Thema Grafik am Computer auch sehr fasziniert - bis der erste Tracker kam. Und Programmieren - da bin ich wohl mittelmäßg talentiert, aber unheimlich fasziniert streckenweise. Es macht mir ziemlich Spaß, aber oft brüte ich viel zu lange an den simpelsten Dingen.
DOSferatu hat geschrieben:Aber SICH SELBST kann man Interesse nicht vortäuschen. Man kann sich nicht selbst einreden, sich für etwas mehr zu interessieren, als man es tut. - DAS ist wohl das Problem dabei.
Das ist wohl wahr. Man kann auch nicht einfach wollen, was man nicht will, lediglich tun was man will, wenn es denn möglich ist.
DOSferatu hat geschrieben:Ehrlich gesagt habe ich eher so wenige musikalische Ideen, daß ich immer, wenn mir zwischendurch etwas einfällt, ich das kurz ins Mikro singe und aufnehme, damit ich's da hab, wenn ich mal 'n Stück Musik brauche.
Ich habe oft nur eine kleine Idee oder bin inspiriert von irgendetwas, und dann improvisiere ich beim Trackern - lasse das bisherige laufen und in meinem Kopf bilden sich dann wie von selbst neue Melodien oder Begleitungen. Deswegen ist mir so wichtig dass der Tracker in dieser Hinsicht ergonomisch ist, d.h. parallele redundante Darstellung.
DOSferatu hat geschrieben:Mit Aussagen wie "geht nicht" und "System zu langsam/unzureichend" werde ich immer vorsichtiger, weil man immer wieder sieht, was wirklich so alles geht.
Scheinbar wird die Hardware vieler Computersysteme erst Jahrzehnte später durch findige Programmierer richtig ausgereizt, so auch beim C64. Ich hab da mal ein Spiel gesehen das könnte glatt DOS 256-Farben VGA sein. War aber nur kurz, vielleicht irre ich mich.
DOSferatu hat geschrieben:Wenn jemand ein Spiel herausgebracht hätte, das, um Musik und Sound zu haben, zwingend eine GUS gebraucht hätte, und ohne GUS komplett stumm gewesen wäre - das Ding hätte er einfach nicht verkaufen können.
Genau das ist die Sache. Wenn ich ehrlich bin sind für mich die spannenden Jahre leider vorbei - die Jahre als die Domäne der Spiele noch DOS waren. Damals hatte ich den langen Atem und wollte schon aus Spielerei meine Spiele für VGA, EGA und CGA konfigurierbar machen. Aber meine beschränkten Fähigkeiten haben dann dazu geführt dass die Projekte schon im frühen Stadium liegen geblieben sind. Wie auch immer, eine Idee mit der GUS wäre, dass man sie einsetzt als Option, wenn z.B. nur ein 386er zu Verfügung steht.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Diese minimal-anfordernden Projekte haben immer ihren Charme, trotzdem bieten nach meinem Empfinden Spiele mit ausführlicherer Grafik und evtl. Sample-Sound einen höheren Unterhaltungswert.
Naja, klingt für mich nach: Schon zu versaut von modernen Medien. Kann ein Spiel bzw. Medium nur genießen, wenn die technischen Parameter entsprechend hoch sind. Diese Attitüde hatte ich nie. Und ich habe schon so einige Spiele gesehen mit viel Sound und vielen Farben und hoher Auflösung, aber dafür lahmen Spielprinzip - deren Unterhaltungswert trotz technischem Gigantismus geringer war als der so manchen pixeligen 16- oder 4-farb-Spiels mit Speakersound.
Das muss ja nicht unbedingt werten. Jeder Mensch ist anders, und ich bin etwas sinnesorientierter. Ich nehme meine Umwelt nicht nur informationsmäßig wahr, sondern vielschichtig und assoziativ auf der Ebene der (irrationalen) Eindrücke - aber wer tut das nicht, vielleicht mehr oder weniger.
Jedenfalls: Deswegen war eine faszinierende Grafik für mich auch immer mit eine Motivation, ein Spiel zu spielen, wenn das Spiel dadurch mehr Atmosphäre hatte. Eine Auflösung höher als 320x200(/240) fand ich dabei eher abträglich, aber 256 Farben waren toll. Sample-Sound Fan war ich spätestens seit ich das MOD Format entdeckt hatte - erstmal nur Player, also noch nicht selber kreativ tätig werdend.
Naja, mir ist aber auch schon mal passiert dass ich mit Freunden im Kino war, die sich die ganze Zeit über die schlechte Handlung beschwerten, während ich die Atmosphäre des Films genossen habe.

Im Nachhinein muss ich sagen, dass z.B. CGA auch etwas Besonderes haben kann.
DOSferatu hat geschrieben:Und - oh Wunder! Plötzlich sind die jahrelang als "verkauft sich nicht" und "will sowieso keiner" titulierten handgezeichneten 2D-Point&Click-Adventures wieder beliebt wie "seinerzeit"! Plötzlich spielen Auflösung, Farbtiefe oder nicht-vorhandenes 3D keine Rolle mehr... Tja: Weil ein gutes Spiel oder hoher Unterhaltungswert sich eben NICHT nur an technischen Parametern messen lassen kann...
Ja, von 3D hab ich bei Spielen auch nichts. Was meinst Du wie mich die 3D-Welle um die Jahrtausendwende angekotzt hat, als alles plötzlich 3D sein musste, aus Prinzip. So ein furchtbarer Stilbruch bei Adventures! Vom gemütlichen, atmosphärischen Point&Click Charme hin zum Egoshooter-Look... Und dann diese Luftmatratzen statt liebevoll gepixelter Sprites. Polygongrafik in Ehren, aber nicht als Ersatz für klassische Point&Clicks.
DOSferatu hat geschrieben:Jedenfalls scheine ich wohl nicht der Einzige zu sein, den "Pixeligkeit" nicht nur "nicht stört", sondern der sogar Wert darauf legt.
Da sind wir schonmal zu zweit, und wenn es noch mehr werden macht das Hoffnung. Es ist vielleicht einfach Prägung, aber ich habe 320x2?? immer magischer empfunden als etwas höheres.
DOSferatu hat geschrieben:
zatzen hat geschrieben: Daraus ziehe ich nun den Schluss dass ich für mein Spiel wohl bei 320x200 bleibe. Auch weil ich die Grafik in Deluxe Paint machen werde, und das Programm bietet keinen 256x256 Modus an.
...was wohl unter anderem auch daran liegen mag, daß WINDOWS keinen 256x256 Modus anbietet... :)
Nein, Deluxe Paint ist ein DOS Programm, gab es auch auf dem Amiga. Damit lässt sich sehr gut pixeln und es hat neben Anti-Aliasing und Gradientenverläufen auch so Sachen wie Kreisfunktionen die an die Aspect Ratio angepasst sind, also Kreis bei 320x200.
DOSferatu hat geschrieben:Ich bin nie davon ausgegangen, daß irgendeins meiner Programme oder Entwicklungen von entscheidender Bedeutung für Dein Spiel/Deine Entwicklungen sind oder sein müßten.
Zumindest aber das von Dir vermittelte Wissen.
DOSferatu hat geschrieben:Ich habe hier noch etwas gebastelt, daran habe ich in den letzten Wochen (waren so 3 Wochenenden, netto 5 Tage, mit kranheitsbedingter Unterbrechung) so experimentiermäßig herumgebaut. Vielleicht gefällt's Dir ja. Zeigt auch mal, was so ein 486er wirklich kann.
Du Schelm! Netter Gruß, das wirkt ja ein bisschen an mich gerichtet, auch mit den ominösen quadratischen Pixeln. Du hast mich zweimal erwischt: Gute Sache, dass man den ROL/ROR error abfangen kann. Und dann hatte ich die Cycles auf 26800 (~66 Mhz 486) aber wurde noch als Dumbass beschimpft...
Ich hab's dann noch mal mit 40000 Cycles laufen lassen, ging dann durch, war aber irgendwie alles immer noch ein bisschen flimmerig - wahrscheinlich noch nicht optimale Emulatoreinstellungen. Sehr lustige Sache, auch mit den Schweinchen.
Und technisch - da kann ich natürlich nur staunen und werde diesen 640x480 Modus wohl nie ansteuern. Und dann noch mit Scrolling. Ist mir ein Rätsel, da Du ja auch nicht mehrere Seiten zur Verfügung hast. 307200 Bytes sind ja ein Screen, hast Du deshalb am Anfang noch nicht das volle Bild gezeigt? Die Musik klingt schön sauber, 15 KHz Mischfrequenz - komisch, eigentlich fand ich sowas zu stumpf, aber es reicht irgendwie. Vielleicht werde ich alt - nein der Lautsprecher den ich hier grade dran habe ist "forgiving". Es klingt ähnlich Deiner früheren Musik für Rockus. Laut meiner Analyse kommen die ersten (wie) zufälligen Töne im klassischen PC-Speaker-Stil auch aus der ISM Engine, stimmt das?
Also, schön das mal alles zusammen zu sehen, auch mit ISM. Ich hätte vielleicht eine weniger aggressive Wellenform für die Hauptstimme genommen. Aber schön, die Portamentos. Das kann ZSM nicht. Was ich noch bemerke: Die Musik wird insgesamt leiser im Verlauf, wenn mehr Stimmen dazukommen. Das fällt so direkt nicht auf, aber ich hab das mal aufgenommen und genauer betrachtet. Sehr schön deutlich übrigens auch das "Yeah"-Sample. Ich hab da eigentlich nichts zu meckern. Hat was von nem SID und ist von der Soundqualität her absolut akzetabel. Ich bin gar nicht so ein Kristallsoundmensch. Es kommt immer drauf an, was es ist.


Ich habe hier über die Tage übrigens immer mal wieder ein bisischen etwas am Text geändert.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

zatzen hat geschrieben: So 6. Sep 2020, 00:46
DOSferatu hat geschrieben:Ahja. d.h. es gibt keine gepreßten CDs von Dir zu kaufen [...]
Pressen macht nicht viel Sinn, dann hab ich hier hinterher über 200 CDs rumliegen die keiner haben will. [...]Aber Case/Inlay/Booklet ja, und das kann man sich auch professionell drucken lassen in kleinen Mengen, ebenso bedruckte Rohlinge.
Wenn's nur um Einzelstücke geht und man einen Drucker hat, geht das sicher auch einfacher...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Für mich ist also jeder, der ein Programm (Spiel/Tool) als "App" bezeichnet ein verkappter Apple-Fanboy...
Hmm, Windows 10 macht das auch...
Weil Microsoft zwar reicher ist, aber trotzdem Apple beneidet: Apple-User LIEBEN ja diesen ganzen Scheiß und sind total stolz drauf. Zeigen auch überall ihr Apfelzeug rum und so.

Und MS will auch gern geliebt werden. Die wollen, daß die Leute stolz drauf sind, Windows zu benutzen. (Hat da selbst mal einer gesagt von denen.) Problem ist, daß sich MS fast solange wie es sie gibt, immer nur wie eine Krake oder Bulldozer verhalten hat, der alles vernichtet, was nicht Windows ist, damit die Leute keine Alternative haben. Mit sowas macht man sich nicht beliebt. Die Leute nutzen Windows, weil sie, um das "normale Zeug" (professionelle Programme, Spiele) zu nutzen, keine Wahl haben - weil MS quasi ein Monopol aufgebaut hat und die Softwarehersteller das jetzt bedienen (müssen).

Aber mit dieser Attitüde - bekommt man keine "Fans". Windows ist für die Leute nur ein Arbeitsgerät: Häßlich, lahm, irgendwie schräg, aber man muß sich darin fügen. Und genau deshalb versucht MS jetzt, Apple und Linux zu "imitieren", weil die denken, daß sie damit Fans gewinnen. Armseliger geht's kaum noch.
zatzen hat geschrieben:
DOSferatu hat geschrieben:ICH werd' mich bei der Entwicklung meines Zeugs nicht einschränken/umbiegen lassen [...]
Ich bin da ein bisschen zweigleisiger eingestellt. Vielleicht auch weil ich nicht so der überflieger als Programmierer bin und eher bei Standard-Modi und sowas bleibe. Ich finde es als Bonus ganz nett, wenn meine Software auch in DosBox einwandfrei genießbar ist, so dass auch die dazu Zugang haben, die kein natives DOS-System mehr bereitstehen haben. Wie könnte ich auch anders, ich gehöre ja selber zu denen...
Naja, ich programmiere ja nicht absichtlich so, daß es nicht auf Emulatoren läuft. Ich code so, daß es auf dem Realsystem läuft - denn das Realsystem ist ja die Referenz für den Emulator. Wenn etwas auf dem Realsystem funktioniert, auf einem Emulator aber nicht / nicht richtig, dann hat der Emulator einen Bug, der gefixt werden sollte. Man kann ja nun nicht auch noch beim Coden um jeden eventuellen Bug jedes denkbaren Emulators herum coden (gibt ja nicht nur DOSbox) - das wäre wohl etwas viel verlangt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Zum Beispiel: 16:9, 21:9, 22:9 und all diese Formate finde ich absolut gräßlich. Für mich ist die einzig gültige und gescheite Bildratio 4:3. [...]
4:3 Für den Arbeitsbildschirm, da gebe ich Dir absolut recht. Der Bereich in dem man halbwegs scharf sieht ergibt eher ein 4:3 Verhältnis. Vielleicht sogar eher einen Kreis, weil das wirklich scharfe Sichtfeld ja sehr klein ist und die Augen beide einen Punkt fokussieren. Die komplette Wahrnehmung, um die unscharfen Bereiche links und rechts erweitert, lässt sich aber besser mit 16:9 abdecken. Für Filme kann das sinnvoll sein für ein besseres Erlebnis, denn während man in den Randgebieten des Sichtfelds unklar sieht, reagiert man dort besonders empfindlich auf Bewegungen. So kann man z.B. das Flimmern eines 50 Hz Röhrenfernsehers besonders gut sehen wenn man ihn im Sichtfeld ganz außen platziert.
Das ist nur eine Verarsche durch Marketing: Ich kenne das auch, wo man in den Laden gehen sollte, die haben dann so eine Markierung auf den Boden gemalt und man sollte sich hinstellen und mit den Händen so weit auseinanderhalten, bis man die Hände (beim Geradeausgucken) gerade noch sieht - so als "Beweis", daß 16:9 natürlicher wäre als 4:3.

Darauf fallen immer wieder Leute rein - und zwar, weil das Ganze ohne Referenz gemacht wird und deshalb IMMER irgendwie "breit" wird. D.h. es paßt immer, beweist aber nichts, weil Höhe nicht berücksichtigt - und außerdem: Hände/Arme sind am Körper angeschraubt, somit keine Referenz für Dinge, die in der Entfernung sind.

Der Gegentest ist ganz einfach: Das Gleiche machen, aber die Hände nach oben/unten, bis man sie nicht mehr sieht. Und das Ergebnis ist dann NICHT 16:9, sondern eher näher an 4:3 - quod erat demonstrandum.
zatzen hat geschrieben:[...] Seien wir mal froh dass wir keine Pferde sind. Sonst hätten wir 360° Kinos.
Naja, es gibt ja auch andere Tiere, die so "Breitbild"-Pupillen haben - Ziegen zum Beispiel. Aber Ziegen würden ja keine Filme gucken oder Monitore benutzen. Da müßte es jemanden geben, der einen humanoiden Körper/Verstand hat, aber einen so gehörnten Ziegenkopf... Fällt Dir da jemand ein? ... Und vielleicht war DER es auch, der deswegen dieses 16:9 eingeführt hat.
zatzen hat geschrieben:Einschränkend wird das ganze aber dann, wenn man Grafiken für ein Spiel machen will. Dann ist man entweder auf eine Dos-Software angewiesen,
DOSferatu hat geschrieben:Du sagst das so, als wäre DOS-Software etwas schlechtes.
Das sage ich nicht direkt, aber es gibt sehr praktische Grafiksoftware unter Windows.
Ach, es gibt auch sehr praktische Grafiksoftware unter... anderen Systemen. DOS, zum Beispiel.
zatzen hat geschrieben:Das einzige was mich an Windows bislang stört ist die Programmierung, weil man da nicht einfach so "from scratch" loslegen kann und Ton und Grafik ausgeben kann.
Es gibt sehr viele Sachen, die mich an Windows stören. Z.B. diese ganzen "Wir müssen den dummen User vor sich selber schützen"-Sperren. So, daß mein Betriebssystem mir vorschreibt, was ICH mit MEINEM Computer machen darf. Dafür würde ich gerne mal Herrn Gates - oder die jetzigen Verantwortlichen - für jedes dieser blöden Dinger ohrfeigen. Wer weiß, ob ihn danach überhaupt noch seine eigene Mutter erkennen könnte...
zatzen hat geschrieben:Deswegen ist für mich DOS attraktiver für etwas das Bild und Ton ausgibt, und dass das momentan hier alles in der Box läuft stört mich erstmal nicht.
Naja, andere Leute sehen das anders - die haben ihre Fertiglösungen/ Libraries/ Frameworks für ihren Kram und können auch unter Windows gleich Bild+Ton machen. Ich bin bloß nicht gern so "Fertiglösung"-Nutzer beim Coden - aber das ist eben eine Einstellungssache. Der Nachteil ist eben, daß ich wahnsinnig langsam mal zum Ergebnis komme. Aber wie sagt schon Konfuzius: Der Weg ist das Ziel.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Meine Begeisterung für sog. "moderne Systeme" hält sich echt in Grenzen.
Ich nutze mein modernes System praktisch nur als kreative Bearbeitungsmaschine. Da sind manche Dinge dabei die vor 25 Jahren in DOS noch nicht möglich waren, und auf der damaligen Hardware auch heute nicht möglich wären.
Klar, aber das liegt eher an der schnelleren Hardware und am größeren Speicher - nicht daran, daß Windows toll wäre. Windows verschwendet einen großen Teil der Geschwindigkeit und des Speichers für sich selbst und seine Spielereien. Wahrscheinlich gibt es heutzutage kaum noch jemanden, der weiß oder einschätzen kann, wie schnell sein Rechner WIRKLICH ist.
zatzen hat geschrieben:Das ist natürlich für Dich irrelevant da Du es weder mit zig-spurigen Tonabmischungen in Studioqualität mit Software-Emulation komplexer Studiogeräte noch mit rechenintensiver Bearbeitung von HD Videos zu tun hast.
Stimmt.
zatzen hat geschrieben:Aber das sind eigentlich meine größeren Hobbys hier, zumindest das mit dem Ton, das hat mich wesentlich dazu bewogen, mir alle 5-7 Jahre einen neuen Rechner anzuschaffen, weil zumindest die bestehende Software dann besser performt. Programmieren ist nebenbei immer mal schön, um sich rein rational zu beschäftigen. Aber wenn es nur das wäre, DOS-Anwendungen, dann würde mir in der Tat wohl auch ein 486er genügen.
Ja, so "User-mäßig" mache ich mit Rechnern wenig. Ich hab ja auch Windows-Rechner hier. Aber die benutze ich quasi so für Browsen oder Webstream (vom Kumpel) oder Chat. Es gibt auch ein paar Spiele und so, aber ich bin nicht so der totale Gamer.
zatzen hat geschrieben:Mein aktueller Rechner, i5, 3.4 GHz, C: 250 GB SSD, Windows 10, bootet in weniger als 10 Sekunden (vom Zeitpunkt des Power-Knopf-Drückens). Ich kann mich da nicht beklagen.
Ich habe noch nie irgend ein Windows erlebt, das mir nicht total lahm vorkam. Mein schnellster Rechner hat C: auch als SSD und Windows 7 drauf. Aber trotzdem passiert nichts auch nur annähernd in Echtzeit.
Windows 10 muß ich schon auf Arbeit benutzen, das Ding finde ich eine Zumutung.
zatzen hat geschrieben:Ich habe mich lange gegen Windows 10 gewehrt, so wie ich mich gegen Windows 7 gewehrt habe, aber ich gewöhne mich dran und finde es nicht schlecht.
Tja, jeder wie er will. Ich finde es schlecht und irgendwie wird seit WinXP jedes Windows schlechter.
zatzen hat geschrieben:Aber naja, vielleicht sollten wir hier nicht so viel über Windows reden.
Ja, Off-Topic und so...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn man etwas so entwickelt, daß es auf einem Emulator gut, aber auf dem echten System schlecht performt oder auf dem Emulator funktioniert, aber auf dem echten System nicht, dann entwickelt man für den Emulator - und das macht keinen Sinn, weil der ja nicht dafür gedacht ist, "für sich selbst als System" zu stehen.
Das ist auch nicht meine Absicht. Ich habe bislang wohl Glück gehabt, das bisher alles, was ich in der Emulatorumgebung programmiert habe, auch auf einem echten System funktioniert und performt hat. Möglicherweise ist es eher so, dass was im Emulator funktioniert, auch auf Hardware funktioniert, aber nicht umgekehrt.

Vorausgesetzt, der Emulator hat keine Bugs. Außerdem gehen manche Emulatoren (wie auch z.B. DOSbox) sehr "gnädig" mit manchen Fehlern um - und zwar aus Performancegründen. D.h. manche Dinge, die einen Absturz oder komisches Verhalten erzeugen müßten, stürzen auf dem Emulator nicht ab, weil er sie aus Performancegründen nicht alle testet. DOSbox ist ja nicht dazu gedacht, eine exakte DOS-Maschine nachzubilden (obwohl DOSbox dabei schon ziemlich gut ist) - sondern dazu, alte DOS-Games auf modernen Systemen spielen zu können.
zatzen hat geschrieben:Was die Performance angeht sind die 20000 Cycles ja von mir absichtlich bescheiden gewählt (ist mir klar dass das auch kein Benchmark ist, aber so "über den Daumen gepeilt" verhindert es, dass man als Hardware einen Pentium braucht).
Ja, Du erwähntest das mal.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Was ist für Dich denn ein 486er? Ich meine: Die gab es mit 25, 33, 50, 66, 75, 100, 120, 133 und (selten) 150 MHz (und dann auch noch SX und DX).
(Anm.: Ich hatte hier übrigens noch 40 und 80 MHz vergessen, obwohl die ja, wegen des 40 Mhz FSB, ziemlich cool sind - so wie auch der genannte 120er.)
zatzen hat geschrieben:Sagen wir mal so, dass 100 Mhz für meine Projekte reichen. Laut DosBox-wiki entsprechen 26800 Cycles grob einem 486 mit 66 Mhz. Wenn mein Kram mit 20000 Cycles funktioniert, dürfte eine 100 MHz Maschine das hinkriegen, vielleicht auch eine mit 50.
Ich weiß nicht, was für meine Projekte reicht. Ich versuche immer, so zu programmieren, wie es meinen derzeitigen Fähigkeiten entspricht, um möglichst wenig Speicher und Performance zu verschwenden. Und mir ist natürlich klar, daß meine 10 oder 15 oder 20 Jahre alten Sachen da noch stark ausbaufähig wären. Manchmal benutze ich auch alten Kram, von dem ich weiß, daß er nicht optimal ist, weil ich einfach mal "irgendwas brauche" und noch keinen "neuen Kram" gebaut habe. Ich komme eben mit meinem Zeug nicht mehr so hinterher und in letzter Zeit mache ich wenig - oder wenn, dann auch viele andere Sachen, die gar nichts mit dem "ich mache ein neues 2D Spiel" zu tun haben.
zatzen hat geschrieben:
DOSferatu hat geschrieben:1. Wenn Figur und Hintergrund [...] Foto-Hintergründe[...]
Ja. Tatsächlich ist es ja auch nur eine Demo. Der Witz an dem Hintergrundbild war zum einen, dass es für mich eine Neuheit war, megabyteweise Grafiken aus dem XMS zu holen. Und dann war für uns noch eine Sache, dass diese Häuserlandschaft jene ist, die in der Nähe des Schulgebäudes entlang des dortigen kleinen Flusses verläuft. Ich hatte mich mit meiner Unbegabheit lange genug an der Spielerfigur mit pixeln aufgehalten, da war am Ende der fünf Tage keine Motivation und Phantasie mehr für gepixelte Hintergründe übrig.
Ahso. Naja, ganz nett als Demo, aber für ein Spiel fehlt mir da noch so einiges. Zum Beispiel irgendwas, was man machen kann, außer da rumlaufen/rumhüpfen.
Aber natürlich ist das auch das erste, was man bei einem 2D-Jump'n'run machen würde: Erstmal eine (Pseudo-)Welt bauen und eine Figur und eine Möglichkeit zur Figur/Welt Kollisionsabfrage und eine Steuerung für die Figur, damit man erstmal sieht, daß es von der technischen Seite her funktioniert.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Naja, um jeden Preis ein Spiel zu machen, nur indem ich abartige Systemvoraussetzungen voraussetze, um mit billigsten Möglichkeiten irgendwas zu machen, das wär mir zu doof. Und wie ich es aus dem Subtext lese: Dir wohl auch.
Richtig. Aber damals mit dieser Demo war ich auf dem Weg dahin. Das lag aber auch ein bisschen daran dass ich von der Duke Nukem 3D Engine inspiriert war, die scheinbar keine Speichereinschränkungen kannte. Wir haben das Spiel öfters mal modifiziert und z.B. ewig lange Sounds da reingebaut.
Dir ist aber schon klar, daß Duke Nukem 3D (genau wie Doom, Quake usw.) 32-Bit Spiele sind, die also auch quasi in einem Flat-4G Mode laufen, oder? Das Starten des DOS4GW.EXE (oder PMODE.EXE oder ähnliche) beim Starten des Spiels sollte ja ein Hinweis sein. Diese Spiele nutzen sogenannte 32bit-DOS-Extender, der ist z.B. in diesem Watcom-C schon eingebaut. Diese Dinger kombinieren die Einfachheit des Realmode mit dem riesigen Speicher des Protected Mode (aber ohne daß man das komplizierte PM-Speichermanagement an der Backe hat).
zatzen hat geschrieben:
DOSferatu hat geschrieben:Es gab Zeiten, da gab es eben diese Beschränkungen - und die Leute haben trotzdem coole Spiele gemacht und die Spieler waren glücklich. Also muß es möglich sein. Und zu glauben, daß JEDER Spieler immer nur auf höher-schneller-weiter steht, halte ich auch für voreingenommen.
Klar, so um 1989 habe ich die Spiele auf unserem 286er bestaunt. Sowas wie Captain Comic oder etwas später Commander Keen 4, das funktionierte auch noch meine ich. Aber als mir dann weitere coole Spiele unterkamen die zwar liefen, aber mit ner Framerate von 3 oder so, enstand schon immer mehr der Druck auf einen neuen Rechner. Später waren es dann wie oben erwähnt keine Spiele mehr weshalb ich neue Computer wollte (zu der Zeit wo ich spielte reichte ein 486er eigentlich) sondern kreative Anwendungen, die mit mehr Leistung und Speicherkapazitäten einfach schneller und stabiler liefen.
Ja, schon klar. Ich wollte eben nur darauf hinweisen, daß Spielspaß nicht unbedingt direkt proportional zu Speichermenge, CPU-Geschwindigkeit, Farbanzahl und Bildauflösung ist.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Es gibt Leute, die LIEBEN diesen Chiptune-Sound und pixelige Spielgrafik - gerade momentan, wo "retro" (wie es heute zusammengefaßt wird) ja wieder "in" ist, braucht man sich nicht zu schämen, ein Spiel rauszubringen, das den technischen Standards von 1992 entspricht.
Sehe ich genauso. Man kann nur von den "Neo-Retros" nicht unbedingt verlangen dass sie nen Dos-Rechner haben, geschweige denn überhaupt wissen was z.B. "8 Bit" überhaupt bedeutet.
Ach, "man kann nicht verlangen"...? Echt, ich hab keine Lust, diesen komischen Kiddies die Windeln zu pudern. Wenn die sich "cool genug" für "retro" fühlen, aber zu blöd sind, was WIRKLICH retro-mäßiges zu benutzen, werd' ICH deswegen trotzdem nicht anfangen, in Windows oder Android oder so rumzumurksen, nur damit's den feinen Damen und Herren Pseudo-Retro-Kids genehm ist. Für mich ist das ja hier ein Hobby. Ich mache das, so lange es mir Spaß macht. Wenn meinen Kram jemand benutzen will - gerne. Wenn er ihn nicht benutzen will - auch gut. Wenn er ihn nicht benutzen KANN, aber gern WÜRDE, kann ich gern dabei helfen, dem zu zeigen, wie er's möglich macht. Wenn jemand dafür zu faul ist - ist es mir egal.
Ich kenne ja diese Generation "Instant Gratification": Alles muß SOFORT da sein und ohne jede Mühe. - Bloß nicht, daß man aus Versehen noch etwas dabei lernt!
zatzen hat geschrieben:Der Begriff fällt, sobald man bei der Grafik Pixel sehen kann... Aber es besteht kein Zweifel, dass neue Spiele nach 1992er Standard gut ankommen werden. Zumindest bei denen, die nicht alles in 4K haben wollen.
Ja, dieser "8-Bit" Begriff wird heutzutage sehr inflationär benutzt für alles technische, was irgendwie "alt aussieht". Vieles, was die Kids für 8-Bit halten, ist z.B. eigentlich 16-Bit. "8-Bit" hat für die meisten Leute gar nichts mehr mit irgendeiner Bitbreite zu tun und die meisten Leute wissen auch gar nicht wirklich, was ein Bit ist. (Doch: 'ne Flasche Bier von dieser Firma da...)
zatzen hat geschrieben: Aber wohl:
DOSferatu hat geschrieben:Nicht meine Referenz. Nicht meine Zielgruppe.
So ist es. Wie soll ich sagen: Wenn irgendein Erwachsener z.B. einen Zeichentrickfilm für 5-jährige guckt, weil ihm das gefällt - OK. Aber der kann dann natürlich nicht verlangen, daß die Macher da irgendwas einbauen, das seinem erwachsenen Verstand genehm ist - weil er eben nicht zur Zielgruppe gehört. Und so ist es mit meinem Zeug: Wenn die Leute diesen alten DOS-Kram so lieben, dann sind sie bei meinem Zeug richtig. Wenn die Leute nur diesen Pseudo "so als ob" Kram lieben, dann müssen sie sich eben das holen. Bei mir gibts nur den "echten Shit".
zatzen hat geschrieben:
DOSferatu hat geschrieben:Haben die Leute, die nix abgeliefert hatten (weil nur gedaddelt) wenigstens 'ne 6 für nicht erbrachte Leistung bekommen?
Diese Projektwochen sind unabhängig von Zensuren und werden von Lehrern höchstens betreut aber nicht bewertet. Normalerweise gibt es einen Präsentationstag, aber den hatten wir irgendwie nicht.
Na das ist ja irgendwie lame. Da braucht man sich ja auch nicht zu wundern, wenn die meisten da nur rumgammeln.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn kompliziertere Routinen mindestens Speicher sparen ODER Rechenzeit sparen (oder im Idealfall eben beides), sind sie sinnvoll.[...] Aber wenn ich merke, daß ich damit weder Performance noch Speicher gewinne, dann lege ich es unter "Experimente" ab und benutze es nicht in realen Projekten.
Was ZSM angeht mache ich speichermäßig auf jeden Fall etwas sinnvolles, denn 640K bzw. was noch frei ist, sind mit Sound schnell voll. Performancemäßig ist es ein Kompromiss, der hier wegen der Speicherersparnis aber tragbar scheint. ZVID2 könnte grenzfällig werden. Wenn die Speicherersparnis nicht vonnöten ist, wäre es nur Performanceverlust. Allerdings überlege ich auch schon an einer Art Adventure mit großen, eher wenigfarbigen Grafiken (d.h. Comic-artig). Da kommt das zum tragen und wäre nötig, um wiederum die 640 K nicht zu sprengen. Bei einem Adventure kommt dazu dass man da keine 50 fps braucht... Bei allen Performanceeinbußen kann ich mir überlegen: Was ist mir wichtiger, dass es auf einem 25 SX läuft ohne meine "Tricks" oder auf einem DX 66 mit meinen Tricks...
Klar: Trade-Off, wie ich immer sage. Wenn man so Sachen machen will, macht es zwar Spaß, es immer gleich direkt aufs Metall zu hacken - aber es vorher zu planen kann einem manchmal auch hinterher einigen Ärger ersparen. Wenn man immer erst während der Entwicklung anfangen muß, "herumzumurksen", um noch den letzten Rest Speicher zu sparen, oder die letzte Ecke Performance zu drehen, baut man irgendwann nur noch so Spaghetti-Code. (Ich weiß, wovon ich rede - siehe Xpyderz.)

Was DOSbox angeht: Weil DOSbox ja so "generös" ist, hat man da auch meist viel Heap. So viel Heap wie in DOSbox haben die wenigsten Leute auf der Realmaschine. Daran sollte man auch immer mal zwischendurch denken. Also nicht: "Oh, da sind noch 5 kByte frei - dann ist ja noch Platz für'n weiteren Soundeffekt" - sondern immer dran denken, daß die Realmaschine meist so um die 600 bis 610 kB frei hat - und bei den totalen Obergeeks vielleicht die berühmten 621kB oder 625kB - aber mehr ist nicht. Diese 630 oder sogar 639 kB, die das "DOS-Fenster" von WinXP oder eben auch manche Emulatoren einem hinstellen, sind eigentlich Bullshit - das geht nicht auf der echten Kiste!
zatzen hat geschrieben:
DOSferatu hat geschrieben:Je "komischer" ein Modus ist, umso mehr kann es z.B. passieren, daß das Bild nicht genau zentriert ist (d.h. der Rand oben/unten/links/rechts nicht überall gleich ist) und man nachregeln muß.
Das würde ja dafür sprechen, dass man lieber bei den gängigen Grafikmodi bleibt, gerade wenn es für reale Systeme sein soll.
So ist es. Das mag auch der Grund sein, warum viele der Features der echten SB nicht supportet werden in Spielen. Die echte SB kann nämlich z.B. Sounds im PCM-Format (bzw sogar verschiedenen PCM-Formaten) abspielen. (Erklär ich jetzt nicht. Steht in Wiki. Außerdem weißt Du als Soundfreak sicher auch so, was das ist.) Mit PCM könnte man einiges an Speicher sparen und trotzdem recht guten Sound haben - aber die ganzen SB-Klone supporten nur den "normalen" Kram, von allem, was die SB so kann. Da macht sich dann keiner die Mühe, extra für SB noch zusätzliche Routinen zu basteln.

Das Gleiche gilt für Grafikkarten: Klar, als VGA draußen war (eigentlich schon bei EGA) gab es einen Haufen Hersteller, die immer noch "ein bißchen mehr als Standard" in ihre GraKas eingebaut haben. Nur war das einzige, was das benutzt hat, die Test/Benchmark-Programme, die diese Hersteller herausgebracht haben, um das zu demonstrieren. Kein Spielecoder, der sowieso zu bestimmten Zeiten schon Hercules-Mono, Tandy, PCjr, CGA, EGA und VGA supporten sollte, hat dann zusätzlich noch irgendeinen Supermode einer einzelnen Grafikkarte supportet - auch wenn der vielleicht schöner gewesen oder einfacher anzusteuern gewesen wäre. Da gab's dann ganz einfach die Überlegung: "Wie teuer soll das verdammte Spiel denn noch werden?" und "Wieviel % der Leute haben genau diese GraKa-Familie?"

Aber es gibt bestimmte Register, die so VGA-Grundstandard sind, mit denen man arbeiten kann. Das berühmte Turrican II für PC tweakt da ziemlich rum, da kann man zu Anfang einiges einstellen - Bildfrequenz, Zeilen und dann das Bild zentrieren. Der hat das da alles ziemlich hardwarenah gefreakt. Das Ding performt auch total abartig und sieht dabei super aus. Das ist so die Königsklasse des 2D-Spiels auf PC.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]Testprogramm mit der Anzeige der 172 Modi[...]
Danke! Sehr interessant, das alles mal vergleichen zu können. Und es funktioniert sogar alles in DosBox - halbwegs. Das beachtliche 512x512 wird breiter als 4:3. Für mich kämen aber erstmal auch nur die wenigen MCGA-Modi in Frage, und da würde ich mich lieber noch mit Dir abstimmen wollen ob man dann mit einem echten System nicht immer am Bildschirm drehen muss.
Bitte nicht die Ausgabe eines Emulators auf einem Windows, das kein echtes Vollbild für Programme mehr zuläßt zur Bewertung nehmen. Auf realer Hardware wird das alles etwa 4:3.
Und: Da ist so eine Taste (glaub F oder S), wo man die ganzen "Freak-Modes" ausblenden kann. Dann bleiben nur die "normalsten" übrig, die auch auf jeder Kiste laufen: Breite 320 oder 360, Höhe 200, 240, 400, 480.
zatzen hat geschrieben: Nebenbei: 160x200 auf vollen 4:3 Bildschirm ist wohl ein EGA-Mode. Hatten ja früher u.a. Sierra Spiele.
Es gibt verschiedene Arten, das zu machen. 160x200x16 geht ja auch mit Textmode (siehe mein Posting im anderen Thread). In Fall dieses Tools ist es echter 160x200x256. Und EGA hat ja keine 256 Farben.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn die Sprite-Routinen kein X-spiegeln[...]
Spiegeln ist ja kein Ding. Das konnten nur die ollen PUT-Routinen in QBASIC nicht. Wie auch keine Transparenz.
Ja, wollt's ja nur erwähnen. Wenn man einerseits supersparende Packroutinen hat, aber andererseits dadurch bestimmte Features nicht hat - für die man dann neue Spriteimages braucht, spart man das auf der einen Seite, was man auf der anderen dann wieder zusätzlich machen muß.
zatzen hat geschrieben:Ja, da ich mich nie mit der Programmierung von Drehen oder Skalieren (in "Echtzeit") beschäftigt habe, kommt das bisher für mich auch nicht in Frage und daher brauche ich keinen "random access" auf die Pixel und kann mir erlauben sie in 4x4 Blöcken seriell zu entpacken. So gesehen opfere ich hier wegen Kompression großartige Möglichkeiten, allerdings würden skalierte oder gedrehte Sprites mein Konzept der Grafik im Spiel stören.
Ja, wie eben jeder will.
zatzen hat geschrieben: Ich fand auch die Skalierung in Monkey Island I nicht so schön. Wenn die gesamte Spielgrafik wohlüberlegt gepixelt ist und dann etwas "lieblos" (auch ohne Anti-Aliasing) runterskaliert wird ist das für mich ein Stilbruch.
Für mich nicht. Für mich wäre Anti-Aliasing der Stilbruch gewesen - ist auch gar nicht so einfach mit 256 Farben.

Monkey Island wechselt z.B. immer Teile der Palette aus, um für die Hintergründe optimale Paletten zu haben. Einen Teil der Palette muß man aber immer behalten, weil die Figuren und Texte ja trotzdem noch ihre Farben brauchen. Und ICH fand das Skalieren eigentlich eine gute Idee, um dem Ganzen etwas "Räumlichkeit" zu geben - d.h. wenn die Figur weiter hinten ist, daß sie dann kleiner wird. (Sähe sonst komisch aus, so als ob die Figur wenn sie nach hinten ins Bild geht, wächst.) Und Anti-Aliasing ist bei so geringen Pixelmengen keine gute Idee mehr, das würde nur noch ein Farbmatsch werden. Desweiteren laufen Monkey Island 1 und 2 auf 286er (1 vielleicht sogar auf 8086 ?), da ist die normal berechnete Skalierung eigentlich schon das maximale was geht - Live-Antialiasing auf 'nem 286er... - da glaube ich nicht, daß das einer mal in Erwägung für ein Spiel gezogen hat.

Und man sieht wieder: Zu versaut von aktuellem Multimedia. Man fragt sich, wieso so jemand eigentlich 320x200x256 Spiele machen will.
zatzen hat geschrieben:Das muss aber nicht bei jedem Spiel so sein. Bei XPYDERZ finde ich das gut, es hängt damit zusammen wie die Grafik insgesamt gehalten ist.
Ach naja, Xpyderz hat ja nun nicht gerade tolle Grafik. Das ist ja alles so eher schematisch gehalten, damit man erkennt, was es sein soll. Aber ja: in Xpyderz brauche ich nur SpriteImages, die "nach Norden" zeigen. Alles andere wird bei der Ausgabe softwaremäßig gedreht.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Natürlich versucht man immer, sich irgendwie weiterzuentwickeln. Aber dabei eine realistische Selbstbetrachtung zu bewahren, ist dabei auch Voraussetzung, um immer noch überhaupt eine Entwicklung zu machen. Ab dem Punkt, wo man sich selbst für den Größten hält, hat's keinen Sinn mehr.
Das war bei mir beim Programmieren auch nie der Fall, da ist es ja auch relativ leicht, zu kapieren, dass man niemals so gut sein wird wie dieser oder jene Spielentwickler, oder eine Demogruppe. Etwas wagemutiger war ich im Bereich der Tracker-Musik, und da kann man auf Szene-Partys an Musikwettbewerben teilnehmen. Das erste mal als ich das gemacht habe war ich nicht auf dem letzten Platz, das zweite mal schon, und dafür hatte ich extra ein Stück gemäß den Wettbewerbsvorgaben gemacht... Das hat mich etwas negativ beeindruckt und da habe ich beschlossen an keinen Wettbewerben mehr teilzunehmen, egal was.
Andere Leute hätten dann einfach weitergemacht, wären irgendwann immer besser geworden und hätten bei so Wettbewerb vielleicht auch mal bessere Plätze belegt. Der Vergleich mit anderen kann einem zeigen, wo man so steht. Allerdings ist gerade bei Grafik und Musik so eine Einschätzung auch hochgradig subjektiv und hängt stark vom "Publikum" oder dem Geschmack einer eventuellen Jury ab.
Ich selbst habe mich mit meinem Zeug quasi fast nie mal Wettbewerben gestellt. Das liegt bei mir aber an meiner Persönlichkeit: Mir war die Meinung anderer Leute über mich oder dem, was ich so mache, nie so wichtig. Und: Ich gehe nicht gern auf Veranstaltungen.
zatzen hat geschrieben:Ich habe ein gewisses musikalisches Talent - bin aber zu faul ein richtiger Musiker zu werden mit allem drum und dran. Deswegen beschränke ich mich darauf, musikalische Ideen sofort einzutrackern anstatt Instrumente zu erlernen und das ganze darauf zu zelebrieren.
Ach, Musiker sein hat nichts mit Instrumenten zu tun. Instrumente spielen ist nur "Werkzeug". Wenn etwas gut klingt oder es gefällt, ist es doch egal, womit es gemacht ist. Kreativität braucht man nicht am Werkzeug bemessen. - Andererseits kann eine "Beschränkung" (z.B. vom System her) sogar Kreativität befördern.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ehrlich gesagt habe ich eher so wenige musikalische Ideen, daß ich immer, wenn mir zwischendurch etwas einfällt, ich das kurz ins Mikro singe und aufnehme, damit ich's da hab, wenn ich mal 'n Stück Musik brauche.
Ich habe oft nur eine kleine Idee oder bin inspiriert von irgendetwas, und dann improvisiere ich beim Trackern - lasse das bisherige laufen und in meinem Kopf bilden sich dann wie von selbst neue Melodien oder Begleitungen.
So ist es bei mir auch.
zatzen hat geschrieben:Deswegen ist mir so wichtig dass der Tracker in dieser Hinsicht ergonomisch ist, d.h. parallele redundante Darstellung.
Aber ich brauche dafür nicht diese Tracker-Darstellung. Die ist mir zu umständlich. Wenn ich z.B. irgend eine coole "Begleitung" habe, weiß ich, wie die klingen soll, gebe die 1x ein und baue so lange dran rum, bis es so klingt wie es muß. Ich muß es dann aber nicht zigmal irgendwohin "zusammenkopieren", sondern sage einfach: Hier 30x spielen. Und wenn ich merke: Ach, 30x gefällt mir nicht, ich will am Ende etwas anderes, dann ändere ich die 30 z.B. in 26 und baue da den Rest woanders. Dadurch bin ich schnell genug, bevor ich meine Idee wieder vergessen habe.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Mit Aussagen wie "geht nicht" und "System zu langsam/unzureichend" werde ich immer vorsichtiger, weil man immer wieder sieht, was wirklich so alles geht.
Scheinbar wird die Hardware vieler Computersysteme erst Jahrzehnte später durch findige Programmierer richtig ausgereizt, so auch beim C64.
Nicht nur "scheinbar" - es ist genau so. Da aber heutzutage die Technik sich viel zu schnell ändert/erneuert, als daß irgendwer Zeit hätte, sich darin zu vertiefen und zu lernen, was das Zeug wirklich kann, wird aus Zeit- und Kostengründen heute das meiste nur noch irgendwie oberflächlich abgeackert und bleibt extrem hinter den wahren Möglichkeiten zurück. Ich selber finde das schade um die schöne Technik. Den meisten anderen Leuten ist das egal. Ignorantes Pack eben. Total unwürdig, irgendwas technisches zu benutzen/besitzen.
zatzen hat geschrieben:Ich hab da mal ein Spiel gesehen das könnte glatt DOS 256-Farben VGA sein. War aber nur kurz, vielleicht irre ich mich.
Du meinst auf C64? Naja, es gibt so komische Tweak-Modi, wo die so Eigenschaften von PAL ausnutzen, so daß der Eindruck entsteht, da wären mehr als 16 Farben.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn jemand ein Spiel herausgebracht hätte, das, um Musik und Sound zu haben, zwingend eine GUS gebraucht hätte, und ohne GUS komplett stumm gewesen wäre - das Ding hätte er einfach nicht verkaufen können.
Genau das ist die Sache. Wenn ich ehrlich bin sind für mich die spannenden Jahre leider vorbei - die Jahre als die Domäne der Spiele noch DOS waren. Damals hatte ich den langen Atem und wollte schon aus Spielerei meine Spiele für VGA, EGA und CGA konfigurierbar machen. Aber meine beschränkten Fähigkeiten haben dann dazu geführt dass die Projekte schon im frühen Stadium liegen geblieben sind. Wie auch immer, eine Idee mit der GUS wäre, dass man sie einsetzt als Option, wenn z.B. nur ein 386er zu Verfügung steht.
Ja, so geht's mir auch:
Früher: Viel Energie, wenig Ahnung.
Heute: Viel Ahnung, wenig Energie.
Anders ausgedrückt: Mit der Energie meines 20-jährigen Ichs, aber der Ahnung von heute könnte ich das DOS-Spiel des Jahrhunderts bauen...

Natürlich wäre so optionaler GUS-Support immer eine gute Idee. Warum man das zu 386er-Zeiten noch nicht so oft gemacht hat, lag wohl daran, daß die anvisierte Zielgruppe sich vielleicht gerade mal den damals schweineteuren 386er leisten konnte und dann selten noch Geld für die damals schweineteure GUS übrig hatte.

Dem "System zu lahm für Digisound" ist man ja, wie wir alle wissen, damals anders begegnet: Musik wurde generell nur für AdLib gemacht - weil Creative Labs ja so schlau waren, diesen AdLib-Chip auch auf die SB zu klatschen. D.h. die ganze "Soundblaster-Musik" damals war eigentlich AdLib. Selbst die Soundeffekte wurden oft in AdLib gemacht - das Digitalzeug kam viel später, als genug Speicher und Leistung dafür da waren.

Der Kram, den ich hier mache, mit "Mindestanforderung 386er" ist das ja nur, weil ich bislang 486er-Opcodes vermeide (da sind auch nicht wirklich viele dabei, die ich bisher vermißt hätte) und da es mit max. 386er-Opcodes gemacht ist, stürzt es auf 386ern nicht ab. Aber mein ganzes Grafikzeug und auch ISM und der ganze Kram wird alles, was ich so an Spielen mache, auf 386ern wohl zu einem 3-5 fps-Erlebnis machen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]Naja, klingt für mich nach: Schon zu versaut von modernen Medien[...]
Das muss ja nicht unbedingt werten. Jeder Mensch ist anders, und ich bin etwas sinnesorientierter. Ich nehme meine Umwelt nicht nur informationsmäßig wahr, sondern vielschichtig und assoziativ auf der Ebene der (irrationalen) Eindrücke - aber wer tut das nicht, vielleicht mehr oder weniger.
Alles nur Varianten von "Schon zu versaut von modernen Medien".
Wer Real-Life mäßige Grafik/Sound will, ist eben kein echter "8-Bit-Nerd". Der richtige Computernerd geht vor die Tür (um Pizza reinzuholen) und denkt: Igitt, Real-Life, schnell zurück vor'n Monitor!
zatzen hat geschrieben:Jedenfalls: Deswegen war eine faszinierende Grafik für mich auch immer mit eine Motivation, ein Spiel zu spielen, wenn das Spiel dadurch mehr Atmosphäre hatte. Eine Auflösung höher als 320x200(/240) fand ich dabei eher abträglich, aber 256 Farben waren toll. Sample-Sound Fan war ich spätestens seit ich das MOD Format entdeckt hatte - erstmal nur Player, also noch nicht selber kreativ tätig werdend.Naja, mir ist aber auch schon mal passiert dass ich mit Freunden im Kino war, die sich die ganze Zeit über die schlechte Handlung beschwerten, während ich die Atmosphäre des Films genossen habe.
Ist wohl wie mit P0rn: Manche beschweren sich über die schlechte/dumme Handlung und andere genießen die Atmosphäre und Bilder.

Ich bin da irgendwie so, daß mich es immer fasziniert, wenn Leute mit wenigen Mitteln (Grafik wie Sound) tolle Dinge erreichen. Ich habe hier z.B. "Loom" (auch Lucas Arts). Das Ding hat nur 16 Farben (320x200) und ich find's wunderschön.
zatzen hat geschrieben:Im Nachhinein muss ich sagen, dass z.B. CGA auch etwas Besonderes haben kann.
Ja, ich finde auch, daß Farbanzahl nicht die Rolle spielt, sondern was man draus macht. Find nur die Farbauswahl von CGA etwas wenig geglückt - der Standard-Mode mit Magenta/Cyan, das beißt irgendwie. Da hätte ich als GraKa-Konstrukteur das vielleicht so gemacht, daß man die 8 (oder 16) Farben hat und für alle 4 Farben entscheiden kann, welche davon man nimmt. Aber das war damals eben alles total simpel und "hartverdrahtet"... (Und ja, ich weiß, daß es eigentlich 4 CGA-Farbmodi gibt, wo man jeweils Intensity und Blue weglassen kann und außerdem Farbe 0 wählbar war.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:[2D-Point&Click-Adventures]
Ja, von 3D hab ich bei Spielen auch nichts. Was meinst Du wie mich die 3D-Welle um die Jahrtausendwende angekotzt hat, als alles plötzlich 3D sein musste, aus Prinzip. So ein furchtbarer Stilbruch bei Adventures! Vom gemütlichen, atmosphärischen Point&Click Charme hin zum Egoshooter-Look... Und dann diese Luftmatratzen statt liebevoll gepixelter Sprites. Polygongrafik in Ehren, aber nicht als Ersatz für klassische Point&Clicks.
Ja, bei den WENIGEN Adventures, die ÜBERHAUPT noch rauskamen. Denn als "alles 3D sein mußte", mußte ja auch automatisch alles "3D Ego-Kriegs-Geballer" sein. So als könnte man mit 3D nichts anders machen als das. Ich fand (und finde heute noch), daß sich die ganze "Tomb Raider" Serie wohltuend von dem restlichen Scheiß abhebt, der so mit 3D gemacht wurde/wird. Bei TR geht's um Geschicklichkeit, Lösen von Rätseln/Mechanismen/Fallen usw. und nur sehr sekundär um Geballer - und es gibt eine fortlaufende Story. Das zeigt, daß mit "3D" auch mehr geht als immer nur die gleichen doofen Kriegssimulationen.

Doom fand ich ja noch ganz angenehm - die Steuerung war simpel genug, daß es nicht genervt hat und mir gefiel die Grafik und das ganze Setting. (Ja, ich hab eben so einen Geschmack.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:Jedenfalls scheine ich wohl nicht der Einzige zu sein, den "Pixeligkeit" nicht nur "nicht stört", sondern der sogar Wert darauf legt.
Da sind wir schonmal zu zweit, und wenn es noch mehr werden macht das Hoffnung. Es ist vielleicht einfach Prägung, aber ich habe 320x2?? immer magischer empfunden als etwas höheres.
Magisch... Naja. Mir war schon immer klar, daß die 320x200 sich eher aus technischen Gründen ergeben hatten und find's praktisch, weil's eben sehr simpel anzusteuern ist. (Was ja wohl auch die Idee dahinter war.) Es heißt ja nicht umsonst auch MCGA, weil's eben aufgebohrt aus schon vorher bestehenden/ vorhandenen Modi war. Aber ja: Viele der besten Spiele für DOS kamen eben in 320x200. Nur liegt das eher an der Zeit: Zu der Zeit war das der einzige 256-Farb-Modus, der quasi überall wo es VGA gab ohne Tricks verfügbar war.

Das ganze VESA-Zeug kam ja erst, als DOS schon kurz vorm Schlußverkauf war. Mit "Super VGA" konnte man ja nichts anfangen: Jeder GraKa-Hersteller hatte seine eigene Suppe gekocht, um "mehr aus der Karte" rauszuholen - aber Spielehersteller mußten natürlich auch rechnen: Wenn man ein Spiel an die Zielgruppe verkaufen will, gibt es bestimmte Preisgrenzen, bei denen es noch Sinn macht. Zusätzliche Entwicklungen für jeden herstellerabhängigen komischen Grafikmodus kosten alle Zeit und Geld. Erst als die VESA da diese Standardisierung gemacht hat, fing es an, etwas Sinn zu machen, auch "höhere" Modi zu benutzen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:...was wohl unter anderem auch daran liegen mag, daß WINDOWS keinen 256x256 Modus anbietet... :)
Nein, Deluxe Paint ist ein DOS Programm, gab es auch auf dem Amiga. Damit lässt sich sehr gut pixeln und es hat neben Anti-Aliasing und Gradientenverläufen auch so Sachen wie Kreisfunktionen die an die Aspect Ratio angepasst sind, also Kreis bei 320x200.
Achso. Naja, kennst mich ja: Bin so totaler Stoffel, baue mir immer allen Kram selbst, sogar meine Tools. Ich habe unter DOS quasi von Anfang an alle meine Grafiken immer in selbstgebauten Tools erstellt.

Aber: Anti-Aliasing und Verläufe machen so 256-Farb-Programme leider oft mit so Dither, so richtig gefällt mir das nicht. Außerdem wirken berechnete Farbverläufee innerhalb von ansonsten handgepixelten Bildern immer irgendwie wie "reingesetzt"/"drübergestanzt". Das ist ähnlich häßlich wie die ersten Computergrafiken in Billig-Filmen, wo man dann immer genau gesehen hat, wo die CGI aufhört und der Rest anfängt.

Und, wie bereits erwähnt: Ein Kreis ist nur ein Sonderfall der Ellipse. Ein Programm, das Kreise UND Ellipsen zeichnen kann, hat NUR eine Ellipsen-Subroutine - für Kreise werden einfach beide Radien gleichgesetzt. Kommt Aspect-Ratio dazu, wird diese einfach mit einem der Radien multipliziert (so daß es wieder eine Ellipse wird, die durch die Bildzerrung dann wie ein Kreis aussieht).

Ich selbst bin übrigens überhaupt kein Fan von so Aspect-Ratio Zeug, das Programme automatisch machen, weil ich beim Pixeln/"Zeichnen" immer die volle Kontrolle über mein Zeug haben will und also auch wissen will, wo die Pixel landen, wenn ich die setze. Bei sehr schrägen Auflösungen würde ich vielleicht noch mit Aspect Ratio arbeiten. Bei 320x200 ist mir die Abweichung nicht groß genug, als daß ich da mit sowas rummurksen wollen würde.

Desweiteren kommt es in meinen Spielen äußerst selten vor, daß ich irgendwo reine große Kreise benutze (oder überhaupt unveränderte geometrische Formen) -das sieht mir zu "konstruiert" aus. Und wenn ich kreisförmige Objekte (Kugeln usw.) habe, sind die meistens noch so klein, daß Ratio nicht auffällt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich bin nie davon ausgegangen, daß irgendeins meiner Programme oder Entwicklungen von entscheidender Bedeutung für Dein Spiel/Deine Entwicklungen sind oder sein müßten.
Zumindest aber das von Dir vermittelte Wissen.
Naja, das ist auch nur Kram, den ich entweder irgendwo gelesen oder selbst herausgefnnden habe. Ich schreibe so Zeug immer nur mit dem Gedanken "Bei mir funktioniert's, also muß es ja gehen" hin. Aber nichts von alledem ist "der Weisheit letzter Schluß" - bin auch nur ein Hobby-Krauter.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich habe hier noch etwas gebastelt, daran habe ich in den letzten Wochen (waren so 3 Wochenenden, netto 5 Tage, mit kranheitsbedingter Unterbrechung) so experimentiermäßig herumgebaut. Vielleicht gefällt's Dir ja. Zeigt auch mal, was so ein 486er wirklich kann.
Du Schelm! Netter Gruß, das wirkt ja ein bisschen an mich gerichtet, auch mit den ominösen quadratischen Pixeln.
Es IST ja auch an Dich gerichtet - deshalb ja auch in diesem Thread.
zatzen hat geschrieben:Du hast mich zweimal erwischt: Gute Sache, dass man den ROL/ROR error abfangen kann.
Klar, wenn er nichts so Blödes machen würde, bräuchte man ihn ja nicht abfangen. Man fängt ihn ab, indem man die Befehle ausführt und sie dann mit dem Ergebnis vergleicht, das eigentlich korrekt wäre. Bei Abweichungen wird der Fehler gemeldet.
zatzen hat geschrieben: Und dann hatte ich die Cycles auf 26800 (~66 Mhz 486) aber wurde noch als Dumbass beschimpft...Ich hab's dann noch mal mit 40000 Cycles laufen lassen, ging dann durch, war aber irgendwie alles immer noch ein bisschen flimmerig - wahrscheinlich noch nicht optimale Emulatoreinstellungen.
In einem Spiel würde ich das Timing und den ganzen Kram etwas mehr "selbstregulierend" machen, aber das hier ist ja nur eine simple Demo.

Im Prinzip macht er für diese "zu wenig Power" Abfrage nur eins: Wenn er an die Stelle kommt, wo ein neuer Soundpuffer generiert werden soll, darf die Anzahl neu zu generierender Puffer nur 0 oder 1 sein. (Diese Anzahl wird im SB-IRQ erhöht, d.h. wenn ein Buffer fertig ist.) Ich arbeite ja mit Doublebuffer. Wenn die Anzahl höher als 1 ist, bedeutet das, daß in der restlichen Schleife so viel passiert ist, daß schon der nächste Puffer abgelaufen ist, bevor man den neuen anderen generiert hatte - also im Klartext: Die Schleife insgesamt zu langsam ist.

ABER: Das Programm hat einen Parameter, um dem zu begegnen;
Mit einer einstelligen Zahl 1 bis 9 als Parameter wird die initial gesetzte Puffergröße damit multipliziert, d.h. man vergrößert damit den Soundpuffer und dann gibt's keinen "Überlauf" mehr.

Übrgens: Mit einem zweistelligen numerischen Parameter 10 bis 44 wird stattdessen die Soundrate in kHz eingestellt - bei höheren Werten macht es natürlich nur Sinn in Kombination mit größeren Puffern (je mehr Framerate, umso größer der Puffer).

Die Reihenfolge dieser Parameter ist egal. D.h. wenn man z.B.
486power 4 44
eingibt, hat man einen 4x so großen Doublebuffer und der Sound wird mit ca. 44 kHz generiert und abgespielt. Bei genügend groß gesetztem Puffer kann man auch bei niedrig gesetzten DOSbox-Cycle-Werten das Ding noch ansehen, ohne "DUMBASS"-Modus...

(In einem SPIEL würde ich selbstverständlich die Pufferlänge selbständig anpassen, d.h. bei höhrer Frequenz muß der Puffer natürlich größer sein, weil ja mehr Daten in gleicher Zeitspanne gebraucht werden.)

Allerdings, wenn man in diesem Demo den Puffer viel größer macht, KÖNNTEN Demo und Musik eventuell geringfügig unsynchron werden - weiß nicht, ob es so ist. ISM hat ja das Feature, Daten "an das Hauptprogramm" abzugeben, über so einen Puffer - und das wird in diesem Demo auch benutzt, um bestimmte Dinge passend zur Musik einsetzen zu lassen.

Anm.: Es gibt auch ein Feature, wo das Hauptprogramm an ISM Daten gibt - also die andere Richtung. Allerdings nützt das ja nur etwas, wenn die Musik in ISM entsprechend "programmiert" ist, d.h. Befehle drin sind, die diese Daten auch abfragen und für irgend etwas benutzen. Das Feature ist z.B. dafür gedacht, daß das Programm einfach nur Daten in einen Puffer schmeißen muß, wenn ISM einen Soundeffekt abspielen soll und der ganze Kram, welcher Effekt gespielt und welche Stimmen dafür benutzt werden, von ISM übernommen werden kann. (Allerdings werde ich da wohl in meinem "Spielschleifen-Container" trotzdem noch ein "Zwischen-Interface" einbauen, das die Stimmenzuteilung übernimmt, damit man da flexibler ist.)

D.h. die Spielfigurensteuerung (GameSys2) kann einfach an einer Stelle einen "Befehl" generieren - das Hauptprogramm prüft diese "Befehle" und wenn es ein Befehl für ISM ist, startet es die Musik oder Soundeffekt mit der entsprechenden Nummer. Naja, ich schätze, so würde das wohl jeder machen, der sein Zeug einigermaßen modular aufbaut.
zatzen hat geschrieben:Sehr lustige Sache, auch mit den Schweinchen.
Naja, ich wollte ein paar Sprites haben, hatte dann erst so einen Schweinekopf gepixelt, fand dann, daß er mit einer Fliege gut aussehen würde und habe dann den Rest gepixelt. Daß der Kopf unproportional größer als der Körper ist, ist Absicht, das soll so Zeichentrickfigur-mäßig aussehen. Aber eigentlich ist es nur dazu da, um zu zeigen, daß Sprites gehen.
zatzen hat geschrieben:Und technisch - da kann ich natürlich nur staunen und werde diesen 640x480 Modus wohl nie ansteuern. Und dann noch mit Scrolling. Ist mir ein Rätsel, da Du ja auch nicht mehrere Seiten zur Verfügung hast. 307200 Bytes sind ja ein Screen, hast Du deshalb am Anfang noch nicht das volle Bild gezeigt?
OK, dann schaffe ich mal Klarheit:
Das ist kein VGA, das ist VESA, der VESA-Modus 640x480x256 (Mode $0101).
Damit die Ansteuerung schnell und einfach geht, habe ich die Scanline auf 1024 Bytes/Pixel erweitert. Somit hat jede Zeile 1024 Bytes, der Wechsel der 64k-Bank passiert immer genau in jeder 64. Zeile. Die Klötze sind 32x32 Pixel, somit passen genau 2 Klotzzeilen übereinander in eine so Bank. Es werden immer nur GANZE Klötze gezeichnet (32bit-kopiert). Das Scrolling passiert, indem der Bildanfang um 0 bis 31 Pixel verschoben wird. Es gibt 2 "Bilder", jedes ist 1024x512, somit hat man zusätzlich zu den 480 Zeilen noch diese 32 Zeilen "Versatz". Das Bild wird auch links immer um 32 Pixel verschoben dargestellt, somit kann man GANZE Blocks außerhalb des Bilds anfangen zu zeichnen, für halb reingescrollt.
Das "Scrolling" ist also eine Kombination aus Bild im Offset darstellen und geschickter Berechnung/Plazierung der Levelklötze. Der "Scroll-Offset" wird auch in Variablen vermerkt - somit wird alles andere (z.B. Texte oder Sprites) um diese Offsets verschoben ins Bild kopiert. Die unterste Blockzeile wird mit einer anderen Schleife dargestellt, damit sie unten "abgeschnitten" sein kann, wenn da noch etwas anderes dargestellt werden soll.

Am Anfang werden für die erste Demo-Hälfte die Blocks erst geladen, dann jeder Block auf 4 Blocks verteilt, mit in X-/Y-Richtung verdoppelten Pixeln. In Wirklichkeit sind das also nicht einzelne Xpyderz-Blocks sondern jeweils 4 Blocks im Quadrat angeordnet. Die Sprites werden mit doppelter Vergrößerung dargestellt, genau wie die Texte. Einfach ausgedrückt: Jeder "Pixel" sind eigentlich 4 gleichfarbige kleinere Pixel. Außerdem wird zu Anfang der untere 80 Pixel-Bereich schwarz gemacht.
Das dient dazu, damit es zu Anfang so aussieht, als wäre es ein 320x200-Mode - später zieht die Bild-Unterkante ja ganz runter... so sieht es aus wie 320x240, mit quadratischen Pixeln.

In der Mitte, wo die Musik etwas an "Dramatik" zunimmt, wird das Geheimnis gelüftet und eigentlich dachte ich, das Ganze wäre damit selbsterklärend: Daß das ganze Ding eigentlich schon von Anfang an in 640x480 läuft und scrollt und Sprites anzeigt usw. Der zieht ja dann die Blöcke zusammen und macht sie kleiner und hochauflösender, den großen Kopf-Sprite und die Schweinesprites und die Texte auch. Und ganz am Ende wird sogar als Text eingeblendet, daß das alles schon von Anfang an auf 640x480 lief.

Also: Ja, es ruckelt etwas (ohne Musik ruckelts übrigens um einiges weniger), aber ich schaufle ja auch (OHNE Text+Sprites) 4,8 mal so viele Daten durch die Gegend als wie es bei 320x200 wäre. Mit Sprites/Text usw. sind es wohl eher 5- bis 6-mal so viele Daten. Will sagen: Wenn ein 486er mit 640x480 schon DAS machen kann, sollte er wohl auch 320x200 schaffen.
zatzen hat geschrieben:Die Musik klingt schön sauber, 15 KHz Mischfrequenz - komisch, eigentlich fand ich sowas zu stumpf, aber es reicht irgendwie.
Die Mischfrequenz ist eigentlich genau 16000 Hz - die Abspielfrequenz wohl ca. 15873 oder 16129 Hz. Mit dem SB auf ca. 16129 Hz könnte ich eigentlich ISM auch mit 16128 generieren lassen - das ist auch eine der möglichen Frequenzen von ISM. (ISM kann man auf 128 Hz genau einstellen, weil das die Minimal-Tonlänge ist.) D.h. wenn ich ISM und SB auf 16128 / 16129 stelle, hätte ich ein relativ frequenzgenaues Ergebnis. Andererseits ist es bei Musik ja so, daß man sie beliebig transponieren kann, weil die Konsistenz der Melodie ja nur davon abhängt, daß das Frequenz-Verhältnis der Töne ZUEINANDER stimmt.

Diese 16kHz sind so meine Referenz für ISM. Was ISM so ausgibt, wird mit über 16kHz nicht mehr besser.
zatzen hat geschrieben:Vielleicht werde ich alt - nein der Lautsprecher den ich hier grade dran habe ist "forgiving". Es klingt ähnlich Deiner früheren Musik für Rockus.
Ja, wie gesagt: Ich bin nicht besonders talentiert. Meinen lahmen "Stil" erkennt man wahrscheinlich immer wieder.
zatzen hat geschrieben:Laut meiner Analyse kommen die ersten (wie) zufälligen Töne im klassischen PC-Speaker-Stil auch aus der ISM Engine, stimmt das?
Nein, stimmt nicht.
Sie werden über den PC-Speaker abgespielt - aber Emulatoren geben meist jegliche Soundausgabe über das Standardsoundausgabegerät aus, die emulieren den Speaker quasi auch und mixen den mit rein.
Es ist nicht "wie" zufällig, es ist mit Zufallsgenerator gemacht - es soll so dieses altmodisce "elektronische Geräusch" machen, während sich das "Bild" da füllt. Das ist übrigens der gleiche Textmode-Trick wie in meinem "Hello World" Ding.
zatzen hat geschrieben:Also, schön das mal alles zusammen zu sehen, auch mit ISM. Ich hätte vielleicht eine weniger aggressive Wellenform für die Hauptstimme genommen.
Naja, ich mag's wenn die Musik so etwas "reinhaut" - und speziell in dem Fall hier wollte ich die Musik laut und schräg haben. Man kann übrigens während es läuft mit +/- die Blaster-Lautstärke hoch-/runterdrehen.
zatzen hat geschrieben: Aber schön, die Portamentos.
Ja, das ist eine der wenigen Fähigkeiten von ISM und ich wollte das auch mal selbst benutzen. Außerdem hatte ich dieses Stück "Musik" im Kopf und da gehörten Portamentos dazu. (Und wenn man Portamentos in Portacola wirft...)
zatzen hat geschrieben:Das kann ZSM nicht.
Ich weiß. Aber ich glaube, der Effekt wird sowieso gar nicht so oft in MODs benutzt. Übrigens: Um mein Portamento so sauber hinzukriegen, wird intern mit 48-Bit-Werten gearbeitet.
zatzen hat geschrieben: Was ich noch bemerke: Die Musik wird insgesamt leiser im Verlauf, wenn mehr Stimmen dazukommen. Das fällt so direkt nicht auf, aber ich hab das mal aufgenommen und genauer betrachtet.
Ja, und da KÖNNTE man jetzt vermuten, das läge an der Arbeitsweise von ISM mit dem Gesamtlautstärke-Dings und der "Clipping-Vermeidung" etc...
Ist es aber nicht!
Bei diesem Entenlied - DA hatte ich das mal ABSICHTLICH so gemacht, daß alle Stimmen erst nacheinander angeschaltet werden.

Aber bei dem Stück hier sind alle Stimmen von Anfang an aktiv - und stehen auf "Mute"-Befehlen, bis sie einsetzen, d.h. das Zusammenaddieren der Stimmen passiert schon von Anfang an. Daß die "Begleitstimmen" leiser werden, ist kein technischer Effekt von ISM, sondern absichtlich von mir gemacht, d.h. an der Stelle, wo die Hauptstimme einsetzt, stehen VOLUME-Befehle in den anderen Stimmen, die deren Lautstärke runtersetzen.

Ich bin nicht total talentiert, aber ich habe inzwischen, so lange, wie ich schon "Musik" am PC mache, mitbekommen, daß sich die einzelnen Stimmen sowohl im Oktavenbereich als auch in der Lautstärke unterscheiden sollten, damit sie differenzierter klingen und nicht totaler "Soundbrei" werden.

Ich wollte, daß das Ding gleich laut anfängt, deshalb habe ich die Begleitstimmen zu Anfang auf Maximum gestellt - vor allem die "melodische" Begleitstimme mit diesem Portamento am Schleifen-Ende sollte das erstmal richtig "einläuten", um "in den Groove" zu kommen. Aber, damit die nicht so überpräsent wird und die Hauptstimme kaputtplärrt, habe ich sie beim Einsetzen der Hauptstimme zurückgenommen.

Also: Hier mal kein technisches Versagen von ISM - das ist alles so Absicht.
zatzen hat geschrieben:Sehr schön deutlich übrigens auch das "Yeah"-Sample.
Ja, das habe ich selbst aufgenommen und ein bißchen dran rumgespielt (Grundrauschen raus, damit es auch auf 4-Bit noch OK klingt).

Ich benutze ja (leider) für so Sample-Zeug immer noch dieses uralte VOC386. Das ist zwar an sich eine gute Idee, aber es ist eben von der Bedienung her SOWAS von 1990.... Da kann man nichtmal alle Laufwerke ansprechen, weil's scheinbar eine Laufwerksbuchstaben-Obergrenze hat. Und die Anzeige der Files ist unsortiert - wie arm ist DAS DENN? Außerdem stürzt es manchmal aus unerfindlichen Gründen ab oder fängt an, komische Effekte bei der Grafikausgabe zu haben. (Wer weiß, was der da für'n seltsamen Grafikmode benutzt, ich glaube es ist irgendwie dieser 640x480x16 oder so.) Und schlußendlich, wegen der Bedienung, ist es auch nicht möglich, manche Sachen genau genug einzustellen in dem Soundbereich. Achja: Und beim Abspeichern als WAV scheint der irgendwie nur so einen generalisierten Header davorzuklatschen - egal welche Samplerate man im Programm eingestellt hat, im Header steht dann immer 22050. (D.h. man muß nachträglich den WAV-Header anpassen. Dazu hab ich mir vor etlichen Jahren mal ein Programm geschrieben.)

Also: Ja, das Ding ist zwar irgendwie nützlich und man kann auch einige "Effekte" damit machen (obwohl ich das meiste davon wohl auch schon selbst machen könnte) - aber es ist irgendwie ein Pain-In-The-Ass, damit zu arbeiten. Ich muß dafür z.B. auch immer meinen 486er neu booten auf so eine Config, die EMS freimacht und so.

Ich wollte mir immer mal selbst so ein Tool bauen - mit VESA-Modi und etwas besserer Bedienung. Ich würd's hinkriegen - nur komme ich sowieso schon zu nix (wie ich ja immer wieder schreibe) und muß mittlerweile planen, daß WENN ich mal die Energie zum Coden finde, wofür ich die einsetze...

Vielleicht sollte man den Kids, die so gerne "erwachsen werden" wollen, mal sagen, daß das nicht SOOO cool ist: Wenig Zeit haben, dauernd müde sein... Klar, ich hab' jetzt so viel Geld, daß ich mir jederzeit ein Eis oder Schokolade kaufen kann, soviel ich will und brauche keinen fragen... - aber dafür hab ich eben kaum noch Kraft, um mein Hobby auszuüben... - Selbst jetzt, am Wochenende, wo ich Zeit habe, ist es kaum besser: Ich gehe müde schlafen und stehe müde wieder auf. Irgendwie ist es ein wenig frustrierend, wenn man fast sein ganzes Leben nur mit Dingen verbringt, die einem egal sind.
zatzen hat geschrieben:Ich hab da eigentlich nichts zu meckern. Hat was von nem SID und ist von der Soundqualität her absolut akzetabel.
Ja, SID aus "Ice Age"...
Naja, Du weißt ja: Ich bin kein talentierter Musiker und baue meinen Kram eher nach "mathematischen" Gesichtspunkten zusammen. Manchmal habe ich auch so Ideen. Mitunter mögen die sogar von irgend etwas inspiriert sein, was ich mal irgendwo gehört habe - so funktioniert das ja meistens mit dem Gehirn.
zatzen hat geschrieben:Ich bin gar nicht so ein Kristallsoundmensch. Es kommt immer drauf an, was es ist.
Im ZSNES (SNES-Emulator) stelle ich Soundausgabe auf 11 kHz oder sogar 8 kHz ein - irgendwie klingen die Musiken da voller und hauen mehr rein - wahrscheinlich, weil der "Baß-Anteil" dann höher ist. Normalerweise bin ich ja nicht so der "Es muß Baß sein"-Typ und so Techno-Gehämmer nervt mich wie Sau. Und bei so Chiptune-Zeug (C64) LIEBE ich ja dieses Treble (Höhen)- lastige Zeug total. Wie Du schon sagst: Es kommt immer drauf an, was es ist.

Die "Musik" zu diesem Demo sollte einfach nur Laune machen, laut und brachial sein usw. - Die ist quasi das Gegenteil von dem, was ich z.B. als Hintergrundmusik für ein Spiel machen würde. Hintergrundmusik soll ja eher den Spieler "im Flow" halten, aber nicht total ablenken mit irgendwelchen "Höhepunkten".

Zur Grafik nochmal:
Man kann auch in "Mode-X" die Scanline erweitern. Und ja, da sind Nebeneinander-Pixel in unterschiedlichen "Planes". Aber das ist ja nur eine Frage, wie man die Blocks im Speicher ablegt. Wenn man sie so speichert, daß jeder Block aus 4 Bereichen besteht, die jeweils nur immer jeden 4. Pixel haben (in den Spalten), dann kann man auch in Mode-X die Blocks mit 32-Bit-Befehlen kopieren. Vielleicht sollte ich da einfach mal neue Routinen bauen, da wäre die Leveldarstellung (für sowas wie Xpyderz und auch anderes) noch um einiges schneller.

Das ginge dann zwar nicht für "Mehrebenen"-Levels - aber: Wenn es "Löcher" gibt, heißt das ja, es wird mind. 1 Pixel nicht gebraucht. Naja, dann 32bit-Wert laden, prüfen, ob das erste Byte<15 ist und wenn ja, woanders hin verzweigen. Da muß man die Blockdaten entsprechend vorher aufbereiten...

OK, soviel zu diesem Thread.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

DOSferatu hat geschrieben:Windows ist für die Leute nur ein Arbeitsgerät: Häßlich, lahm, irgendwie schräg, aber man muß sich darin fügen.
Genau, und irgendwie habe ich eine Zeit lang vemisst, dass jede Software zu DOS Zeiten ihren ganz eigenen Stil hatte. Aber für mich als Arbeitsgerät gut, spätestens für die Soundbearbeitung mit Interfaces/speziellen Soundkarten die in DOS nicht funktionierten und Tonbearbeitungssoftware die Welten mehr konnte als das was ich in DOS hatte. Dieses VOC386 würde mich aber mal interessieren zu Begutachtung, falls das Free-/Shareware ist.


Zum Thema 16:9 habe ich mich noch etwas belesen. Was Kinos betrifft ist es tatsächlich so, dass durch die breitere Leinwand die Sitzreihen flacher gemacht werden konnten. Zudem sei 16:9 etwas breiter als das wirkliche Sichtfeld, das liegt eher irgendwo in der Mitte von 16:9 und 4:3. 16:9 habe man dennoch gewählt, weil man den Blick für gewöhnlich in der Horizontalen weiter schweifen lässt als in der Vertikalen.

DOSferatu hat geschrieben:Da müßte es jemanden geben, der einen humanoiden Körper/Verstand hat, aber einen so gehörnten Ziegenkopf... Fällt Dir da jemand ein? ... Und vielleicht war DER es auch, der deswegen dieses 16:9 eingeführt hat.
Ja, der hat auch eine Lautsprecherfirma. Sehr beliebt wegen Preis/Leistung, deswegen haben schon zwei Freunde von mir diese Kisten denen vorgezogen, die ich ihnen hätte bauen können, auch weil ich ein paar Monate brauche zum Bau. Wäre mal was erfrischend anderes gewesen mit Horntechnik und so, aber nein, es gehen lieber noch ein Paar weitere der zig Millionen des 08/15-Prinzips über den Ladentisch. Da bin ich dann immer etwas enttäuscht. Was soll's, ich brauche noch ein bisschen Zeit für weitere Entwicklungen, die dann von den Abmessungen so sind wie beliebte Standlautsprecher, aber Hörner sind - einziges Problem wird sein dass ich dann preislich nicht mit den in Fernost gefertigten simplen Kisten mithalten kann. Aber genug, das ist sehr Off-Topic.

DOSferatu hat geschrieben:
zatzen hat geschrieben:Deswegen ist für mich DOS attraktiver für etwas das Bild und Ton ausgibt, und dass das momentan hier alles in der Box läuft stört mich erstmal nicht.
Naja, andere Leute sehen das anders - die haben ihre Fertiglösungen/ Libraries/ Frameworks für ihren Kram und können auch unter Windows gleich Bild+Ton machen. Ich bin bloß nicht gern so "Fertiglösung"-Nutzer beim Coden - aber das ist eben eine Einstellungssache.
Für Windows wäre mir das egal. Da muss die Sache nur funktionieren, nicht mal performen, ist mir irgendwie egal was da für'n Dreck bzw. Overhead passiert wenn ich was in Freepascal mache - meistens Tools, und da müssen letztlich einfach die erzeugten Daten stimmen. Eine Library für Tonausgabe, oder auch Bilder einlesen oder darstellen, das wäre mal nett, zumindest wenn ich die Daten über Arrays fliessen lassen kann. Ich versteh nix von Programmierung mit Klassen und sowas, und wenn ich Daten nicht in ein eigenes Datenfeld einlesen kann bringt mir das nichts. OOP mit Freepascal wäre vielleicht mal einen Blick über den Tellerrand wert, es scheint für Windows-GUIs eine gute Lösung zu sein - wenn man sowas braucht. Angeblich soll man dabei generell ja auch effizienter programmieren können - falls ich irgendwann dahin komme: Für Windows Tools wo ich Dinge wie Assembler sowieso nicht einsetze wäre es vielleicht ne Option. Allerdings wäre es schon etwas komisch, wenn der Code nur aus Definitionen besteht und man nicht wirklich nachvollziehen kann was unter der Haube passiert.

DOSferatu hat geschrieben:
zatzen hat geschrieben:Sagen wir mal so, dass 100 Mhz für meine Projekte reichen. Laut DosBox-wiki entsprechen 26800 Cycles grob einem 486 mit 66 Mhz. Wenn mein Kram mit 20000 Cycles funktioniert, dürfte eine 100 MHz Maschine das hinkriegen, vielleicht auch eine mit 50.
Ich weiß nicht, was für meine Projekte reicht. Ich versuche immer, so zu programmieren, wie es meinen derzeitigen Fähigkeiten entspricht, um möglichst wenig Speicher und Performance zu verschwenden. Und mir ist natürlich klar, daß meine 10 oder 15 oder 20 Jahre alten Sachen da noch stark ausbaufähig wären. Manchmal benutze ich auch alten Kram, von dem ich weiß, daß er nicht optimal ist, weil ich einfach mal "irgendwas brauche" und noch keinen "neuen Kram" gebaut habe. Ich komme eben mit meinem Zeug nicht mehr so hinterher und in letzter Zeit mache ich wenig - oder wenn, dann auch viele andere Sachen, die gar nichts mit dem "ich mache ein neues 2D Spiel" zu tun haben.
Mir wird an dieser Stelle mal klar, dass ich eigentlich bisher nie versucht habe, auch nur in die Nähe von schnellen "Arcades" zu kommen. In meinen Basic-Zeiten war alles durch Basic selbst und meine Unfähigkeit limitert, dann kam Pascal und Assembler, aber damit ist noch kein richtiges Spiel fertig geworden.
Ich denke, dass ich auch demnächst nicht versuchen werde, einen schnellen 2D Platformer wie Super Mario Bros. zu erreichen, sondern es wird was gemütliches, das, wie eh und je, unterhalb dessen bleibt, was der Computer zu leisten vermag. Ich bin geprägt von Adventures und Rätselspielen, und würde so eine gemütliche Art von Spiel selbst machen, vielleicht ein Jump&Run, aber eher ohne Scrolling - die Handlung kann innerhalb eines Screens vollendet werden, und dadurch muss dann auch alles etwas kompakter gehalten werden, was wiederum das Pixeln der Grafik erleichtern kann. Also, so könnte es aussehen: So, wie Kotzman II lächerlicherweise erst auf einem 486 optimal performte (d.h... Die Geschwindigkeit wurde durch eine Schleife gebremst, und wenn mehr Figuren dazukamen wurde alles langsamer, und je langsamer der Rechner, desto stärker war dieser Effekt), obwohl soetwas in der Art auf einem 286 möglich ist, wäre es mir jetzt nicht zuwider, auf einem 486er ein ansprechenderes Spiel zu machen, das vielleicht findige Coder auch auf nem langsamen 386er hinkriegen würden. Ich sagte sowas schonmal. Der Unterschied ist jetzt nur, dass ich gar nichts anderes als etwas gemütliches realisieren will, egal wieviel Leistung ich zur Verfügung habe. Und dann statte ich das Ding gerne mit Prozessorlasten wie ZSM aus.

DOSferatu hat geschrieben:Aber natürlich ist das auch das erste, was man bei einem 2D-Jump'n'run machen würde: Erstmal eine (Pseudo-)Welt bauen und eine Figur und eine Möglichkeit zur Figur/Welt Kollisionsabfrage und eine Steuerung für die Figur, damit man erstmal sieht, daß es von der technischen Seite her funktioniert.
Ja, und ich hab da auch einfach parallel zur Landschaft in Pixeln alles markiert wo man gehen konnte und wo nicht, oder wo man draufspringen konnte. Ich weiss nicht mehr ob ich dafür je Pixel 8 Bit genommen habe oder das sparsam mit 1 Bit gemacht habe. Immerhin konnte man so auch Rampen (je nur 1 Pixel Höhenunterschied) hochlaufen, aber es ist definitiv unter "Experimente" abzulegen.
DOSferatu hat geschrieben:[Ewige lange Sounds in Duke Nukem 3D einbauen]Dir ist aber schon klar, daß Duke Nukem 3D (genau wie Doom, Quake usw.) 32-Bit Spiele sind, die also auch quasi in einem Flat-4G Mode laufen, oder?
Ja schon, es war nur einfach so dass damals, so um 1998, das mit Stand der Technik war und dann habe ich etwas in diesen Dimensionen gedacht, hatte natürlich keine Kenntnis wie man in diesem 32 Bit Mode programmiert, aber ich hatte ein paar MB XMS und hab dann eben für meine billigen eigenen Spieletest aus den Vollen geschöpft. Pentium eben.

DOSferatu hat geschrieben:Was DOSbox angeht: Weil DOSbox ja so "generös" ist, hat man da auch meist viel Heap. So viel Heap wie in DOSbox haben die wenigsten Leute auf der Realmaschine. Daran sollte man auch immer mal zwischendurch denken.
Mach ich!

DOSferatu hat geschrieben:Die echte SB kann nämlich z.B. Sounds im PCM-Format (bzw sogar verschiedenen PCM-Formaten) abspielen. [...] Mit PCM könnte man einiges an Speicher sparen und trotzdem recht guten Sound haben - aber die ganzen SB-Klone supporten nur den "normalen" Kram, von allem, was die SB so kann.
Ich hatte mich ziemlich ausführlich mit der Soundblaster Pro beschäftigt als ich sie damals hatte. Pulse Code Modulation (PCM) an sich ist nur die simple Codierung, dass jedes Byte oder z.B. bei 16 Bit ein Integer einen momentanen Zustand der Wellenform darstellt. Ich erzähl' Dir hier nix neues... Was die Soundblaster nun hardwareseitig konnte waren verschiedene Delta(ADPCM)-Formate, 4- 3- 2- oder 1 Bit, kann sein dass es nicht alles diese waren. ADPCM ist besser als was ich bei ZSM gemacht habe, d.h. es wird bei 4 Bit noch deutlich besser klingen (es wird auch für 16 Bit eingesetzt). Das VOC-Format kann verschiedene Blöcke enthalten die unterschiedliche Komprimierungsverfahren nutzen, und es gibt auch Silence-Blöcke, so konnte besonders Sprache effektiv komprimiert werden.

DOSferatu hat geschrieben:Es gibt verschiedene Arten, das zu machen. 160x200x16 geht ja auch mit Textmode (siehe mein Posting im anderen Thread). In Fall dieses Tools ist es echter 160x200x256.
Der war einer der wenigen Modi die Dosbox nicht auf 4:3 "gezogen" hat, sondern es war 2:3

DOSferatu hat geschrieben:[Zatzens Ästhetik-Problem mit Sprite-Skalierung]Und man sieht wieder: Zu versaut von aktuellem Multimedia. Man fragt sich, wieso so jemand eigentlich 320x200x256 Spiele machen will.
Nee! Mich haben wenn überhaupt die vielen tollen in 320x200 gehaltenen Spiele versaut (ob 4, 16 oder 256 Farben) bei denen jeder Pixel übelegt gesetzt war und ein Sprite nicht durch Echtzeit-Skalierung/Drehung fusselig oder pixelig-schrumpelig wurde. In manchen Spielen stört das nicht und es ist toll wenn sich ein Sprite quasi stufenlos dreht, aber es gibt eben viele Spiele wo wie gesagt jeder Pixel genau da sitzen muss wo er ist. Meinetwegen geht das bei Monkey Island I noch, weil es besser ist roh runterzuskalieren als wenn Scheinriesen entstehen, logisch. Vielleicht können wir uns drauf einigen dass es Geschmackssache ist.
320x200 ist aus mehreren Gründen meine liebste Auflösung und ich will dafür Spiele machen, aber mit konsistenten Pixeln. Aktuelles Multimedia brauche ich nur für Dinge außerhalb von Spielen. Und weil ein Computer heute HD Video und Studioqualität-Ton kann, erübrigt sich das Staunen über technische Eckdaten. So haben dann Spiele wie Alley Cat (CGA, PC Speaker) immer noch bzw. wieder ihren nostalgischen Charme.

DOSferatu hat geschrieben:[Trackermusik-Wettbewerb]Andere Leute hätten dann einfach weitergemacht, wären irgendwann immer besser geworden und hätten bei so Wettbewerb vielleicht auch mal bessere Plätze belegt. Der Vergleich mit anderen kann einem zeigen, wo man so steht. Allerdings ist gerade bei Grafik und Musik so eine Einschätzung auch hochgradig subjektiv und hängt stark vom "Publikum" oder dem Geschmack einer eventuellen Jury ab.
Eben. So ein Wettbewerb zeigt nicht unbedingt objektiv wie "gut" man ist, es zeigt nur, wie es bei der Jury ankommt. Ich habe einige sehr beliebte Musikstücke, und wenn ich dann etwas bastle, extra für einen Wettbewerb, was dort dann total abkackt, dann ist meine Schlussfolgerung daraus nicht, dass ich es immer wieder und wieder versuchen muss, nur um endlich in irgendeiner Rangliste zu steigen, während ich mich dabei immer mehr von meiner kreativen Freiheit verabschiede und mich an Erwartungen anpasse. Sondern ich erkenne eben, dass ich lieber einfach weiterhin nur genau das machen sollte worauf ich Bock habe und wofür außerhalb von Wettbewerben sich immer wieder Leute finden die daran auch ihren Spaß haben. Musik ist für mich kein Sport den man leistungsmäßig rational messen und bewerten kann, für manche vielleicht schon - aber solche Musik finde ich dann wiederum meistens langweilig.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ich habe ein gewisses musikalisches Talent - bin aber zu faul ein richtiger Musiker zu werden mit allem drum und dran. Deswegen beschränke ich mich darauf, musikalische Ideen sofort einzutrackern anstatt Instrumente zu erlernen und das ganze darauf zu zelebrieren.
Ach, Musiker sein hat nichts mit Instrumenten zu tun. Instrumente spielen ist nur "Werkzeug". Wenn etwas gut klingt oder es gefällt, ist es doch egal, womit es gemacht ist.
Die klassische Musikerdomäne ist eben die, wo man Instrumente beherrscht und auch auf diesen improvisieren kann. Die Herangehensweise eines typischen Musikers ist auch anders als die meine - bei ersterem geht es oft um Lieder, es steht eine eingängige Melodie und ein guter Text im Vordergrund. Am Computer erzeugte Musik wird vorschnell in die Schublade "kann ja jeder, der Computer macht ja alles" geschoben und von vornherein von manchen missachtet. Wenn jemand auf einem Instrument gut spielen kann wird das höher gewertet, als wenn jemand am Computer kreativ eigene Stücke erfindet. Weil, kann ja nur stumpfsinniger BummBumm-Techno sein bzw. der "User" muss absolut nix können...
Wie auch immer - ich distanziere mich bewusst etwas vom typischen Musiker, weil mein Ansatz doch unterm Strich etwas anders ist, vor allem wohl der Punkt, dass ich von vornherein direkt in die "Dose" produziere, während einige Musiker überhaupt keinen Wert auf ein Endprodukt ihrer Musikstücke legen und ihre Erfüllung eben im (auch gemeinsamen) Musizieren finden. Ich kann das aus eigener Erfahrung nachvollziehen dass das schön sein kann (ich war in nem Chor, kann ein paar simple Instrumente, hab auch mal Klavier gespielt) - aber mich fasziniert einfach am meisten, mit computergestützten Möglichkeiten und Sampling eine Produktion zu basteln die man dann jederzeit genießen und auf sich wirken lassen kann - und die in ausproduzierter Form genau so klingen muss und gar nicht handgespielt auf Instrumenten sein soll.
DOSferatu hat geschrieben:Andererseits kann eine "Beschränkung" (z.B. vom System her) sogar Kreativität befördern.
Technische Kreativität auf jeden Fall. Siehe meine Kompressionsformate. Beim Beispiel Musik bin ich mir nicht so sicher. Die Beschränkungen des X-Trackers haben mich auch eher nur zu technischer Kreativität bewogen, wie ich gewisse Beschränkungen umgehen konnte. Allemal könnte eine zu hohe Funktionalität eines Programms ein wenig zerstreuend sein: Zu viele technische Möglichkeiten mögen kreative Entscheidungen erschweren, oder anfänglich das Gefühl geben, man müsse alles nutzen.
DOSferatu hat geschrieben:Aber ich brauche dafür nicht diese Tracker-Darstellung. Die ist mir zu umständlich. Wenn ich z.B. irgend eine coole "Begleitung" habe, weiß ich, wie die klingen soll, gebe die 1x ein und baue so lange dran rum, bis es so klingt wie es muß. Ich muß es dann aber nicht zigmal irgendwohin "zusammenkopieren", sondern sage einfach: Hier 30x spielen.
Ich hab halt lieber immer alles redundant auf einen Blick, damit ich meine ganze Denkpower für die Musik nutzen kann.


DOSferatu hat geschrieben:Ja, so geht's mir auch:
Früher: Viel Energie, wenig Ahnung.
Heute: Viel Ahnung, wenig Energie.
Anders ausgedrückt: Mit der Energie meines 20-jährigen Ichs, aber der Ahnung von heute könnte ich das DOS-Spiel des Jahrhunderts bauen...
Vor allem noch in der damaligen Zeit: Dann hätte es auch große Verbreitung gefunden.
Kotzman II und Frankus Tetris hat sich sogar damals ein wenig verbreitet, hauptsächlich im Freundeskreis natürlich, aber eben auf echten Systemen. Lustig, Frankus Tetris hat sich sogar im Netz verbreitet (z.B. hier: https://dosgamezone.com/games/f/page8.html - ich hatte es mal bei einer Zeitschrift eingeschickt.
Tja mit der Energie ist das so ne Sache. Hinzu kommt (bei mir jedenfalls): Damals hat man sich auch noch nicht viel Gedanken darüber gemacht, dass das Leben auch mal ein Ende findet. Mit so einer Haltung war es einfacher, große Projekte anzupacken bzw. an eine "große" kreative Zukunft zu denken. Vielleicht sollte man solche Gedanken an die Endlichkeit des Lebens besser mal ausblenden, um produktiver zu werden. Was nützt es wenn man irgendwann stirbt und wegen dem Gedanken "ich wäre ja doch nicht fertig geworden" hat man nie was großes gemacht. Letztlich ist mein wohl größtes damaliges Projekt, der X-Tracker DMF-2-WAV Renderer, auch innerhalb von Wochen und nicht Jahren fertig geworden.
Wenn ich heute etwas programmiere tut sich das unterm Strich mit der Geschwindkeit nicht viel: Ich programmiere überlegter, erfahrener, aber langsamer als früher. Dafür funktionieren Programme öfters direkt fehlerfrei.

Bei Musik sieht es ähnlich aus: Auch hier bin ich langsamer geworden. Mir gelingt es aber besser, das zu kreiren was ich will bzw. habe ich beim Improvisieren Ideen, die mir besser gefallen als was ich früher so hatte. Auch beim Abmischen zahlt sich die Erfahrung aus. In meiner Jugend war ich irgendwie flotter unterwegs, wenn man so will im Tracker etwas "akrobatischer" und "trittsicherer". Das muss aber nicht unbedingt auch bessere Musik bedeuten. Das einzig Blöde ist das mit den Ohren, dass die obere Hörgrenze sinkt je älter man wird. Noch einige Jahre und man könnte für mich 160 Minuten CDs rausbringen mit ner Abtastrate von nur 22050 Hz. Aber da gibt's ja den Spectrum Analyzer der einem verrät, was obenrum noch so passiert. Oder man hört sich alles schonmal auf 22 kHz an zur Kontrolle (so dass alles einen Oktave tiefer ist und halb so schnell läuft).

DOSferatu hat geschrieben:Natürlich wäre so optionaler GUS-Support immer eine gute Idee. Warum man das zu 386er-Zeiten noch nicht so oft gemacht hat, lag wohl daran, daß die anvisierte Zielgruppe sich vielleicht gerade mal den damals schweineteuren 386er leisten konnte und dann selten noch Geld für die damals schweineteure GUS übrig hatte.
Die GUS war wohl, wegen der geringen Verbreitung, auch schlecht zu beziehen, in Deutschland zumindest.

AdLib ist ja eigentlich ein leistungsstarkes Ding: FM Synthese wäre softwaremäßig so wie ich das verstehe gar nicht so ohne. Da muss man ja zwei Wellenformen so multiplizieren , dass die eine die "Samplerate" der anderen bestimmt. Naja, vielleicht doch nicht soo rechenintensiv. Auf jeden Fall kann die AdLib, wenn geschickt programmiert, schon wirklich nette Sounds machen.

DOSferatu hat geschrieben:[Umwelteindrücke irrational wahrnehmen]Alles nur Varianten von "Schon zu versaut von modernen Medien".
Wer Real-Life mäßige Grafik/Sound will, ist eben kein echter "8-Bit-Nerd". Der richtige Computernerd geht vor die Tür (um Pizza reinzuholen) und denkt: Igitt, Real-Life, schnell zurück vor'n Monitor!
Wohl eher vom halbwegs normalen Leben versaut. Ich bin zu wenig Computernerd um das Real-Life zu verabscheuen. Ich habe auch schonmal gedacht, vielleicht wäre es ganz schön, wenn ich ausschliesslich vom Programmieren fasziniert wäre und somit alle meine freie Zeit da reininvestieren würde und richtig tolles zustande bringen würde. Aber dafür bin ich nicht der Typ, ich brauche die Abwechslung. Nur Musik oder Videos machen wäre auf der anderen Seite nämlich auch nichts. Oder nur Lautsprecher bauen. Oder nur Unternehmungen mit Freunden, ohne kreative Hobbys.
DOSferatu hat geschrieben:Ich bin da irgendwie so, daß mich es immer fasziniert, wenn Leute mit wenigen Mitteln (Grafik wie Sound) tolle Dinge erreichen. Ich habe hier z.B. "Loom" (auch Lucas Arts). Das Ding hat nur 16 Farben (320x200) und ich find's wunderschön.
Natürlich, ich dürfte mittlerweile klar gemacht haben dass es nicht 1080p und 5.1 Surround sein muss damit ich Spiel schön finde. So wie es Dir mit Loom ging, ging es mir mit Monkey Island in der EGA Version, aber die VGA Version fand ich noch ein Eckchen schöner.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Im Nachhinein muss ich sagen, dass z.B. CGA auch etwas Besonderes haben kann.
Ja, ich finde auch, daß Farbanzahl nicht die Rolle spielt, sondern was man draus macht.
Ich habe mich in meinen Jugendjahren mehr mit Grafik beschäftigt, einiges mit viel Zeitaufwand handgepixelt, inspiriert von guter 320x200 Grafik. Mich hat auch fasziniert, wie im EGA Mode trotz der Beschränkung auf die festen 16 Farben der Eindruck nach mehr Farben und Farbverläufen enstanden ist, indem z.B. zwischen Grünwerten oder Blauwerten auch Grauwerte verwendet wurden, ohne dass es einem wirklich auffiel.

Was 3D angeht: Ich habe damit generell etwas ein Problem, weil 3D direkt auf ein realistisches Erlebnis abzielt. Während bei Spielen wie Monkey Island II bei der Grafik noch Interpretationsraum gegeben ist, empfinde ich 3D-Grafik als konkretisiert. Und dann hat der ganze technische Aufwand genau das Gegenteil zur Folge als er haben soll: Das Spiel wirkt steril und unwirklich, während man bei guten alten 2D Spielen, weil die Grafik eher nur angedeutet ist, im Hinterkopf alles selber zu einem sehr realen Erlebnis ausschmückt.
Einen ähnlichen Effekt haben die Neuauflagen von z.B. Monkey Island I: Die Grafik ist hochauflösend, keine Pixel mehr zu erkennen, aber alles sieht irgendwie so stilisiert und konkretisiert aus, was wieder das Eintauchen in die Spielwelt für mich erschwert.

Ein Experiment was ich mir vor längerer Zeit schon einmal überlegt habe wäre, eine Art 3D Engine zu bauen, die mit massiven 3D-Pixel Objekten arbeitet. Der Unterschied wäre, dass es keine Polygonkörper mit Skins gäbe, sondern dass alles als 3-dimensional angeordnete Pixel einer gewissen Auflösung definiert ist. Das geht natürlich nur als Experiment und mit meinen Fähigkeiten auf meinem Computer nur in nicht-Echtzeit, als lahmes Ding in Freepascal was dann Einzelbilder ohne Interaktion rausrendert, zumal ich auch gern wenigstens lineare Interpolation verwenden würde - allerdings nur vekleinernd, d.h. eher ein Zusammenrechnen der Pixel auf einen Mittelwert, denn für Z = 0 soll die Hauptauflösung gelten. Das sind eher meine ersten Gedanken zu 3D, die ein etwas anderes Konzept verfolgen, vielleicht ist es lachhaft.

DOSferatu hat geschrieben:
zatzen hat geschrieben:Es ist vielleicht einfach Prägung, aber ich habe 320x2?? immer magischer empfunden als etwas höheres.
Magisch... Naja. Mir war schon immer klar, daß die 320x200 sich eher aus technischen Gründen ergeben hatten und find's praktisch, weil's eben sehr simpel anzusteuern ist.
Magisch, weil die Pixel einerseits klein genug sind, dass sie bei entsprechender Farbwahl verschmelzen können (und die Auflösung einfach reicht), andererseits groß genug, dass man sie noch als Pixel erkennen kann. Ich hatte das glaube ich schonmal irgendwo erwähnt, dass es z.B. auch so einen gläsernen Effekt haben kann wenn man im 320x200 Modus größerflächiges Anti-Aliasing hat. Das ist wieder diese Wahrnehmungs-Sache, verstehst Du vielleicht nicht. In Anti-Aliasing involvierte Pixel empfinde ich oft als durchsichtig. Was daran jetzt toll ist muss wohl jeder für sich selbst klären.
DOSferatu hat geschrieben:Ich habe unter DOS quasi von Anfang an alle meine Grafiken immer in selbstgebauten Tools erstellt.
Ich habe in meinen Anfängen nur wenige "Tools" notdürftig gemacht: Ich wusste nicht wie ich Grafikformate wie PCX in Basic reinladen kann. Also habe ich mir in Basic einfach ein super-simples Malprogramm gemacht, Mauscursor einfach ein flackernder Pixel, Farbwahl irgendwie über +/-, und dann ohne jede geometrischen Hilfen oder Füllfunktionen ein Bild von ca. 200x150 gepixelt. Das ist wieder ein Beispiel dafür dass man Begeisterung und Energie hatte...

DOSferatu hat geschrieben:
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich bin nie davon ausgegangen, daß irgendeins meiner Programme oder Entwicklungen von entscheidender Bedeutung für Dein Spiel/Deine Entwicklungen sind oder sein müßten.
Zumindest aber das von Dir vermittelte Wissen.
Naja, das ist auch nur Kram, den ich entweder irgendwo gelesen oder selbst herausgefnnden habe. Ich schreibe so Zeug immer nur mit dem Gedanken "Bei mir funktioniert's, also muß es ja gehen" hin. Aber nichts von alledem ist "der Weisheit letzter Schluß" - bin auch nur ein Hobby-Krauter.
Bis über die Mitte der 90er kannte ich keinen der sonst noch programmiert. Und über Assembler reden kann man sowieso mit kaum jemandem. Pascal ist ja auch etwas unmodern...

DOSferatu hat geschrieben:Ich habe hier noch etwas gebastelt [...] Zeigt auch mal, was so ein 486er wirklich kann.[...]Übrigens: Mit einem zweistelligen numerischen Parameter 10 bis 44 wird stattdessen die Soundrate in kHz eingestellt - bei höheren Werten macht es natürlich nur Sinn in Kombination mit größeren Puffern (je mehr Framerate, umso größer der Puffer).
Ich habe es mal mit 44 kHz laufen lassen (mit Pufferwert 4), es profitiert durchaus. Nicht super dramatisch, aber es klingt alles feiner aufgelöst und sauberer - wie ein Hardware-Synthesizer. Schön, dass man diese Option bei ISM hat.
DOSferatu hat geschrieben:Anm.: Es gibt auch ein Feature, wo das Hauptprogramm an ISM Daten gibt - also die andere Richtung. Allerdings nützt das ja nur etwas, wenn die Musik in ISM entsprechend "programmiert" ist, d.h. Befehle drin sind, die diese Daten auch abfragen und für irgend etwas benutzen. Das Feature ist z.B. dafür gedacht, daß das Programm einfach nur Daten in einen Puffer schmeißen muß, wenn ISM einen Soundeffekt abspielen soll und der ganze Kram, welcher Effekt gespielt und welche Stimmen dafür benutzt werden, von ISM übernommen werden kann. (Allerdings werde ich da wohl in meinem "Spielschleifen-Container" trotzdem noch ein "Zwischen-Interface" einbauen, das die Stimmenzuteilung übernimmt, damit man da flexibler ist.)
Das ist eine Stärke von ISM - bei ZSM kann ich nur in andere Patterns springen und so vielleicht einen musikalischen "Break" erzeugen, alle anderen Soundeffekte müssen über Samples erledigt werden, was aber auch meine Intention war.

Übrigens muss ich hier gerade dran denken, dass in dem von mir oft genannten Super Mario Bros. auch nur eine überschaubare Anzahl Soundeffekte vorkommen, da könnte ich mir also leisten, diese auch als Samples zu realisieren. Und da denke ich auch daran, dass so ein ausführliches Spiel schon was Level-Design und Grafiken angeht ein ziemlich großes Projekt ist. Meine Schlussfolgerung wäre, dass ich für ein Spiel eine maßgeschneiderte Engine bauen würde, damit komme ich von meinem Gedanken den ich bis vor einiger Zeit hatte, eine Art generelle Spielengine zu bauen, ab.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Sehr lustige Sache, auch mit den Schweinchen.
Naja, ich wollte ein paar Sprites haben[...]
Hast Du für alles Deine Sprite-Routinen genommen? Bis auf die Hintergrund-Kacheln (oder den Text)? Wäre Drehen oder Skalieren mit ungeraden Verhältnissen zu langsam gewesen?
DOSferatu hat geschrieben:Das ist kein VGA, das ist VESA, der VESA-Modus 640x480x256 (Mode $0101).
OK - mit VESA hab ich mich bisher nie beschäftigt, auch weil mir 320x200 als Grafikauflösung immer genügte.
DOSferatu hat geschrieben:Das Scrolling passiert, indem der Bildanfang um 0 bis 31 Pixel verschoben wird.
D.h. alle 32 Frames wird der Hintergrund neu gezeichnet und dazwischen nicht? Würde das nicht zu Hakeln führen?
DOSferatu hat geschrieben:In der Mitte, wo die Musik etwas an "Dramatik" zunimmt, wird das Geheimnis gelüftet und eigentlich dachte ich, das Ganze wäre damit selbsterklärend: Daß das ganze Ding eigentlich schon von Anfang an in 640x480 läuft und scrollt und Sprites anzeigt usw.
Das hatte ich beim Ansehen schon verstanden, nur war es mir ein Rätsel wie ich selbst sowas machen könnte.
DOSferatu hat geschrieben:Wenn ein 486er mit 640x480 schon DAS machen kann, sollte er wohl auch 320x200 schaffen.
Das macht doch Hoffnung. Vielleicht kann ich ja dann doch für gemütliche Spielchen bei der Blockmethode die Hintergründe komprimiert anlegen. *duck und renn weg*
Nein, werde ich sehen. Vielmehr macht es Mut zu Scrolling.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Das kann ZSM nicht.[Portamento]
Ich weiß. Aber ich glaube, der Effekt wird sowieso gar nicht so oft in MODs benutzt.
Kommt immer drauf an, manche nutzen den in großem Ausmaß, andere gar nicht. Aber eben deswegen hab ichs auch nicht unterstützt, und weil es nur gerastert geht, z.b. mit 50 Hz. Dann müsste ich aber alles so fein rastern (statt zeilenweise) und hätte nur Tempi bzw. Zeilenlängen zur Verfügung die sich aus vielfachen von 1/50 Sekunde zusammensetzen.
DOSferatu hat geschrieben:Übrigens: Um mein Portamento so sauber hinzukriegen, wird intern mit 48-Bit-Werten gearbeitet.
Also 48 Bit mit Festkomma für die Tonhöhen? Vielleicht kannst Du mir erzählen, wie es bei Dir mit BPM Tempo im Zusammenhang mit Portamento Effekten aussieht.
DOSferatu hat geschrieben:Ich bin nicht total talentiert, aber ich habe inzwischen, so lange, wie ich schon "Musik" am PC mache, mitbekommen, daß sich die einzelnen Stimmen sowohl im Oktavenbereich als auch in der Lautstärke unterscheiden sollten, damit sie differenzierter klingen und nicht totaler "Soundbrei" werden.
Letztlich geht es technisch darum, das Spektrum gleichmäßig auszufüllen, mit Tendenz dass es nach oben leiser wird, ähnlich Rosa Rauschen (3 dB Abfall pro Oktave).
Wenn sich die Töne frequenzmäßig nicht ins Gehege kommen geht es was Lautstärke angeht vielmehr darum, dass man alles gut zueinander abstimmt und man alles gut raushört, ohne dass etwas banal gesagt zu leise oder zu laut ist.

DOSferratu hat geschrieben:Ich benutze ja (leider) für so Sample-Zeug immer noch dieses uralte VOC386. Das ist zwar an sich eine gute Idee, aber es ist eben von der Bedienung her SOWAS von 1990....
Vielleicht kannst Du Dich ja mit dem "Advanced Digiplayer" aus dem Hause Future Crew anfreunden. Müsste ich noch haben. Beim Googeln hab ich gesehen dass der hier im Forum auch schonmal diskutiert wurde in nem Thread wo Du auch drin bist. Jedenfalls hab ich mit dem Ding viel gearbeitet damals und in den ersten Tracker-Jahren meine Samples bearbeitet. Aufnehmen kann man bis 12288 Hz oder 13000, 8 Bit. Aber ich weiss nicht ob ich das empfehen kann, dazu müsste ich vergleichen was VOC386 so kann und wie ergonomisch es aufgebaut ist.
Ansonsten habe ich eine lange Zeit lang mehrgleisig gearbeitet: Aufnahmen in Windows gemacht, Samples bearbeiten ebenfalls dort, und dort auch nach 8 Bit und niedrigerer Samplerate für den X-Tracker konvertiert, der in früheren Versionen nur in echtem DOS lief und nicht in DosBox.

DOSferatu hat geschrieben:Naja, Du weißt ja: Ich bin kein talentierter Musiker und baue meinen Kram eher nach "mathematischen" Gesichtspunkten zusammen. Manchmal habe ich auch so Ideen. Mitunter mögen die sogar von irgend etwas inspiriert sein, was ich mal irgendwo gehört habe - so funktioniert das ja meistens mit dem Gehirn.
Nunja, man könnte meinen, beim Basslauf direkt von Anfang an könntest Du inspiriert sein von... Eurodance. Ich fand diese Musikrichtung der 90er irgendwie nie so toll, und diese Bassmelodie (z.B. E - E - E - E - C - C - C - C - D - D - D - D - ...) findet sich in fast allen dieser Songs, das scheint schon so ein Standard davon zu sein wie beim Blues das entsprechende Schema. Also das ist vielleicht nicht so super originell (aber fast schon wieder wie ein Running Gag weil es so viele Musik gibt mit genau dem drin) - aber ich finde gut und kreativ was Du an sonstigen Melodien dazugebastelt hast.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ich bin gar nicht so ein Kristallsoundmensch. Es kommt immer drauf an, was es ist.
Im ZSNES (SNES-Emulator) stelle ich Soundausgabe auf 11 kHz oder sogar 8 kHz ein - irgendwie klingen die Musiken da voller und hauen mehr rein - wahrscheinlich, weil der "Baß-Anteil" dann höher ist.
Technisch gesehen wird es natürlich etwas dumpfer (bei 8 kHz Abtastrate kommen nicht mehr Höhen durch als durch ein Telefon) und wenn die Engine bzw. der Emulator nicht filtert gibt es schönen Spiegelfrequenzen-Aliasing-Dreck, der je nachdem ja auch seinen Charme haben kann.


Mode-X Scanline erweitern:
Da fehlt mir etwas der Durchblick. Verstehe ich so ungefähr.
Ich bleib erstmal bei MCGA. Kann man da irgendwas sinnvolles mit Scanline-Manipulation machen?


Ich bin zur Zeit stärker beschäftigt mit Musik mischen, die Antwort zum "Eigenes Videoformat"-Thread kommt auch bald.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

Ich sollte hier wohl endlich mal antworten. Der Post ist von September...
zatzen hat geschrieben: Di 22. Sep 2020, 20:21 Dieses VOC386 würde mich aber mal interessieren zu Begutachtung, falls das Free-/Shareware ist.
Lustigerweise ist es sogar Shareware.
zatzen hat geschrieben:
DOSferatu hat geschrieben:
zatzen hat geschrieben:Deswegen ist für mich DOS attraktiver für etwas das Bild und Ton ausgibt, und dass das momentan hier alles in der Box läuft stört mich erstmal nicht.
Naja, andere Leute sehen das anders - die haben ihre Fertiglösungen/ Libraries/ Frameworks für ihren Kram und können auch unter Windows gleich Bild+Ton machen. Ich bin bloß nicht gern so "Fertiglösung"-Nutzer beim Coden - aber das ist eben eine Einstellungssache.
Für Windows wäre mir das egal. Da muss die Sache nur funktionieren, nicht mal performen, ist mir irgendwie egal was da für'n Dreck bzw. Overhead passiert wenn ich was in Freepascal mache - meistens Tools, und da müssen letztlich einfach die erzeugten Daten stimmen. Eine Library für Tonausgabe, oder auch Bilder einlesen oder darstellen, das wäre mal nett, zumindest wenn ich die Daten über Arrays fliessen lassen kann.
Naja, Arrays sind ja auch nur ein Programmkonstrukt. Solange man Pointer auf irgend einen Speicherbereich zeigen lassen kann, kann man das lesen wie man will. Und naja, meine Units (=Libraries) können ja sowas. Ich habe z.B. eine hier, die das Einlesen/Schreiben von Bildern in PCX oder BMP automatisiert (und zusätzlich noch in 2 eigenen Formaten). Die erweitere ich ständig. Ich wollte da immer mal GIF mitnehmen. GIF lesen habe ich schon in einem anderen Programm gemacht - aber das automatisiert in dieser Unit wäre auch nicht schlecht. Wenn ich die in meine neueren Programme eincompiliere, können die auch automatisch alles lesen/schreiben, was die Unit kann. Die Menüs müssen es nur hergeben.
zatzen hat geschrieben:Ich versteh nix von Programmierung mit Klassen und sowas, und wenn ich Daten nicht in ein eigenes Datenfeld einlesen kann bringt mir das nichts.
Naja, OOP ist auch nicht so meins. Aber Arrays sind nichts, was ich zwingend brauche. Da ich ja diese Speicherverwaltung habe, brauche ich nur einen Pointer, der sagt, wo die Daten anfangen (und einen anderen Wert für die Größe).
zatzen hat geschrieben:OOP mit Freepascal wäre vielleicht mal einen Blick über den Tellerrand wert, es scheint für Windows-GUIs eine gute Lösung zu sein - wenn man sowas braucht. Angeblich soll man dabei generell ja auch effizienter programmieren können - falls ich irgendwann dahin komme: Für Windows Tools wo ich Dinge wie Assembler sowieso nicht einsetze wäre es vielleicht ne Option.
Naja, "effizienter"... Kommt darauf an. OOP empfinde ich als sehr umständlichen Code. Man braucht länger, bis man da mal sieht, daß etwas passiert. Und Effizienz hängt dann vom Compiler ab. Die CPU führt Code ja weiterhin linear aus, die kennt kein OOP. Also muß jedes "Konstrukt", das sich irgendein Hochsprachen-Mensch ausdenkt, wieder so umgebaut werden, daß eine CPU etwas damit anfangen kann. Und linearer Code ist eben am nächsten an der CPU. Bisher habe ich OOP noch nie vermißt und konnte bisher alles, was ich wollte ohne OOP coden.
zatzen hat geschrieben:Allerdings wäre es schon etwas komisch, wenn der Code nur aus Definitionen besteht und man nicht wirklich nachvollziehen kann was unter der Haube passiert.
Naja, OOP und andere Sachen sind ja gerade dazu gedacht, daß man das nicht weiß/wissen soll. Es abstrahiert Code vom System - verbessert die Portierbarkeit. Aber Portierbarkeit interessiert mich nicht - mein Zeug soll sowieso nur auf x86/DOS laufen. In meinem Fall würden diese zusätzlichen Dinge nur Speicher und Rechenzeit kosten.
zatzen hat geschrieben:[...]Mir wird an dieser Stelle mal klar, dass ich eigentlich bisher nie versucht habe, auch nur in die Nähe von schnellen "Arcades" zu kommen. In meinen Basic-Zeiten war alles durch Basic selbst und meine Unfähigkeit limitert, dann kam Pascal und Assembler, aber damit ist noch kein richtiges Spiel fertig geworden.
Naja, erinnert auch an mich - ich nenne mich "Imperial Games" - aber so richtig "Game"-mäßiges, auf das man stolz sein könnte, ist von mir auch noch nicht gekommen.
zatzen hat geschrieben:Ich denke, dass ich auch demnächst nicht versuchen werde, einen schnellen 2D Platformer wie Super Mario Bros. zu erreichen, sondern es wird was gemütliches, das, wie eh und je, unterhalb dessen bleibt, was der Computer zu leisten vermag. Ich bin geprägt von Adventures und Rätselspielen, und würde so eine gemütliche Art von Spiel selbst machen, vielleicht ein Jump&Run, aber eher ohne Scrolling - die Handlung kann innerhalb eines Screens vollendet werden, und dadurch muss dann auch alles etwas kompakter gehalten werden, was wiederum das Pixeln der Grafik erleichtern kann.
Ja, wie schon mehrmals erwähnt: So technische Dinge sind für mich zweitrangig. Wenn ein Spiel Spaß macht, ist es egal, wie es gemacht ist. Und Fixed-Screen-Spiele können auch Spaß machen: PacMan, BubbleBobble und vieles andere auf alten Konsolen oder C64 war auch Fixed-Screen.
zatzen hat geschrieben:Also, so könnte es aussehen: So, wie Kotzman II lächerlicherweise erst auf einem 486 optimal performte (d.h... Die Geschwindigkeit wurde durch eine Schleife gebremst, und wenn mehr Figuren dazukamen wurde alles langsamer, und je langsamer der Rechner, desto stärker war dieser Effekt), obwohl soetwas in der Art auf einem 286 möglich ist, wäre es mir jetzt nicht zuwider, auf einem 486er ein ansprechenderes Spiel zu machen, das vielleicht findige Coder auch auf nem langsamen 386er hinkriegen würden. Ich sagte sowas schonmal. Der Unterschied ist jetzt nur, dass ich gar nichts anderes als etwas gemütliches realisieren will, egal wieviel Leistung ich zur Verfügung habe. Und dann statte ich das Ding gerne mit Prozessorlasten wie ZSM aus.
Ja, aber wie ich immer wieder erwähne: Wenn man das Spiel-Timing unabhängig von der Soundkarte macht und auch nicht mit Timer-Schleifen, dann bleibt mehr Performance übrig, die man z.B. für höhere Frameraten beim Sound benutzen kann. Aber ich denke mal, über Timerschleifen bist Du inzwischen hinweg.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[Ewige lange Sounds in Duke Nukem 3D einbauen]Dir ist aber schon klar, daß Duke Nukem 3D (genau wie Doom, Quake usw.) 32-Bit Spiele sind, die also auch quasi in einem Flat-4G Mode laufen, oder?
Ja schon, es war nur einfach so dass damals, so um 1998, das mit Stand der Technik war und dann habe ich etwas in diesen Dimensionen gedacht, hatte natürlich keine Kenntnis wie man in diesem 32 Bit Mode programmiert, aber ich hatte ein paar MB XMS und hab dann eben für meine billigen eigenen Spieletest aus den Vollen geschöpft. Pentium eben.
Ja, ich wollte es nur erwähnt haben. Daß bei Duke&Co so viel Speicher frei war (z.B. für Sounds usw) lag daran, daß das Ding im Flatmode läuft und dadurch natürlich alles bis Anschlag direkt ansprechbar ist, auch über der 1MB-Grenze.

[SB-Features]
Ja, ADPCM, das war das, was ich meinte, diese gepackten Sounds. Das kann SB, aber die Clones nicht. Deshalb wurde das auch quasi nie in Games benutzt, was zwar schade ist, aber man kann die Spielefirmen verstehen: Wenn man Zeug auf bestimmte Hardware beschränkt, verringert das potentielle Kundschaft.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Es gibt verschiedene Arten, das zu machen. 160x200x16 geht ja auch mit Textmode (siehe mein Posting im anderen Thread). In Fall dieses Tools ist es echter 160x200x256.
Der war einer der wenigen Modi die Dosbox nicht auf 4:3 "gezogen" hat, sondern es war 2:3
Ja, weil das nicht "Chained" gemacht war, sondern mit halbiertem Pixeltakt UND Pixelverdopplung. Manches, was "zu crazy" ist, stellt DOSbox nicht 100% so dar wie auf 'nem echten CRT an VGA. DOSbox ist ja zum Abspielen alter Games - und SO tweaked Modi hat man kaum für Spiele benutzt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[Zatzens Ästhetik-Problem mit Sprite-Skalierung]Und man sieht wieder: Zu versaut von aktuellem Multimedia. Man fragt sich, wieso so jemand eigentlich 320x200x256 Spiele machen will.
Nee! Mich haben wenn überhaupt die vielen tollen in 320x200 gehaltenen Spiele versaut (ob 4, 16 oder 256 Farben) bei denen jeder Pixel übelegt gesetzt war und ein Sprite nicht durch Echtzeit-Skalierung/Drehung fusselig oder pixelig-schrumpelig wurde. In manchen Spielen stört das nicht und es ist toll wenn sich ein Sprite quasi stufenlos dreht, aber es gibt eben viele Spiele wo wie gesagt jeder Pixel genau da sitzen muss wo er ist. Meinetwegen geht das bei Monkey Island I noch, weil es besser ist roh runterzuskalieren als wenn Scheinriesen entstehen, logisch. Vielleicht können wir uns drauf einigen dass es Geschmackssache ist.
Naja, man hätte für jede Verkleinerungsstufe noch eigene Sprites pixeln können - aber man muß dabei berücksichtigen, für welche Kisten das damals programmiert wurde: Das mußte auf ein paar Disketten passen und in den Heap.
zatzen hat geschrieben:320x200 ist aus mehreren Gründen meine liebste Auflösung und ich will dafür Spiele machen, aber mit konsistenten Pixeln. Aktuelles Multimedia brauche ich nur für Dinge außerhalb von Spielen. Und weil ein Computer heute HD Video und Studioqualität-Ton kann, erübrigt sich das Staunen über technische Eckdaten. So haben dann Spiele wie Alley Cat (CGA, PC Speaker) immer noch bzw. wieder ihren nostalgischen Charme.
Klar. Wie ich ja schon unzählige Male erwähnte: Leuten wie mir, denen es um das Spiel an sich geht, kann ein Spiel auch gefallen / Freude machen, wenn da nicht Grafik-/Sound-Auflösungen an irgendwelche Obergrenzen stoßen.
zatzen hat geschrieben:Die klassische Musikerdomäne ist eben die, wo man Instrumente beherrscht und auch auf diesen improvisieren kann. Die Herangehensweise eines typischen Musikers ist auch anders als die meine - bei ersterem geht es oft um Lieder, es steht eine eingängige Melodie und ein guter Text im Vordergrund. Am Computer erzeugte Musik wird vorschnell in die Schublade "kann ja jeder, der Computer macht ja alles" geschoben und von vornherein von manchen missachtet.
Naja, das sind Leute, die es noch nicht selbst gemacht haben. Ich meine, klar: Irgendein Lied hochpitchen und hämmernden Masterbass drunterlegen (so wie vieles Zeug mal eben billig in den 1990ern gemacht wurde), ist natürlich keine Kunst. da sind wir uns wohl einig.

Aber es gibt auch richtige Künstler, die mit elektronischen Mitteln Großartiges leisten können. Und auch die klassischen Komponisten haben ja ihre Musik auf Notenblätter geschrieben - was nicht zwangsläufig bedeutet, daß sie alle Instrumente, die eine solche Sinfonie braucht, auch selber spielen konnten. Und wenn man als "Notenblatt" heute numerische Daten in einem Computerspeicher benutzt, ändert das zwar das Medium, aber nicht das grundsätzliche kompositorische Talent, das man braucht, um sich Musik auszudenken.
zatzen hat geschrieben:Wenn jemand auf einem Instrument gut spielen kann wird das höher gewertet, als wenn jemand am Computer kreativ eigene Stücke erfindet. Weil, kann ja nur stumpfsinniger BummBumm-Techno sein bzw. der "User" muss absolut nix können...
Naja, elektronische Musik gibt es schon länger als den stumpfsinnigen BummBumm-Techno und auch während und nach der Stumpf-Techno-Zeit gab und gibt es Musiker, die mit Elektronik etwas mehr können als nur Primitiv-Kram.
zatzen hat geschrieben:Wie auch immer - ich distanziere mich bewusst etwas vom typischen Musiker, weil mein Ansatz doch unterm Strich etwas anders ist, vor allem wohl der Punkt, dass ich von vornherein direkt in die "Dose" produziere, während einige Musiker überhaupt keinen Wert auf ein Endprodukt ihrer Musikstücke legen und ihre Erfüllung eben im (auch gemeinsamen) Musizieren finden.
Naja, so "Jam-Sessions" sind ein komplett anderer Ansatz. Daß man aber Musik auch "erhält", um sie wiederverwendbar zu machen, ist ja nichts Schlechtes - und z.B. für Spiele unabdingbar. Das komponiert sich ja nicht "live" mit, während man spielt.
zatzen hat geschrieben:Ich kann das aus eigener Erfahrung nachvollziehen dass das schön sein kann (ich war in nem Chor, kann ein paar simple Instrumente, hab auch mal Klavier gespielt) - aber mich fasziniert einfach am meisten, mit computergestützten Möglichkeiten und Sampling eine Produktion zu basteln die man dann jederzeit genießen und auf sich wirken lassen kann - und die in ausproduzierter Form genau so klingen muss und gar nicht handgespielt auf Instrumenten sein soll.
Klar - Computermusik kann ruhig auch für sich selbst stehen. Es ist nicht nötig, reale Klänge zu imitieren. ISM ist ja ein Beispiel dafür: Man kann's auch ohne Samples nutzen und komplett auf elektronische Klangsynthese setzen. Und der SID vom C64 bietet ja Ähnliches (nur besser) - und was Leute aus dem SID schon rausgeholt haben, nötigt vielen Leuten - auch denen, die von Musik und Sound keine Ahnung haben - auch heute noch Respekt ab. Zu Recht!
zatzen hat geschrieben:
DOSferatu hat geschrieben:Andererseits kann eine "Beschränkung" (z.B. vom System her) sogar Kreativität befördern.
Technische Kreativität auf jeden Fall. Siehe meine Kompressionsformate. Beim Beispiel Musik bin ich mir nicht so sicher. Die Beschränkungen des X-Trackers haben mich auch eher nur zu technischer Kreativität bewogen, wie ich gewisse Beschränkungen umgehen konnte. Allemal könnte eine zu hohe Funktionalität eines Programms ein wenig zerstreuend sein: Zu viele technische Möglichkeiten mögen kreative Entscheidungen erschweren, oder anfänglich das Gefühl geben, man müsse alles nutzen.
Ja, da gibt's dann Leute, die das übertreiben - und dann ist es nicht mehr gut. Das ist so wie wenn ein Laie einen Flyer für irgend eine Veranstaltung mit einem DTP-Programm layouten soll. Der benutzt dann 20 Schriftarten, 5 Schriftschnitte und 1000 Farben und das sieht einfach GAR NICHT aus...
zatzen hat geschrieben:Vor allem noch in der damaligen Zeit: Dann hätte es auch große Verbreitung gefunden.
Kotzman II und Frankus Tetris hat sich sogar damals ein wenig verbreitet, hauptsächlich im Freundeskreis natürlich, aber eben auf echten Systemen. Lustig, Frankus Tetris hat sich sogar im Netz verbreitet (z.B. hier: https://dosgamezone.com/games/f/page8.html - ich hatte es mal bei einer Zeitschrift eingeschickt.
Naja, mein C64-Spiel "Rockus" hat es auch ins Netz geschafft (an mehreren Stellen) - und eine Crackergruppe hat es sogar Wert gefunden, ein so Crackerdemo davorzusetzen.

Xpyderz war im Freundeskreis sehr beliebt - aber es ist eben ein unfertiges Spiel, bisher nur mit Zufallsgenerator-erstellten Levels. Aber das Ding enthält eigentlich einen eingebauten Level-Editor, der nur auskommentiert ist. Ich überlege immer mal wieder, ob ich die Version MIT Editor veröffentlichen sollte. Andererseits überlege ich, mal eine zweite, richtige Version davon zu machen - mit vernünftigem Code (habe ja inzwischen viele Engines hier) und mit eingebauten Levels und Musik/SoundFX. Eigentlich war's ja auch mal als Multiplayer gedacht; ich habe's nur bisher nicht hingekriegt, daß das vernünftig funktioniert.

Ein Tetris habe ich auch mal gemacht. Relativ einfach gemacht, aber es tut, was es soll.
zatzen hat geschrieben:Tja mit der Energie ist das so ne Sache. Hinzu kommt (bei mir jedenfalls): Damals hat man sich auch noch nicht viel Gedanken darüber gemacht, dass das Leben auch mal ein Ende findet. Mit so einer Haltung war es einfacher, große Projekte anzupacken bzw. an eine "große" kreative Zukunft zu denken.
So ist es. Heute denkt man: Wenn ich 5 Jahre für das Projekt brauche, bin ich XX Jahre, wenn es fertig ist. Hinzu kommt, daß die Computerwelt sich (im Gegensatz zu früher) dermaßen schnell ändert, daß ein Computer/Pad/wasweißich, das am Jahresanfang noch total angesagt war, am Jahresende schon veraltet ist. Und das System unter/für das ich hier code (DOS), ist vielen Leuten heutzutage nicht einmal mehr namentlich bekannt. Und die heutige "bloß nichts lernen oder selber nachdenken"-Generation schätze ich auch als viel zu blöde ein, sowas wie DOSbox zu installieren und konfigurieren.
zatzen hat geschrieben: Letztlich ist mein wohl größtes damaliges Projekt, der X-Tracker DMF-2-WAV Renderer, auch innerhalb von Wochen und nicht Jahren fertig geworden.
Wenn ich heute etwas programmiere tut sich das unterm Strich mit der Geschwindkeit nicht viel: Ich programmiere überlegter, erfahrener, aber langsamer als früher. Dafür funktionieren Programme öfters direkt fehlerfrei.
Ja, so geht's mir auch. Das Problem dabei ist: Ein TOOL wird dabei vielleicht noch irgendwann einmal fertig. Aber ein SPIEL an sich braucht ja schon TOOLS und Engines und Planung und... - naja, jedenfalls bin ich (wenn ich überhaupt mal etwas an meinem Spiele-Zeug mache) nur noch am Planen und Tools/Engines bauen/verbessern usw., daß ich zum eigentlichen Spiel gar nicht komme. Ich hatte das ja schon vor ein paar Jahren mal erwähnt: Xpyderz hatte ich mehr oder weniger gleich auf die blanke Maschine gehackt. Dadurch hatte ich schon in kürzerer Zeit etwas Spielbares fertig - aber jede Änderung oder immer, wenn ich etwas hinzufügen wollte, mußte ich Code umsortieren und auslagern (in Units) und teilweise ist da doppelter, umständlicher, ineffizienter Code drin oder Code, der "um anderen Code herum" (Zwiebel) gebaut ist... quasi alles, was man eigentlich NICHT machen soll, wenn man ein vernünftiges Programm schreiben will.
Das führt u.a. auch dazu, daß ich heute keine Lust mehr hätte, jemals wieder diesen fragilen Code anzufassen - aber leider eben auch dazu, daß ich inzwischen in die gegenteilige Falle gerannt bin: Damit ich nicht so unwartbaren und ineffizienten Spaghetticode habe, plane ich die ganze Zeit, baue an meinen Engines und Engine-zu-Engine (bzw Engine-zu-Hauptprogramm) Interfaces herum, damit das alles ordentlich ist und Sinn ergibt - um eben nicht wieder Zeug zu bauen, bei dem ich, schon bevor es fertig ist, anfange, meinen eigenen Code zu workarounden. Allerdings kostet das Zeit und Mühe - und inzwischen fürchte ich: Mehr Zeit und Mühe, als es das Ergebnis wert ist.
zatzen hat geschrieben:Bei Musik sieht es ähnlich aus: Auch hier bin ich langsamer geworden. Mir gelingt es aber besser, das zu kreiren was ich will bzw. habe ich beim Improvisieren Ideen, die mir besser gefallen als was ich früher so hatte. Auch beim Abmischen zahlt sich die Erfahrung aus.
Ja, Erfahrung ist natürlich in JEDEM Bereich (Coden, Grafik, Musik, Steuerung) ein unschätzbarer Vorteil. Man kann die Dinge, die man wirklich will, besser und schneller hinbekommen, weil das, was man dazu braucht, DAMIT man es hinbekommt, mehr und mehr zum "Handwerkszeug" wird, das einem leicht von der Hand geht.
zatzen hat geschrieben:In meiner Jugend war ich irgendwie flotter unterwegs, wenn man so will im Tracker etwas "akrobatischer" und "trittsicherer". Das muss aber nicht unbedingt auch bessere Musik bedeuten. Das einzig Blöde ist das mit den Ohren, dass die obere Hörgrenze sinkt je älter man wird. Noch einige Jahre und man könnte für mich 160 Minuten CDs rausbringen mit ner Abtastrate von nur 22050 Hz.
Ach, damit hätte ich nicht mal "damals" ein Problem gehabt. Aber gerade bei Dingen mit künstlerischem Anspruch/Teil, wie Musik oder Grafik, ist die Bewertung auch eher subjektiv - und das nicht nur von ANDEREN, sondern auch von einem SELBST: Was man als 20-jähriger noch total OK und "cool" gefunden hat, findet man heute als "älterer Herr" vielleicht eher albern und würde es nicht mehr so machen. Ich selbst VERSUCHE zwar, mir immer noch meinen etwas albernen Humor zu bewahren - weil mein geplantes Jump'n'run vor allem lustig sein soll - aber da mache ich mir mittlerweile auch schon Notizen in 'nem File, wenn mir mal zwischendurch etwas Lustiges einfällt - denn so spontan bin ich nicht gerade, daß mir immer im passenden Moment, wenn ich's brauche, auch ein passender Gag einfällt... Naja, ich bin eben ein Nerd. Wer so mathematisch denkt, und teilweise selbst Probleme hat, den Humor/Witze anderer Leute zu verstehen, tut sich auch schwer, selbst lustig zu sein. Es mag auch daran liegen, daß einem die Begeisterung für das ganze Leben etwas abhanden kommt, wenn das DOS-Zeug, das man so baut, nirgends mehr nativ läuft und dafür 95% der Leute dieses lächerliche Windows benutzen und ernstnehmen.
zatzen hat geschrieben:Aber da gibt's ja den Spectrum Analyzer der einem verrät, was obenrum noch so passiert. Oder man hört sich alles schonmal auf 22 kHz an zur Kontrolle (so dass alles einen Oktave tiefer ist und halb so schnell läuft).
Naja, da sowohl Grafik als auch Musik Geschmackssache sind und nicht nur nach rein mathematischen Gesichtspunkten bewertet werden können (bzw sollten), ist das natürlich etwas "creepy". Mit einem Spektrum Analyzer herausfinden, ob etwas gut klingt (weil man es selbst nicht [mehr] hört), ist so, wie wenn ein Farbenblinder ein buntes Bild malen soll. Keine Ahnung, ob das der Weg wäre, gute Musik zu machen. Ich selbst bin ja musikmäßig der totale Laie, was man auch an den Stücken merkt, die ich so fabriziere - aber bin noch nie auf die Idee gekommen, solche Geräte dazu einzusetzen, um zu entscheiden, ob es gut klingt.

[GUS]
zatzen hat geschrieben:Die GUS war wohl, wegen der geringen Verbreitung, auch schlecht zu beziehen, in Deutschland zumindest.
Keine Ahnung - meinen ersten eigenen DOS-Computer hatte ich Ende 1996. Da war das für andere Leute wohl schon lange kein Thema mehr. Windows macht ja sowieso alles mit Treibern: Da konnte man auch die hundsmiserabelste NoName-Grafik-/Soundkarte drin haben, solange es einen Treiber dazu gab, kam irgendwas heraus. (Daß Treiber natürlich Zugriffe und damit die allgemeine Programmausführung verlangsamen, war Windows-Usern ja schon immer scheißegal. Windows-User sagen ja nur: "Der Computer ist zu langsam" und nie "die Software ist zu schlecht programmiert" - obwohl letzteres in Wahrheit eigentlich viel öfter zutrifft.)
zatzen hat geschrieben:AdLib ist ja eigentlich ein leistungsstarkes Ding: FM Synthese wäre softwaremäßig so wie ich das verstehe gar nicht so ohne. Da muss man ja zwei Wellenformen so multiplizieren , dass die eine die "Samplerate" der anderen bestimmt.
Ja, so funktioniert das wohl. Solange ich da bei max. 8bit wäre, würde ich dafür in Software wohl Tabellen benutzen. Und ja, natürlich wird da multipliziert. Aber wenn man einen Chip baut, der genau für einen dedizierten Zweck erschaffen wurde (wie z.B. diese OPLs von AdLib), dann optimiert man's natürlich für diesen Zweck.
zatzen hat geschrieben: Naja, vielleicht doch nicht soo rechenintensiv. Auf jeden Fall kann die AdLib, wenn geschickt programmiert, schon wirklich nette Sounds machen.
Ich weiß. Dazu muß man aber Ahnung von Sound haben. ICH wüßte nicht vorher, wie sich das anhört, wenn ich da irgendwelche Werte setze, d.h. ich müßte so lange herumprobieren, bis es so klingt wie ich will. Bei Farben dagegen weiß ich inzwischen ungefähr, welche Rot/Grün/Blau Werte ich setzen muß, damit es die Farbe ergibt, die ich haben will. Ich baue (oder berechne) meine Paletten immer selbst.
zatzen hat geschrieben:Wohl eher vom halbwegs normalen Leben versaut. Ich bin zu wenig Computernerd um das Real-Life zu verabscheuen.
Ach, was ist schon "normal"?
Aber ich finde, bei einem Spiel geht es um das Spiel-Erlebnis, d.h. wie viel Spaß und Begeisterung es bringt und nicht darum, wie möglichst ähnlich es dem echten Leben ist. Lebensechtheit spielt bei der Bewertung, ob ich ein Spiel mag oder nicht, für mich überhaupt keine Rolle.
zatzen hat geschrieben: Ich habe auch schonmal gedacht, vielleicht wäre es ganz schön, wenn ich ausschliesslich vom Programmieren fasziniert wäre und somit alle meine freie Zeit da reininvestieren würde und richtig tolles zustande bringen würde.
Ich auch. Und früher war's auch so. Ich würd's eigentlich immer noch gerne so haben. Ich bin nur oft so unverständlich müde - und das schadet der Konzentration. Und ohne daß ich mich auf etwas richtig konzentrieren/fokussieren kann, kommt nichts wirklich Gescheites heraus.
zatzen hat geschrieben: Aber dafür bin ich nicht der Typ, ich brauche die Abwechslung. Nur Musik oder Videos machen wäre auf der anderen Seite nämlich auch nichts. Oder nur Lautsprecher bauen. Oder nur Unternehmungen mit Freunden, ohne kreative Hobbys.
Unternehmungen mit Freunden... Hm. Dazu müßte ich erst mal welche haben. Ich habe quasi 3 Kumpels. Der eine wohnt 300 km, der andere 800 km und der dritte 1000 km weit weg...
Abwechslung - ja, ich gucke eben gern Filme und Serien, das ist die einzige Abwechslung. Die größte "Abwechslung" in meinem Leben ist mein Job: Und selbst da sitze ich vor einem Computer.

[CGA]
zatzen hat geschrieben:Ich habe mich in meinen Jugendjahren mehr mit Grafik beschäftigt, einiges mit viel Zeitaufwand handgepixelt, inspiriert von guter 320x200 Grafik. Mich hat auch fasziniert, wie im EGA Mode trotz der Beschränkung auf die festen 16 Farben der Eindruck nach mehr Farben und Farbverläufen enstanden ist, indem z.B. zwischen Grünwerten oder Blauwerten auch Grauwerte verwendet wurden, ohne dass es einem wirklich auffiel.
Ja, das unterscheidet eben wirkliche Künstler von Laien, die einfach nur irgendwas bunt hinklecksen. Und man erkennt auch gut, ob jemand wirklich selbst richtige Grafik macht oder einfach nur irgendwelche "Füll/Raster/Farbverlauf" Features und feste geometrische Formen seines Lieblings-Malprogramms benutzt hat. Letzters wirkt immer eher laienhaft und steril, da kann man machen, was man will...
zatzen hat geschrieben: [3D-Grafik] Das Spiel wirkt steril und unwirklich, während man bei guten alten 2D Spielen, weil die Grafik eher nur angedeutet ist, im Hinterkopf alles selber zu einem sehr realen Erlebnis ausschmückt.
Ja, es gibt nur immer weniger Leute, die das verstehen. Den Leuten geht Phantasie (und damit Kreativität) immer mehr abhanden, weil sie ihre eigene Vorstellungskraft immer mehr einschränken - indem sie nur alles vorgekaut kriegen, ohne Chance zu haben, selbst nachzudenken, "was sein KÖNNTE". Das betrifft nicht nur Computer und Computerspiele, sondern inzwischen quasi jeden Lebensbereich. Deshalb werden Leute auch immer schlechter im Improvisieren usw.
zatzen hat geschrieben:Einen ähnlichen Effekt haben die Neuauflagen von z.B. Monkey Island I: [...]
Hab das neue Monkey Island noch nicht gesehen - aber andere ähnliche Sachen. Und ich weiß, was Du meinst.
zatzen hat geschrieben:Ein Experiment was ich mir vor längerer Zeit schon einmal überlegt habe wäre, eine Art 3D Engine zu bauen, die mit massiven 3D-Pixel Objekten arbeitet. Der Unterschied wäre, dass es keine Polygonkörper mit Skins gäbe, sondern dass alles als 3-dimensional angeordnete Pixel einer gewissen Auflösung definiert ist.
Gibt es schon - nennt sich Voxel. (Kunstwort aus "Volume Pixel" - wobei ja Pixel selbst schon ein Kunstwort ist.) Ein Pixel wird dabei nicht wie eine zweidimensionale Fläche (1x1) wahrgenommen, sondern wie ein dreidimensionaler Würfel (1x1x1). Eine gröbere Variante dieser Idee wurde ja im bekannten "Minecraft" umgesetzt. Der große Nachteil von Voxelgrafik ist, daß sie meist abartig viel Speicher benötigt - oder eine intelligende Engine, die das verhindert, die dann dafür aber abartig viel Rechenzeit benötigt.
zatzen hat geschrieben:Das geht natürlich nur als Experiment und mit meinen Fähigkeiten auf meinem Computer nur in nicht-Echtzeit, als lahmes Ding in Freepascal was dann Einzelbilder ohne Interaktion rausrendert, zumal ich auch gern wenigstens lineare Interpolation verwenden würde - allerdings nur vekleinernd, d.h. eher ein Zusammenrechnen der Pixel auf einen Mittelwert, denn für Z = 0 soll die Hauptauflösung gelten. Das sind eher meine ersten Gedanken zu 3D, die ein etwas anderes Konzept verfolgen, vielleicht ist es lachhaft.
Wie gesagt: Gibt's schon.
Ich selbst habe das auch mal vor etlichen Jahren als Idee durchgesponnen. Das sollte eigentlich nur dazu dienen, Sprites zu rendern. Habe dann so gedacht: Ein 64x64x64 Voxelwürfel für so kleine/mittelgroße Sprites sollte ja machbar sein. Ist er auch. Braucht 256kByte, wenn jeder Einzelwürfel nur ein Byte braucht. Wenn er z.B. 3 Bytes braucht (Truecolor, 24bit Farben), sind es 768kByte oder 0,75 MB... - ja, alles machbar, aber war mir dann letztendlich wohl den Aufwand nicht wert.
zatzen hat geschrieben:[320x200]
Magisch, weil die Pixel einerseits klein genug sind, dass sie bei entsprechender Farbwahl verschmelzen können (und die Auflösung einfach reicht), andererseits groß genug, dass man sie noch als Pixel erkennen kann. Ich hatte das glaube ich schonmal irgendwo erwähnt, dass es z.B. auch so einen gläsernen Effekt haben kann wenn man im 320x200 Modus größerflächiges Anti-Aliasing hat. Das ist wieder diese Wahrnehmungs-Sache, verstehst Du vielleicht nicht.
Klar verstehe ich das. Es ergibt sich automatisch so ein Milchglas-Effekt. Natürlich nur, wenn man entweder 15/16/24bit Farben benutzt ODER die Farbpalette so gebaut ist, daß sich die Mischfarben zumindest größtenteils auch ergeben können. Bei falsch gewählter/gebauter Palette hat man nur grobe "Ringe", "Bögen" und "Kringel", die sich als klar abgegrenzte Einzelfarben um die "Anti-Alias"-ten Pixel winden und das sieht nicht gut aus. Geeignete 256-Farb-Paletten zu bauen, die für ein Spiel/Tool oder mehrere Grafiken gleichzeitig benutzbar sind und dabei immer noch gut aussehen, ist auch schon eine "Wissenschaft für sich". Ich beschäftige mich mit so etwas in letzter Zeit ziemlich oft.

Die 256er-Palette (eigentlich nur 248, die letzten 8 werden nie gesetzt, sind beim ersten Aufruf schwarz) die VGA einem da vorgibt, ist relativ unbrauchbar: Über die Hälfte der Farben sind eine dunklere Version der davorliegenden - aber dermaßen dunkel, daß man sie kaum benutzen kann. Und dazwischen (d.h. zwischen bunt/leuchtend hell und schmutzig dunkel) gibt es keine Farben - und gerade die wären so wichtig. Außerdem ist die Palette natürlich viel zu generalisiert (weil eher "berechnet"): Wer braucht in einem Spiel schon dermaßen viele Abstufungen von pink? Andererseits gibt es zu wenige wirklich brauchbare Grüntöne (für Landschaft) oder Hauttöne (für Figuren).

Die VGA-Version von Monkey Island geht da einen interessanten Weg: Ein Teil der Palette (für Figuren, Schrift und Menü-Gegenstände) bleibt gleich und ein anderer Teil wird immer ausgetauscht für das entsprechende Hintergrundbild. Für ein Adventure ist das eine klasse Idee - für ein scrollendes Jump'n'run oder Shoot'em'up dagegen natürlich nur sehr bedingt brauchbar.

Ich find's aber interessant, daß man sich darüber ÜBERHAUPT Gedanken gemacht hat. Man kann natürlich auch einfach häßliche 6-7-6 oder 8-8-4 oder ähnliche Paletten benutzen - aber damit schränkt man sich eben ein, weil man manche der Farben daraus überhaupt nicht benutzen würde und bei anderen wiederum nicht genug hätte, um einen Grün- oder Hautton feiner abzustufen. Und wenn man nur 256 Farben hat, sollte man diese nicht durch irgendwelche "Generalisierungen" verschwenden und die ohnehin schon begrenzte Menge Farben mit unbrauchbaren Farbtönen noch weiter einschränken. Und Dithering - ja, das kann eine gute Idee ein, sieht aber nur dann noch OK aus, wenn die am Dither beteiligten Farben sich ähnlich genug sind, daß dadurch der neue gewünschte Farbeindruck entsteht - und es NICHT als ein häßliches Pixelgitter wahrgenommen wird. "Manuelles" Dithering führt leider meist zu letzterem, weil es eben wirklich schwierig ist. Deshalb gibt's ja Programme, die das machen. Allerdings muß man denen auch die Chance geben, es gut machen zu können - indem die Palette nicht schon von vornherein Mist ist.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ich habe unter DOS quasi von Anfang an alle meine Grafiken immer in selbstgebauten Tools erstellt.
Ich habe in meinen Anfängen nur wenige "Tools" notdürftig gemacht: Ich wusste nicht wie ich Grafikformate wie PCX in Basic reinladen kann. Also habe ich mir in Basic einfach ein super-simples Malprogramm gemacht, Mauscursor einfach ein flackernder Pixel, Farbwahl irgendwie über +/-, und dann ohne jede geometrischen Hilfen oder Füllfunktionen ein Bild von ca. 200x150 gepixelt. Das ist wieder ein Beispiel dafür dass man Begeisterung und Energie hatte...
Kenn ich: Auf meinem KC 85/4 (der Ost-Computer, den ich vor dem C64 hatte), habe ich Levels auf Kästchenpapier erstellt, mit Zahlenwerten, diese dann als DATA-Zeilen eingegeben. Ziemlicher Pain-In-The-Ass, aber wie Du schon sagtest: Damals hatte man noch diese Energie. Heute habe ich schon ganz gerne einen (selbstgebauten) Level-Editor, der das Ganze (Level und Figur-Einsatzpunkte) gleich im richtigen Format lädt/speichert, aber eben so anzeigt, wie es auch im Spiel aussehen würde - einfach aus dem Grund, weil Levelbauen für mich sowieso schon nicht so einfach ist (daß es dann trotzdem noch ein gutes/schönes Level wird) und daß ich damit dann schneller vorankomme. Aber erstmal diesen Editor haben, wäre ja schonmal nicht schlecht.
zatzen hat geschrieben:Bis über die Mitte der 90er kannte ich keinen der sonst noch programmiert. Und über Assembler reden kann man sowieso mit kaum jemandem. Pascal ist ja auch etwas unmodern...
Ja, ich weiß. Im neuen Coding-Board (im Gegensatz zum originalen, das ja vor einem Jahr dichtgemacht hat), wird Pascal nichtmal mehr einzeln geführt (dafür so'n Unfug wie Python). Man kann da zwar auch noch Dinge zu Pascal und anderen "unmodernen" Sprachen posten, aber das wird unter "Sonstiges" zusamemngefaßt. Und über Assembler mit Leuten "reden", ist quasi fast unmöglich - und darüber in Foren zu posten wird auch immer schwieriger.

Diese ganzen User von Interpretern/Skripts sind einfach überhaupt keine Ansprechpartner mehr für mich. Die machen vielleicht auch ihr Zeug und es funktioniert und so... - aber was sollen die mir beibringen? Mein Weg ist ja, mich immer mehr auf die Maschine zu - nicht davon weg zu bewegen. Also nützt es mir nichts, wenn mir einer sagt, wie ich mein Zeug noch systemferner abstrahieren kann - weil's das Gegenteil von dem ist, was ich will.

[das 486-Power Demo]
zatzen hat geschrieben:Ich habe es mal mit 44 kHz laufen lassen (mit Pufferwert 4), es profitiert durchaus. Nicht super dramatisch, aber es klingt alles feiner aufgelöst und sauberer - wie ein Hardware-Synthesizer. Schön, dass man diese Option bei ISM hat.
Naja. ich finde, höhere Abspielrate tut dem Ganzen nicht gut. Das liegt daran, daß die zugrundeliegenden Wellenformen nur 4bit und damit recht grob aufgelöst sind. Je höher die Abspielfrequenz, umso deutlicher hört man die "Treppen" in den Wellenformen und es klingt "knarrender", als es eigentlich gedacht ist. Bei niedrigerer Abtastrate "verschmiert" die Soundkarte das etwas weicher und es klingt eher so, wie es soll. Ich denke, diese 16 kHz werden's dann wohl auch sein, die ich für Musiken/Effekte in meinem Spielen benutzen werde. Von "unten" bis zu 16 kHz nehme ich noch eine Steigerung der Qualität (von dumpf bis so wie es soll) wahr, alles darüber macht nur die Unzulänglichkeiten von ISM deutlich.

[ISM In/Out-Interface...]
zatzen hat geschrieben:Das ist eine Stärke von ISM - bei ZSM kann ich nur in andere Patterns springen und so vielleicht einen musikalischen "Break" erzeugen, alle anderen Soundeffekte müssen über Samples erledigt werden, was aber auch meine Intention war.
Naja, ISM kann ja Samples ODER Klangsynthese. Soundeffekte, die per Klangsynthese schlecht klingen, werd ich sicher auch eher als Sample machen. Aber für so ein "Bling!" wenn jemand Münzen oder Boni sammelt oder so comicmäßige "Hüpfgeräusche" (wenn ich im RL hüpfe, macht das übrigens NIE "uuuiiiip" oder so) kriegt man auch mit Klangsynthese hin, da verschwende ich nicht für'n "Bling!" 32kByte, in die ich stattdessen auch hunderte Levelklötze oder etliche Sprites legen könnte. Und immer dran denken: Ja, das NES hat zwar extra Grafik-/Soundchip, aber das NES Super Mario Bros. ist (inkl. Levels, Musiken, Grafiken, Figuren und der ganzen Steuerung) insgesamt 48 kByte groß! Da brauchen andere Leute schon mehr für EINEN EINZIGEN SOUNDEFFEKT! - Das sind so Dinge, die mir dabei immer einfallen...
zatzen hat geschrieben:Übrigens muss ich hier gerade dran denken, dass in dem von mir oft genannten Super Mario Bros. auch nur eine überschaubare Anzahl Soundeffekte vorkommen, da könnte ich mir also leisten, diese auch als Samples zu realisieren.
Ulkig, daß Du es ausgerechnet DAS Game gerade erwähnst. Tja, wie oben gesagt: NICHTS von den Super Mario Bros. Soundeffekten ist ein Sample! Das ist alles Klangsynthese über den Soundchip. Die hätten in den 48 kByte, die diese Cartridge da hat, nie im Leben Platz für'n einziges Sample gehabt. Sogar die Levels sind "konstruiert". Die liegen nicht "ungepackt" da drin herum! Und die Grafiken auch nicht: Die grünen Büsche unten am Weg nutzen z.B. die gleichen Blocks/"Chars" wie die Oberseite der Wolken oben am Himmel, nur anders gefärbt!
Der Typ, der das Spiel gemacht hat, hat quasi alles ausgereizt, um mit dem wenigen Speicher, den er hat, ein riesiges abwechslungsreiches Spiel zu machen.

NATÜRLICH muß man das beim PC, der über 10x soviel freien Speicher hat, nicht dermaßen mit der Sparsamkeit übertreiben, ist klar. (Außerdem hat die VGA ja keine Patternlevel-Option und keine Hardwaresprites und die AdLib/Soundblaster sind auch etwas schwerer zu überreden, das gleiche zu machen, was die Soundchips in so alten Konsolen schon hardwaremäßig anbieten, um die mit 1 bis 3 MHz getaktete CPU zu entlasten.

Soll also nicht heißen, daß man hier mit Methoden von 1985 programmieren/ entwickeln soll, wenn man eigentlich 486er mit 500-600 kB (Heap-) RAM hat. Es soll nur mal als Denkanstoß dienen, was alles geht, wenn man will.
zatzen hat geschrieben:Und da denke ich auch daran, dass so ein ausführliches Spiel schon was Level-Design und Grafiken angeht ein ziemlich großes Projekt ist. Meine Schlussfolgerung wäre, dass ich für ein Spiel eine maßgeschneiderte Engine bauen würde, damit komme ich von meinem Gedanken den ich bis vor einiger Zeit hatte, eine Art generelle Spielengine zu bauen, ab.
Naja. Irgend eine Art "Spielengine" braucht man ja sowieso - ob man's "generell" macht oder nicht, macht von der Programmierung her wenig Unterschied. Zumindest für'n 2. Teil des "gleichen" Spiels kann man selbst eine spezialisierte (d.h. "nicht-generelle") Engine noch wiederverwenden. Und zumindest Dinge wie Anzeigen von Levels/Sprites oder Abspielen von Musiken/Soundeffekten sollte man in irgend etwas "generelles" auslagern - sowas braucht man nicht wirklich für jedes neue Spiel neu programmieren.
[Demo: Schweine-Sprites]
zatzen hat geschrieben:Hast Du für alles Deine Sprite-Routinen genommen? Bis auf die Hintergrund-Kacheln (oder den Text)? Wäre Drehen oder Skalieren mit ungeraden Verhältnissen zu langsam gewesen?
Das ist NICHT *die* Sprite-Routine, die ich normalerweise benutze. Meine andere Spriteroutine (die Drehen/Spiegeln/Skalieren/Dithern kann), ist für Mode-X ausgelegt.

Für dieses Demo habe ich eine NEUE Sprite-Routine gebaut, die noch unfertig ist und von der es noch - falls ich mal Lust haben sollte, ein Spiel in 640x480 zu bauen - eine neuere Variante geben könnte. Diese Spriteroutine ist speziell für VESA (und muß daher komplett anders aufgebaut sein als die für Mode-X) und kann derzeit nur: Sprites Spiegeln in X-Richtung und getrennt in beide Richtungen entweder mit einfacher oder doppelter Auflösung darstellen. Außerdem ist sie nicht meta-palettenbasiert, sondern stellt die Pixel 1:1 so dar, wie es das Byte angibt.

ALLE Routinen von dem Demo - Hintergrund/Level/Anzeige, Sprites und Textausgabe - sind komplett von Grund auf neu gemacht (in einer neuen Unit) und direkt auf VESA ausgelegt. Eigentlich ist's nur ne Machbarkeitsstudie, aber man könnte damit schon ein Spiel bauen, wenn einem Sprite-Skalierung und -Drehung nicht wichtig ist. Es sollte eher zeigen, was so'n 486er wirklich leisten kann, wenn man sich reinhängt: Immerhin wird das mehr als 5-fache an Daten bei jedem Frame durchgeschaufelt, als es bei MCGA wäre.

[Demo Scrolling]
zatzen hat geschrieben:D.h. alle 32 Frames wird der Hintergrund neu gezeichnet und dazwischen nicht? Würde das nicht zu Hakeln führen?
Nein, der Hintergrund wird bei JEDEM Frame 100% neugezeichnet. Der Bildanfang im Speicher wird nur verschoben, damit's leichter ist, Blocks an ganzen Positionen zu setzen.

Dazu muß man wissen, daß der "Banked" Mode bei VESA (im Real-Mode einzig sinnvoller VESA-Mode) ein 64kByte-Fenster bei $A000:$0000 bis $A000:$FFFF einblendet (weil eben nicht mehr Platz da ist), was ein Ausschnitt aus dem realen Grafikspeicher ist. Man muß dann den Ausschnitt umschalten (mit einem INT), wenn man auf anderen Ausschnitt zugreifen will und man kann den nicht beliebig "verschieben", sondern die liegen immer hintereinander im Speicher - d.h. im Normalfall endet dann so'n "Speicherfenster" mitten in einer Pixelzeile, weil 640 kein ganzzahliger Teiler von 65536 ist.

Wenn man aber - wie ich in dem Demo/der Unit - die Scanline auf 1024 setzt, werden 640 Pixel dieser 1024 angezeigt und ich habe bei 1 MB Grafikspeicher 2 "Bilder" zu je 1024x512 Pixeln, in die die 640x480 "eingebettet" sind. Dadurch ist die Grenze zwischen den 64k-VESA-Fenstern aber immer genau in jeder 64. Bildzeile und ich kann das Ganze so hinschieben, daß ich immer genau 2 Levelblocks übereinander in jedes "Fenster" kriege ohne beim Zeichnen des Blocks darauf achten zu müssen, ob ich mittendrin an die 64k-Fenstergrenze komme.
Horizontal ("in X-Richtung") kann man leider nicht pixelweise, sondern nur minimal 8-pixelweise das Bild verschieben (ist von Grafikkarte zu Grafikkarte verschieden, aber min. 8 können alle.). ICH verschiebe in dem Fall generell horizontal IMMER um 32 Pixel und fange den Block links dann entsprechend an Position 0..31 zu zeichnen an. Damit verschwende ich etwas Performance, weil ich vom ersten (linken angezeigten) Block teilweise Pixel zeichne, die nicht zu sehen sind - aber dafür brauche ich keine spezielle Blockroutine, die Clipping berücksichtigt - das gleiche gilt für rechts: Da Scanline ja 1024 ist, macht's nichts, wenn Block rechts drübersteht, weil Bild-SPEICHER ja nicht bei 640, sondern erst bei 1024 wraparoundet.

Für die Blocks OBEN gilt, daß ich sie immer bei Zeile 0 anfange zu zeichnen, aber das Bild entsprechend um 0-31 Pixel hochschiebe und man dadurch Teile des Blocks evtl. nicht sieht, dafür aber kein "Clipping-Block" benutzt werden muß. Für UNTEN (letzte "Block-Zeile") hab ich ne spezielle abgwandelte "Clipping-fähige" Routine gemacht - damit's möglich ist, unten so Anzeige (wie im Demo zu sehen) zu haben.

Natürlich muß man beachten, immer die für den Screen gemachten Verschiebungen bei Koordinaten von Schrift und Sprites zu addieren, damit sie bei der Anzeige genau da stehen, wo sie sollen.

Die Schrift ist nochmal ein Ding für sich: Da mein Proportionalschrift-Format sinnvollerweise die Daten senkrecht speichert (Schrifthöhe bzw Glyphenhöhe ist ja immer gleich, aber Breite unterschiedlich), wird Schrift senkrecht "gepixelt". Wenn Schrift aber genau inmitten einer VESA-Fenstergrenze landen würde (also so, daß eine oder mehrere der "64. Linien" überquert werden würden, würde sich alles sehr verlangsamen, da in jeder Schriftspalte mind. 1x das VESA-Fenster gewechselt werden müßte. So macht's auch die normale Schriftausgabe!!

ABER: Die normale Schriftausgabe hat Clipping-Option für alle 4 Seiten - ich kann an jeder Stelle die Schriftausgabe abschneiden. Das nutze ich für einen Trick: Es gibt eine zweite Routine, die die Schriftausgabe mehrmals aufruft und zwar so beschnitten, daß die Einzelteile der Schrift nur innerhalb der jeweiligen 64-Zeilen-Streifen dargestellt werden. Ja, das ruft dann öfter die Schrift auf und EINIGE der internen Berechnungen werden dadurch mehrmals ausgeführt - ABER: Trotzdem erreiche ich damit - weil ich pro Schriftausgabe meist nur 1- bis 2-mal das "Fenster" wechseln muß - solche Geschwindigkeitssteigerung, daß sich dieser Trick als sehr sinnvoll erwiesen hat.

Wenn man wie ich schon so ewig Grafikprogrammierung macht, lernt man dabei, extrem "um die Ecke" zu denken. Man denkt NICHT: "Ich habe Koordinate X und Y und Farbe C und der Pixel (X,Y,C) muß da hin" - sondern: "Ich befinde mich grade mit meinen Registern so, daß ich an Koordinate X,Y wäre, was sollte ich als nächstes machen, um so wenig wie möglich neu ändern/berechnen zu müssen?" Man denkt nicht in Pixeln, sondern in Bytes, die in einem Speicher liegen und die, wenn man es geschickt anstellt, am Ende die Anzeige ergeben, die man haben will.

Und ob man auf dem geraden, leicht-verständlichen, aber leider auch dümmstmöglichen Weg da hin kommt (zwei verschachtelte X und Y FOR-Schleifen, die dann sowas wie putpixel(X,Y,Color) aufrufen) oder etwas kreativer ist, indem man sich an die technischen Gegebenheiten der Speicheranordnung der Grafikkarte anpaßt, macht den Unterschied, ob man ein Hochsprachen/Skriptsprachen-User ist, der selbst ein simples 2D-Spiel nur mit wahnwitzig schnellen Maschinen ruckelfrei/spielbar bekommt oder ob man sowas hinkriegt wie die Typen, die heutzutage aufm C64 (mit 1 MHz und komischer Grafikspeicheranordnung) ein superbuntes 8-Wege-Scrolling-Spiel wie "Sam's Journey".

Anders ausgedrückt: Wenn man sich EINMAL die Mühe macht, eine richtig geile Grafik- und Sound-Engine zu bauen, die viel kann, aber wenig braucht, hat man dann etwas, bei dem man genügend Speicherplatz und Rechenzeit übrig hat, um das alles für kreative Ideen für ein Spiel zu benutzen, weil man den Engine-Routinen vertrauensvoll "die ganze Arbeit" überlassen kann.

Ist natürlich (wie immer) nur meine persönliche Meinung. Achja, und modulare Programmierung (also diese "Engines") hat auch den kleinen Vorteil, daß man sie verbessern/auswechseln kann, wenn man mal etwas besseres gemacht hat - OHNE am restlichen Spiel etwas ändern zu müssen. Es wird dann vielleicht nur schneller/flüssiger.

[640x480]
zatzen hat geschrieben:Das hatte ich beim Ansehen schon verstanden, nur war es mir ein Rätsel wie ich selbst sowas machen könnte.
Achso. Naja, ist eigentlich kein Hexenwerk.
VESA hat nur so ca. 10 Subfunktionen, von denen man vielleicht 3 oder 4 wirklich braucht. Es ist INT $10, Funktion AH=$4F und AL= die jeweilige VESA-Funktion. Einfach mal Ralph Brown's Interrupt-List durchschauen.

Das soll jetzt natürlich nicht heißen, daß man VESA (statt MCGA) programmieren soll. Wie schon erwähnt, war's nur 'ne Machbarkeits-Demo, um zu sehen, ob/wie ein 486er bei dieser Auflösung performen könnte.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wenn ein 486er mit 640x480 schon DAS machen kann, sollte er wohl auch 320x200 schaffen.
Das macht doch Hoffnung. Vielleicht kann ich ja dann doch für gemütliche Spielchen bei der Blockmethode die Hintergründe komprimiert anlegen. *duck und renn weg*
Nein, werde ich sehen. Vielmehr macht es Mut zu Scrolling.
Wie auch schon mehrfach erwähnt, macht Scrolling für mich nicht den Unterschied, ob ich ein Spiel gut finde / mir Spaß machen kann oder nicht. Scrolling ist nur eine Möglichkeit, eine "größere Welt" zu begehen, die größer ist als sie auf den Bildschirm paßt. Das Ganze kann etwas "Überraschendes" haben - weil man nicht von Anfang an alles sieht und auch etwas vom "Suchen", weil z.B. bei 8-Wege-Scrolling Finden von Boni/Geheimräumen eine Herausforderung sein kann.
Genauso kann aber auch ein Fixed-Screen-Spiel Spaß machen. Entweder, wenn das "Große Welt"-Konzept statt Scrolling durch Umblenden in angrenzende Räume (mit so "Ausgängen/Eingängen") gemacht wird (gibt sehr viele ältere Spiele, wo das so ist) oder wenn der Fixed Screen an sich viele interessante Möglichkeiten bietet, was man damit machen kann und man dann gleich auch das Ergebnis seiner Aktion sieht. Und selbst wenn man sich nur aus technischen Gründen gegen Scrolling oder gegen Sprites oder für/gegen Effekte oder für viele/wenige oder hohe/niedrige Auflösung entscheidet, kann das trotzdem Ansporn oder Herausforderung sein, nicht nur OBWOHL, sondern WEGEN solchen Beschränkungen ein ganz neues interessantes Spielkonzept zu entwickeln.

Genauso, wie 3D nicht "verpflichtend" ist, damit Spiele Spaß machen können
(außer für sehr sehr dumme Leute), ist auch bei 2D nicht "verpflichtend", daß es immer mit Scrolling haben muß.
[Portamento]
zatzen hat geschrieben:Kommt immer drauf an, manche nutzen den in großem Ausmaß, andere gar nicht. Aber eben deswegen hab ichs auch nicht unterstützt, und weil es nur gerastert geht, z.b. mit 50 Hz. Dann müsste ich aber alles so fein rastern (statt zeilenweise) und hätte nur Tempi bzw. Zeilenlängen zur Verfügung die sich aus vielfachen von 1/50 Sekunde zusammensetzen.
Naja, diese Einschränkung ergibt sich nur daraus wie MODs aufgebaut sind. ISM hat diese ja nicht. Die 1/128-Note ist der kleinstmögliche per Befehl einstellbare Zeitabstand - alles andere kann so gerade oder krumm sein, wie es will.

Aus dem Grund konnte ich aus ISM eine "MOD-Ansicht" machen: Indem ich manche Dinge, die ISM kann, nicht benutze. Andersherum ist's eben nicht möglich. Das liegt aber u.a. auch daran, daß ISM für ein Musikformat ungewöhnlich viele Befehle enthält, die gar nichts mit Musik zu tun haben. Das Zahlenratespiel-Beispiel ist ja ein guter Beweis dafür, daß man damit - wenn auch teilweise etwas umständlich - auch ganz andere "Programme" machen kann. Und die Möglichkeit, in AtavISM das Zeug live einzugeben und trotzdem im gespeicherten Format (dank internen "ISM-Code-Containers") ohne Konvertierung abspielen zu können, ist der noch größere Beweis, daß das ganze Ding wie ein "Programm" benutzt werden kann.

Eigentlich war das so in der Form gar nicht mal vorgesehen. Der ursprüngliche Plan war nur, daß ich Unterprogramme und Schleifen haben wollte, um die gleiche Funktionalität wie in meinem alten MUSIX-Format (max. 3-stimmig für PC-Speaker) zu haben. Die anderen Dinge (mit den ganzen Berechnungen und bedingten Sprüngen) haben sich noch ergeben, weil noch Platz frei war.

Dadurch hat's den Vorteil, daß selbst Effekte, die ISM selbst nicht hat, durch "Programmierung" erzeugt werden können, wie z.B. Vibrato, Tremolo oder Glissando (die beliebten Dinge, weswegen C64-Musik so klingt, wie sie klingt).
zatzen hat geschrieben:
DOSferatu hat geschrieben:Übrigens: Um mein Portamento so sauber hinzukriegen, wird intern mit 48-Bit-Werten gearbeitet.
Also 48 Bit mit Festkomma für die Tonhöhen? Vielleicht kannst Du mir erzählen, wie es bei Dir mit BPM Tempo im Zusammenhang mit Portamento Effekten aussieht.
Ja, 48 Bit Festkomma für Tonhöhe. Die normalen Töne sind in ISM 32 Bit Festkomma (16 Vorkomma, 16 Nachkomma). Für Portamento zu machen, braucht man nicht nur einen Adder, der den Frequenzwert immer wieder addiert, sondern einen "Adder-Adder", der den Adder quasi immer wieder ändert. (Den gleichen Trick kann man z.B. benutzen, um bei 2D-Spielen einen sinusbogen-förmigen Sprung (anstelle eines Dreiecks) hinzukriegen - OHNE Multiplikation!

BPM spielen in ISM gar keine Rolle, wird nirgendwo angegeben. In ISM gibt man eine Note an, dann einen Portamentobefehl (mit Länge) und eine andere Note. Der Portamentobefehl kennt die letzte gespielte Note und tut erstmal nix, bis er zur nächsten spielbaren Note kommt. Diese wird nicht abgespielt, sondern es wird der Frequenz-Abstand beider Noten berechnet und durch die Länge des Portamento geteilt, um den 48bit-Adder-Adder (siehe oben) zu ermitteln und dann wird erst das Zeug für das Portamento generiert, bevor die neue Note abgespielt wird.
Will man GLEICH Portamento haben (ohne daß die erste Note vorher noch ohne Portamento gespielt wird), gibt man als Notenlänge einfach 0 an.

Im Gegensatz zu MOD, wo man NICHT von-Note-zu-Note das Portamento angibt, sondern angeben muß, um wieviel pro Tick sich das ändern soll und ob positiv/ negativ (also nach oben oder unten gehen soll), gibt man bei ISM einfach Anfang und Ende als Noten an und die Länge - und die Berechnung übernimmt ISM selbst.
zatzen hat geschrieben:Letztlich geht es technisch darum, das Spektrum gleichmäßig auszufüllen, mit Tendenz dass es nach oben leiser wird, ähnlich Rosa Rauschen (3 dB Abfall pro Oktave).
Wenn sich die Töne frequenzmäßig nicht ins Gehege kommen geht es was Lautstärke angeht vielmehr darum, dass man alles gut zueinander abstimmt und man alles gut raushört, ohne dass etwas banal gesagt zu leise oder zu laut ist.
Naja, ich selbst habe zu wenig Ahnung von Klang und Musik - ich murks einfach so lange herum, bis es so klingt, wie ich will, oder bis es zufällig gut klingt, auch wenn es so nicht geplant war.

Mir geht's bei "direkter" Musik (zum "Anhören"), wie bei Demos oder Titelmusiken, darum, daß diese laut und mitreißend sind, mit kleinen "Überraschungen" drin - und bei "indirekter" Musik (zum "Überhören"), wie bei Hintergrundmusik zum Spielen, darum, daß sie KEINE Überraschungen hat, sondern eher einen stetigen Fluß, der den Spielverlauf begleitet und unterstützt, ohne zu nerven.

Wie gut ich das hinkriege, hängt von meiner Tagesform ab. Oft mache ich aber auch einfach irgendwelche Musik und entscheide hinterher, ob besser als direkte oder indirekte Musik geeignet. Das war z.B. bei der (Speaker) Musik zu diesem PLAYBOX so (gibt's auf meiner Website): Die Musiken eigentlich umgekehrt gedacht: Die Spielmusik sollte erst Titelmusik werden und umgekehrt - aber es hat sich eben anders entwickelt und ich hab's dann getauscht. Ulkig, was?
zatzen hat geschrieben:
DOSferratu hat geschrieben:Ich benutze ja (leider) für so Sample-Zeug immer noch dieses uralte VOC386. Das ist zwar an sich eine gute Idee, aber es ist eben von der Bedienung her SOWAS von 1990....
Vielleicht kannst Du Dich ja mit dem "Advanced Digiplayer" aus dem Hause Future Crew anfreunden. Müsste ich noch haben.
Achnaja, das Ding ist bestimmt professionell.
Und eigentlich will ich gerne etwas, das NOCH simpler und banaler als VOC386 ist, nicht komplexer. Ich brauch's wirklich nur zum Aufnehmen/Beschneiden. Ich wollte mir immer mal selber sowas schreiben. Prinzipiell weiß ich, wie ich per SB aufnehmen kann.

Eine andere Idee von mir (hab ich vielleicht schonmal erwähnt), ist ein Programm (vielleicht auch als prISM-Zusatzfunktion, aber ungern, weil ich Speicher freihalten will), bei dem man einfach ins Mikro summt oder pfeift (Pfeifen macht schön einfache fast perfekte Sinuswellen) und das Ding analysiert live die Wellenberge/Frequenz und macht daraus gerundete Daten mit Tonhöhe und Tonlänge, die man dann als "Melodie" (bzw ISM-File) in prISM importieren könnte. So könnte man viel schneller Ideen "komponieren"...

Auf C64 hab ich das mal gemacht und es ist eigentlich damals nur an Systemleistung und geringer Aufnahmerate gescheitert, aber das Konzept an sich hat funktioniert.

Aber das hab ich schon ewig vor - und die Dinge, die ich auf PC "schon ewig vorhabe", sind inzwischen zweistellig.
zatzen hat geschrieben:[...]Aber ich weiss nicht ob ich das empfehen kann, dazu müsste ich vergleichen was VOC386 so kann und wie ergonomisch es aufgebaut ist.
Ja, ich häng den mal hier an:
http://www.imperial-games.de/z/voc386.zip
zatzen hat geschrieben:Ansonsten habe ich eine lange Zeit lang mehrgleisig gearbeitet: Aufnahmen in Windows gemacht, Samples bearbeiten ebenfalls dort, und dort auch nach 8 Bit und niedrigerer Samplerate für den X-Tracker konvertiert, der in früheren Versionen nur in echtem DOS lief und nicht in DosBox.
Ja, Windows... Da nutz ich inzwischen für manche grafischen Dinge gern Irfanview (kann ich zum Anschauen und Konvertieren von Bildern sehr empfehlen), weil sich's ganz gut bedient und ein paar ganz nützliche Funktionen hat. Wandeln von Bildern in palettenbasiert ist auch ganz gut, man kann sogar angeben, wieviele Farben man haben will. Das Ding wird von einem einzigen Typen immer weiter entwickelt und ist Freeware.
zatzen hat geschrieben:Nunja, man könnte meinen, beim Basslauf direkt von Anfang an könntest Du inspiriert sein von... Eurodance.
Naja, Eurodance & Techno mag ich gar nicht. Der Baßlauf wurde von mir passend zu der hohen Begleitmelodie gewählt - die hatte ich als erstes im Kopf.
Der Break in der Mitte, wo es erst ruhig wird und dann dieser gegenläufige erst fallende dann steigende Portamento, zusammen mit der immer schneller werdenden Percussion, DAS war eindeutig eine ironische Anspielung auf diese ganzen 90er-Mucken, wo das in quasi 99% der "Musiken" so oder ähnlich im Mittelteil gemacht wurde.
zatzen hat geschrieben:Ich fand diese Musikrichtung der 90er irgendwie nie so toll, und diese Bassmelodie (z.B. E - E - E - E - C - C - C - C - D - D - D - D - ...) findet sich in fast allen dieser Songs, das scheint schon so ein Standard davon zu sein wie beim Blues das entsprechende Schema.
Wie gesagt, der Baß mußte harmonisch zu dieser crazy Begleitung passen und hat sich dadurch so ergeben.
zatzen hat geschrieben:Also das ist vielleicht nicht so super originell (aber fast schon wieder wie ein Running Gag weil es so viele Musik gibt mit genau dem drin) - aber ich finde gut und kreativ was Du an sonstigen Melodien dazugebastelt hast.
Wie schon erwähnt, bin ich Musik-/Soundtechnisch eher unterentwickelt - quasi unmusikalisch. Daher ist mein bescheidener Kram auch immer ganz gut erkennbar.
zatzen hat geschrieben:Mode-X Scanline erweitern:
Da fehlt mir etwas der Durchblick. Verstehe ich so ungefähr.
Ich bleib erstmal bei MCGA. Kann man da irgendwas sinnvolles mit Scanline-Manipulation machen?
Eher nicht. Das Problem ist nicht, daß es nicht geht, sondern daß es kaum Sinn macht. Der Grund ist, daß 320x200 ja schon fast die kompletten 64kByte benutzen. Man kann die Scanline nicht in 1er-Schritten erhöhen, sondern in 8er-Schritten (bei MCGA/Mode-X sinds 4er, wegen der Pixelverdopplung). Aber 324*200 ist 64800, bei 328*200 ist man schon bei 65600 (also über 65536) und das Bild wraparounded dann unten.

WAS aber geht, wäre bei 324*200 so softscrolling, weil man ja 4-pixel-weise das Bild verschieben kann und man bräuchte trotzdem nicht bei 4ern "clippen".

Das wäre z.B. auch eine Möglichkeit, Deine Sprites, die auf 4x4 Quadrate ausgelegt sind, nur an ganzen Quadraten abzubrechen, weil der "Umbruch" sowohl links als auch rechts in den "unsichtbaren" Bereich geschrieben werden würde.
zatzen hat geschrieben:Ich bin zur Zeit stärker beschäftigt mit Musik mischen, die Antwort zum "Eigenes Videoformat"-Thread kommt auch bald.
Ja, die kam inzwischen. Das sollte ich auch noch bei Gelegenheit mal beantworten. Aber nicht mehr heute.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

DOSferatu hat geschrieben:Naja, Arrays sind ja auch nur ein Programmkonstrukt. Solange man Pointer auf irgend einen Speicherbereich zeigen lassen kann, kann man das lesen wie man will. Und naja, meine Units (=Libraries) können ja sowas. Ich habe z.B. eine hier, die das Einlesen/Schreiben von Bildern in PCX oder BMP automatisiert (und zusätzlich noch in 2 eigenen Formaten). Die erweitere ich ständig. Ich wollte da immer mal GIF mitnehmen. GIF lesen habe ich schon in einem anderen Programm gemacht - aber das automatisiert in dieser Unit wäre auch nicht schlecht. Wenn ich die in meine neueren Programme eincompiliere, können die auch automatisch alles lesen/schreiben, was die Unit kann. Die Menüs müssen es nur hergeben.
Ja, bei Freepascal (oder Windows eben) fehlt ja einfach die direkte Möglichkeit, Hardware anzusprechen, und wie man dann unter Windows aus dem Programmspeicher heraus Sound wiedergibt und nicht nur aus Dateien heraus (wie es diese Libraries irgendwie nur anbieten), das verstehe ich noch nicht. PCX/BMP ist ja nicht so das Problem, aber vor Formaten wie JPG habe ich noch Respekt. Wiederum habe ich aber auch keinen Schimmer wie man mit Freepascal Vollbildgrafik anzeigt und das wiederum aus dem Programmspeicher heraus und nicht bloß eine Library auf eine Datei ansetzen. GIF beinhaltet Huffmann, vielleicht sollte ich mich damit mal befassen, ich hab es bisher nicht gerafft mit diesen Rekursionen. Vielleicht geht es auch nicht-Rekursiv. Irgendwo hier im Forum sagte mal jemand, da wäre eine Huffman-Decodier-Routine die so schnell wäre wie memcpy bzw. einfaches Speicher-Kopieren. Das kann rekursiv ja gar nicht gehen, weil dabei ständig Takte für Funktionsaufrufe verbraten werden.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ich versteh nix von Programmierung mit Klassen und sowas, und wenn ich Daten nicht in ein eigenes Datenfeld einlesen kann bringt mir das nichts.
Naja, OOP ist auch nicht so meins. Aber Arrays sind nichts, was ich zwingend brauche. Da ich ja diese Speicherverwaltung habe, brauche ich nur einen Pointer, der sagt, wo die Daten anfangen (und einen anderen Wert für die Größe).
Freepascal hat ja Zugriff auf 2 oder 4 GB. Und die Segmente sind auch nicht auf 64K beschränkt, das "flat" Speichermodell ist ja ein ganz anderes. Daher kann man einfach z.B. ein Array von 1 GB Größe definieren. Es macht dann keinen Unterschied und ist, wenn man eben rein in Pascal programmiert, ganz praktisch mit Arrays zu arbeiten und keine Pointer für Zugriffe bemühen zu müssen. Im DOS-Realmode ist das natürlich etwas anders, das stimmt.
Übrigens wegen Speicherverwaltung: Ich will nicht einfach Dein System übernehmen sondern wenn, mir eines selber basteln, damit ich da auch durchblicke und ich es nach meinem Geschmack gestalten kann. Ich habe mal die Functions Getmem und Freemem unter die Lupe genommen, was der Compiler draus macht. Nun, er generiert einen CALL mit Parameterübergabe, einmal an Programmadresse 6:$028a und an 6:$029f. Gerne würde ich mir den Assembler-Code dieser Routinen ansehen, um zu verstehen versuchen was Pascal da wirklich macht (denn dann könnte man ja evtl. eigene Routinen schreiben), aber dazu müsste ich erstmal genau im EXE Format durchblicken um die Position des Codes ausfindig zu machen. Sicherlich kann man sich auch einfach informieren wie man unter blankem Assembler den Heap verwaltet, aber ich bin einfach mal neugierig wie Getmem und Freemem funktionieren.
DOSferatu hat geschrieben:
zatzen hat geschrieben:[...]Mir wird an dieser Stelle mal klar, dass ich eigentlich bisher nie versucht habe, auch nur in die Nähe von schnellen "Arcades" zu kommen. In meinen Basic-Zeiten war alles durch Basic selbst und meine Unfähigkeit limitert, dann kam Pascal und Assembler, aber damit ist noch kein richtiges Spiel fertig geworden.
Naja, erinnert auch an mich - ich nenne mich "Imperial Games" - aber so richtig "Game"-mäßiges, auf das man stolz sein könnte, ist von mir auch noch nicht gekommen.
Ein bisschen Team wäre vielleicht gut. Wenn sich nicht einer um alles zu kümmern hat geht dann auch alles schneller. Aber wir hatten da schon das Problem mit der Verlässlichkeit thematisiert. Auf mich könntest Du Dich verlassen, aber ich kann Dir nur Sound/Musik bieten.
DOSferatu hat geschrieben:Wenn man das Spiel-Timing unabhängig von der Soundkarte macht und auch nicht mit Timer-Schleifen, dann bleibt mehr Performance übrig, die man z.B. für höhere Frameraten beim Sound benutzen kann. Aber ich denke mal, über Timerschleifen bist Du inzwischen hinweg.
Klar, Bremsschleifen sind ein No-Go für mich. Wie ich eine dynamische Framerate realisiere ist mir noch ein Rätsel, aber ich möchte da selbst draufkommen.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Wie auch immer - ich distanziere mich bewusst etwas vom typischen Musiker, weil mein Ansatz doch unterm Strich etwas anders ist, vor allem wohl der Punkt, dass ich von vornherein direkt in die "Dose" produziere, während einige Musiker überhaupt keinen Wert auf ein Endprodukt ihrer Musikstücke legen und ihre Erfüllung eben im (auch gemeinsamen) Musizieren finden.
Naja, so "Jam-Sessions" sind ein komplett anderer Ansatz. Daß man aber Musik auch "erhält", um sie wiederverwendbar zu machen, ist ja nichts Schlechtes - und z.B. für Spiele unabdingbar. Das komponiert sich ja nicht "live" mit, während man spielt.
...was aber interessant wäre, wenn man eine Art KI hätte die passend zu jeder Spielesituation entsprechende Musik macht. Aber das wäre wohl mit Kanonen auf Spatzen geschossen, bei Spielen wie Super Mario genügt es, wenn die Musik auf einmal schneller ist wenn die Zeit knapp wird, und das iMuse System von LucasArts ist eine andere sehr ausgeklügelte Sache. Die ich selber aber nicht anstrebe, da sie mit den Tracker-Gepflogenheiten schwer vereinbar ist.
Ansonsten gibt es natürlich durchaus Musiker, die einen großen Wert auf ihre Studioproduktionen legen und dort erst richtig kreativ werden, ein Beispiel sind die Beatles.
DOSferatu hat geschrieben:Ein Tetris habe ich auch mal gemacht. Relativ einfach gemacht, aber es tut, was es soll.
Ja, Tetris ist ein praktisches Spielprinzip, relativ einfach zu programmieren und trotzdem sehr unterhaltsam. Vielleicht habe ich mal Lust eins mit ZSM Sound und evtl. ZVID2 Grafik zu machen - also irgendwie multimediamäßig aufdonnern, aber nur dann, wenn das ganze auch zum Spielspaß beiträgt und nicht einfach dasselbe in "knallig bunt und klingeling" und ist aber ansonsten öde.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Tja mit der Energie ist das so ne Sache. Hinzu kommt (bei mir jedenfalls): Damals hat man sich auch noch nicht viel Gedanken darüber gemacht, dass das Leben auch mal ein Ende findet. Mit so einer Haltung war es einfacher, große Projekte anzupacken bzw. an eine "große" kreative Zukunft zu denken.
So ist es. Heute denkt man: Wenn ich 5 Jahre für das Projekt brauche, bin ich XX Jahre, wenn es fertig ist. Hinzu kommt, daß die Computerwelt sich (im Gegensatz zu früher) dermaßen schnell ändert, daß ein Computer/Pad/wasweißich, das am Jahresanfang noch total angesagt war, am Jahresende schon veraltet ist. Und das System unter/für das ich hier code (DOS), ist vielen Leuten heutzutage nicht einmal mehr namentlich bekannt. Und die heutige "bloß nichts lernen oder selber nachdenken"-Generation schätze ich auch als viel zu blöde ein, sowas wie DOSbox zu installieren und konfigurieren.
Ich denke jetzt, darüber muss man sich irgendwie philosophisch hinwegsetzen. Das mit DosBox könnte eine Hürde sein (wenn ich allein schon diese vielen Youtube Videos sehe wo man noch das Windows-Fenster um die DosBox sieht - hey, das kann auch Fullscreen!), andererseits gibt es Youtube und man kann dort vermeintlichen Retros Appetit auf sein Spiel machen, bis sie angefixt genug sind um die Hürde zu nehmen und DosBox zum Laufen zu bringen. Ansonsten mache ich eben jetzt einfach. Wie gesagt kommt das bei mir so in Wellen worauf ich gerade Lust habe. Im Moment ist es wieder Pascal/Assembler programmieren. Dabei programmiere ich schon so, dass es möglichst auf echter Hardware performen würde bzw. gebe mir Mühe, effizienten Code zu schreiben, auch wenn DosBox auf meinem System hier knapp einen Pentium III 500 MHz emulieren kann. Wenn man nicht auf Ruhm und Geld aus ist, kann einem getrost egal sein für welche Rechnergeneration man programmiert. Ich sehe mein gemütliches Gecode hier so ähnlich an wie sich durch ein Rätselhaft arbeiten. Nur dass am Ende nicht bloß irgendwelche Lösungswörter rauskommen, sondern schöne Anwendungen oder Spiele. Eine Art Kunst vielleicht auch, so wie manch ein Maler Bilder malt aber diese nicht für Geld oder überhaupt loswird.
Übrigens das Problem mit der schnellen Systemveraltung hatten auch die Entwickler von der Fortsetzung von Duke Nukem 3D. Das Spiel musste immer wieder verzögert werden weil es fähigere Hardware gab und die Software das nicht ausreizte. Oder das war nur ein Gerücht und die brauchten einfach so lange. Wäre aber plausibel. Aber sowas muss und kann uns egal sein, weil wir nichts verkaufen wollen und von nichts abhängig sind.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Aber da gibt's ja den Spectrum Analyzer der einem verrät, was obenrum noch so passiert. Oder man hört sich alles schonmal auf 22 kHz an zur Kontrolle (so dass alles einen Oktave tiefer ist und halb so schnell läuft).
Naja, da sowohl Grafik als auch Musik Geschmackssache sind und nicht nur nach rein mathematischen Gesichtspunkten bewertet werden können (bzw sollten), ist das natürlich etwas "creepy". Mit einem Spektrum Analyzer herausfinden, ob etwas gut klingt (weil man es selbst nicht [mehr] hört), ist so, wie wenn ein Farbenblinder ein buntes Bild malen soll. Keine Ahnung, ob das der Weg wäre, gute Musik zu machen. Ich selbst bin ja musikmäßig der totale Laie, was man auch an den Stücken merkt, die ich so fabriziere - aber bin noch nie auf die Idee gekommen, solche Geräte dazu einzusetzen, um zu entscheiden, ob es gut klingt.
Wenn ich hier ernsthaft Musik produziere muss ich zusehen dass es auch rein klanglich möglichst optimal ist, das ist weitestgehend unabhängig von Musikgeschmäckern (ich bearbeite auch schonmal Musik von anderen klanglich). Wenn ich die ganz hohen Tönchen nicht mehr wahrnehme kann ich keine Aussage darüber machen ob da oben zu viel oder zu wenig los ist. Ein Analyzer stellt das dar, und da kann ich einfach sehen was ich nicht mehr höre. In etwa vergleichbar mit einer Lupe. Als Kind konnte man vielleicht noch sehr kleine Dinge einfach sehen, aber später werden die Augen schlechter und man nimmt als Hilfmittel zwischendurch ne Lupe um sicherzustellen dass die Details auch stimmen.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Naja, vielleicht doch nicht soo rechenintensiv. Auf jeden Fall kann die AdLib, wenn geschickt programmiert, schon wirklich nette Sounds machen.
Ich weiß. Dazu muß man aber Ahnung von Sound haben. ICH wüßte nicht vorher, wie sich das anhört, wenn ich da irgendwelche Werte setze, d.h. ich müßte so lange herumprobieren, bis es so klingt wie ich will.
Ganz so schwierig fand ich das nicht, aber es war natürlich Herumprobiererei. Letztlich ist mir der AdLib-Sound aber irgendwie zu stereotyp, Samples bringen da viel mehr frischen Wind rein. Und auch ISM, weil es Klänge machen kann die AdLib nicht kann.
DOSferatu hat geschrieben: [CGA]
zatzen hat geschrieben:Ich habe mich in meinen Jugendjahren mehr mit Grafik beschäftigt, einiges mit viel Zeitaufwand handgepixelt, inspiriert von guter 320x200 Grafik. Mich hat auch fasziniert, wie im EGA Mode trotz der Beschränkung auf die festen 16 Farben der Eindruck nach mehr Farben und Farbverläufen enstanden ist, indem z.B. zwischen Grünwerten oder Blauwerten auch Grauwerte verwendet wurden, ohne dass es einem wirklich auffiel.
Ja, das unterscheidet eben wirkliche Künstler von Laien, die einfach nur irgendwas bunt hinklecksen. Und man erkennt auch gut, ob jemand wirklich selbst richtige Grafik macht oder einfach nur irgendwelche "Füll/Raster/Farbverlauf" Features und feste geometrische Formen seines Lieblings-Malprogramms benutzt hat. Letzters wirkt immer eher laienhaft und steril, da kann man machen, was man will...
Ja, das habe ich auch tendentiell öfters bei Shareware-Spielen erlebt und fand ich dann auch enttäuschend, egal wieviele tolle schillernde VGA-Farben dabei waren.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ein Experiment was ich mir vor längerer Zeit schon einmal überlegt habe wäre, eine Art 3D Engine zu bauen, die mit massiven 3D-Pixel Objekten arbeitet. Der Unterschied wäre, dass es keine Polygonkörper mit Skins gäbe, sondern dass alles als 3-dimensional angeordnete Pixel einer gewissen Auflösung definiert ist.
Gibt es schon - nennt sich Voxel. (Kunstwort aus "Volume Pixel" - wobei ja Pixel selbst schon ein Kunstwort ist.)
Ah, danke, dieses Wort hab ich gesucht. Ich hatte es vergessen und stattdessen "Vortex" im Kopf, aber das ist ja was anderes...
DOSferatu hat geschrieben:Wie gesagt: Gibt's schon.
Ich selbst habe das auch mal vor etlichen Jahren als Idee durchgesponnen. Das sollte eigentlich nur dazu dienen, Sprites zu rendern. Habe dann so gedacht: Ein 64x64x64 Voxelwürfel für so kleine/mittelgroße Sprites sollte ja machbar sein. Ist er auch. Braucht 256kByte, wenn jeder Einzelwürfel nur ein Byte braucht. Wenn er z.B. 3 Bytes braucht (Truecolor, 24bit Farben), sind es 768kByte oder 0,75 MB... - ja, alles machbar, aber war mir dann letztendlich wohl den Aufwand nicht wert.
Immerhin gibts sowas prinzipiell im Real-Life: Legoland.
DOSferatu hat geschrieben:
zatzen hat geschrieben:[320x200]
Magisch, weil die Pixel einerseits klein genug sind, dass sie bei entsprechender Farbwahl verschmelzen können (und die Auflösung einfach reicht), andererseits groß genug, dass man sie noch als Pixel erkennen kann. Ich hatte das glaube ich schonmal irgendwo erwähnt, dass es z.B. auch so einen gläsernen Effekt haben kann wenn man im 320x200 Modus größerflächiges Anti-Aliasing hat. Das ist wieder diese Wahrnehmungs-Sache, verstehst Du vielleicht nicht.
Klar verstehe ich das. Es ergibt sich automatisch so ein Milchglas-Effekt. Natürlich nur, wenn man entweder 15/16/24bit Farben benutzt ODER die Farbpalette so gebaut ist, daß sich die Mischfarben zumindest größtenteils auch ergeben können.
Ich bin das erste mal richtig auf sowas aufmerksam geworden als ich Monkey Island II gespielt habe. Da kann man sowas beobachten, wenn auch nicht ganz sauber.
DOSferatu hat geschrieben:[VGA Palette]Ich find's aber interessant, daß man sich darüber ÜBERHAUPT Gedanken gemacht hat. Man kann natürlich auch einfach häßliche 6-7-6 oder 8-8-4 oder ähnliche Paletten benutzen - aber damit schränkt man sich eben ein, weil man manche der Farben daraus überhaupt nicht benutzen würde und bei anderen wiederum nicht genug hätte, um einen Grün- oder Hautton feiner abzustufen. Und wenn man nur 256 Farben hat, sollte man diese nicht durch irgendwelche "Generalisierungen" verschwenden und die ohnehin schon begrenzte Menge Farben mit unbrauchbaren Farbtönen noch weiter einschränken.
Das ist ein überzeugendes Argument. Bloß wenn man es komplett mit eingescannter Grafik zu tun hat deren Farbinhalte man nicht gezielt bestimmen kann scheint eine generalisierte Palette plausibel.
DOSferatu hat geschrieben:[Notdürftige Tools für Grafik]Kenn ich: Auf meinem KC 85/4 (der Ost-Computer, den ich vor dem C64 hatte), habe ich Levels auf Kästchenpapier erstellt, mit Zahlenwerten, diese dann als DATA-Zeilen eingegeben. Ziemlicher Pain-In-The-Ass, aber wie Du schon sagtest: Damals hatte man noch diese Energie.
Ja, es ist verrückt. An sowas mit Kästchenpapier und Zahlen erinnere mich auch, nur habe ich das mal mit Grafik gemacht. War wohl EGA bzw. die ersten 16 der VGA, die Farbwerte kennt man ja auswendig. Ich hab auch oft in der Schule so neben dem Unterricht oft irgendwas geschrieben, oder hatte auf einem Familienausflug einen Zettel dabei... Total besessen irgendwie. Es ist heute letztlich effektiver, wenn man mit mehr System an Problemlösungen rangeht.
DOSferatu hat geschrieben:Diese ganzen User von Interpretern/Skripts sind einfach überhaupt keine Ansprechpartner mehr für mich. Die machen vielleicht auch ihr Zeug und es funktioniert und so... - aber was sollen die mir beibringen? Mein Weg ist ja, mich immer mehr auf die Maschine zu - nicht davon weg zu bewegen. Also nützt es mir nichts, wenn mir einer sagt, wie ich mein Zeug noch systemferner abstrahieren kann - weil's das Gegenteil von dem ist, was ich will.
Bei der Programmierung unter Borland Pascal 7 habe ich jedenfalls den Eindruck dass mit Assembler viel zu reissen ist. Allein weil der Compiler den Pascalcode in 286er-Befehle umwandelt, und da lässt sich mit 386er-Code oft einiges besser machen. Ich bekomme langsam Routine darin, online zu disassemblieren und die Opcodes abzutippen. Natürlich nach Möglichkeit in DW oder DD strukturiert.
DOSferatu hat geschrieben:[kompakt programmiertes Mario Bros ...]Soll also nicht heißen, daß man hier mit Methoden von 1985 programmieren/ entwickeln soll, wenn man eigentlich 486er mit 500-600 kB (Heap-) RAM hat. Es soll nur mal als Denkanstoß dienen, was alles geht, wenn man will.
Ja. Mit Speicher sparen gebe ich mir ja schon Mühe, und achte drauf nicht zu sehr in den unroll-Wahn zu verfallen - die Routinen müssen auch kompakt bleiben. Wobei ich das auch immer relativ zum Gesamtcode sehe, oder zur Speicherersparnis - aber gut, irgendwann ist der Laden eben dicht, und wenn es nur wegen einem Byte ist. Naja, was mir bleibt ist, mit viel Überlegung die Routinen möglichst effizient, d.h. schnell ausführbar zu gestalten, mit dem (nicht wirklich erreichbaren) Ziel, dass am Ende alles so läuft als wäre es nicht komprimiert. Aber eine gut programmierte Routine könnte durchaus gepackte Daten schneller verarbeiten als eine schlechte, je nachdem.
Ich habe vorhin kurz ein Video gesehen wo eine neue Voxel Engine gezeigt wird. Da komm ich mir mit meinen selbstgemachten Problemchen ja eigentlich ziemlich mickrig vor. Aber was soll's, HD-Voxel in Echtzeit kann und will ich gar nicht programmieren, und alle möglichen VR Sachen können andere einfach besser auf aktuellen Systemen mit GPU.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Und da denke ich auch daran, dass so ein ausführliches Spiel schon was Level-Design und Grafiken angeht ein ziemlich großes Projekt ist. Meine Schlussfolgerung wäre, dass ich für ein Spiel eine maßgeschneiderte Engine bauen würde, damit komme ich von meinem Gedanken den ich bis vor einiger Zeit hatte, eine Art generelle Spielengine zu bauen, ab.
Naja. Irgend eine Art "Spielengine" braucht man ja sowieso - ob man's "generell" macht oder nicht, macht von der Programmierung her wenig Unterschied. Zumindest für'n 2. Teil des "gleichen" Spiels kann man selbst eine spezialisierte (d.h. "nicht-generelle") Engine noch wiederverwenden. Und zumindest Dinge wie Anzeigen von Levels/Sprites oder Abspielen von Musiken/Soundeffekten sollte man in irgend etwas "generelles" auslagern - sowas braucht man nicht wirklich für jedes neue Spiel neu programmieren.
Sound- und Grafik "Engines" mache ich selbstverständlich modular, so dass man auch immer wieder etwas dran optimieren kann. Und das "Uhrwerk" des Spiels würde sicher auch in einer Unit verschwinden. Ich müsste dann einfach mal sehen inwieweit ich das dann universell einsetzbar mache. Beim ZSM-Player habe ich einfach das Hauptprogramm mit Routinen vollgeklatscht. Da war ich ungeduldig, unüberlegt, aber mir war das auch nicht so wichtig. Der Player ist ja eigentlich nur eine Demo von der Player-Unit, fing ganz klein und dürftig an, nur als Test, und ist dann immer mehr gewuchert.

Die Erklärungen zu Deiner VESA-Programmierung sind gerade etwas viel Input auf einmal. Ich speichere mir den Textabschnitt aber mal separat ab, damit ich darauf zurückkomme wenn mich das Thema gerade näher interessiert. Dann lernt man am besten.
DOSferatu hat geschrieben:Wenn man wie ich schon so ewig Grafikprogrammierung macht, lernt man dabei, extrem "um die Ecke" zu denken. Man denkt NICHT: "Ich habe Koordinate X und Y und Farbe C und der Pixel (X,Y,C) muß da hin" - sondern: "Ich befinde mich grade mit meinen Registern so, daß ich an Koordinate X,Y wäre, was sollte ich als nächstes machen, um so wenig wie möglich neu ändern/berechnen zu müssen?" Man denkt nicht in Pixeln, sondern in Bytes, die in einem Speicher liegen und die, wenn man es geschickt anstellt, am Ende die Anzeige ergeben, die man haben will.
So eine ähnliche Erfahrung mache ich gerade beim Programmieren mit Assembler, wenigstens ansatzweise. Ich habe z.B. bei ZSM zwei Befehle an zeitkritischer Position eliminieren können, bei denen ich lange Zeit dachte da wäre nichts mehr zu machen. Einfach mit mehr Ruhe und Erfahrung an die Sache rangegangen. Auch für die Schleifenroutine habe ich eine Idee zu einer Lösung, welche an zeitkritischer Stelle die Routine nur um einen Takt langsamer macht als die ohne Schleife. Um Penaltys zu vermeiden, vermeide ich direkt aufeinanderfolgende Speicherzugriffe.
EDIT: Ich habe jetzt auch davon gelesen, dass es Interlocks (AGI) gibt, wenn zwei aufeinanderfolgende Befehle dasselbe Register verwenden. Das verlangsamt den Programmablauf dann um einen Takt (bzw. Tick). Da vergeht einem ja fast der Spaß wenn es so komplex wird, aber es ist gut zu wissen. Allerdings blicke ich da noch nicht ganz durch, deshalb erwähne ich das hier.
Bei der ganzen Sache spielen 386er Befehle eine Rolle (mehrfache Einberechnung von Registern zur Adressierung, ohne Werte ändern zu müssen z.B.) aber auch eine gegenüber der alten Version klügere Koordination der Registernutzung. Der Lernweg ist wohl noch lange nicht zuende. Die Mnemonics und die Syntax sind eher einfach, aber richtig blickt man erst durch wenn man die ganze Struktur des Speichers und die Hardware versteht. Mit Assembler ist es wie mit dem Schreiben: Schreiben kann so gut wie jeder, aber nicht jeder ist ein guter Schriftsteller. Und es ist auch die Kunst, dem Computer Faulheit beizubringen. "Mach nur das was unbedingt sein muss." Hochsprachen kehren das ganze eher um... Klar, Software muss heute möglichst schnell geschrieben sein. Wie ganz oben zum Beispiel von Huffman: Bei einem Praktikum vor 20 Jahren sollte ich das mal in C schreiben. Hab's nicht hinbekommen aber ein Kollege schrieb das in ein paar Minuten runter um mir das zu zeigen. Wie gesagt frage ich mich, ob man das nicht auch ohne Rekursion schreiben kann um sich die vielen CALLs und PUSH/POPs sparen zu können.
DOSferatu hat geschrieben:Und ob man auf dem geraden, leicht-verständlichen, aber leider auch dümmstmöglichen Weg da hin kommt (zwei verschachtelte X und Y FOR-Schleifen, die dann sowas wie putpixel(X,Y,Color) aufrufen) oder etwas kreativer ist, indem man sich an die technischen Gegebenheiten der Speicheranordnung der Grafikkarte anpaßt, macht den Unterschied, ob man ein Hochsprachen/Skriptsprachen-User ist, der selbst ein simples 2D-Spiel nur mit wahnwitzig schnellen Maschinen ruckelfrei/spielbar bekommt oder ob man sowas hinkriegt wie die Typen, die heutzutage aufm C64 (mit 1 MHz und komischer Grafikspeicheranordnung) ein superbuntes 8-Wege-Scrolling-Spiel wie "Sam's Journey".
Habe ich mir gerade angesehen. Da bekommt man fast wieder ein schlechtes Gewissen wenn man so verspielt mit komischen Packformaten an ein Spiel gehen will. Aber ich würde soetwas sowieso niemals erreichen von der Performance her, d.h. annähernd eine angemessene Performance auf dem PC. Da spiel ich lieber rum mit meinen komischen Erfindungen, beim Spielen lernt man.
DOSferatu" hat geschrieben:Anders ausgedrückt: Wenn man sich EINMAL die Mühe macht, eine richtig geile Grafik- und Sound-Engine zu bauen, die viel kann, aber wenig braucht, hat man dann etwas, bei dem man genügend Speicherplatz und Rechenzeit übrig hat, um das alles für kreative Ideen für ein Spiel zu benutzen, weil man den Engine-Routinen vertrauensvoll "die ganze Arbeit" überlassen kann.
Ja, ich werde sehen was mir bei der ZVID2 Routine noch so einfällt. Scheinbar war ich ja (s.o.) bisher einfach nur blind für einige Lösungen.
DOSferatu hat geschrieben:Wie auch schon mehrfach erwähnt, macht Scrolling für mich nicht den Unterschied, ob ich ein Spiel gut finde / mir Spaß machen kann oder nicht. Scrolling ist nur eine Möglichkeit, eine "größere Welt" zu begehen, die größer ist als sie auf den Bildschirm paßt. Das Ganze kann etwas "Überraschendes" haben - weil man nicht von Anfang an alles sieht und auch etwas vom "Suchen", weil z.B. bei 8-Wege-Scrolling Finden von Boni/Geheimräumen eine Herausforderung sein kann.
Genauso kann aber auch ein Fixed-Screen-Spiel Spaß machen. Entweder, wenn das "Große Welt"-Konzept statt Scrolling durch Umblenden in angrenzende Räume (mit so "Ausgängen/Eingängen") gemacht wird (gibt sehr viele ältere Spiele, wo das so ist) oder wenn der Fixed Screen an sich viele interessante Möglichkeiten bietet, was man damit machen kann und man dann gleich auch das Ergebnis seiner Aktion sieht. Und selbst wenn man sich nur aus technischen Gründen gegen Scrolling oder gegen Sprites oder für/gegen Effekte oder für viele/wenige oder hohe/niedrige Auflösung entscheidet, kann das trotzdem Ansporn oder Herausforderung sein, nicht nur OBWOHL, sondern WEGEN solchen Beschränkungen ein ganz neues interessantes Spielkonzept zu entwickeln.
Ich lass mich irgendwie immer ein bisschen beeinflussen, wenn ich einem Freund von nem Jump&Run erzählt habe kam direkt quasi "aber muss dann mit Scrolling sein". Gut, die typischen Jump&Runs wo die Figuren so riesige schnelle Bewegungen machen brauchen einfach Scrolling, aber mit einem anderen Konzept geht das wohl auch ohne. Das sind mal schöne Aussagen von Dir, und es gibt so viele Jump&Runs, da könnte es fruchtbar sein, wie Du abschliessend geschrieben hast, dass man vielleicht sogar von den Beschränkungen inspiriert wird.

Danke für Deine Erläuterungen zu ISM! Speichere ich mir auch mal raus um es nochmal lesen zu können (ohne im Forum zu suchen).
DOSferatu hat geschrieben:
zatzen hat geschrieben:Vielleicht kannst Du Dich ja mit dem "Advanced Digiplayer" aus dem Hause Future Crew anfreunden. Müsste ich noch haben.
Achnaja, das Ding ist bestimmt professionell.
Und eigentlich will ich gerne etwas, das NOCH simpler und banaler als VOC386 ist, nicht komplexer. Ich brauch's wirklich nur zum Aufnehmen/Beschneiden. Ich wollte mir immer mal selber sowas schreiben. Prinzipiell weiß ich, wie ich per SB aufnehmen kann.
Professionell ist das nicht wirklich, aber schon etwas komplex, ja.
DOSferatu hat geschrieben:Eine andere Idee von mir (hab ich vielleicht schonmal erwähnt), ist ein Programm (vielleicht auch als prISM-Zusatzfunktion, aber ungern, weil ich Speicher freihalten will), bei dem man einfach ins Mikro summt oder pfeift (Pfeifen macht schön einfache fast perfekte Sinuswellen) und das Ding analysiert live die Wellenberge/Frequenz und macht daraus gerundete Daten mit Tonhöhe und Tonlänge, die man dann als "Melodie" (bzw ISM-File) in prISM importieren könnte. So könnte man viel schneller Ideen "komponieren"...
Ich würde das spontan auch eher extern handhaben, einfach ein Tool das einen Sound analysiert und die Notendaten als Datei ausspuckt. Ich muss aber sagen dass ich mit nem Tracker eine Melodie schneller einprogrammiert hätte als gepfiffen und aufgenommen, zumindest wenn man berücksichtigt dass dabei höchstwahrscheinlich Fehler bei Rhyhthmus oder Tonhöhe entstehen. Ansonsten natürlich eine gute Idee wogegen ich nichts sagen will, und auf dem C64 stelle ich mir das auch schön vor.
DOSferatu hat geschrieben:
zatzen hat geschrieben:[...]Aber ich weiss nicht ob ich das empfehlen kann, dazu müsste ich vergleichen was VOC386 so kann und wie ergonomisch es aufgebaut ist.
Ja, ich häng den mal hier an: [...]
Habe ich mir angesehen. Sieht so nicht schlecht aus (wobei man die Knöpfe kompakter/reduzierter hätte machen können und dafür irgendwie die Darstellung besser), natürlich ungewohnt für mich, weil ich seit über 20 Jahren mit ein und demselben Windows-Programm arbeite, was doch "etwas" mehr Komfort in Umfang und Bedienung bietet, und trotzdem übersichtlich ist. Vielleicht müsstest Du hier einfach trennen zwischen dem Idealismus, effizient für ein Zielsystem (486er) zu programmieren und einer Sache wie Sound-Bearbeitung, wo es nur aufs Endergebnis ankommt das absolut kompatibel aus der Windows-Software rauskommt. Die Oberfläche von VOC386 zielt ja eigentlich auf eine Windows-ähnliche Bedienung ab. Ich sähe dann höchstens einen Mehraufwand wenn Du die Dateien per Diskette transferieren musst, aber vielleicht (bzw. wahrscheinlich) ist Dein 486er per Netzwerk mit den anderen Rechnern verbunden.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ansonsten habe ich eine lange Zeit lang mehrgleisig gearbeitet: Aufnahmen in Windows gemacht, Samples bearbeiten ebenfalls dort, und dort auch nach 8 Bit und niedrigerer Samplerate für den X-Tracker konvertiert, der in früheren Versionen nur in echtem DOS lief und nicht in DosBox.
Ja, Windows... Da nutz ich inzwischen für manche grafischen Dinge gern Irfanview (kann ich zum Anschauen und Konvertieren von Bildern sehr empfehlen), weil sich's ganz gut bedient und ein paar ganz nützliche Funktionen hat. Wandeln von Bildern in palettenbasiert ist auch ganz gut, man kann sogar angeben, wieviele Farben man haben will. Das Ding wird von einem einzigen Typen immer weiter entwickelt und ist Freeware.
Wovon ich weiter oben schrieb... Genauso könntest Du mit Sounds verfahren. Irfanview benutze ich auch schon länger, wobei ich für wirkliche Bearbeitung noch sowas ähnliches wie Photoshop benutzt habe, aber jenes Programm funktioniert nicht mehr auf Windows 10 (Applaus), ging aber noch mit Win7. Jetzt bleibt mir nur noch Gimp erstmal.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Also das ist vielleicht nicht so super originell (aber fast schon wieder wie ein Running Gag weil es so viele Musik gibt mit genau dem drin) - aber ich finde gut und kreativ was Du an sonstigen Melodien dazugebastelt hast.
Wie schon erwähnt, bin ich Musik-/Soundtechnisch eher unterentwickelt - quasi unmusikalisch. Daher ist mein bescheidener Kram auch immer ganz gut erkennbar.
Ich wäre ja doch immer noch interessiert, was man aus ISM so rausholen kann. Für ZSM hatte ich mal die Idee, von Mike Batt "Caravans" umzusetzen, aber das ist doch ne Hausnummer zu hoch. Aber irgendwas anderes etwas einfacheres könnte ich mal in ISM (nicht ZSM) umsetzen, vielleicht hast Du ein paar Vorschläge aus denen ich mir was aussuchen kann. Ich hatte mal die Idee, den Pineapple Rag von Scott Joplin umzusetzen, aber in einer klein-orchestralen Version, d.h. nicht Klavier und auch kein großes Orchester, diese Version habe ich als Kind mal aus dem Radio aufgenommen, aber nur Bruchstückhaft und ich finde sie jetzt nicht mehr. Reicht aber vielleicht als Orientierung.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Mode-X Scanline erweitern:
Da fehlt mir etwas der Durchblick. Verstehe ich so ungefähr.
Ich bleib erstmal bei MCGA. Kann man da irgendwas sinnvolles mit Scanline-Manipulation machen?
Eher nicht. Das Problem ist nicht, daß es nicht geht, sondern daß es kaum Sinn macht. Der Grund ist, daß 320x200 ja schon fast die kompletten 64kByte benutzen. Man kann die Scanline nicht in 1er-Schritten erhöhen, sondern in 8er-Schritten (bei MCGA/Mode-X sinds 4er, wegen der Pixelverdopplung). Aber 324*200 ist 64800, bei 328*200 ist man schon bei 65600 (also über 65536) und das Bild wraparounded dann unten.

WAS aber geht, wäre bei 324*200 so softscrolling, weil man ja 4-pixel-weise das Bild verschieben kann und man bräuchte trotzdem nicht bei 4ern "clippen".

Das wäre z.B. auch eine Möglichkeit, Deine Sprites, die auf 4x4 Quadrate ausgelegt sind, nur an ganzen Quadraten abzubrechen, weil der "Umbruch" sowohl links als auch rechts in den "unsichtbaren" Bereich geschrieben werden würde.
Da muss ich nochmal nachhaken, das klingt ja interessant. Ich hatte bisher geplant, dass ich den Puffer mit maximal 326x201 anlege, so hätte ich einen nutzbaren Bereich von 320x195. Es verschwinden ja von den 4x4 Blocks immer nur 3 Pixel in jeder Himmelsrichtung im unsichtbaren Bereich, bevor diese abgeclippt werden. Mit einer Breite von nur 324 dürften ja links und rechts nur 2 Pixel überragen.
Aber das mit dem Scrolling hört sich interessant an. Heisst das, das Scrolling wäre in 4-Pixel Schritten? Wie auch immer, ich glaube Scrolling würde mich mit meinen Konzepten erstmal noch überfordern.

Aber Moment, denke ich schon wieder zu wenig um die Ecke?
Wenn ich jetzt mal einfach den Puffer auf nur 324er Breite anlege, und ich den Bereich 2-321 als sichtbar definiere. Was passiert wenn links 3 Pixelspalten rausragen? Sie erscheinen (bzw. eine Spalte davon) eine Zeile höher rechts, aber im unsichtbaren Bereich. Umgekehrt rechts rausragend: Ein Pixel erscheint eine Zeile tiefer links im unsichtbaren Bereich. Müsste eigentlich so funktionieren wenn man sich dann noch etwas Gedanken über die Dimensionierung oben und unten macht.
Da muss ich einfach sehen wie ich es mache, 324er Breite gibt auch nur eine Zeile mehr in 64K, die man auf eine Weise wieder verliert wegen dem horizontalen Wraparound.
Zuletzt geändert von zatzen am Di 2. Feb 2021, 00:12, insgesamt 3-mal geändert.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Kleines Update was GetMem angeht:
Ersteinmal zur Übersicht die Zeilen Code die beim Aufrufen der Funktion generiert werden:

Code: Alles auswählen

0x0000000000000000:  B8 CD AB          mov   ax, 0xabcd { $ABCD Bytes Speicher reservieren }
0x0000000000000003:  50                push  ax
0x0000000000000004:  9A 8A 02 06 00    call 6:0x28a { abhängig wie das Programm letztlich kompiliert wird }
0x0000000000000009:  A3 50 00          mov   word ptr [0x50], ax
0x000000000000000c:  89 16 52 00       mov   word ptr [0x52], dx
Dann habe ich den Code der eigentlich Funktion in der EXE gefunden:

Code: Alles auswählen

0x0000000000000000:  55          push bp
0x0000000000000001:  8B EC       mov  bp, sp
0x0000000000000003:  8B 46 06    mov  ax, word ptr [bp + 6]
0x0000000000000006:  E8 C0 00    call 0xc9 {der rechnet hier die absolute Adresse aus, anhand des Code-Ausschnitts }
0x0000000000000009:  5D          pop  bp
0x000000000000000a:  72 03       jb   0xf
0x000000000000000c:  CA 02 00    retf 2
0x000000000000000f:  B8 CB 00    mov  ax, 0xcb
0x0000000000000012:  E9 70 FE    jmp  0xfe85 { $FE70 = -400, wo auch immer er da hinspringt... vielleicht Fehlermeldung }
Da muss man erst nochmal den CALL nacherfolgen und sehen was sich dahinter verbirgt...
Okay, ich hab den Einstiegspunkt gefunden, aber dann folgt eine ziemlich lange und komplizierte Routine wo auch wieder ein CALL drin ist usw. Da fehlt mir jetzt doch die Motivation dahinterzusteigen.

Aber was mir die Sache gezeigt hat: Im Grunde ist so ein Programm simpel aufgebaut, man kann sich auch in einer EXE zurechtfinden. Mein Einstieg war, dass ich eine Testroutine geschrieben habe die an Position $50 platziert wurde. Das Codesegment war auf diese Adresse verankert, wird Dir nix neues sein. Sieht wahrscheinlich bei größeren Dateien anders aus.
Dieses disassemblieren geht hier mit Multitasking sehr bequem (EXE ist im HexEditor geladen, der auch schon punktuell disassembliert), wenn ich in der DosBox kompiliere aktualisiert der sofort, dann Abschnitte markieren und in den Online Disassembler damit.
Das bringt einfach alles ein besseres Verständnis von den ganzen Zusammenhängen.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Ich bin gerade darüber gestolpert, dass PUSH/POP das Register BP verwendet. Mir war schon klar dass BP bei Parameterübergabe beiteiigt ist. Bisher funktioniert auch alles wo ich BP mit PUSH/POP gesichert habe und zwischendrin für was anderes benutzt habe, bei Routinen ohne Parameter. Aber vielleicht sollte ich es lieber im Speicher sichern?
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

Hallo, zatzen!
Zuerst mal möchte/muß ich um Verzeihung bitten, weil ich mich so lange nicht gemeldet habe.
Am 15. Januar 2021 hat eine der 3 Festplatten in meinem geliebten 486er ohne Vorwarnung den Geist aufgegeben - früh lief sie noch, als ich Abends nach Hause kam und den Rechner startete: keine Reaktion. Ich habe die Platte zu 2 verschiedenen so "Rettungs-Firmen" gegeben - ohne Erfolg. Die 2. hat die Platte wohl nicht mal geöffnet. Als ich am Telefon fragte, wieso die mit Reinraum werben und daß man davon ausgeht, daß die die Scheiben einzeln auslesen (Laser etc) wollte der mich für dumm verkaufen, im Sinne von "Jaja, das ist es, was die Leute immer denken..." und ich dachte: Deswegen geben die Leute das zu so Firmen. Kumpel sagte mir dann: Ja, die Firma kennt er, die wollen nur ihre File-Recovery-Tools verkaufen.

Aber es war eben ein Hardwareschaden. Und seien wir ehrlich: Wenn ein DOS-Freak, der nicht völlig bekloppt ist, noch selber die Sektoren lesen könnte, bräuchte er nicht so'ne Firma. FAT16 softwaremäßig wiederherstellen ist ja kein Hexenwerk. So Firmen sind wohl bloß für so Mausschieber und Bildchenklicker...

Naja, und dann habe ich mit dem, was auf den anderen Rechnern verteilt war, mein Zeug wiederhergestellt. Von meinem selbstgebauten Kram konnt ich so 95% wiederstellen. Andere Daten oder Tools ca. 50%. Wenigstens kann ich jetzt wieder coden. Aber sowas nimmt einen eben mit.

Das eine Tool für meinen Kumpel (der brauchte es eben kurzfristig) hatte ich deshalb teilweise unter DOSbox auf 'nem Windows-Rechner bauen müssen, das ist so unwürdig...
zatzen hat geschrieben: Do 19. Nov 2020, 16:05Ja, bei Freepascal (oder Windows eben) fehlt ja einfach die direkte Möglichkeit, Hardware anzusprechen, und wie man dann unter Windows aus dem Programmspeicher heraus Sound wiedergibt und nicht nur aus Dateien heraus (wie es diese Libraries irgendwie nur anbieten), das verstehe ich noch nicht.
Ja, unter so Multitasking-Zeug ist direkter Zugriff eher eine schlechte Idee, weil Ressourcen ja vom OS verwaltet werden. Und "am OS vorbei" zu coden, selbst wenn man's hinkriegt, führt dann oft zu Problemen beim Restsystem.
zatzen hat geschrieben:PCX/BMP ist ja nicht so das Problem, aber vor Formaten wie JPG habe ich noch Respekt.
Naja, PCX/BMP sind ja simpel. JPG habe ich auch noch nicht gemacht.
Ich habe mal eine Doku zu PNG gelesen - an sich machbar. Nur das eigentliche "Packen" wird mit dem ZIP-Algorithmus gemacht und da steht dann nur, daß man "den ja einbinden kann, weil er sowieso in den meisten OS schon da ist". Zu ZIP habe ich zwar auch schon Doku, aber bisher keine Lust gehabt, das selber umzusetzen. Keine hohe Priorität - vor allem jetzt, wo durch den HDD-Crash anderes liegengeblieben ist.
zatzen hat geschrieben:Wiederum habe ich aber auch keinen Schimmer wie man mit Freepascal Vollbildgrafik anzeigt und das wiederum aus dem Programmspeicher heraus und nicht bloß eine Library auf eine Datei ansetzen.

Code: Alles auswählen

asm mov ax,13h;int 10h;end;
geht nicht?
Naja, Vollgrafik setzt voraus, daß das OS es einem überhaupt erlaubt. Ab Win7 (oder sogar schon Vista?) geht das wohl gar nicht mehr - selbst wenn etwas wie "Vollbild" aussieht, wird das soweit ich weiß emuliert. Kann mich aber irren.
zatzen hat geschrieben:GIF beinhaltet Huffmann, vielleicht sollte ich mich damit mal befassen, ich hab es bisher nicht gerafft mit diesen Rekursionen. Vielleicht geht es auch nicht-Rekursiv.
Ja, ich "baue mir meine Rekursionen meist selbst", d.h. lege selber einen künstlichen Stack an und sichere nur, was wirklich gesichert werden muß. (siehe Posting-Ende)- GIF lesend hab ich schon gebaut (länger her), will aber mal lesen UND schreiben bauen und in meine Bild-Lade/Speicher-Unit einbauen. Dann können meine ganzen Grafik-bearbeitenden Programme, die die Unit nutzen automatisch GIF, wenn ich's neu compiliere.
zatzen hat geschrieben: Irgendwo hier im Forum sagte mal jemand, da wäre eine Huffman-Decodier-Routine die so schnell wäre wie memcpy bzw. einfaches Speicher-Kopieren. Das kann rekursiv ja gar nicht gehen, weil dabei ständig Takte für Funktionsaufrufe verbraten werden.
Wie gesagt: Geht ohne Funktionsaufrufe. Sowas mit Funktionsaufrufen machen nur Anfänger, die sich nicht klar über Speicher-/Rechenzeitverbrauch sind, oder Skript-Coder, die sich unklar über... naja eigentlich ALLES sind.
zatzen hat geschrieben:Ich versteh nix von Programmierung mit Klassen und sowas, und wenn ich Daten nicht in ein eigenes Datenfeld einlesen kann bringt mir das nichts. [...] Freepascal hat ja Zugriff auf 2 oder 4 GB. Und die Segmente sind auch nicht auf 64K beschränkt, das "flat" Speichermodell ist ja ein ganz anderes. Daher kann man einfach z.B. ein Array von 1 GB Größe definieren. Es macht dann keinen Unterschied und ist, wenn man eben rein in Pascal programmiert, ganz praktisch mit Arrays zu arbeiten und keine Pointer für Zugriffe bemühen zu müssen.
Ja, aber genau diese Art Programmierung macht Programme UND Systeme langsam. Erstens ist nicht überall so viel Speicher eingebaut, zweitens brauchen OS und andere Prozesse auch Speicher. Was macht das OS dann? Lagert RAM auf Festplatte aus und swappt zwischen Festplatte/RAM ständig hin und her um "mehr RAM zur Verfügung zu stellen, als vorhanden". Deshalb bin ich kein Freund von "reservieren wir erstmal einen riesigen Speicherklotz und sehen dann, was wir brauchen". Muß jeder selbst wissen - aber für mich totales Anti-Pattern.
zatzen hat geschrieben:[...] Übrigens wegen Speicherverwaltung: Ich will nicht einfach Dein System übernehmen sondern wenn, mir eines selber basteln, damit ich da auch durchblicke und ich es nach meinem Geschmack gestalten kann.
Klar. Ich mach meinen Kram auch immer alleine, übernehm nicht ungesehen fremde Bibliotheken.
zatzen hat geschrieben:Ich habe mal die Functions Getmem und Freemem unter die Lupe genommen, was der Compiler draus macht. Nun, er generiert einen CALL mit Parameterübergabe, einmal an Programmadresse 6:$028a und an 6:$029f. Gerne würde ich mir den Assembler-Code dieser Routinen ansehen, um zu verstehen versuchen was Pascal da wirklich macht (denn dann könnte man ja evtl. eigene Routinen schreiben), aber dazu müsste ich erstmal genau im EXE Format durchblicken um die Position des Codes ausfindig zu machen.
Diese Adressen liegen im RAM - und zwar innerhalb Deines Programms. Die haben nichts zu bedeuten. Wenn Du ein anderes Programm schreibst, werdem die GetMems woanders hin zeigen. Meiner Meinung nach sind dann irgendwo INTs, die entsprechende DOS-Funktionsaufrufe machen, weil die Speicherverwaltung ja von DOS aus passiert. Sollte in Ralph Brown's Interrupt List zu finden sein. Bei FreePascal kann ich's natürlich nicht sagen, da kommt's sicher drauf an, für welche Plattform man's compiliert.
zatzen hat geschrieben:Sicherlich kann man sich auch einfach informieren wie man unter blankem Assembler den Heap verwaltet, aber ich bin einfach mal neugierig wie Getmem und Freemem funktionieren.
Das wird auch nicht anders sein als was man selber machen würde. Auf irgend eine Art wird gespeichert, welche Segmente schon belegt sind. GetMem/FreeMem machen aber eins nicht: Sie verschieben keinen Speicher, d.h. wenn man Speicher belegt, dahinter noch welchen und dann den ersten wieder freigibt, entsteht ein freies "Loch" von der Größe. Belegt man dann nochmal Speicher und der ist größer als das "Loch", bleibt es frei und der neue Speicher wird hinter den zweiten gelegt, usw. Meine Speicherverwaltung vermeidet das, indem sie solche Löcher immer gleich schließt, daher auch "dynamische" Speicherverwaltung.
zatzen hat geschrieben:[...]Mir wird an dieser Stelle mal klar, dass ich eigentlich bisher nie versucht habe, auch nur in die Nähe von schnellen "Arcades" zu kommen. In meinen Basic-Zeiten war alles durch Basic selbst und meine Unfähigkeit limitert, dann kam Pascal und Assembler, aber damit ist noch kein richtiges Spiel fertig geworden.
DOSferatu hat geschrieben:Naja, erinnert auch an mich - ich nenne mich Imperial Games - aber so richtig "Game"-mäßiges, auf das man stolz sein könnte, ist von mir auch noch nicht gekommen.
Ein bisschen Team wäre vielleicht gut. Wenn sich nicht einer um alles zu kümmern hat geht dann auch alles schneller. Aber wir hatten da schon das Problem mit der Verlässlichkeit thematisiert. Auf mich könntest Du Dich verlassen, aber ich kann Dir nur Sound/Musik bieten.
Naja, wie Du schon schriebst, Thema Verläßlicheit. Ich selbst komme auch kaum noch zum Entwickeln. Unter der Woche wenig Zeit, kombiniert mit Müdigkeit. Auch Wochenende werd' ich selten richtig wach/fit. Und im halbkomatösen Zustand coden bringt kaum was, weil man damit nur ineffizienten verbuggten Code baut, bei dem's am Ende mehr Arbeit macht, zu debuggen als gleich neu zu coden.
zatzen hat geschrieben:Klar, Bremsschleifen sind ein No-Go für mich. Wie ich eine dynamische Framerate realisiere ist mir noch ein Rätsel, aber ich möchte da selbst draufkommen.
Der Timer (IRQ0=INT8) wäre ein guter Ansatz.
zatzen hat geschrieben:...was aber interessant wäre, wenn man eine Art KI hätte die passend zu jeder Spielesituation entsprechende Musik macht. Aber das wäre wohl mit Kanonen auf Spatzen geschossen, bei Spielen wie Super Mario genügt es, wenn die Musik auf einmal schneller ist wenn die Zeit knapp wird, und das iMuse System von LucasArts ist eine andere sehr ausgeklügelte Sache. Die ich selber aber nicht anstrebe, da sie mit den Tracker-Gepflogenheiten schwer vereinbar ist.
Das iMuse ist gar nicht mal so "ausgeklügelt" wie man denken könnte. Prinzipiell laufen da alle Musikstücke "stumm nebeneinander" und die Stimmen, die gerade gebraucht werden, werden eingeblendet und die anderen ausgefaded. Zumindest bei MI2 zu Anfang - in "Woodtick", diesem Schiff-Dorf. Das wird dann nach Lokation entschieden. Der Witz dran ist, die verschiedenen Stimmen im gleichen Takt anzulegen.
zatzen hat geschrieben:Ansonsten gibt es natürlich durchaus Musiker, die einen großen Wert auf ihre Studioproduktionen legen und dort erst richtig kreativ werden, ein Beispiel sind die Beatles.
Naja, da es mir ausschließlich um Begleitmusik für meine Spiele geht und ich an 'Standalone' gar nicht denke (bin ja kein Musiker), spielt das für mich keine Rolle. Und mein "Studio" ist mein 486er und prISM.
zatzen hat geschrieben:Ich denke jetzt, darüber muss man sich irgendwie philosophisch hinwegsetzen. Das mit DosBox könnte eine Hürde sein (wenn ich allein schon diese vielen Youtube Videos sehe wo man noch das Windows-Fenster um die DosBox sieht - hey, das kann auch Fullscreen!), andererseits gibt es Youtube und man kann dort vermeintlichen Retros Appetit auf sein Spiel machen, bis sie angefixt genug sind um die Hürde zu nehmen und DosBox zum Laufen zu bringen. Ansonsten mache ich eben jetzt einfach.
Naja, für mich ist es bloß ein Hobby - ich mache das nicht, um "berühmt zu werden". Wenn's ein paar Leuten gefällt, ist zwar schön und Bestätigung dafür, daß es ein brauchbares Spiel geworden ist, aber die wirkliche Befriedigung ist eigentlich das Selbsterschaffen eines Werks mit den mir möglichen Dingen.
zatzen hat geschrieben: [...] Ich sehe mein gemütliches Gecode hier so ähnlich an wie sich durch ein Rätselhaft arbeiten. Nur dass am Ende nicht bloß irgendwelche Lösungswörter rauskommen, sondern schöne Anwendungen oder Spiele. Eine Art Kunst vielleicht auch, so wie manch ein Maler Bilder malt aber diese nicht für Geld oder überhaupt loswird. Übrigens das Problem mit der schnellen Systemveraltung hatten auch die Entwickler von der Fortsetzung von Duke Nukem 3D. Das Spiel musste immer wieder verzögert werden weil es fähigere Hardware gab und die Software das nicht ausreizte. Oder das war nur ein Gerücht und die brauchten einfach so lange. Wäre aber plausibel. Aber sowas muss und kann uns egal sein, weil wir nichts verkaufen wollen und von nichts abhängig sind.
Es war kein Gerücht, aber der wahre Grund war ein anderer: Die wollten das beste Spiel der Welt draus machen und waren verständlicherweise immer langsamer als die aktuelle technische Entwicklung. Haben immer wieder 3D-Engines verworfen und neue, bessere genommen. Irgendwann ist denen aber aufgefallen, daß sich das Projekt nach 14 Jahren Laufzeit so langsam zum Treppenwitz der Softwareentwicklung verwandelt hat und haben's dann rausgebracht. Es lebt aber ehrlich gesagt nur vom "Duke"-Bonus, denn technisch/grafisch gabs damals schon besseres.
zatzen hat geschrieben:Wenn ich hier ernsthaft Musik produziere muss ich zusehen dass es auch rein klanglich möglichst optimal ist, das ist weitestgehend unabhängig von Musikgeschmäckern (ich bearbeite auch schonmal Musik von anderen klanglich). Wenn ich die ganz hohen Tönchen nicht mehr wahrnehme kann ich keine Aussage darüber machen ob da oben zu viel oder zu wenig los ist. Ein Analyzer stellt das dar, und da kann ich einfach sehen was ich nicht mehr höre. In etwa vergleichbar mit einer Lupe. Als Kind konnte man vielleicht noch sehr kleine Dinge einfach sehen, aber später werden die Augen schlechter und man nimmt als Hilfmittel zwischendurch ne Lupe um sicherzustellen dass die Details auch stimmen.
Ja, schon. Aber der Vergleich hinkt: Mit Lupe: Etwas SEHEN, was man sonst nicht SEHEN kann. Aber ein Tool, mit dem man etwas SEHEN kann, was eigentlich GEHÖRT werden soll, ist kein Vergleich. Wenn ich da irgendwelche Werte sehe, hab ich trotzdem keine Klangvorstellung davon im Hirn.

Selbst wenn ein Blinder, der mal sehen konnte ein Bild malt nach Erinnerungen, wie Farben aussehen, wird es nicht so malen können wie jemand, der wirklich sieht was er tut und wie das Ergebnis aussieht. Und so denke ich auch bei Sound: Wenn man an einem Programm sieht, ob es 'so klingt wie es soll', ohne es selbst als der Komponist zu hören... Da muß man schon ein Genie wie Beethoven sein, der seine letzten Stücke komplett taub komponiert hat.
zatzen hat geschrieben:Naja, vielleicht doch nicht soo rechenintensiv. Auf jeden Fall kann die AdLib, wenn geschickt programmiert, schon wirklich nette Sounds machen.
DOSferatu hat geschrieben:Ich weiß. Dazu muß man aber Ahnung von Sound haben. ICH wüßte nicht vorher, wie sich das anhört, wenn ich da irgendwelche Werte setze, d.h. ich müßte so lange herumprobieren, bis es so klingt wie ich will.
Ganz so schwierig fand ich das nicht, aber es war natürlich Herumprobiererei.
Ja, aber als ich das in diesem Soundblaster-Buch gelesen habe, wie man die Adlib-Stimmen setzt, man so kombinierende Sinuswellen nimmt... Da müßt ich ewig rumprobieren, bis das dann das wird, was es soll. Liegt bei mir aber wohl auch dran, daß ich vom SID ausgehe und deshalb erwarte, sowas wie Rechteck-/ Sägezahn-/ Dreieckwellen haben zu wollen.
zatzen hat geschrieben:Letztlich ist mir der AdLib-Sound aber irgendwie zu stereotyp,
Ja, man hört quasi immer gleich, wenn es AdLib ist. Aber das muß ja nicht schlecht sein. Gibt Leute, die da Großartiges geleistet haben.
zatzen hat geschrieben:Samples bringen da viel mehr frischen Wind rein.
Naja, wie Du weißt, bin ich nicht so Fan von Überbeanspruchung von Samples - und wenn, dann kleine Samples, die z.B. für Sounds sind, die man mit Wellenformen/Kombinationen nicht oder nur sehr aufwendig hinkriegt (z.B. Percussions oder Gitarrenriffs). Also eher Länge weit unterhalb 1 Sekunde.

Aber so ganz lange Klänge und daraus Stücke zusammenbauen, das wäre so gar nicht meins. Speicherverbrauch ist da nur einer der Gründe - wenn auch kein unwesentlicher: Da ich kein Musiker bin, daher also nicht vorhabe, Standalone-Musik zu machen, sondern eher Untermalung für Spiele, ist Speicherverbrauch kein unwesentliches Thema.

Nehmen wir z.B. an, ich hätte 64kB Leveldaten, 64kB Spritedaten, 64kB Pattern ("Levelblöcke") Daten - zusammen 192kB. Und nun hätte man dazu gleiche Größe (192kB) Soundsample-daten, 8bit, 32kHz (nur mal als Beispiel). Durch das Level läuft man einige Minuten lang, die Blocks und Sprites sieht man beim Spielen die ganze Zeit und hat daran die ganze Zeit Freude. Und die Sounddaten sind zusammengenommen in diesem Beispiel 6 Sekunden Klang. Damit kann man zwar theoretisch eine Menge anstellen - aber wenn man lange Samples nimmt, hört man alle paar Sekunden das gleiche lange Sample - wird schnell öde.

Und dann kommt vielleicht noch ein Sound-Purist, sagt: 32kHz is ja wie Mittelalter - wir brauchen 48kHz! - Blieben 4 Sekunden. Alternative wäre gleich 384kB oder 512kB Sounddaten - paßt ja alles noch in Heap. Aber in Heap muß auch Programmcode und Level, Steuerung, Grafiken... Wir Realmode-Bastler haben zwar Möglichkeit, auf XMS zuzugreifen - aber eben nur indirekt. Und das sind dann so Überlegungen, die ich anstelle. Ich bin sowieso nicht gut genug für gescheite Musik, da helfen auch keine Samples. Da müßt man gute Samples finden und damit kreativ sein... - Da ist für mich einfacher, mit 'ner Handvoll vorgegebener/ rekombinierbarer Wellen irgendwas zusammenzubauen.
zatzen hat geschrieben:Und auch ISM, weil es Klänge machen kann die AdLib nicht kann.
Ja, und ISM kanns außerdem in aus Sicht eines Soundfetischisten total unterirdischer Qualiät. - Auch etwas, das AdLib nicht kann. :)
zatzen hat geschrieben:
DOSferatu hat geschrieben:[VGA Palette]Ich find's aber interessant, daß man häßliche 6-7-6 oder 8-8-4 oder ähnliche Paletten benutzen - aber damit schränkt man sich eben ein, weil man manche der Farben daraus überhaupt nicht benutzen würde und bei anderen wiederum nicht genug hätte, um einen Grün- oder Hautton feiner abzustufen. Und wenn man nur 256 Farben hat, sollte man diese nicht durch irgendwelche "Generalisierungen" verschwenden und die ohnehin schon begrenzte Menge Farben mit unbrauchbaren Farbtönen noch weiter einschränken.
Das ist ein überzeugendes Argument. Bloß wenn man es komplett mit eingescannter Grafik zu tun hat deren Farbinhalte man nicht gezielt bestimmen kann scheint eine generalisierte Palette plausibel.
Nein, das kann man auch anpassen, da gibt es gute Algos, gab's damals schon. Mein Malprogramm (256 Farben) macht das z.B. auf Wunsch auch, wenn man 24bit-Bilder lädt. Und: Die Grafiken der LucasArts-Spiele SIND gezeichnet und gescannt! Die wurden gezeichnet, gescannt und runtergerechnet - spätestens bei Monkey Island 2.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[Notdürftige Tools für Grafik]Kenn ich: Auf meinem KC 85/4 (der Ost-Computer, den ich vor dem C64 hatte), habe ich Levels auf Kästchenpapier erstellt, mit Zahlenwerten, diese dann als DATA-Zeilen eingegeben. Ziemlicher Pain-In-The-Ass, aber wie Du schon sagtest: Damals hatte man noch diese Energie.
Ja, es ist verrückt. An sowas mit Kästchenpapier und Zahlen erinnere mich auch, nur habe ich das mal mit Grafik gemacht. War wohl EGA bzw. die ersten 16 der VGA, die Farbwerte kennt man ja auswendig. Ich hab auch oft in der Schule so neben dem Unterricht oft irgendwas geschrieben, oder hatte auf einem Familienausflug einen Zettel dabei... Total besessen irgendwie. Es ist heute letztlich effektiver, wenn man mit mehr System an Problemlösungen rangeht.
Das liegt u.a. auch daran, daß man früher VIEL MEHR ZEIT hatte. Heute MUß man quasi "mit System" rangehen, weil man sonst gar nicht mehr fertig wird. Job, Pennen und (wenn vorhanden) Restleben, sowie natürlich ständige Müdigkeit sind totale Performancekiller.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Diese ganzen User von Interpretern/Skripts sind einfach überhaupt keine Ansprechpartner mehr für mich. Die machen vielleicht auch ihr Zeug und es funktioniert und so... - aber was sollen die mir beibringen? Mein Weg ist ja, mich immer mehr auf die Maschine zu - nicht davon weg zu bewegen. Also nützt es mir nichts, wenn mir einer sagt, wie ich mein Zeug noch systemferner abstrahieren kann - weil's das Gegenteil von dem ist, was ich will.
Bei der Programmierung unter Borland Pascal 7 habe ich jedenfalls den Eindruck dass mit Assembler viel zu reissen ist. Allein weil der Compiler den Pascalcode in 286er-Befehle umwandelt, und da lässt sich mit 386er-Code oft einiges besser machen. Ich bekomme langsam Routine darin, online zu disassemblieren und die Opcodes abzutippen. Natürlich nach Möglichkeit in DW oder DD strukturiert
.
Ja, ich auch. War vor dem Festplatten-Ausfall auch an was dran, um das zu erleichtern (nehme an Du ahnst wovon ich rede). Wwill da noch nicht zu viel verraten - an dem Projekt muß ich noch einiges umstrukturieren. Aber SOLLTE es jemals fertig werden, wird's wohl für einige DOS/Pascal+ASM Coder ein Fest...
zatzen hat geschrieben:
DOSferatu hat geschrieben:[kompakt programmiertes Mario Bros ...]Soll also nicht heißen, daß man hier mit Methoden von 1985 programmieren/ entwickeln soll, wenn man eigentlich 486er mit 500-600 kB (Heap-) RAM hat. Es soll nur mal als Denkanstoß dienen, was alles geht, wenn man will.
Ja. Mit Speicher sparen gebe ich mir ja schon Mühe, und achte drauf nicht zu sehr in den unroll-Wahn zu verfallen - die Routinen müssen auch kompakt bleiben. Wobei ich das auch immer relativ zum Gesamtcode sehe, oder zur Speicherersparnis - aber gut, irgendwann ist der Laden eben dicht, und wenn es nur wegen einem Byte ist.
Wobei Unroll-Loop nicht das Schlechteste ist. Noch viel mehr Speicher als mit schlechtem Code versaut man mit schlecht organisierten/aufgeblähten Daten.
zatzen hat geschrieben:Naja, was mir bleibt ist, mit viel Überlegung die Routinen möglichst effizient, d.h. schnell ausführbar zu gestalten, mit dem (nicht wirklich erreichbaren) Ziel, dass am Ende alles so läuft als wäre es nicht komprimiert. Aber eine gut programmierte Routine könnte durchaus gepackte Daten schneller verarbeiten als eine schlechte, je nachdem.
Kommt meiner Meinung nach immer auf den Einzelfall an, da gibt's keine pauschale Aussage. Manchmal verschwende ich absichtlich Speicher, wenn der Geschwindigkeitsvorteil enorm ist. Manchmal verzichte ich absichtlich auf Performance, wenn viel Speicher wichtiger ist.
zatzen hat geschrieben:Ich habe vorhin kurz ein Video gesehen wo eine neue Voxel Engine gezeigt wird. Da komm ich mir mit meinen selbstgemachten Problemchen ja eigentlich ziemlich mickrig vor. Aber was soll's, HD-Voxel in Echtzeit kann und will ich gar nicht programmieren, und alle möglichen VR Sachen können andere einfach besser auf aktuellen Systemen mit GPU.
Echtzeit-Voxel-Kram sollte man auf 486er (und RealMode) echt seinlassen. Der ist dafür wirklich nicht die geeignete Maschine! Abgesehen von der Rechenpower, die das braucht, sind auch die benötigten Speichermengen viel zu abartig. Voxel ist zwar die plausibelste Idee, wenn man "Pixler" ist und dann "auf 3D gehen" will - aber ist eigentlich die schlechteste Methode, 3D zu machen. Die vielen Nachteile überwiegen die wenigen Vorteile.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]Naja. Irgend eine Art "Spielengine" braucht man ja sowieso - ob man's "generell" macht oder nicht, macht von der Programmierung her wenig Unterschied. [generalisierte Routinen]
Sound- und Grafik "Engines" mache ich selbstverständlich modular, so dass man auch immer wieder etwas dran optimieren kann. Und das "Uhrwerk" des Spiels würde sicher auch in einer Unit verschwinden.
Ja, das was ich immer "die Steuerung" nenne...
zatzen hat geschrieben:Ich müsste dann einfach mal sehen inwieweit ich das dann universell einsetzbar mache.
Wo wir ja vorhin bei Effizienz und "keine Zeit haben" waren: Universelle Einsetzbarkeit ist nicht zu unterschätzen. Die Idee bei Arbeit mit Computern ist ja, daß irgendwann der Computer die Arbeit macht. Immer wieder das gleiche coden kostet unnötig Zeit, die besser in neuen Code investiert wäre. Und ja, ich weiß: Manchmal sind Aufrufe von Subroutinen ein Hakenfuß, weil sie Zeit/Stack kosten - aber eben nicht immer. Nicht jede Routine der Welt ist "zeitkritisch". Wiederverwendbarer Code ist wertvoller Code.
zatzen hat geschrieben:Beim ZSM-Player habe ich einfach das Hauptprogramm mit Routinen vollgeklatscht. Da war ich ungeduldig, unüberlegt, aber mir war das auch nicht so wichtig. Der Player ist ja eigentlich nur eine Demo von der Player-Unit, fing ganz klein und dürftig an, nur als Test, und ist dann immer mehr gewuchert.
Bei so Testprogrammen macht das nichts - die müssen schnell fertig werden und sind ja eher ein Nebenprodukt. Wenn man sich mit denen zu viel Zeit/Aufwand läßt, ist keine Zeit mehr für's eigentliche Projekt. Ich hab einige Testprogramme hier, die hab ich derart schnell und schlampig zusammengeschustert, daß sie keinerlei Sicherheiten haben und bei Fehlbedienung oder falschen Daten einfach gnadenlos abstürzen.
zatzen hat geschrieben:Die Erklärungen zu Deiner VESA-Programmierung sind gerade etwas viel Input auf einmal. Ich speichere mir den Textabschnitt aber mal separat ab, damit ich darauf zurückkomme wenn mich das Thema gerade näher interessiert. Dann lernt man am besten.
Ja, den VESA-Kram hatte ich ja nur im Zusammenhang mit diesem kleinen Demo erwähnt. Der sollte nur verdeutlichen, wie schnell so ein 486er WIRKLICH ist. Ich meine: 640x480=307200 gegen 320x200=64000. Ich schaufle also inkl. Scrolling, das 4,8-fache an Daten durch die Gegend als mit MCGA. Da sind die Sprites und die Schrift noch nicht mal mitgerechnet. Es sollte nur verdeutlichen, daß ein 486er (und auch noch mit Assemblerprogrammierung) für so'n bißchen MCGA auf keinen Fall irgendwie "zu langsam" wäre.
zatzen hat geschrieben:
DOSferatu hat geschrieben: [Grafikprogrammierung in Asm]
So eine ähnliche Erfahrung mache ich gerade beim Programmieren mit Assembler, wenigstens ansatzweise. Ich habe z.B. bei ZSM zwei Befehle an zeitkritischer Position eliminieren können, bei denen ich lange Zeit dachte da wäre nichts mehr zu machen. Einfach mit mehr Ruhe und Erfahrung an die Sache rangegangen. Auch für die Schleifenroutine habe ich eine Idee zu einer Lösung, welche an zeitkritischer Stelle die Routine nur um einen Takt langsamer macht als die ohne Schleife. Um Penaltys zu vermeiden, vermeide ich direkt aufeinanderfolgende Speicherzugriffe.
Wo man die Möglichkeit hat, aufeinanderfolgende Zugriffe auf Speicher oder auf die gleichen Register zu vermeiden, sollte man's tun. Man muß nur aufpassen, daß man nicht deswegen den Code umständlicher (und damit auf andere Weise langsamer) macht, dann hätte man damit nichts gewonnen.

Achja, und ich neige ja (leider) dazu, meinen Code zu wenig zu kommentieren. Aber: Wenn man mal wirklich mit einer total schrägen abgefuckten Idee extrem effizienten Code an einer Stelle hingekriegt hat, sollte man das unbedingt dokumentieren! Sonst fragt man sich, wenn man nach 3 Monaten den Code nochmal ansieht, was man da verrückes angestellt hat.
zatzen hat geschrieben:EDIT: Ich habe jetzt auch davon gelesen, dass es Interlocks (AGI) gibt, wenn zwei aufeinanderfolgende Befehle dasselbe Register verwenden. Das verlangsamt den Programmablauf dann um einen Takt (bzw. Tick).
Ja, siehe oben.
zatzen hat geschrieben: Da vergeht einem ja fast der Spaß wenn es so komplex wird, aber es ist gut zu wissen.
Naja, man kann es auch weiterhin "spaßig" haben. Da muß man sich eben überlegen; Will man ein Gates oder ein Carmack sein?
zatzen hat geschrieben:Allerdings blicke ich da noch nicht ganz durch, deshalb erwähne ich das hier. Bei der ganzen Sache spielen 386er Befehle eine Rolle (mehrfache Einberechnung von Registern zur Adressierung, ohne Werte ändern zu müssen z.B.) aber auch eine gegenüber der alten Version klügere Koordination der Registernutzung. Der Lernweg ist wohl noch lange nicht zuende.
Ja, früher (lange her, als ich gerade mit Assembler angefangen hatte), hatte ich die CPU-Register eher so wie BASIC/Pascal-Variablen behandelt, quasi "immer genommen, was gerade frei war"...

Das ist natürlich kein Weg für effizienten Code! Schließlich haben die einzelnen Register auch teilweise besondere "Fähigkeiten": z.B. ist nicht jedes Register (im RealMode) ein Index-Register oder die Sache mit den Multiplikationen/ Divisionen, Portzugriffen oder sog. "Stringoperationen", die sind ja an bestimmte Register gebunden. Wenn man da einfach wie "Kraut und Rüben" die Register benutzt, ist man dann ständig nur am Sichern/Wiederherstellen von Registerinhalten, teilweise auf Stack, teilweise per Auslagern in andere Register... Das kostet Speicherplatz UND Rechenzeit gleichzeitig. (Also groß UND langsam - da kann man ja auch gleich zu Microsoft gehen und das nächste Windows bauen...)

Da habe ich dann (glaube bereits an anderer Stelle erwähnt) angefangen, (also nicht bei so "Dreizeilern", aber bei größeren Routinen/Projekten), den Registern einen Hauptzweck zuzuweisen. Das bedeutet dann nicht, daß man dann auch mal ein Register "zweckentfremden" kann, wenn es sich gerade anbietet oder man mal eins braucht. Es bedeutet aber, daß wenn man etwas Bestimmtes machen will und für die Aufgabe hätte man noch 3 Register frei, sich dann nicht mehr die Frage stellt, welches man nimmt. Auf diese Idee mußte ich selber kommen. Meine Erfahrung hat aber gezeigt, daß ich damit viel besseren/ schnelleren/ speichersparenderen Code schreibe.
zatzen hat geschrieben:Die Mnemonics und die Syntax sind eher einfach, aber richtig blickt man erst durch wenn man die ganze Struktur des Speichers und die Hardware versteht. Mit Assembler ist es wie mit dem Schreiben: Schreiben kann so gut wie jeder, aber nicht jeder ist ein guter Schriftsteller.
Wenn man das verstanden hat, ist man auf bestem Wege, ein guter Programmierer zu werden. Es gibt Leute, die haben die Syntax und Befehle von 20 Programmier- und/oder Skriptsprachen drauf und sind stolz drauf "so viel zu wissen/können" - aber die wirkliche Idee dahinter, wie man effizienten Code schreibt, haben sie nicht (weil zu beschäftigt damit, ständig die Vokabeln der neuesten gerade angesagten Sprache zu lernen).

Da sind mir Leute lieber, die vielleicht nur so 1-3 Programmiersprachen und dann noch Assembler auf vielleicht einigen Systemen kennen, aber diese dann auch verstehen, richtig gescheit einzusetzen. Es gibt Leute, die kennen 20 Programmiersprachen und halten sich deswegen für einen Programmierer. Ein Programmierer lernt aber nicht Sprachen (denn die sind nur das Mittel zum Zweck), sondern er programmiert. Und einen guten Programmierer/ Entwickler erkennt man an den Projekten/ Tools/ Spielen/ etc., die er schon fertiggestelt hat, nicht daran, was er alles "könnte, wenn er wollte".
zatzen hat geschrieben:Und es ist auch die Kunst, dem Computer Faulheit beizubringen. "Mach nur das was unbedingt sein muss."
So ist es. Alles was nicht sein muß und trotzdem gemacht wird, kostet Platz und Zeit.
zatzen hat geschrieben: Hochsprachen kehren das ganze eher um... Klar, Software muss heute möglichst schnell geschrieben sein.
Ja, es gibt zwar schon sehr effiziente Compiler (vor allem für C und Konsorten) - aber es gibt auch leider viele Sprachen (oder auch Bibliotheken, die immer wieder benutzt werden), die alle zu übergebenden Werte bei der Übergabe UND Übernahme prüfen, die ständig irgendwelche Boundary- und Überlaufprüfungen machen, auch wenn der Wert schon an 5 anderen Stellen daraufhin gecheckt wurde.

In Assembler fällt einem das ja direkt auf, weil man direkt "sieht", was gemacht wird. Was ein Compiler dagegen aus dem Code macht, kann man meist eher nur erraten. (Ja, ich weiß: man kann compilierten Code auch direkt im Disassembler ansehen. Aber mancher compilierte Code ist ein totaler Pain-in-the-Ass, das WILL man gar nicht sehen...)
zatzen hat geschrieben:Wie ganz oben zum Beispiel von Huffman: Bei einem Praktikum vor 20 Jahren sollte ich das mal in C schreiben. Hab's nicht hinbekommen aber ein Kollege schrieb das in ein paar Minuten runter um mir das zu zeigen. Wie gesagt frage ich mich, ob man das nicht auch ohne Rekursion schreiben kann um sich die vielen CALLs und PUSH/POPs sparen zu können.
Kann man definitiv, denn ich hab's schon gemacht. Regel 1 der Logik: Wenn etwas passiert, muß es möglich sein. (Und ja: Es war, um GIF anzuzeigen.)
zatzen hat geschrieben:
DOSferatu hat geschrieben:Und ob man auf dem geraden, leicht-verständlichen, aber leider auch dümmstmöglichen Weg da hin kommt (zwei verschachtelte X und Y FOR-Schleifen, die dann sowas wie putpixel(X,Y,Color) aufrufen) oder etwas kreativer ist, indem man sich an die technischen Gegebenheiten der Speicheranordnung der Grafikkarte anpaßt, macht den Unterschied, ob man ein Hochsprachen/Skriptsprachen-User ist, der selbst ein simples 2D-Spiel nur mit wahnwitzig schnellen Maschinen ruckelfrei/spielbar bekommt oder ob man sowas hinkriegt wie die Typen, die heutzutage aufm C64 (mit 1 MHz und komischer Grafikspeicheranordnung) ein superbuntes 8-Wege-Scrolling-Spiel wie "Sam's Journey".
Habe ich mir gerade angesehen. Da bekommt man fast wieder ein schlechtes Gewissen wenn man so verspielt mit komischen Packformaten an ein Spiel gehen will.
Der Fairneß halber muß man natürlich sagen, daß sich ein C64 technisch schon recht umfänglich von einem DOS-PC unterscheidet. Ja, er hat Sprites. Und ja, der Grafikchip ist so crazy zusammengebaut, daß man damit echt schräge Sachen machen kann. Und ja, er hat 'n eingebauten Soundchip... -

ABER: Er hat eben auch bloß 64kB Speicher und läuft mit ca. 1 MHz (die dank Grafikchip nicht mal 100% zur Verfügung stehen) - d.h. da muß man beim Coden ganz anders rangehen. Da kann man nicht mal eben riesige Tabellen und unrolled Loops machen, aber andererseits kann man auch nicht winzigen Code bauen der wegen vieler Aufrufe so klein ist, weil dann wieder langsam. Also, (abgesehen von Demos - aber was Spiele angeht), sind sowas wie Sam's Journey, Turrican II und Fred's Back schon so die absolute Königsklasse der C64-Spieleprogrammierung. Da braucht man sich nicht zu schämen, wenn man das nicht selber kann...
zatzen hat geschrieben:Aber ich würde soetwas sowieso niemals erreichen von der Performance her, d.h. annähernd eine angemessene Performance auf dem PC. Da spiel ich lieber rum mit meinen komischen Erfindungen, beim Spielen lernt man.
Ach, sag niemals nie. Ich hab früher auch oft gedacht: "Kann ich nicht" oder "Keine Ahnung wie das geht". Ich staune immer wieder, was dann plötzlich alles doch geht, wenn man sich etwas damit beschäftigt. Dranbleiben ist das einzige Motto, was mir dazu einfällt. Oder, wie es der Raumschiff-Käpt'n in "Galaxy Quest" gesagt hat: "Niemals aufgeben! Niemals kapitulieren!"
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...Scrolling...]
Ich lass mich irgendwie immer ein bisschen beeinflussen, wenn ich einem Freund von nem Jump&Run erzählt habe kam direkt quasi "aber muss dann mit Scrolling sein". Gut, die typischen Jump&Runs wo die Figuren so riesige schnelle Bewegungen machen brauchen einfach Scrolling, aber mit einem anderen Konzept geht das wohl auch ohne. Das sind mal schöne Aussagen von Dir, und es gibt so viele Jump&Runs, da könnte es fruchtbar sein, wie Du abschliessend geschrieben hast, dass man vielleicht sogar von den Beschränkungen inspiriert wird.
Solche Herausforderungen sind es, an denen man lernt. Und diese zu meistern machen (meiner Meinung nach) den Unterschied zwischen gutem Programmierer und Skriptkiddie aus. Wer immer nur mit maximalem Speicher und schnellstmöglichem System arbeiten kann, weil sonst alles zu langsam ist oder nicht funktioniert, sollte darüber nachdenken, daß die Unfähigkeit nicht auf Seiten der Hardware liegt...
zatzen hat geschrieben:Danke für Deine Erläuterungen zu ISM! Speichere ich mir auch mal raus um es nochmal lesen zu können (ohne im Forum zu suchen).
Erläuterungen? Naja, im Gegensatz zu vielem anderen Kram, den ich so gemacht habe, ist ISM ja gut dokumentiert.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]Zusatztool zum Melodie-Pfeifen][...]
Ich würde das spontan auch eher extern handhaben, einfach ein Tool das einen Sound analysiert und die Notendaten als Datei ausspuckt. Ich muss aber sagen dass ich mit nem Tracker eine Melodie schneller einprogrammiert hätte als gepfiffen und aufgenommen, zumindest wenn man berücksichtigt dass dabei höchstwahrscheinlich Fehler bei Rhyhthmus oder Tonhöhe entstehen. Ansonsten natürlich eine gute Idee wogegen ich nichts sagen will, und auf dem C64 stelle ich mir das auch schön vor.
Den C64 hatte ich nur erwähnt, weil ich es da schon versucht hatte - dort allerdings mit mäßigem Erfolg, da System zu langsam. Und ich würde bei so einem Tool selbstverständlich dann auf plausible Tonhöhen fixen und bei der Länge eine einstellbare Mindest-Tonlänge (die "Granularität") haben. Das entspräche in etwa dem "Speed" Befehl (ZOM) von prISM.
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]VOC386 [...]
Habe ich mir angesehen. Sieht so nicht schlecht aus (wobei man die Knöpfe kompakter/reduzierter hätte machen können und dafür irgendwie die Darstellung besser),
Ja, ich finde auch, daß der Typ hier etwas zu sehr mit seinen verspielten Buttons und Text rumgemurkst hat. Da wäre weniger besser gewesen. Aber das Ding ist so simpel daß sogar ein Idiot wie ich das bedienen kann - obwohl ich von Sound quasi keine Ahnung habe.
zatzen hat geschrieben:natürlich ungewohnt für mich, weil ich seit über 20 Jahren mit ein und demselben Windows-Programm arbeite, was doch "etwas" mehr Komfort in Umfang und Bedienung bietet, und trotzdem übersichtlich ist.
Naja, mir ging es bei dem Tool genau um diesen verringerten Komfort. Es soll nur die paar Grundfunktionen haben. Mehr brauche ich nicht.
zatzen hat geschrieben:Vielleicht müsstest Du hier einfach trennen zwischen dem Idealismus, effizient für ein Zielsystem (486er) zu programmieren und einer Sache wie Sound-Bearbeitung, wo es nur aufs Endergebnis ankommt das absolut kompatibel aus der Windows-Software rauskommt.
Wie gesagt: Windows-Programme haben oft zu viele Features. Und ich arbeite nicht gern mit/unter Windows.
zatzen hat geschrieben:Die Oberfläche von VOC386 zielt ja eigentlich auf eine Windows-ähnliche Bedienung ab.
Naja, Buttons, Mauspfeil und GUI sind ja nicht unbedingt Windows. Da gab es vor Windows schon andere. Übriges: Mein selbstgemachtes Malprogramm hat zwar auch rudimentäre Mausbedienung (nur für das Schieben des Zeigers), aber die ganzen Menüs und das alles ist tastaturbedient und das eigentliche, genauere Positionieren ist auch Sache der Tastatur. SO will ich meine Programme haben!
zatzen hat geschrieben:Ich sähe dann höchstens einen Mehraufwand wenn Du die Dateien per Diskette transferieren musst, aber vielleicht (bzw. wahrscheinlich) ist Dein 486er per Netzwerk mit den anderen Rechnern verbunden.
Ja, er ist verbunden. Auf dem einen Windows-Rechner läuft ein kleines Programm als FTP-Server. Nervt trotzdem.
zatzen hat geschrieben:Ansonsten habe ich eine lange Zeit lang mehrgleisig gearbeitet: Aufnahmen in Windows gemacht, Samples bearbeiten ebenfalls dort, und dort auch nach 8 Bit und niedrigerer Samplerate für den X-Tracker konvertiert, der in früheren Versionen nur in echtem DOS lief und nicht in DosBox.
DOSferatu hat geschrieben:[...]Windows, Irfanview[...]
Wovon ich weiter oben schrieb... Genauso könntest Du mit Sounds verfahren. Irfanview benutze ich auch schon länger, wobei ich für wirkliche Bearbeitung noch sowas ähnliches wie Photoshop benutzt habe, aber jenes Programm funktioniert nicht mehr auf Windows 10 (Applaus), ging aber noch mit Win7. Jetzt bleibt mir nur noch Gimp erstmal.
Naja, wie gesagt eher eine Notlösung. Und mit Sound mache ich eher wenig bis gar nichts. IrfanView hat den Vorteil, es auch per Kommandozeile aufrufen zu können (auch von "DOS" unter Windows aus) - solange das geht, ist es mir recht.
zatzen hat geschrieben:Ich wäre ja doch immer noch interessiert, was man aus ISM so rausholen kann. Für ZSM hatte ich mal die Idee, von Mike Batt "Caravans" umzusetzen, aber das ist doch ne Hausnummer zu hoch. Aber irgendwas anderes etwas einfacheres könnte ich mal in ISM (nicht ZSM) umsetzen, vielleicht hast Du ein paar Vorschläge aus denen ich mir was aussuchen kann.
Naja, das Tool ist auf meiner Webseite, Benutzung erlaubt. Aber so wie Du schreibst, bist Du inzwischen eher an diesen "Windows-Komfort" gewöhnt. Da kann so ein kleines lahmes DOS-Tool wie prISM natürlich nicht mithalten.
zatzen hat geschrieben:Ich hatte mal die Idee, den Pineapple Rag von Scott Joplin umzusetzen, aber in einer klein-orchestralen Version, d.h. nicht Klavier und auch kein großes Orchester, diese Version habe ich als Kind mal aus dem Radio aufgenommen, aber nur Bruchstückhaft und ich finde sie jetzt nicht mehr. Reicht aber vielleicht als Orientierung.
Gibts im Internet. Einfach auf Youtube suchen.
Vorschlag zur Umsetzung: Die crazy Titelmusik von "Doctor Who". Da die Mucke sehr elektronisch klingt und ISM so abartig gut Portamento supportet, wär's ideal.
zatzen hat geschrieben:Mode-X Scanline erweitern:
Da fehlt mir etwas der Durchblick. Verstehe ich so ungefähr.
Ich bleib erstmal bei MCGA. Kann man da irgendwas sinnvolles mit Scanline-Manipulation machen?
DOSferatu hat geschrieben:Eher nicht. Das Problem ist nicht, daß es nicht geht, sondern daß es kaum Sinn macht. Der Grund ist, daß 320x200 ja schon fast die kompletten 64kByte benutzen. Man kann die Scanline nicht in 1er-Schritten erhöhen, sondern in 8er-Schritten (bei MCGA/Mode-X sinds 4er, wegen der Pixelverdopplung). Aber 324*200 ist 64800, bei 328*200 ist man schon bei 65600 (also über 65536) und das Bild wraparounded dann unten.

WAS aber geht, wäre bei 324*200 so softscrolling, weil man ja 4-pixel-weise das Bild verschieben kann und man bräuchte trotzdem nicht bei 4ern "clippen".

Das wäre z.B. auch eine Möglichkeit, Deine Sprites, die auf 4x4 Quadrate ausgelegt sind, nur an ganzen Quadraten abzubrechen, weil der "Umbruch" sowohl links als auch rechts in den "unsichtbaren" Bereich geschrieben werden würde.
Da muss ich nochmal nachhaken, das klingt ja interessant. Ich hatte bisher geplant, dass ich den Puffer mit maximal 326x201 anlege, so hätte ich einen nutzbaren Bereich von 320x195. Es verschwinden ja von den 4x4 Blocks immer nur 3 Pixel in jeder Himmelsrichtung im unsichtbaren Bereich, bevor diese abgeclippt werden. Mit einer Breite von nur 324 dürften ja links und rechts nur 2 Pixel überragen.
Aber das mit dem Scrolling hört sich interessant an. Heisst das, das Scrolling wäre in 4-Pixel Schritten? Wie auch immer, ich glaube Scrolling würde mich mit meinen Konzepten erstmal noch überfordern.
Nein, das Scrolling wäre in 1-Pixel-Schritten, nur an 2 verschiedenen Stellen zu machen:
1.)
Scanline auf 324 erweitern.

2.)
Mit einem speziellen VGA-Register kann man das Bild um 0-8 (nicht 0-7) Pixel verschieben (für Textmode mit 9 Pixel breiten Zeichen). Im MCGA (320x200) sind die Verschiebungen aber nur um 0,2,4,6 (was 0,1,2,3 Pixeln entspricht) - das liegt daran, daß der MCGA mit Pixelverdopplung in beide Richtungen arbeitet.

3.)
Natürlich muß man weiterhin links/rechts die neuen Bereiche rankopieren. Vorteil ist eben, daß man die Routinen auf ganze Blocks bzw. ganze 4er Pixel auslegen kann - UND daß das Spriteclipping bei 4ern kein Problem mehr ist.
zatzen hat geschrieben:Aber Moment, denke ich schon wieder zu wenig um die Ecke?
Wenn ich jetzt mal einfach den Puffer auf nur 324er Breite anlege, und ich den Bereich 2-321 als sichtbar definiere. Was passiert wenn links 3 Pixelspalten rausragen? Sie erscheinen (bzw. eine Spalte davon) eine Zeile höher rechts, aber im unsichtbaren Bereich. Umgekehrt rechts rausragend: Ein Pixel erscheint eine Zeile tiefer links im unsichtbaren Bereich. Müsste eigentlich so funktionieren wenn man sich dann noch etwas Gedanken über die Dimensionierung oben und unten macht.
Du hast es richtig erkannt: Das wraparoundet links/rechts und wohin es das tut, kann Dir ja egal sein. Aber damit wär Clipping-Problem Deiner Sprites behoben.
zatzen hat geschrieben:Da muss ich einfach sehen wie ich es mache, 324er Breite gibt auch nur eine Zeile mehr in 64K, die man auf eine Weise wieder verliert wegen dem horizontalen Wraparound.
Ja, wie gesagt; In dem Fall dient's eher einfacherem Softscrolling und Lösung des Clipping-Problems. Großartig "drumherum" ums 320x200 Bild gibts nunmal nicht, 64kByte bleiben 64kByte. Eigentlich verbraucht der Modus die vollen 256kByte der VGA und "schaltet die zusammen", damit man den Vorteil linearen Zugriffs hat. Nachteil ist eben, daß man so nur ein Viertel des Speichers nutzt als den, der VGA ansprechbar wäre.
zatzen hat geschrieben: Do 19. Nov 2020, 18:09Kleines Update was GetMem angeht:Ersteinmal zur Übersicht die Zeilen Code die beim Aufrufen der Funktion generiert werden:

Code: Alles auswählen

0x0000000000000000:  B8 CD AB          mov   ax, 0xabcd { $ABCD Bytes Speicher reservieren }
0x0000000000000003:  50                push  ax
0x0000000000000004:  9A 8A 02 06 00    call 6:0x28a { abhängig wie das Programm letztlich kompiliert wird }
0x0000000000000009:  A3 50 00          mov   word ptr [0x50], ax
0x000000000000000c:  89 16 52 00       mov   word ptr [0x52], dx
Dann habe ich den Code der eigentlich Funktion in der EXE gefunden:

Code: Alles auswählen

0x0000000000000000:  55          push bp
0x0000000000000001:  8B EC       mov  bp, sp
0x0000000000000003:  8B 46 06    mov  ax, word ptr [bp + 6]
0x0000000000000006:  E8 C0 00    call 0xc9 {der rechnet hier die absolute Adresse aus, anhand des Code-Ausschnitts }
0x0000000000000009:  5D          pop  bp
0x000000000000000a:  72 03       jb   0xf
0x000000000000000c:  CA 02 00    retf 2
0x000000000000000f:  B8 CB 00    mov  ax, 0xcb
0x0000000000000012:  E9 70 FE    jmp  0xfe85 { $FE70 = -400, wo auch immer er da hinspringt... vielleicht Fehlermeldung }
Da muss man erst nochmal den CALL nacherfolgen und sehen was sich dahinter verbirgt...
Okay, ich hab den Einstiegspunkt gefunden, aber dann folgt eine ziemlich lange und komplizierte Routine wo auch wieder ein CALL drin ist usw. Da fehlt mir jetzt doch die Motivation dahinterzusteigen.
Naja, prinzipiell braucht man da nicht in Pascal suchen. GetMem wird nichts anderes tun als an irgendeiner Stelle entsprechende DOS-Funktion dazu aufzurufen. Turbo-Pascal programmiert nicht "am Betriebssystem vorbei".
zatzen hat geschrieben:Aber was mir die Sache gezeigt hat: Im Grunde ist so ein Programm simpel aufgebaut, man kann sich auch in einer EXE zurechtfinden.
Natürlich ist es das. Und compilierte Pascal-EXE sowieso, ist nicht gerade viel optimiert.
zatzen hat geschrieben: Mein Einstieg war, dass ich eine Testroutine geschrieben habe die an Position $50 platziert wurde. Das Codesegment war auf diese Adresse verankert, wird Dir nix neues sein. Sieht wahrscheinlich bei größeren Dateien anders aus.
Ja, ich schmeiß irgendne auffällige Bytesequenz in den Code und die suche ich im Hex-Editor. (Der Code ist damit nicht ausführbar, aber dann find ich die Stelle im Hexdump schneller. Die Bytes nehm ich dann wieder raus, wenn ich gefunden/erkannt habe, was ich wissen wollte.)
zatzen hat geschrieben: Fr 20. Nov 2020, 00:13Ich bin gerade darüber gestolpert, dass PUSH/POP das Register BP verwendet.
Das ist ein Fehlschluß. PUSH/POP verwendet !NICHT! das Register BP! - Sondern nur und ausschließlich Register SP. Das mit dem BP wird als "Stackrahmen" bei Hochsprachen genutzt, wenn Subroutinen aufgerufen werden, damit man da z.B. lokale Variablen anlegen kann. Der "ENTER" Befehl macht eigentlich nur das:

Code: Alles auswählen

push BP;mov BP,SP;sub SP,Anzahl_reservierte_Bytes
zatzen hat geschrieben: Mir war schon klar dass BP bei Parameterübergabe beiteiigt ist. Bisher funktioniert auch alles wo ich BP mit PUSH/POP gesichert habe und zwischendrin für was anderes benutzt habe, bei Routinen ohne Parameter. Aber vielleicht sollte ich es lieber im Speicher sichern?
Nö, es ist alles in Ordnung. Da kann man PUSH/POP benutzen. Im Speicher (oder anderem Register) sichere ich nur, falls mir mal Stack zu langsam ist.

Zum Schluß:
Noch ein paar Anmerkungen zu diesem 486-Power Demo von mir:

1) Parameter
Du hattest das mit den Parametern falsch verstanden. Es geht nicht um die Reihenfolge der Parameter, sondern: Jeder Parameter 1 bis 9 (auch wenn mit Führungsnullen) bestimmt Größe des halben Sound-Framebuffers (Double-Buffering) in kByte. 5 würde also 10kB Speicher belegen, 2x 5kB. Und Parameter über 9, also 10-44, bestimmen die Abspielfrequenz in kHz, also 10000 bis 44000. Kommen 2 "gleiche" Parameter, überschreibt der nächste den vorigen.

2) Sound-Stottern
Das Ding läuft in Dauerschleife. Bei höhrer Frequenz wird ein gleich-großer Puffer schneller "leer", weil er ja schneller abgespielt wird. Das ist der Grund für Soundstottern bei hoher Frequenz mit kleinem Puffer: Wenn die Sound-Generator-Routine (also ISM) innerhalb des Schleifendurchlaufs nicht schafft, den Soundpuffer zu füllen, weil der Puffer "leerläuft", bevor die Schleife zu Ende ist.

Das Demo testet das auf einfache Weise: Wenn bei mir der Soundpuffer leerläuft, wird nicht nur ein Flag (0/1) gesetzt, sondern der Wert wird entsprechend erhöht. Im Idealfall ist es dann ebenfalls nur 0 oder 1. Wenn er aber 2 oder mehr wird, d.h. es am Ende der Schleife mehr als 1 Anfrage gibt (Bender: "Gruselig: Nur Einsen und Mullen überall! Und ich glaub, ich hab ne ZWEI gesehen...!") - dann weiß das Programm, daß die Sound Blaster schneller Sound blastet, als neue Daten generiert werden.

Also: Das tritt auf, wenn der Puffer zu klein ist! - Ja, ich weiß: Große Puffer machen böse unsynchron... Aber, im Gegensatz zu einem generischen Soundprogramm, das quasi nichts anderes macht, als in Dauerschleife Sound abzuspielen und ein paar Ausgaben und Tastenabfragen, enthält ein Computerspiel in der Regel noch eine (teils recht aufwendige) Grafikausgabe, Steuerung, Kollisionsabfrage und all den kleinen Mist, der außerdem so gebraucht wird und das läuft alles ebenfalls in der Hauptschleife und konkurriert um Ressourcen (Rechenzeit/ Speicherplatz) mit den Soundroutinen/ Sounddaten. Weil Spiele auf die "Reaktion" des Spielers angewiesen sind - UND weil sowohl Grafikdaten als auch Sounddaten immer erst gepuffert und dann angezeigt/abgespielt werden, haben sie quasi IMMER einen Versatz, im Idealfall ist der Versatz bei Grafik und Sound der gleiche, dann fällt's weniger auf. Kann man aber nicht "planen", weil Erzeugen von Grafik- und Sounddaten komplett unterschiedliche Dinge sind, die man schlecht "timen" kann.

2a) Spiel-Multitasking
Und, wie schon erwähnt, braucht ein (etwas aufwendigeres) Spiel immer eine Art Multitasking:
Der simple Fall ist eine Hauptschleife, wo einfach immer "im Kreis" alles abgefragt wird, ob es Beachtung braucht und dann ausgeführt wird. Vorteil ist einfache Umsetzung. Nachteil ist, daß bevor auf ein Subsystem reagiert wird, im Worst Case die Zeit eines ganzen Schleifendurchlaufs vergeht. Das nennt man kooperatives Multitasking - man weist der Subroutine zwar Zeit zu, muß aber warten, bis diese sich selbst zurückmeldet.

Der komplexere Fall ist dann (wie in heutigen Betriebssystemen realisiert) das sog. präemptive Multitasking. Wird über Timer-INT gelöst, der quasi Kontrolle über das gesamte Programm übernimmt. Die "Hauptschleife" ist einfach nur noch ein "Dummy", der gar nicht zur Ausführung kommt. Realisiert wird's (im einfachsten Fall) so: Jeder Subroutine wird ein "Slot" zugewiesen, der einen eigenen Stack enthält. Der Ticker tickt (z.B. 100 oder 1000 mal pro Sekunde) und immer wenn er getickt hat, unterbricht er die Subroutine (wie es eine Interruptserviceroutine nunmal macht) und speichert alle Register (inkl. Segmentregister) auf dem Stack (ebenfalls bekannt). Dann wechselt es aber zu einem NEUEN Stack (d.h. es ändert das Stacksegment SS entsprechend dorthin) und dann IRET. Der "Rücksprung" aus dem Interrupt ist dann also in eine ANDERE Subroutine (außer wenn nur eine "eingeloggt" ist). Auf diese Art braucht man nicht auf eine Subroutine "warten" bis diese fertig ist, sondern unterbricht alle eiskalt, damit jede mal drankommt. Die einfachste Variante macht das mit allen Routinen "im Kreis", die etwas schickere hat dann noch die Möglichkeit, den Anteil der zugewiesenen Gesamt-Rechenzeit einzeln für die Subroutinen festzulegen.

Vorteil ist hier (wenn es erstmal läuft), daß man sich in den Subroutinen um nichts kümmern muß und so coden kann, als wäre sie die einzige, die gerade läuft - und: Es wird zeitnah (also spätestens nach einem Tick) auf ein Event reagiert. Nachteile sind, komplizierter zu implementieren, braucht mehr Speicher (mehrere Stacks) und ehr Rechenzeit (weil der Haupt-Interrupt im Timer auch Zeit braucht und außerdem häufiges Laden/Speichern aller Register (vor allem Segmentregister!). Bei mir ist Speicher und Rechenzeit immer knapp, wenn es um Spiele geht. Deshalb hatte ich mich bisher gescheut, da auch noch "echtes Multitasking" einzubauen.

3) Sound vs. Grafik
Den Sound habe ich nur dazu gemacht, damit es a) nicht so langweilig ist und b) gezeigt werden kann, daß trotz 8-Wege-Soft-Scrolling, Sprites und Anzeigen auch zusätzlich immer noch möglich ist, Sound zu generieren und abzuspielen. Das Demo ist eigentlich kein Sound- sondern ein Grafik-Demo. Es ging damals darum, daß Du Dir nicht sicher warst, ob ein 486er das von Performance her stemmen kann. Wie Du siehst: Er kann.

Eine Anmerkung zu einem Deiner früheren Posts, betreffend Stack:
Du hattest erwähnt, daß man dann Arrays global deklarieren sollte... - Ist so meiner Meinung nach nicht richtig. Global sollten nur Variablen (inkl. Arrays/Strings usw.) deklariert werden, die auch von mehreren Subroutinen angesprochen werden sollen und wo die Übergabe (über Stack) dann wegfallen soll.
Lokal (also in der Subroutine) sollte man alles deklarieren, was nur in dieser gebraucht wird. Sagtest ja, würde Speicher kosten - das Gegenteil ist der Fall: Lokal deklarierte Variablen werden auf dem Stack gespeichert. (Damit man darauf Zugriff hat, wird BP dann entsprechend gesetzt, weil man ja nicht wissen kann, an welcher Stelle der Stack gerade stand, wenn die Subroutine aufgerufen wird.) Diese Variablen "existieren" nur so lange, wie die Subroutine läuft, nach Beenden wird der Stackpointer wieder auf den Ursprung gesetzt. D.h. alle Subroutinen benutzen den gleichen Stack - also spart das Speicher.

Einzige Ausnahme ist hier rekursive Programmierung mit sich selbst aufrufenden Subroutinen. Bei jedem Aufruf wird wieder so viel Platz auf dem Stack angelegt für alle Variablen usw. In diesem Fall kann es helfen, alles global zu deklarieren, so daß der aufgerufenen Routine wirklick nur Dinge bereitgestellt werden müssen, die sich ändern. Im besten Fall braucht dann jeder rekursive Aufruf nur den Platz einer Rücksprungadresse (2 Bytes für NEAR, 4 Bytes für FAR) auf dem Stack.

Aber: Es gibt wesentlich weniger Fälle als man denkt, wo "echte" rekursive Programmierung (mit Selbstaufruf der Routine) nötig ist. Bekannte Anwendung ist z.B. eine Füllroutine für Grafik. Ich habe es in meinem Malprogramm gelöst - funktioniert 100% und braucht keine rekursiven Aufrufe. Der Gedanke ist, daß man ausgehend von den Koordinaten des Punkts auf dem man "sich befindet", die 4 oder 8 (je nach Methode) umliegenden Punkte testet und wenn einer "gefüllt" werden muß, ruft man den mit seinen Koordinaten auf und wiederholt das Ganze... -

Ja, so "elegant" würden das heutige Skripter nachm Lehrbuch machen - ohne nachzudenken (und der Sourcecode wäre ja "schön klein"). Und: Jeder Routinenaufruf braucht: Rücksprungadresse (2 oder 4 Bytes), Platz für gerettetes BP (2 Bytes), 2 Koordinaten (2x2 Bytes), sind mind. 8 oder 10 Bytes PRO PIXEL - im Worst Case das ganze 5 bis 10 mal soviel Speicher wie das Bild groß ist. Und: Die ständigen Aufrufe / Parameterübergaben kosten natürlich auch Rechenzeit.

Mein Ansatz: Nur speichern, was wirklich gebraucht wird. Pixelkoordinaten braucht man nicht speichern, ergeben sich aus dem vorherigen Pixel, der liegt ja an einem der umliegenden 4 oder 8 Pixel - d.h. man braucht nur die RICHTUNG speichern, die der Pixel zum vorherigen hat. (wenn er "zurückgeht", geht er in die entgegengesetzte Richtung. Eine Richtung braucht nur 2 oder 3 Bit! - und das ist alles, was ich pro "Aufruf" speichere! (Mein Malprogramm supportet wählbar beide Füllmethoden, die mit 4 Pixeln (nur ganze "Himmelsrichtungen") und die mit 8 Pixeln (auch die diagonalen).) Beide Pixelkoordinaten sind global, genauso wie das angelegte Array (das 2-/3-bit-weise gefüllt wird) und der Zeiger auf den "Füllstand" des Arrays. Die Koordinaten werden ausgehend von den Daten immer neu berechnet. Wie das? Etwa so:

Code: Alles auswählen

const AddX:array[0..7]of shortint=( 0,+1, 0,-1,-1,+1,+1,-1);
const AddY:array[0..7]of shortint=(-1, 0,+1, 0,-1,-1,+1,+1);
Reihenfolge ist egal, es muß nur jede X/Y Kombination einmal vorkommen. Nimmt man die "gerade" Richtungen als erste, kann man die Arrays für beide Varianten gleichzeitig nutzen. Es gibt dann also eine 2-bit oder 3-bit Richtung. Die Koordinaten werden dann so geändert:

Code: Alles auswählen

inc(Xkoord,AddX[Richtung]); inc(Ykoord,AddY[Richtung]);
Wird ein neuer Pixel "angelegt", wird ihm Richtung 0 gegeben. Der prüft dann weiter jede der Richtungen. Wenn er in einer Richtung einen zu füllenden Pixel findet, dann wird dieser erstmal gefüllt und dann wieder (mit Richtung 0) neu angelegt- Wenn nicht (also in der Richtung nix zu füllen), dann bleibt er wo er ist und tickt seinen Richtungswert um 1 weiter und prüft in die nächste Richtung. Wenn er beim Weiterticken die letzte Richtung wrappt (also von 3 auf 0 oder von 7 auf 0), dann ist er "fertig" und er geht zurück zu seinem vorigen Pixel. Dazu geht er im Array eins zurück, holt sich die Richtung (vom vorigen) und SUBTRAHIERT diesmal die Koordinaten:

Code: Alles auswählen

dec(Xkoord,AddX[Richtung]); dec(Ykoord,AddY[Richtung]);
Wenn er beim Zurückgehen im Array unterhalb der ersten Array-Position (1 oder auf 0 oder... je nachdem wie man's anlegt) landet, ist das Füllen erledigt.

Wie man ein Array baut, daß man es 2-bit oder 3-bit-weise (statt byte-weise) benutzt, sollte kein Problem sein.

Tja: Die "ach-so-komplizierte Füllfunktion", die ja "ohne rekursive Aufrufe gar nicht geht" mal eben so für Doofe erklärt, wie es DOCH geht. Klar, das ist immer noch rekursiv, weil es ja mit diesem 2-bit (bzw. 3-bit) Array simuliert wird. Aber schlauer. Und, weil mein Malprogramm auch so abartig riesige Auflösungen wie 1280x1024 supportet, hat es die Option, dem Array eine begrenzte Größe zu geben und jedesmal, wenn es über diese "wrapt", das Array auf Festplatte temporär zu speichern und wenn es untenlang "wrapt", wieder zu laden. Damit es an der "Wrapgrenze" nicht komisch wird (wenn da grad ein Pixel um sich herum testet), sind 8 aufeinanderfolgende "Richtungen" in einer 24-Bit Variable gespeichert - die hat dann glatte Bytegröße und ja: SO kann man ein 3-Bit-Array machen...

Und mein erwähntes GIF-Leseprogramm kommt ja trotz des bekannten Huffman/LZW-Algo auch ohne Selbstaufruf-Rekursion aus
So, fast 60000 Zeichen. Ich mach mal Schluß.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Ich habe leider gerade keine Zeit um ausführlich zu antworten, aber ich denke, SSD Platten sind relativ sicher. Das Lesen/Schreiben ist ja nicht mit Magnetisus verbunden, nebenbei noch viel schneller (da wie RAM), und bevor sich eine SSD verabschiedet merkt man das ersteinmal daran, dass nichts mehr draufgeschrieben werden kann. Dann kann man die vorhandenen Daten aber immer noch sicher lesen, und auch Wiederherstellungsfirmen haben die Möglichkeit, die Speicherchips auszulesen selbst wenn die Steuerungselektronik kaputt ist.
Vielleicht ja für Dich in Zukunft ein Medium für Backups, nebenbei auch stoßfest.
LG
Zatzen
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Am Wochenende habe ich Zeit, Deinen ganzen Beitrag zu lesen/zu beantworten.

Ich möchte nur noch schnell meine neue Strategie erläutern:
Ich werde wohl demnächst meine Assembler-Routinen in 16 Bit halten.
Für Adventure-Spiele oder ähnliches dürfte das an Geschwindigkeit hinkommen.
Und das rechtfertigt dann endlich auch mal den Real Mode mit 640 K, sprich meine Programme wären dann auch auf einem 286 lauffähig.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

DOSferatu hat geschrieben: Hallo, zatzen!
Zuerst mal möchte/muß ich um Verzeihung bitten, weil ich mich so lange nicht gemeldet habe.
Und genau dafür möchte ich mich auch entschuldigen, zuletzt besagtes Wochenende hat sich nun vielmehr in drei Monate Verzug gewandelt. Aber besser spät als nie, vielleicht möchtest Du die Konversation trotzdem weiterführen.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Wiederum habe ich aber auch keinen Schimmer wie man mit Freepascal Vollbildgrafik anzeigt und das wiederum aus dem Programmspeicher heraus und nicht bloß eine Library auf eine Datei ansetzen.

Code: Alles auswählen

asm mov ax,13h;int 10h;end;
geht nicht?
Ich habe es bisher nicht versucht, und möchte es auch nicht, hinterher zerschieße ich mir noch irgendwie mein System und wichtige Daten. Mittlerweile wird ja jegliche Grafik in Windows vielmehr virtuell über OpenGL oder sonstiges realisiert, wovon ich keine Ahnung habe.
Ist natürlich nur ein übervorsichtiges Gefühl, warum ich das nicht ausprobieren will. Effektiv würde so ein Programm wohl nur mit einem Ausnahmefehler beendet werden, Windows ist ja mehr oder weniger idiotensicher.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ich versteh nix von Programmierung mit Klassen und sowas, und wenn ich Daten nicht in ein eigenes Datenfeld einlesen kann bringt mir das nichts. [...] Freepascal hat ja Zugriff auf 2 oder 4 GB. Und die Segmente sind auch nicht auf 64K beschränkt, das "flat" Speichermodell ist ja ein ganz anderes. Daher kann man einfach z.B. ein Array von 1 GB Größe definieren. [...]
Ja, aber genau diese Art Programmierung macht Programme UND Systeme langsam. Erstens ist nicht überall so viel Speicher eingebaut, zweitens brauchen OS und andere Prozesse auch Speicher. Was macht das OS dann? Lagert RAM auf Festplatte aus und swappt zwischen Festplatte/RAM ständig hin und her um "mehr RAM zur Verfügung zu stellen, als vorhanden".
Jo, da ich bisher in Freepascal weder Ton noch Bild ausgeben kann nutze ich es nur um Tools zu bauen, und da ist die Geschwindkeit unwichtig, bequemes einlesen/abspeichern von z.T. großen Datenmengen aber umso wichtiger.


Eigene Speicherverwaltung: Momentan habe ich gerade eine weniger intensive Phase was programmieren angeht. Kann und wird wahrscheinlich aber wiederkommen. Zuletzt hab ich eben gedacht, man müsste einfach, etwa in einem eigenen Tracker, beim Laden eines neuen Samples erstmal alle wieder rausschmeissen und dann alle plus das neue wieder reinladen. Etwas umständlich, dürfte aber im Rahmen von 500KB und auf 386er+ Standard zeitlich kein Problem sein.

Team, bisher nix richtiges hinkriegen:
DOSferatu hat geschrieben:Naja, erinnert auch an mich - ich nenne mich Imperial Games - aber so richtig "Game"-mäßiges, auf das man stolz sein könnte, ist von mir auch noch nicht gekommen.
Immerhin hast Du Dir bereits eine technische Grundlage für "Arcade" Spiele aufgebaut. Ich habe mich eher dazu entschieden, wenn ich etwas machen sollte, dann etwas gemütliches. Mir selbst fehlt heutzutage auch total der Anreiz, ein "schnelles" Spiel zu spielen. Ich bin da eher der ruhige Genießer, und Adventure Spiele haben mich stark geprägt. Soetwas bringt einen beim Programmieren nicht so sehr in die Bedrängnis von Performance, aber es braucht ein Team von Grafikern. Ich habe die Zwischensequenzen bei Kotzman II mit viel Mühe gemacht als 15jähriger, voller Energie und Faszination. So könnte man durchaus ein Adventure angehen, wenn man denn noch die Energie hätte.
Vielleicht überlege ich mir nochmal ob ich sowas machen will.
Wie Du bemerkt hast, tendiere ich im Zweifelsfall eher zu Demos oder Simus, weniger zu einem Spiel wo es um gewinnen oder verlieren geht. Mit einem irgendwie gearteten Adventure lässt sich meine Haltung zu Spielen schon eher vereinen.
Es ist alles eine Frage der Motivation. Ich habe "leider" noch andere Hobbys die mich vom Programmieren oder Grafik machen ablenken und mich ihrerseits zufrieden stimmen.
Diese Hobbys (inkl. Programmieren) haben mir letztlich aber auch aufgezeigt, dass es wichtig ist, dass man das alles für sich selbst macht, d.h. das Endergebnis muss einem gefallen, einen faszinieren, weil man kaum Reichweite hat als "Amateur" und somit die Freude über Feedback oder Beschäftigung anderer mit seinem Kram ausbleibt. Das war bei mir in jungen Jahren etwas anders, da gab es durchaus Begeisterung im Freudes- oder Klassenkameraden-Kreis bzgl. meiner Musik oder auch simplen Spielen. Heute kann man sich wohl am besten über Youtube publik machen, mit rund 300 Abonnenten ergeben sich aktuell ungefähr so viele "Fans" wie damals zu Schulzeiten, d.h. ein Video wird im Schnitt von 5-10 Leuten positiv aufgenommen. Für Youtube-Verhältnisse ist das natürlich winzig.
DOSferatu hat geschrieben:Naja, für mich ist es bloß ein Hobby - ich mache das nicht, um "berühmt zu werden". Wenn's ein paar Leuten gefällt, ist zwar schön und Bestätigung dafür, daß es ein brauchbares Spiel geworden ist, aber die wirkliche Befriedigung ist eigentlich das Selbsterschaffen eines Werks mit den mir möglichen Dingen.
Genau, Du sagst es hier selbst. Ich lege dann nur noch Wert darauf dass es bei mir anschliessend nicht einfach nur tot auf irgendeiner Platte gammelt, sondern dass ich auch immer wieder Lust hätte, es selbst zu spielen. Das hat sich bei meinen bisherigen Spielen eher nur auf die Entwicklungszeit beschränkt. Liegt auch an dem "linearen" Ablauf der Spiele, irgendwann kennt man seine Sachen auswendig und hat sie 20x durchgespielt. Dann bleibt mir als Programmierer noch das Betrachten meiner Datenformate die ich mir dafür ausgedacht habe, deswegen mach ich sowas u.a. so gerne. Ansonsten wäre eben mal so ein eher simulationartiges Spiel für mich interessanter, weil ich da mit Zufallsgenerator arbeiten würde und somit das Spiel jedes mal anders wäre. Und interaktiv, aber ohne ein eindeutiges Ziel zu verfolgen.


Sound bei Spielen:
Ich bin aufgewachsen mit PC ohne Soundkarte, die ersten Jahre.
Soetwas wie Battle Chess war vom Sound her großartig, auch wenn es wohl nur 1 Bit waren. Laut, krachend verzerrt, aber: Reale Klänge! Nicht nur Piepserei.
Bei Spielen ist mir die Qualität vom Sound eigentlich egal, es muss irgendwie nur zur Atmosphäre des Spiels passen. 1 Bit Krachsound würde die Atmosphäre von Spielen wie Monkey Island zerstören. Daher eben nur der dezente PC-Speaker Pieps-Blubbs-Sound oder AdLib.
Wenn es ins Konzept passt kann man da machen was man will.
Für Spiele mit Trackermusik wäre für mich 22 kHz die qualitativ vernünftige Obergrenze, vielleicht auch 16 kHz. Die untere Grenze wäre 8 kHz, lieber 11, dann kommt etwas mehr Brillanz durch, mit nur verhältnismäßig wenig mehr Datendurchsatz.

Generell bin ich im professionellen Audio-Bereich auch ziemlich geerdet: 16 Bit 44.1kHz sind perfekt, alles darüber ist als Verbraucher-Endprodukt Unsinn. Heute könnten es für mich auch ruhig nur noch 32 kHz sein, ich höre nicht höher als 15 kHz. Aber es gibt ja auch noch andere, jüngere Menschen.


Ich schrieb zuletzt dass ich wohl dazu übergehen würde, nur noch 16 Bit Assembler zu coden. Ich halte daran aber nicht fest. Es ist nur eine Frage, was man will. Vernünftig performende Sample-Trackermusik-Routinen sind nur schwer in 16 Bit Assembler machbar.

DOSferatu hat geschrieben:
zatzen hat geschrieben:Ich wäre ja doch immer noch interessiert, was man aus ISM so rausholen kann. Für ZSM hatte ich mal die Idee, von Mike Batt "Caravans" umzusetzen, aber das ist doch ne Hausnummer zu hoch. Aber irgendwas anderes etwas einfacheres könnte ich mal in ISM (nicht ZSM) umsetzen, vielleicht hast Du ein paar Vorschläge aus denen ich mir was aussuchen kann.
Naja, das Tool ist auf meiner Webseite, Benutzung erlaubt. Aber so wie Du schreibst, bist Du inzwischen eher an diesen "Windows-Komfort" gewöhnt. Da kann so ein kleines lahmes DOS-Tool wie prISM natürlich nicht mithalten.
Das Problem ist weniger Windows, sondern nur die Umgewöhnung auf einen anderen Tracker. Auch wenn Du mir ein ähnliches Tastatur-Layout in AtavISM geliefert hast, erfordert es trotzdem einige Eingewöhnung in den Workflow, bis man da zügig vorankommt.
DOSferatu hat geschrieben:Vorschlag zur Umsetzung: Die crazy Titelmusik von "Doctor Who". Da die Mucke sehr elektronisch klingt und ISM so abartig gut Portamento supportet, wär's ideal.
Darauf kann ich mal zurückkommen, wenn sich bei uns beiden wieder ein Dialog ergibt.
Gerade reingehört... Ich befürchte allerdings, dass sich der Effekt dieser Musik erst durch die präzisen und konkreten Klangfarben inkl. Halleffekt ergibt, und weniger durch die rein melodische Ebene.

Vielen Dank für Deine weiteren Erläuterung bzgl. MCGA und Scanline. Ich stecke da gerade nicht so drin, aber es wird noch wertvoll für mich werden.
Ansonsten war meine Idee eben einfach, statt 64000 Byte als Puffer direkt 65200 Byte zu nehmen, wo links und rechts immer 3 Pixel rausragen können, und dann kopiere ich nur den Bereich 320x200 zeilenweise in den MCGA Speicher rüber.
Das ist alles erst richtig sinnvoll bei größeren Sprites die eher Comic-artig aber durchaus detailliert sind (sonst würde auch RLE gut greifen), weil da meine Kompression gut anspricht, und andernfalls wäre Clipping auch gar nicht unbedingt notwendig, angenommen man hätte nur so kleine 16x16 Sprites wo es kaum auffällt wenn die einfach so rechts oder links ins Bild herein oder heraus "ploppen".

Gut zu wissen, das mit BP. Also darf man das nur dann nicht anrühren, wenn es sich um eine Routine mit lokalen Variablen handelt. Ich nehme an, das sind auch Variablen im "Header", d.h. übergebene Parameter.

Multitasking und so... Ich werde in absehbarer Zeit wohl nicht über das "Video" Prinzip hinauswachsen. Bild anzeigen, zugehörige Soundkulisse dieses Moments ausgeben. Dann während der Blaster blastert die Tastatur abfragen, Spielberechnungen machen, Grafik updaten, Sound für den Moment berechnen und wieder von vorn. Für die zsmplay4 Moonwalker Demo hat es genau auf diese Weise zufriedenstellend und Bild/Ton-synchron funktioniert, aber damit kann ich natürlich nicht sowas wie Jazzjack Rabbit mit 70 fps und schnell reaktiver Steuerung machen, soetwas würde ich aber selber auch gar nicht spielen wollen. Wir hatten das zur Genüge auch diskutiert dass man auf meine Weise keine gute Steuerungspräzision hinkriegt, aber ich muss aus der Not eine Tugend machen und daraus folgend eben ein ziemlich gemütliches Spiel.

Wo Du von Deiner Füllfunktion schreibst fällt mir auf, dass ich mich bezüglich Grafik bisher programmiertechnisch kaum mehr als mit Sprites beschäftigt habe. Also im Prinzip nur die Beschäftigung mit der Positionierung von rechteckigen Elementen. Ich hatte ein Buch über Spieleprogrammierung in Turbo Pascal, und das machte Gebrauch von der Unit Graph, und da war ich aber schon verwöhnt von etlichen Spielen mit schöner Pixelgrafik. Also habe ich diesen Weg der geometrischen Grafikerzeugung nicht weiter verfolgt, zumal ich davor schon Erfahrung mit dem Grafik-PUT von QuickBasic gemacht hatte. Alles was ich also wirklich wollte waren transparente Sprites mit Clipping. Das habe ich dann einige Jahre später in Pascal + ASM realisiert, und jetzt stehe ich eben an dem Punkt der Knobelei mit Kompressionsverfahren.

Ich kann im großen Stil keine besondere Software schreiben, aber ich genieße im Kleineren von Zeit zu Zeit die Assembler-Programmierung, die eben Dinge ermöglicht, die anders nicht machbar wären. Mein Know-How und meine Ausdauer reichen nicht dazu, ein umfassend technisch optimales Spiel zu erschaffen. Ich denke, ich kenne meine technischen Grenzen, und jetzt muss ich sehen ob ich etwas machen möchte, das unabhängig davon, ob man es auch performanter hätte kreieren können, Spaß macht.
mov ax, 13h
int 10h

while vorne_frei do vor;
Antworten