zatzen hat geschrieben:Kopfhörer!
Aber sobald man diese beiseite legt krächzt und zischelt es nur noch. Direkt vor dem Ohr macht auch eine Hummel oder vielmehr ein Käfer mächtig Bass, aber auf einen Meter Entfernung hört man kaum noch etwas davon.[...]
Ist mir schon klar.
zatzen hat geschrieben:Es gibt allerdings Breitbandlautsprecher, die vielleicht von 80-10000 Hz brauchbar sind und meinetwegen 10 cm groß, aber eine vernünftige Fläche für den Tiefmitten- und Bassbereich klingt doch überzeugender.
Man kann sich die ganze Sache auch verbildlichen indem man es mit Wasser und Paddeln vergleicht - mit einem richtigen Paddel kommt man besser voran als mit Teelöffeln. Aber es geht um Schwingungen, Wellen, nicht das bloße Abstoßen innerhalb eines Mediums.
Naja, ich sag's mal so:
Früher, mit 16, konnte ich, sozusagen "die Flöhe husten hören": Wenn in einem Raum ein Röhrenfernseher an war, konnte ich das hören - an diesem 15 kHz "Pfeifen". Heutzutage, in der Firma (Großraumbüro), lausche ich auf alles, was phonetisch so ähnlich klingt wie mein Name, damit es nicht heißt, ich reagiere nicht, wenn ich angesprochen werde. Meinst Du wirklich, daß es sich da noch lohnt, mannshohe Boxen mit kristallklarem Sound anzuschaffen?
zatzen hat geschrieben:Und klar, leider, so wie ich das zu meinem Frust als Lautsprecherkonstrukteur erlebe, ist es so - Lautsprecher müssen in die Möblierung passen, und zwar möglichst unauffällig. Sitzecke, Sessel, Schränke und auch der Fernseher dürfen mächtig und klotzig sein, aber die Lautsprecher am besten unsichtbar. Als würde man sich dafür schämen, oder, als würde man denken, was klein ist klingt besser, weil ja modern und neue Technologie, muss ja besser sein.
Oh, ich habe ja keinerlei Abscheu vor "zuviel Technik im Raum". Bei mir ist es eben so, daß die Lautsprecher noch Platz auf dem Schreibtisch finden müssen und auf dem stehen auch noch 3 Computer und 2 Monitore, ein Telefon, ein 4-fach Monitor/Keyboard/Maus-Switch, ein Modem usw. und ich sitze außerdem so ca. 70-80 cm (und wenn ich mich zurücklehne 1 m) von den Lautsprechern entfernt - und da brauche ich einfach keine riesigen Kisten.
zatzen hat geschrieben:Aber wie wir wissen: $$$-Denken dominiert den Markt und kein Idealismus. Design und Klavierlack - das Auge hört bei vielen scheinbar mehr als das Ohr.
Naja, so bin ich ja nicht. Ich besitze auch kein Smartphone. Und daß meine Playstation3 noch das alte Modell mit Klavierlack ist, liegt weniger am Klavierlack, sondern mehr daran, daß bei der neuen kleineren ein paar Anschlüsse wegrationalisiert wurden und sowas kann ich nun gar nicht ab.
zatzen hat geschrieben:Ich brauche aber "klare Sicht", großes Kino was Ton angeht. Was für andere das große Fenster mit Panoramablick im Wohnzimmer ist, ist für mich die "Lautsprecherwand", da sie für mich das große Fenster ist, durch das ich alles gut beurteilen kann.
Meine Fenster sind zugeklebt, damit es hier schön duster ist. Mein TV hat 15Zoll CRT, mein Monitor 14Zoll CRT, meine neueste Technik ist 15 Jahre alt oder so... Und im Gegensatz zu Dir lege ich nicht SO einen Wert auf Kristallsound. MIr reicht die Qualität aus, die meine Lautsprecher produzieren - ehrlich gesagt LIEBE ich sogar so Zeug aus dem PC-Speaker - deshalb wird der auch in meiner Spiel-Engine (neben der Sound Blaster) mit unterstützt.
Eigentlich reicht Sound Blaster (und kompatible) zu unterstützen ja schon aus, weil jemand, der DOS-Spiele spielt, sich sowieso irgend etwas SB-mäßiges holt. Aber, ich hatte immer mal überlegt, ob ich die GUS (Gravis Ultrasound) mit supporten sollte - aber habe dann gemerkt, daß ich dazu komplett anders vorgehen müßte - weil sie hardwaremäßig das macht (Samples abspielen/abmixen) was ich in Software mache und weil sie für diesen "Chiptune"-artigen (sample-freien) Sound, den ich
eigentlich machen will, völlig ungeeignet ist.
Dann habe ich überlegt, ob man die AbLib unterstützen sollte. Wäre sicher cool - andererseits ist die "AdLib", die die meisten Leute benutzen, sowieso keine AbLib-Karte, sondern nur der entsprechende Chip, der auf allen Sound Blastern mit drauf ist. AdLib hätte wohl den entscheidenden Vorteil, auch auf langsamen Systemen gut zu performen, weil sie ja quasi so Zeug selbst generiert, was ich in Software mache - allerdings hat sie auch diese niedlichen Timing-Glitches beim Ansprechen mancher Register...
VIELLEICHT baue ich aber irgendwann mal eine Erweiterung in ISM ein, die für AdLib geeignet ist - aber momentan hat das einfach keine Priorität. Ich programmiere sowieso schon viel zu wenig in letzter Zeit. Aber daß ich mal die GUS supporte... Das wird wohl kaum passieren - außer, daß ich vielleicht einen "Blaster-mäßige" Hack benutze, d.h. die generierten Sounddaten dann nur auf einem Channel der GUS zyklisch ausgebe und den Rest das ISM machen lasse. Damit würde man die GUS zwar eher "mißbrauchen", weil man ihre Möglichkeiten gar nicht benutzt - es wäre quasi nur ein "Hack", um Leuten mit GUS-only System zu ermöglichen, Sound zu haben.
PC-Speaker ist sowieso eine "unsichere Kiste": Macht nur Sinn, wenn der Rechner schnell genug ist. So'n früher 386er kann wahrscheinlich gar nicht meine klotzartigen Routinen (Grafik, Sound, Steuerung) alle gleichzeitig bedienen in adäquater Geschwindigkeit.
zatzen hat geschrieben:Das Prinzip von akustischen Hörnern ist, eine kleine Lautsprecherfläche ohne Erhöhung der Membranmasse deutlich zu vergrößern. Dabei erfährt die Lautsprechermembran eine höhere akustische Impedanz und kann so tiefere Töne effektiver bzw. überhaupt wiedergeben, die sie mit ihrer eigentlich kleinen Fläche nur schlecht wiedergeben könnte.
Also eher Trööte, am Anfang der kleine Lautsprecher, am Ende die große Öffnung. Man denke einfach an eine Tuba.
Also sehen die quasi so aus wie diese Dinger, die an einem Grammophon dran sind?
zatzen hat geschrieben:MP3 ist ja ähnlich wie JPG eigentlich. Macht ja auch bei JPG Sinn, einen guten Monitor zu haben, trotz mancher geringer Artefakte.
Naja, was ich meine ist, daß MP3 (und MP2/MPG) ja quasi die Qualität reduziert - und eigentlich
AUSSCHLIEßLICH dafür gedacht ist, Speicherplatz zu sparen. Niemand benutzt MP3, damit es besser klingt. Den besten (digitalen) Klang erreicht man mit ungepacktem WAV.
Das Prinzip von MPG (und nachfolgenden) basiert ja darauf, Dinge wegzulassen, die man nicht bewußt hört - nur so ist das "Packen" (bzw die Reduktion der Größe auf 1/10) möglich. Es wird quasi alles in einen Haufen von Wellen zerlegt und diese werden vereinfacht und quasi werden, einfach ausgedrückt, nur die "Formelwerte" einer Bildungsformel für diese Wellen gespeichert. Und diese Werte werden eben irgendwie "gerundet/geglättet", um weniger Platz zu brauchen. Und ich weiß auch nicht, wie viele Wellen gleichzeitig ein MP3 nebeneinander macht. Aber das ist auch der Grund, wieso bei jedem Percussion-Schlag die CPU-Auslastung (auf einem 386er/486er) kurz in die Höhe geht: Alles was "Rauschen"/"Noise" braucht, kann mit Sinuswellen schlechter abgebildet werden und braucht mehr Daten.
zatzen hat geschrieben:Der Unterschied von kleinen Lautsprechern vs. guten großen zeichnet sich für mein Empfinden vielmehr in der Deutlichkeit und Differenziertheit des Klangs ab, die einzelnen Elemente sind bei letzteren viel besser auseinanderzuhalten und auch "Unschönheiten" viel besser rauszuhören.
Ja, ich weiß - und deshalb meine Bemerkung mit MP3: Wenn diese Dinge sowieso "rausgerechnet" werden, brauchts vielleicht dafür auch keine entsprechend qualitativen Lautsprecher mehr.
Aber, wie gesagt: Mich stört es auch nicht, wenn jemand extremen Wert auf guten Sound legt und sich daher hochwertigere Lautsprecher holt (oder baut).
Ich bin, was Bild angeht, ja ähnlich: Heutzutage sagen viele Leute: Wozu CRT, gibt ja TFT, ist flacher und leichter. Aber ich (im Gegensatz zu "Windowsern") arbeite gern mit verschiedenen Bildauflösungen (Windowser nutzen ja nur die maximale, bzw. "native" auflösung ihres TFT).
Und bei allen Auflösungen, die geringer/anders sind als die native des TFT (d.h. die identisch mit seiner Pixelauflösung sind), sieht das Bild einfach mal SCHEIßE aus: Entweder er verkleinert das Bild zentriert in die Bildmitte (um nur ganzzahlige Pixel-Teiler zu haben) oder er streckt das Bild und dann sind die Pixel unregelmäßig breit/hoch bei nicht ganzzahligen Teilern oder er streckt das Bild und interpoliert die Pixel (dann sieht es verwaschen und schwammig aus). Und selbst bei ganzzahligen Teilern wirkt auf einem hochauflösenden TFT dann eine niedrige Auflösung klotzig, weil es keine Pixel, sondern scharf abgegrenzte Quadrate sind.
All diese Argumente sind den Leuten aber egal - man wird für seine Rückständigkeit ausgelacht, wenn man noch Kathodenstrahlröhren-Monitore benutzt.
Das Gleiche mit Touchscreens: Der 8-Bit-Guy hat neulich mal das Gleiche gesagt, was ich auch dazu immer sage: Er spielt lieber auf einem alten Handheld, als auf einem Smartphone.
Abgesehen davon, daß Spiele, die mit etwas Herumwischen/Herumdrücken aufm Bild meist eher simpel sind (gibt ein paar Ausnahmen), kommen folgende Dinge hinzu:
Man hat keine richtigen Knöpfe - d.h. es gibt keine taktile Wahrnehmung, ob man bedient hat oder nicht. Und: Man kann nicht "blind" die "Knöpfe" drücken, weil ja alles eine homogene glatte Fläche ist, muß also immer gucken, wo man drückt. OK, da guckt man ja sowieso - drittes Problem: Der Bildschirm, der zur Anzeige dient, ist gleichzeitig Bedienfeld, d.h. es sind immer Teile der Anzeige durch Finger verdeckt. Und das vierte, eher physikalische: Früher hieß es immer: "Nicht auf die Fensterscheibe/Bildschirm fassen, das gibt eklige Schmierschlieren." - Scheint heute keinen mehr zu jucken, daß der Anzeigebildschirm aussieht als hätte man sein Butterbrot drauf geschmiert...
Mein persönliches Argument, das nicht nur gegen Smartphones, sondern "Händies" allgemein spricht: Man hat quasi ständig einen mobilen Transponder, also Sender am Körper, der die Position durchfunkt. Da muß ich immer an den Film "Demolition Man" denken, wo man in der Zukunft allen Leuten ins Handgelenk einen Sender implantiert hat, damit die Leute jederzeit aufgefunden werden können. Und Phoenix oder so (der von Wesney Snipes gespielte "Bösewicht") war ja ausgebrochen und hatte keinen so Sender. Und als die Polizei da dann überlegte: "Ohne Sender? Wie konnte die Polizei nur früher Leute finden?", hat der Demolition Man (Sylvester Stallone) gesagt: "Na, wie schon? Sie haben gearbeitet. Sollten Sie vielleicht auch mal versuchen.
Ich jedenfalls finde diese faschistische Scheiße zum Kotzen!"
Tja, und heute trägt jeder freiwillig so ein Ding mit sich rum - Implantation nicht nötig: reicht ja, wenn man Dummheit ins Gehirn implantiert, dann braucht's keinen Zwang von außen mehr...
Und all solche Argumente prallen auch an Leuten ab. Ich hab's da inzwischen aufgegeben, irgendwen von irgendwas überzeugen zu wollen. Das funktioniert sowieso nicht.
Bis heute kann ich z.B. Windows nicht ernstnehmen (und wundere mich immer noch, daß es überhaupt jemand ernstnimmt). Man muß es zwar benutzen, weil Webseiten derart Javaskript (und ähnliches) verseucht sind, daß alte Browser da kaum noch etwas darstellen können, aber von MÖGEN bin ich weit entfernt. Und wenn dann einer kommt mit "Nimm doch Linux"... naja - Linux macht das, was ich schon an Windows nicht leiden kann, noch mehr: Alle Zugriffe indirekt über etliche Abstraktionsstufen - das macht alles mit allem kompatibel. Aber es macht es auch lahm.
zatzen hat geschrieben:Kommen wir mal zu einer Überlegung, die ich bisher kaum näher verfolgte, aber ich habe in letzter Zeit öfters davon (nachts) geträumt, dass ich mit nem eigenen (ZSM) Tracker Musik gemacht hätte und das wäre ganz toll gewesen. Der Tracker war bunti (320x200x256) aber nicht klicki. Ungeachtet der Tatsache, dass es rein pragmatisch wenig Sinn macht, da ich auch einfach in X-Tracker was erstellen und dann konvertieren kann, mal folgende Überlegungen:
- Ich müsste entweder XMS oder einen "pagefile" benutzen. Gründe: Selbst bei interner leichter Kompression der Patterns wäre die eigentliche Stärke von ZSM, ca. 500 Patterns halten zu können, nicht machbar. Ist klar, man wird allemal nur 50 brauchen, aber es geht ums technische Prinzip.
Ja, so teilweises Auslagern (XMS, Festplatte) wäre hier wohl die Idee. Aber ich persönlich bin ja immer der Meinung, daß man, wenn man Dinge wesentlich größer dimensioniert als man sie braucht, genau immer die Fehler macht, die Microsoft macht: Alles wird ein Performance-/Speicherfresser, auch wenn es gar nicht nötig wäre, nur für eine theoretische Möglichkeit, "herumzuaasen". Wenn man schon ein Tool baut, das man vorrangig selbst benutzen will und nicht einmal selbst die Disziplin haben will, sich irgendwo auf ein vernünftiges Maß einzuschränken, braucht man sich auch nicht zu wundern, wenn alles so ausufert.
Ich weiß, daß "aus dem Vollen schöpfen" immer schön klingt. Meiner Erfahrung nach kommt man damit irgendwann an gewisse Grenzen, wenn man "alles auf einmal" will - und hat dann nachher seine liebe Not, an allen Ecken das Programm/die Daten zu beschneiden.
Ich sag's mal so: Geht alles - auf GHz-Maschinen mit GB-Speicher und TB-Platten. Das hat aber nichts mehr mit DOS zu tun...
zatzen hat geschrieben:Weiterhin ist auch die dynamische Verwaltung der Samples mit Problemen verbunden, zudem brauche ich Headroom für Funktionen wie Importieren von WAV zu 4 Bit Delta.
Naja - genau das wäre ja die Kunst, die disziplinierte Coder von Speicherschluderern unterscheidet.
Gerade letztens ist bei mir ein Ding fertig geworden, das ein SKRIPT ist (ja, ich weiß: Skript - IGITT!) Das Ding soll dazu dienen, Menüs und ähnliches nachladbar zu machen, d.h. der "Code" dafür ist in diesem Skript gemacht. Es gibt Variablen, sowohl interne als auch externe. Externe Variablen (mehrere Typen) haben, simpel ausgedrückt, einen Pointer und noch Daten zur Größe/Typ usw. D.h. man kann von dem Skript aus auf jede Variable/Speicherstelle zugreifen. Ebenfalls hat es Labels (für Sprünge) und alle Parameter können auch als Formel dargestellt werden, die Operationen, Funktionen, Konstanten und eben Variablen enthalten. Man kann einen Befehl entweder "intern" benutzen (gibt schon ein paar einprogrammierte z.B. für die Sprünge oder Variablenzuweisungen) oder direkt auf eine Pascal-Procedure verweisen und ihr die Parameter als Werte übergeben.
Der Skriptinterpreter/Ausführer ist in 100% Assembler - und, klar, das performt dann nicht so wie ein direktes Programm und braucht ja eben den Skriptinterprester. Aber es ist ja auch nicht dazu gedacht, damit ein Spiel zu schreiben, sondern nachladbare Programmteile zu haben, die man nur so lange im Speicher halten muß, wie sie gebraucht werden und die trotzdem unabhängig vom Hauptprogramm entwickelt/geändert werden können.
Etwas ähnliches - damals war der Interpreter aber noch in Pascal geschrieben - wird in den ganzen Menüs von Xpyderz benutzt und mein erster externer Skriptinterpreter, der sowas tut, war ebenfalls noch in Pascal (der wird in TheGame3, meinem Level/Sprite-Editor benutzt).
Jedenfalls ist der Sinn des Ganzen, ein Programm mit beliebig vielen Funktionen haben zu können, das trotzdem noch genügend Platz für die eigentlichen Daten übrigläßt, weil jede Funktion nur so lange im Speicher ist, wie sie gebraucht wird.
Vor einer Weile habe ich auch mal eine (eigentlich 4) ultraschnelle (ebenfalls 100% Assembler) Routine geschrieben, die sowohl für MCGA als auch für Mode-X Texte eines 4x8-Pixel Zeichensatzes ausgibt und auch eine - ebenfalls schnelle (100% Assembler), die mein spezielles Zeichensatzformat für Proportionalschrift benutzt, für Zeichensätze bis 32 Pixeln Höhe - allerdings skalierbar und optional mit Funktionen Fett, Kursiv, Unterstrichen, Invers, usw.
Das, in Kombination mit den anderen Funktionen, die ich da schon habe, könnte benutzt werden, um eine generalisierte 320x200x256 (bzw auch Mode-X-Auflösungen) GUI zu bauen...
Daran mußte ich so denken, als Du von Deinem Traum geschrieben hast.
zatzen hat geschrieben:Letzlich würde ich lieber eine Auslagerungdatei und nicht XMS benutzen, Patterns würde ich somit daraus laden und drin speichern, fragt sich nur ob das schnell genug ist, es müsste ja innerhalb einer Pufferzeit geseekt und geblockloadet werden, und je nachdem entpackt - aber das zeilenweise, mal sehen.
Naja, bei Tools sehe ich die Benutzung von XMS nicht so kritisch an wie bei Spielen. Wenn man sich selber Tools schreibt, können die ja so viel Speicher benutzen, wie in die Maschine eingebaut ist. Bei Spielen will man ja vielleicht auch, daß jemand anders sie benutzen kann - und es können umso mehr Leute ein Spiel benutzen, je geringer die Systemanforderungen (was ja Speicherbedarf einschließt) sind.
XMS (Himem.Sys) hat ja das "Problem", daß es darauf angewiesen ist, wie schnell die Hardware da umkopiert. - Das ist der Grund, wieso ich es ungern bei irgend etwas benutzen will, was vielleicht 50x pro Sekunde passieren soll. Bei einem Entwickler-Tool dagegen ist Echtzeitausführung ja nicht unbedingt ein Muß - da ist es wichtiger, daß einem möglichst viele Optionen offenstehen.
Das ist so meine Meinung dazu.
zatzen hat geschrieben:- Da bei ZSM die Samples beschnitten werden, d.h. nur so viel gespeichert wird wie wirklich abgespielt wird, was nur an einem fertigen Modul entschieden werden kann, liegt es nahe, intern ein anderes Format zu verwenden, und dann für ZSM eine Exportierfunktion zu integrieren, oder einfach einen Converter beizulegen. Ein internes Format mit ungekürzten 8 Bit Samples hätte immerhin den Vorteil, dass man die Stücke dann auch ohne Verlust in den Samples in andere Formate wie DMF oder MOD exportieren könnte um sie evtl. weiter zu bearbeiten.
Naja, auch in MOD wird vom Sample ja nur so viel abgespielt, wie gebraucht wird. D.h. auch dort würde es kein Problem machen, wenn die Samples entsprechend beschnitten wären. Es gibt ja keine "Standard-Samplegröße" - es ist dann einfach ein kürzeres Sample. Das Problem ergäbe sich nur bei einer nachfolgenden Bearbeitung, bei der ein Ton vielleicht verlängert werden soll - aber dieses Problem hätte man ja auch bei ZSM. Man kann nur Daten benutzen, die vorhanden sind.
Und, da gebe ich Dir recht: Bei so gepackten Formaten, die nicht nur "Packformat für ein anderes Ausgangsformat" sein sollen (wie z.B. MOD), also nicht nur konvertiert, sondern auch selbst erstellt werden sollen, würde es natürlich Sinn machen, entweder ein "Source-Format" dazu zu entwickeln, ODER einen "Rück-Konverter" einzubauen, das das gepackte Format (ZSM) in ein "editierbares" überführt - weil das Editieren in den komprimierten Daten wohl unmöglich wäre.
AtavISM hat da einen ganz eigenen Weg: Die Daten liegen im Speicher weiterhin die ganze Zeit im ISM-Format vor und nur das aktuelle "Pattern" wird jeweils "live" in ein Pattern-Format überführt und wieder zurückgeführt in ISM. Da ist intern eine ziemliche "Maschine" dahinter, die das alles zurechtmurkst, damit der Bediener nichts davon merkt, d.h. hier gibt es wirklich KEIN Source-Format. - Allerdings ist ISM ja auch nicht wirklich "gepackt" - eine eventuelle Speicherersparnis ergibt sich nur deshalb, weil die Daten statt in einer Patternstruktur in einer eher "Programmcode"-artigen Struktur vorliegen (Schleifen, Sprünge, Countdownwerte statt "Auslassen" usw.) Das bißchen "Packen", was ISM macht, passiert nur (optional) beim Speichern, wo gleiche Abfolgen von Befehlen zusammengefaßt werden - also simples Lauflängen-Packen, auf Word-Werte bezogen.
zatzen hat geschrieben:Tja, ein solcher Tracker wäre herzlich un-innovativ, aber vielleicht doch ganz reizvoll, aufgrund der Einfachheit, und der Garantie, dass darin gemachte Musikstücke 100% ZSM kompatibel wären, auch mit Vorschaumöglichkeit des Klangs von 4 Bit Delta. Und ich hätte meinen ersten eigenen Sample-Tracker.
Wäre natürlich cool. Aber da bin ich auch vorbelastet, weil ich es generell cool finde, wenn jemand etwas selbst programmiert.
zatzen hat geschrieben:DOSferatu hat geschrieben:Nur, ein einzelnes Mono-8-Bit-22-kHz Sample braucht für 1 Sekunde nunmal auch 22 kByte RAM. Allein 3 solcher Samples füllen schon ein komplettes Segment!
Ist klar, dass ich da wieder einsteige: Man kommt mit 16 kHz bis auf ganz höhenlastige Sachen wie Rasseln oder sowas sehr gut hin, das ist schon sehr gute Qualität. Wenn man bedenkt dass für Samples wie Bass 8 kHz reichen und sagen wir im Schnitt haben wir 12 kHz, was auch für Sprache hinreichend ist in einem Spiel, dann kommen wir bei 4 Bit Delta auf 6000 Byte pro Sekunde, und damit auf knapp 11 Sekunden pro Segment.
Naja, ich meinte damit ja etwas anderes:
Wenn die Ausgangsdaten nicht 22 kHz sind, sondern vielleicht nur 16 kHz, dann erreicht man, wenn man den Soundblaster auf 22 kHz einstellt, genau die gleiche Qualität wie wenn man ihn auf 16 kHz einstellt. D.h. eigentlich muß man bei der Soundausgabe nur die maximale Frequenz benutzen, die das höchst-aufgelöste Sample hat - denn besser wird's nicht.
Und andersrum ausgedrückt: Wenn man denn 44 kHz Soundqualität haben will, wird man die kaum erreichen, wenn die Samples selbst keine 44 kHz haben - das nachträgliche "Aufblasen" durch Mehrmalsspielen des gleichen Frames (z.B. 4x das Frame spielen bei einem 11 kHz-Sample) erhöht nicht die Qualität.
zatzen hat geschrieben:Ja, das ist irgendwie gemogelt mit der Kompression, aber so auch mit der Grafik, bei Deiner Problematisierung des Speichers erscheint es mir langsam wirklich sinnvoll, ernsthaft an soetwas wie ZVID2 weiterzumachen.
Naja, wie Du schon sagtest: Ich sehe das mit der Speicherauslastung vielleicht zu pessimistisch, weil Du ja auch Kotzman II mit nur 1 Segment hinbekommen hast.
Ich bin dabei nicht davon ausgegangen, wie jemand generell ein Spiel macht, sondern davon, wie mein SLOT aufgebaut ist. Das Ding braucht natürlich auch Speicher für die ganzen Programmroutinen. Man darf ja nicht vergessen, daß wir aufm PC mit einer "Von-Neumann-Architektur" arbeiten: Programmcode und Daten benutzen den gleichen RAM. Darauf versuche ich immer wieder direkt und indirekt hinzuweisen. Beispiel: Wenn man supergepackte Daten hat, aber die Entpackroutine so aufwendig ist, daß sie größer ist als die Daten wenn sie entpackt wären, ist es eine Überlegung wert, entweder nicht ganz so "super" zu packen (und damit die Packroutine zu verkleinern) oder sogar schlimmstenfalls ganz aufs Packen zu verzichten. Wenn also das Packen am Ende gar keine Speicherersparnis bringt (weil die Entpackroutine ja auch im Speicher liegen muß) und zusätzlich Performance kostet (weil Entpacken ja auch Rechenzeit braucht), muß man am Ende abwägen, wie sehr das nützt.
Und meine Programmroutinen brauchen eben auch Speicher: Die Steuerroutine (GameSys2) braucht ca. 21 kByte Speicher, das ISM (ohne die Laderoutinen!) braucht 10 oder 11 kByte. Die Grafikroutinen habe ich nicht ausgemessen, aber das wird wohl auch im zweistelligen kByte-Bereich sein.
Und naja - Sprites und Grafik selbst sind natürlich ein Speicherfresser par excellence. Und je mehr man hier bastelt, um das Einzugrenzen, umso mehr und aufwendigere (ebenfalls Speicher - und Rechenzeit - brauchende) Routinen werden gebraucht, um dann auf diese Daten zuzugreifen.
Das ist der Grund, wieso ich da so pessimistisch rangehe. So eine DOS-Maschine hat nun mal auch Grenzen in der Leistung UND beim Speicher. Ich weiß z.B. immer noch nicht, wo Du Deine Sounddaten erzeugst. Ich meine damit: Wenn die Blaster einen IRQ wirft ("Daten alle") und Du neue Daten in den Sound-Doublebuffer generierst, wo passiert das? Wird das gleich im IRQ gemacht, d.h. in der ISR oder im Hauptprogramm?
Ich selbst traue mich z.B. nicht, Dinge die verhältnismäßig viel Zeit brauchen, im IRQ auszuführen, deshalb haben bei mir die IRQs eher Signalfunktion und Umschaltfunktion und alles, was "generiert" werden muß, wird in der Hauptschleife aufgerufen, wenn signalisiert wurde, daß neue Daten (Grafik, Sound) gebraucht werden. Der Nachteil meiner Methode ist, daß ein Soundpuffer mindestens so lange "durchhalten" muß, wie ich maximal für das Erzeugen EINES Grafikframes brauche (das braucht die meiste Zeit). Habe auch schon für Sound an Triple-Buffering (statt Double) gedacht, aber je mehr "Vorlauf" man dem Sound gibt, umso unsynchroner wird er ja. Das ist bei Musik ja egal, weil die sowieso nur begleitet - aber die Soundeffekte sollten ja trotzdem noch einigermaßen zusammen mit den zugehörigen Aktionen kommen.
Eine andere Möglichkeit wäre, für das Ding quasi Multitasking zu bauen: Jeder Teil hat einen eigenen Stack, auf den auch immer alle Registerinhalte geworfen werden und der Ticker führt "im Kreis" alles aus, d.h. unterbricht eine Routine, schreibt aufn Stack, wechselt zum Stack der nächsten Routine, holt alles und springt zurück. Auf diese Art könnte jede Routine von jeder unterbrochen werden und man hätte das perfekte Timing.
Ich hatte schon wirklich darüber nachgedacht, das so zu machen - allerdings klingt das in der Theorie einfacher als es die Umsetzung in der Praxis ist. Und bestimmte Zugriffe müßte man dann vor Unterbrechungen schützen, weil z.B. manche aufeinanderfolgende Portzugriffe es nicht mögen, wenn da zwischendurch jemand anders reingrätscht, der vielleicht andere Portzugriffe macht... Ich frage mich manchmal sowieso, wie ein PC überhaupt funktionieren kann bei diesem ganzen Chaos...
zatzen hat geschrieben:Notfalls mache ich vielleicht doch etwas in Richtung Adventure, wo es nicht auf hohe Framerates ankommt.
Ach, ein Adventure zu machen, würde ich nicht als "notfalls" und "Notlösung" bezeichnen. Adventures sind toll. Habe ich auch schon selbst Ideen für einige Adventures. Wenn ich diesen Job nicht hätte und nicht immer so müde wäre (keine Ahnung, woran das liegt - vielleicht das Alter), hätte ich schon lange etwas in der Richtung gemacht.
zatzen hat geschrieben:Oder man ermutigt sich wieder einmal angesichts Jump&Runs wie... Captain Comic mit seinen 10 fps und 8 Pixel-Scrolling. Total "outdatet", aber:[...]
So lange es Spaß macht, finde ich solche "technischen Dinge" nebensächlich. Ich bin sowieso der Meinung, daß heutzutage Spiele viel zu sehr nach technischen Dingen als nach Spielideen bewertet werden. Immer die gleiche Spielidee mit immer besserer 3D-Grafik - das wird heute besser bewertet als eine neue Spielidee, die vielleicht zu simple Grafik/Sound hat. Das ist schon schade. Aber das ist eben der Grund, wieso der 'zigste hochauflösende Kriegs-Ego-Shooter gemacht wird...
zatzen hat geschrieben:Sinn macht das Programmieren als Spielwiese für nicht mehr zeitgemäße Ergebnisse und scheinbare sinnlose Datenverarbeitungsverfahren ohnehin, denn gleichermaßen könnte man sagen, die ganze Programmierung für Dos wäre heutzutage sinnfrei. Sieht Du vielleicht anders, weil Du gerade in Dos versuchst, möglichst optimal zu programmieren, so als würde es zu damaligen Zeiten verwendet werden.
Ach naja, ich bin ja kein so Coder-Gott wie vielleicht John Carmack. Das "Optimale" ist es nicht, worum es mir geht, obwohl das natürlich immer erstrebenswert ist. Mir geht es eher darum, daß Speicher und Performance der Maschine auch ausreichen für das was ich da machen will. Und wenn man bei jedem Einzelteil (z.B. eines Spiels) sagen würde: "Macht nichts, wenn's zuviel Speicher braucht und nicht performt", dann funktionieren alle Teile zusammen vielleicht nicht mehr als Spiel.
Früher[tm], als ich vom C64 auf PC kam und gesehen habe, daß der sogar wenn ich in Pascal code mehr performt als auf C64 in Assembler, hatte ich gedacht: Dann kann man ja auch gleich alles in Pascal machen - wozu noch Assembler lernen? Aber dazu muß man sagen, daß ich damals auf C64 in Assembler nicht wirklich gut war, sondern nur so naheliegende Sachen 1:1 in Asm so "umgesetzt" habe wie man sie in BASIC machen würde. Und weiterhin muß man ja sagen, daß der C64 Hardware-Sprites und für Spiele brauchbare Grafikmodes hatte (der Multicolor-Textmode hat ja quasi wie Kacheln funktioniert). Und der Soundchip hat ja alleine losgelegt, sobald man ihm die richtigen Daten gegeben hat. Der PC hat all so etwas ja nicht von sich aus - und da stößt man mit Pascal eben auch an gewisse Grenzen, falls man vorhat, ein nicht ganz so krüppeliges Spiel zu machen.
Naja, wer weiß, ob ich überhaupt noch mal dazu komme, ein Spiel in Angriff zu nehmen. Das bißchen, was ich in letzter Zeit programmiere/entwickle, ist immer noch nur so "Außenherum-Kram". - Ich kann mich einfach nicht dazu durchringen, mit einem Spiel anzufangen, wenn ich immer noch weiß, daß da unfertige Dinge "herumliegen", die ich dann "workarounden" müßte.
Diese blöden Workarounds, die unfertige/unschöne Teile umgehen, brauchen immer Platz und kosten Performance und das Rumgefrickel an den Workarounds, bis sie das machen, was sie sollen, kostet dann immer mehr Zeit als das eigentliche Spiel zu bauen - das minimiert den Spaß und die Kreativität beim Spielebauen enorm.
Xpyderz hat mich ja diesbezüglich sehr desillusioniert. Zu Anfang sah das noch gut aus usw. Und dann kamen viele Dinge dazu, die immer mehr Herumgemurks und "Code um den Code herum" Zeugs erforderten und jetzt kann ich den Kram nicht mehr sehen. Ich spiele das wirklich gerne noch ab und zu. Aber den Programmcode will ich nicht mehr anfassen - und so wird das Spiel wohl auch leider nie vollendet werden. Sollte ich jemals wieder etwas an Xpyderz machen, wird es wohl eher darauf hinauslaufen, daß ich die Grafiken nehme und in SLOT einbaue und den ganzen Rest (Steuerung und endlich auch mal Sound) dann in SLOT mache... Naja, schon wieder dieses Xpyderz... Sollte das nicht so oft erwähnen. Es ist eben meine "Referenz", so wie bei Dir "Kotzman II".
zatzen hat geschrieben:Bei mir haben sich die Hobby-Prioritäten leider anders entwickelt, ich programmiere gerne, nicht zuletzt um etwas zu lernen (besonders in ASM), bin da aber nicht so streng mit mir. Wenn ich Routinen schreibe mache ich das schon möglichst optimal, aber mir fehlt etwas der Atem, um ein Spiel wirklich mit höchster Vernunft und Verzicht auf Spielereien wie ZVID und ZSM aufzuziehen.
Naja, ich programmiere auch gern - nur wird es sehr anstrengend, wenn man so müde ist. Und wenn ich mich nicht richtig konzentrieren kann, kommt auch nichts Gescheites dabei raus. Da weiß ich nicht einmal, an welchem Ende ich anfangen soll und lasse es dann oft ganz sein, um nicht Stunden damit zu verbringen, totalen Bullshit für die Mülltonne zu fabrizieren.
Aber ich programmiere auch nicht "mit höchster Vernunft und Verzicht auf Spielereien". Bei mir ist das eher eine pragmatische Sache: Ich sehe, wie viel Speicher etwas braucht oder sehe, wie sehr etwas performt und dann muß ich ja irgendwie "einschreiten", wenn es nicht mehr paßt. Wenn irgendwann die Steuerung versagt oder der Sound Aussetzer kriegt, auf so ein Spiel hätte ich schon selbst keinen Bock.
zatzen hat geschrieben:Heisst also auch, ich möchte gerne mal meine Formätchen, die etwas Performance zugunsten Speicherplatz opfern, in Action erleben.
Klar - wer will das nicht? Andererseits muß ich auch sagen, daß ich schon oft aufwendig entwickelte Dinge "weggeschmissen" habe, wenn sie am Ende nicht das gemacht haben, was sie sollten - oder wenn sie z.B. selbst mehr Speicher brauchten als sie bei den Daten eingespart haben oder wenn sie so wenig performt haben, daß sie unbenutzbar wurden. Wenn ich an die ganzen Übertragungsprotokolle denke, die ich schon entwickelt und weggeschmissen habe...
Und, wie erwähnt, ist ja auch GameSys2 nicht wirklich die 2., sondern eher schon die 5. Generation...
zatzen hat geschrieben:Das ganze hängt damit zusammen, dass erst die Programmierung in Assembler mir solche eher komplizierten Kompressionsverfahren bei einigermaßen vertretbarer Performance ermöglicht hat, und das ist dann für mich im Moment noch neu und interessant, weil ich zuletzt bei Kotzman II noch kein Assembler konnte. Und nicht-transparente, unkomprimierte Sprites mit PUT setzen war sowas von unspektakulär...
Ja, man wächst mit seinen Aufgaben. Wir beide prokrastinieren hier quasi vor uns hin und halten uns mit "Nebensächlichkeiten" auf, weil wir uns nicht trauen, ein Spiel zu machen - weil wir wohl beide befürchten, daß es ein großer Haufen Mist wird...
zatzen hat geschrieben:Deine auführliche Abhandlung über die Anforderungen eines Spiels wirken etwas pessimistisch. Ich habe nur die Erfahrung dass ich bei Kotzman II mit nur einem(!) Datensegment immerhin etwas vorzeigbares hinbekommen habe.
Ja, wie schon oben erwähnt, bezog ich mich da eher auf MEINE Routinen. Damit ich auch mal mehrere meiner Spielideen umsetzen kann und nicht bei jedem quasi wieder "bei Null anfangen" muß, will ich eben gern etwas haben, das bestimmte Dinge generalisiert und abstrahiert. Das widerspricht zwar teilweise meiner Einstellung (so systemnah wie möglich), dem versuche ich aber durch Performance (durch 100% Assembler für diese Routinen) entgegenzuwirken.
Ich denke dabei so: Wenn sowieso viele meiner Spielideen mit gekachelten 2D-Levels, Sprites und Chiptune-Sound umsetzbar sind, dann macht es schon Sinn, die Routinen, die man dafür braucht, nicht jedesmal neu zu coden - und auch im Vorfeld schon quasi einen "Rahmen" zu haben, in dem ich testen kann, ob der ganze Kram auch wie gewünscht zusammenarbeitet - und zwar, BEVOR ich einen Haufen Mühe in Grafiken, Musiken u.ä. stecke, die ich dann nie benutzen kann, weil die technische Seite nicht funktioniert.
Das liegt bei mir daran, daß ich früher (leider) genau das gemacht habe: Ich habe schon schöne Grafiken (Sprites usw.) für Spiele erstellt (sowohl auf C64 als auch auf PC), die es dann nie gegeben hat - die Zeit hätte man sich sparen können und da tut es einem dann jedesmal weh um die schöne Idee und das ganze Zeug, wenn es unbenutzt auf irgend einer Diskette oder Festplatte verstaubt, weil man einfach noch nichts hat, wo es benutzt werden kann.
zatzen hat geschrieben:Und mein Ziel ist ja eher nur, daran anzuschliessen, soetwas ähnliches nocheinmal zu machen, nur in jeder Hinsicht, also Grafik, Sound, aber auch Spielgeschehen, etwas erweitert (und dafür die restlichen 7 Segmente zu verwenden...).
Wäre 'ne tolle Idee. Auch das komische "zu Anfang 'n Level laden" usw. war ja immer etwas crazy. Aber von der Spielidee her mag ich das ja. (Mag ja generell diese 2D-Jump'n'runs.)
zatzen hat geschrieben:Deswegen mache ich mir da ersteinmal keine solchen Gedanken.
Ich brauche gar nicht erst versuchen einen "Blockbuster" zu programmieren, die Möglichkeiten von Real-Mode Dos reissen heute keinen mehr vom Hocker, wenn man "fotorealistisches" 3D in Full HD erwartet.
Naja, ich weiß schon seit langer Zeit, daß zwischen Leuten wie Carmack und mir ganze Universen liegen und bin auch nicht so verrückt, zu glauben, daß ich irgendein Spiel machen könnte (egal auf welchem System), das irgendwen von irgendeinem Hocker reißt. Wie Du ja weißt, ist mein Ziel, Spiele in dem Genre wie diese SNES-Spiele zu machen - allerdings ist mir schon klar, daß ich da grafisch und musikmäßig natürlich nicht so talentiert bin wie die professionellen Entwickler.
Natürlich gibt einem dieses Wissen auch eine gewisse "Ruhe": Niemand drängelt einen, wann das Spiel endlich fertig ist, niemand hat auf ein neues "2D-Spiel unter MS-DOS" gewartet. Wahrscheinlich würde man auch mehr Motivation haben, WENN jemand drauf warten würde - dann wüßte man, daß es
überhaupt jemanden interessiert, was man da macht und daß es wenigstens schon ein paar Leute gäbe, die das Ding spielen wollen würden. Nur kriegt man heutzutage so etwas viel leichter auch auf seinem SmartPhone - da wartet dann keiner auf ein Spiel für ein obsoletes System, das man auf einem aktuellen System nur mit einem Emulator zum Laufen kriegt, den man auch noch aufwendig konfigurieren muß.
zatzen hat geschrieben:Einfach nur ein kleines nettes liebevoll gestaltetes Spielchen.
Naja, daß man das LIEBEVOLL macht, versteht sich ja wohl von selbst!
zatzen hat geschrieben:Und ob nun ein Spiel auch auf einem 386er statt 486er flüssig laufen würde dürfte auch nur Leute wie Dich und mich im Sinne von Idealismus kümmern, und da kann man selber abwägen wie wichtig einem das ist.
Naja, das Problem ist, daß ich das auch nicht vorher planen kann. Ich kann zwar auf 486er-Opcodes verzichten (was ich auch tue), und habe damit eine "Mindestanforderung 386er", aber das bedeutet ja nicht, daß es auf 386er dann auch ausreichend performt. Wahrscheinlich sind meine ganzen Routinen hier schon "zuviel Geraffel" für 'n 386er. Bekanntermaßen ist ein 486er mit GLEICHER Taktfrequenz mind. doppelt so schnell wie ein 386er. Aber 386er gehen ja nur bis 40 MHz - und mein 486er hier hat 133 MHz und ist zusätzlich noch so ein X5. D.h. man kann davon ausgehen, daß meine Kiste ca. 10x so schnell ist wie der schnellstmögliche 386er. Oder anders ausgedrückt: Wenn ich 50 fps schaffen WÜRDE, dann wären's auf 386er 5 fps! Und das NUR DANN, wenn der 386er auch so eine coole PCI-Grafikkarte mit 16 MB/sek. Durchsatz hat - was er wahrscheinlich nicht hat, schon weil es sein kann, daß auf viele 386er-Motherboards kein PCI draufpaßt...
zatzen hat geschrieben:DOSferatu hat geschrieben:[...]scheint ja auch die ganze Mühe, die ich in den zweiten, alternativen Editor AtavISM gesteckt habe [...] trotzdem kaum dazu zu geführt zu haben, [...] wirklich zur initialen Entwicklung von Musikstücken verwenden zu wollen/können.
Wenn Du ein Spiel machst, das ISM verwendet, und Du gerne Musik von mir gemacht haben möchtest, dann sollte es klar sein, dass ich dann AtavISM verwende. Genauso ist es aber auch klar, dass ich nicht in AtavISM Musik komponiere, wenn ich den Schwerpunkt auf Samples lege oder das ganze am Ende auf CD-Niveau ausproduzieren möchte.
Ja, schon klar. War auch nur eine Anmerkung. Den "Umbau" auf "Tracker-Ähnlichkeit" und "X-Tracker-Bedienung" habe ich ja hauptsächlich wegen Dir (zatzen) gemacht, weil Du der einzige bist, den das ganze Ding überhaupt wenigstens geringfügig interessiert hat.
Wenn ich Musik mache, muß es ja nicht CD-Niveau sein. Es gibt dermaßen viele Leute, die auf den Chiptune-Sound stehen und die genau diesen "retro-mäßigen" (wie man's heute nennt) Sound mögen. Deshalb fände ich es nicht schlimm, wenn auch heute jemand Musik in diesem Stil machen würde. Ich weiß zwar, daß es damals eher nur aufgrund technischer Beschränkungen so gemacht wurde, aber das ist für mich kein Anlaß, deshalb heute nur noch CD-Quali machen zu müssen. Das ist wie mit 2D-Pixelgrafik vs 3D-Fotorealismus:
Kann man machen,
muß man aber nicht.
zatzen hat geschrieben:Es ist "schade" dass es nicht so viele Leute gibt, die neue Software wie AtavISM benutzen, genauso würde es mir aber auch mit dem "Zatzen simple Tracker" (s.o.) gehen. Es gibt eben heute massig kostenlose Tracker (sogar schon Online im Browser) und Musikprogramme für Windows, die VST Instrumente und Gigabyte-weise Samples verarbeiten können.
Naja, daß Leute heutzutage kaum noch Tools benutzen, die nur unter DOS (bzw. bis maximal WinXP 32bit) funktionieren, hat ja auch noch andere Gründe...
Was soll jemand schon mit einem Tool, das nur in einem Emulator läuft und viel weniger kann als aktuelle Tools (die keinen Emulator brauchen) - um damit Daten zu machen, die ebenfalls nur mit Zeug in besagtem Emulator funktionieren? Da kann man die Leute schon verstehen, die so etwas nicht brauchen. Andere Leute sind viel praktischer veranlagt - denen geht es nicht um das OS oder die Programmierung dahinter, wo irgend etwas läuft, die sind eher ergebnisorientiert.
Für mich (und Dich wohl auch) gilt eher "Der Weg ist das Ziel" - und daß es einem mehr Wert ist, es selbst gemacht zu haben, auch wenn's nur auf einem System ist, das seit einem Vierteljahrhundert nicht mehr verkauft wird, als vorgefertigte Dinge zu benutzen, von denen man kaum eine vage Ahnung hat, wie sie funktionieren.
Allerdings muß man zugeben, daß ergebnisorientierte Leute einen wesentlich größeren Output an Software haben.
zatzen hat geschrieben:[...]Jedenfalls hat es für mich schon Vorteile wenn ich nicht vorab erstmal alle Samples auf 8 Bit und 11 kHz runterrechnen muss nur um sie am Ende wieder durch 16 Bit 44 kHz auszutauschen.
Naja, wie gesagt: Es muß ja nicht immer Qualität am Anschlag sein.
zatzen hat geschrieben:Vielleicht hast Du diese Videos von mir gesehen, wo das Gesehene dem Ton entspricht, also praktisch Videos als Samples benutzen. Sowas kann Renoise noch nicht, ich hatte das für X-Tracker auch nur selbst programmiert diese Möglichkeit.
Ja, ich weiß.
Naja, im Prinzip hat ISM solche Möglichkeiten, wenn man alle Features ausnutzt und im Prinzip könnte ich das auch in AtavISM als Befehl einbauen. Weil ISM ja eher eine programmartige Struktur hat, kann man da vieles "nachrüsten". Immerhin war AtavISM ja auch nur möglich, weil ISM so flexibel ist. Allerdings ist ISM nie dafür gedacht gewesen, als Video/Audio zu funktionieren, weil es von Anfang an für Spiele gedacht war. Allerdings könnte man natürlich auch nebenher eine Art Video laufen lassen. Wenn Ton und Bild gleich schnell laufen, bedarf es auch keiner Synchronisation zwischen Bild und Ton.
zatzen hat geschrieben:Ich überlege ob ich sowas auch für Renoise mache. Da müsste ich mich durch das in XML gehaltene Dateiformat durchwursteln und quasi einen Renderer schreiben, der Frame-Informationen die parallel in Samples gehalten werden entsprechend zurechtrechnet.
Auch ein Zeichen der Zeit, dass die Dateien nicht binär sondern als XML gespeichert werden, also aufgeblasen wie sonst was, naja, damit "menschenlesbar", kann ja auch ganz praktisch sein, 600K hab ich da bei einem kleinen Stück mit 4 Patterns, nur die Definitionen, ohne Samples.
Das liegt nicht daran, daß es menschenlesbar sein soll. Niemand ist so irre, die komplizierten XMLs, die heutzutage von Programmen erzeugt werden, wirklich noch von Hand zu editieren. Der Grund dafür ist schlicht FAULHEIT - weil XML schon quasi als API vom OS angeboten wird und man sich dann kein eigenes Format ausdenken muß. Klar wäre XML dann auch theoretisch kompatibel zu anderen Programmen, die XML benutzen - weil die aber andere Parameter haben, ist es das trotzdem nicht.
Meiner Meinung nach ist XML in jeder Hinsicht "mit Kanonen auf Spatzen geschossen": Es braucht einen umständlichen Parser und ist langsam beim Lesen und dadurch, daß es so ein umständliches Format hat, auch noch fehleranfällig. Da wäre jedes CSV (ebenfalls menschenlesbar, falls es einem darum geht) oder File im INI-Format viel simpler. Aber es ist eben momentane Modeerscheinung. Nehme an, daß Daten und Konfigurationen heutzutage nicht schon in so einem Kram wie PDF gespeichert werden, liegt nur daran, daß man da Lizenzen bezahlen müßte.
zatzen hat geschrieben:Aber so ist es nunmal wenn heute so viel Speicher da ist, vor 30 Jahren waren 20 MB Festplatte viel, heute sind es 2 TB, also Faktor 100.000. Verhältnismäßig wären die 600K dann 6 Byte, was ja ziemlich wenig ist.
Das mag ja sein, aber sinnlos Speicher verschwenden, nur "weil er da ist" (und Performance), ist für mich ein Zeichen von entweder Faulheit oder Blödheit (oder beides).
zatzen hat geschrieben:Und eine Datei mit >4GB ist z.B. oft ein Video. Ich habe in letzter Zeit einige Videos von einer (auch heute längst veralteten) Digital8 Kamera im DV Format auf eine externe Festplatte überspielt. Eine Minute braucht ca. 180 MB.
Achso, Videos.
zatzen hat geschrieben:Ich könnte mich ja selber über die "Jugend" aufregen dass nur noch in GB gedacht wird und vielleicht kaum noch einer weiss was ein MB oder gar KB ist, und dass man sich übers Smartphone oder email einfach Videos von mehreren MB Größe schickt, während ich mir immer noch Mühe gebe, den Anhang von emails so klein wie möglich zu halten.
Tja, wenn etwas "geht", wird's auch gemacht. Denkst Du, daß so Leute wirklich noch gescheit programmieren würden, für die alles unter GB schon Peanuts sind? Für die Industrie macht das aber nichts: "Kurbelt ja die Wirtschaft an". Solche Leute sind ja quasi die Rechtfertigung dafür, daß immer größere und schnellere Systeme "gebraucht werden".
Das ist doch auch allgemeiner Konsens: Wenn etwas auf einem Computer nicht richtig läuft, sagt heutzutage doch kaum einer "Das Betriebssystem ist beschissen" oder "Das Programm ist zu beschissen programmiert" - sondern immer: "Der Computer ist zu langsam".
Ist ja auch klar, für die heutigen "Coder": Schnelleren Computer bauen müssen ja DIE ANDEREN, gescheit programmieren lernen müßte man ja SELBER...
zatzen hat geschrieben:Aber es ist eben mittlerweile möglich und ich kann selber nicht leugnen dass ich Nutznießer dieser modernen Technologien/Bandbreiten/Kapazitäten bin, nicht zuletzt auch im Audio-Segment, wo 25 Jahre alte Hardware die Arbeit schon etwas bremsen und einschränken und vor allem verkomplizieren würde.
Tja, aber früher haben's die Leute auch gemacht. (Ja ich weiß: Früher gab's auch Plumpsklos und ich bin auch froh, daß ich ein Innenklo mit Wasserspülung habe.)
Was eher stört ist, daß heutzutage das Denken ist: Wenn etwas irgendwie Mühe machen würde, heißt es nicht "da muß man sich die Mühe machen", sondern immer gleich: "geht nicht".
Dinge, die nicht "wie von selbst" und "auf Anhieb" funktionieren, werden als "geht nicht" eingestuft - diese "Instant Gratification"-Mentalität spielt der Industrie aber in die Hände. Und das nimmt man auch gerne so an - denn wer will schon Konsumenten, die zu viel denken?
zatzen hat geschrieben:Ja, kann man alles auch mit MIDI und nem Fuhrpark von Audio-Peripherie am Atari machen. Hab ich aber nie so gemacht sondern seit 1993 alles in einem Computer ohne externe Hardware. Und jetzt geht eben einfach mehr, damals nur rohe MODs mit LoFi 8 Bit Sound, heute uneingeschränkte Qualität und Möglichkeiten.
Ja, wie gesagt... Gibt heutzutage viele Leute, die sagen: 44 / 48 kHz sind zu wenig, und 96 eigentlich auch. Es müssen 192 bzw 384 kHz sein! Und in ein paar Jahren muß 1 Sekunde Sound 1 GB brauchen und 64 Bit, weil da immer noch jemand "hören wird", daß das sonst unzureichend ist.
Selbes Ding mit Grafik: 24Bit (8-8-8) reicht auch nicht mehr aus heutzutage! Es muß 30Bit oder 48Bit oder 96Bit sein! 4,3 Millarden Farbabstufungen für jede Phase! Nicht mal das weitentwickelste TIER-Auge hat so eine Farbabstufung! Aber wenn irgendwer eine klug genug klingende Ausrede dafür hat, dann reicht das aus, um für die Entwicklung solcher Dinge genug Geld in die Industrie zu pumpen. Man muß ja die Wirtschaft ankurbeln. Klar, braucht alles 3x soviel Speicher (wir haben's ja...) und das menschliche Auge sieht nicht mal bei 24bit noch irgendwelche Stufen... - auch wenn mir diverse Spacken immer wieder weismachen wollen, daß es so wäre...
Na egal. In 20 Jahren wird keiner mehr in Einheiten von BYTE irgend etwas angeben. Da wird selbst eine Textseite schon 1 GB brauchen... - nicht, weil es nötig ist, sondern weil die Hersteller von RAM ja auch von irgendwas leben müssen...
Nicht falsch verstehen: Wo etwas wirklich Sinn macht, habe ich kein Problem damit, auch mal an eine Grenze zu gehen (auch wenn es meiner Meinung nach SEHR OFT unnötig ist) - aber bei vielen Dingen macht es selbst heute schon keinen Sinn mehr.
zatzen hat geschrieben:Aber parallel dazu vergesse ich die "alte Zeit" nie und daher habe ich auch Spaß daran, Daten kompakt zu halten im KB Bereich.
Naja, kommt eben auf das System an, auf dem es ausgeführt werden soll. Auf einem durchschnittlichen DOS-Rechner kann man nunmal nicht "mal eben so" davon ausgehen, daß man da 4 GB Speicher eingebaut hat (obwohl für 32bit-CPUs technisch möglich wäre).
zatzen hat geschrieben:ISM:
Vor Clipping habe ich wie hier oft schon erwähnt aufgrund meiner Erfahrung gerade im Lo-Fi Bereich keine Angst, es muss eben nur wirklich geclippt (Pseudo: if a > 127 then a = 127; if a < -128 then a = -128) werden, was einen zweiten Puffer in 16 Bit erfordert...
Naja, bei mir nicht, weil die Werte ja maximal 240 werden. Ich habe ja (vielleicht) schon mal erwähnt, daß ich einen "Overdrive" Wert mit angeben will, damit man die Musik auch über die Grenze aussteuern kann. Dann muß man aber selbst dafür sorgen, daß es nicht kratzt. Clipping auf die oben beschriebene Art verfälscht aber trotzdem die Töne.
zatzen hat geschrieben:Was Du statt Clipping noch machen könntest, wäre eine momentane Verminderung der Lautstärke über die Pufferlänge.
Wie ich schon erwähnt habe: Das möchte ich nicht. Ich möchte die Möglichkeit haben, leise und laute Töne zu haben und nicht, daß ein leiser Part "hochgezogen" oder ein lauter "runter" und alles gleich laut ist.
zatzen hat geschrieben:und würde statt Verzerrung eher "pumpen" verursachen, wenn's zu laut wird.
Und genau das soll's nicht.
zatzen hat geschrieben:Ich erinnere mich dass Du die Daten vorzeichenlos verarbeitest. Muss man dann evtl. anders rangehen.
1. Ich möchte nicht anders rangehen.
2. Ich verarbeite zuerst alles vorzeichenlos - dann - über die Lautstärketabellen - wird es vorzeichenbehaftet, damit es eine "Mitte" gibt. Am Schluß wird über das komplette Stück eine Fixierung angewendet (ebenfalls per Tabelle, die nur angepaßt wird, wenn sich Gesamtlautstärke oder Anzahl Stimmen ändert), die gleichzeitig die Werte "maximiert" und auf Mitte stellt.
zatzen hat geschrieben:DOSferatu hat geschrieben:Naja, kein Fan von Windows zu sein, muß ja nicht bedeuten, daß man auf NOCH lahmeren Scheiß wie Mac oder NOCH benutzerunfreundlicheren Scheiß wie Linux steht...
Das ist mal eine erfrischende Sichtweise!
Naja...
zatzen hat geschrieben:Im Audio Bereich schwören alle auf Mac, und alle vermeintlichen Freaks die was auf sich halten machen alles mit Linux. Das hatte mich als Microsoft USER schon leicht verunsichert...
Naja, was soll man sagen? Vielleicht gibt es da irgend ein Programm unter Linux, das alle so toll finden? Keine Ahnung. Die meisten Leute, die auf irgend ein OS "schwören", haben sowieso keine Ahnung, wie das Ding technisch funktioniert und was die Vorzüge und Nachteile sind. Ich kenne mich z.B. viel zu wenig mit den Interna von Linux aus, um es deswegen zu mögen oder zu hassen - weil ich mich nie damit beschäftigt habe,
Für mich kommt Linux nicht in Frage, weil mein eigener Scheiß darauf nicht läuft und weil ich einfach zu alt bin, jetzt noch mal einen komplett neuen Ansatz zu fahren. Das was die OS heutzutage machen, nimmt sich - für den User - sowieso nicht mehr viel. Es geht eher nur noch um das "Drumherum". Linux ist mir einfach zu stressig.
Erklärung: Mir sind Betriebssysteme total egal. Ich bin auch kein DOS-Fan (auch wenn's so wirkt). Ein Betriebssystem soll mich einfach so weit wie möglich in Ruhe lassen und so wenig wie möglich nerven. Ich habe keine Lust, großartig an einem OS herumzukonfigurieren (dafür interessiert's mich zu wenig). Betriebssysteme erachte ich als "notwendiges Übel" und je weniger davon da ist, umso genehmer ist es mir.
Leider nehmen sich ALLE Betriebssysteme heutzutage zu wichtig und wollen den User immer nur gängeln - ist wohl leider eine Notwendigkeit, wenn man Multitasking will.
Aber, wie erwähnt: Der Grund für mich, den Kram von MS zu benutzen ist, weil der bis zu einem bestimmten Punkt noch Ähnlichkeiten/Kompatibilität zu dem hat, mit dem ich mein Zeug programmiere. Unter Linux (und anderen) könnte ich nur dummer User sein. Das wäre mir zu blöd.