Seite 22 von 22

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 1. Aug 2020, 14:26
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

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 6. Sep 2020, 00:46
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.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 13. Sep 2020, 14:18
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.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Di 22. Sep 2020, 20:21
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.