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: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...DOSferatu hat geschrieben:Was meinst Du eigentlich immer mit "Album"? Gibt's CDs von Dir zu kaufen?
Ja, das ist die Erklärung - aber eben keine Entschuldigung für so einen Scheiß.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...
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.
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.zatzen hat geschrieben: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.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"...
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....
Du sagst das so, als wäre DOS-Software etwas schlechtes.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,
Genau das sage ich.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.
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.zatzen hat geschrieben:Aber gerade bei Grafik kann Windows-Software von Vorteil sein.
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.
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.zatzen hat geschrieben: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.DOSferatu hat geschrieben:Außer Dir kenne ich keinen, der sich jemals über die nicht ganz quadratischen Pixel in 320x200 ereifert hätte.
Ü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.
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.zatzen hat geschrieben:Aber ich kann schon verstehen dass das alles keine Argumente sind, wenn man Emulatoren sowieso verabscheut.
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.
Achnaja, wie ich schonmal sagte: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.
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.
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: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.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.
Da bin ich mir noch nicht mal so sicher, ob das so ist.zatzen hat geschrieben:Natürlich passiert bei XPYDERZ wesentlich mehr als selbst bei einem 16 spurigen vollausgelasteten ZSM, mal als Beispiel.
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.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.
Mit anderen Worten: Was (welche Kiste) referenzieren denn diese 20000 Cycles?
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.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.
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.
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:zatzen hat geschrieben: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.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.
Kannst Du hier sehen: https://youtu.be/jqx08ubMIps
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.
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: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.
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.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.
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.
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?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.
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.
Ja, schon klar.zatzen hat geschrieben: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.DOSferatu hat geschrieben:Die anderen sehen nur das Endergebnis - nicht den Code und auch nicht die Zeit+Mühe, die es gekostet hat.
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.
Für mich völlig unwichtig. Nicht meine Referenz. Nicht meine Zielgruppe.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.
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: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.
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: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.
Kommt dann wieder ganz auf's Spiel und auch Spielprinzip an, würde ich sagen.zatzen hat geschrieben: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.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".
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.zatzen hat geschrieben: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.htmlDOSferatu 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.
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.
Naja, nicht jeder freut sich über ein breites Bild. Wie schon erwähnt, ist 16:9 für mich keine Augenweide.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.
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: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.
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".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.
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.
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: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.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.
Ist bei mir ja genauso.zatzen hat geschrieben: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.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.
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.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.
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.
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.zatzen hat geschrieben:Fraglich ist, ob ZVID2 effektiv langsamer sein wird als Deine Sprite-Routinen,
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.
Achso. Ja, sowas tät mich natürlich auch nerven.zatzen hat geschrieben: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.DOSferatu hat geschrieben:Wenn Du a) Verzögerungen im einstelligen Millisekundenbereich hörst und b) das für Dich unerträglich ist[...]
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"...zatzen hat geschrieben: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.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.
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.
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.zatzen hat geschrieben: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.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.
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.
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.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.
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.
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.)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
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.
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: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, so ist es.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.
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.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.
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".
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.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
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.
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.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.
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...
Ja, wie gesagt: Hochauflösend ist nicht alles und - zumindest für mich - nicht der magische Weg zum Seelenheil.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.
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.
...was wohl unter anderem auch daran liegen mag, daß WINDOWS keinen 256x256 Modus anbietet... :)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.
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.)zatzen hat geschrieben: Wer dann im Emulator Eier statt Kreise hat - meinetwegen selber schuld.
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.
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.zatzen hat geschrieben:Deine Modi-Demo wäre nach wie vor interessant, ist aber nicht von entscheidender Bedeutung für mein Spiel.
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