Oh hoppla, da ist wohl ne Kleinigkeit schief gelaufen, als ich die Website umgestellt hatte. Das Skript für den generierten Downloadbutton konnte ne Datei nicht mehr finden. :V
Geht jetzt wieder. Danke fürs Bescheid sagen.
Oh hoppla, da ist wohl ne Kleinigkeit schief gelaufen, als ich die Website umgestellt hatte. Das Skript für den generierten Downloadbutton konnte ne Datei nicht mehr finden. :V
Geht jetzt wieder. Danke fürs Bescheid sagen.
Graben wir das Ding nochmal aus, weil ich gerne von Disharmony loskommen würde, mich aber ein paar
Dinge noch daran hindern, die einzige brauchbare Alternative endlich mal zu nutzen.
Hab ich mich schonmal mit der Bitte gemeldet, dass OGG-LoopPoints supermegatoll wären?
Das Format kann sowas ja von sich aus speichern, da sollte Software auch damit umgehen können.
Oder dass der Dateityp überhaupt wieder funktioniert, ich hab 1.2 (aus ClassicRPG 1.6Symph) und 1.5d
mal wieder ausprobiert, bei ersterem wird auf Null geloopt, das macht das coole Format komplett nutzlos,
bei letzterem funktioniert OGG gar nicht.
Und irgendwie hab ich das Gefühl, als würden Dateien, im Speziellen WAVs, weil ich nichts anderes
getestet habe, viiiieeel lauter abgespielt werden als sie sollten, bzw möglicherweise immer auf 100%Vol.
Dass OGG native Loop-points hat höre ich heute zum ersten Mal. Neuere Maker und andere Software wie ZDoom scheinen aber Kommentar-Metadata-Felder dafür auszunutzen. Gehört aber nicht direkt zur Format-Spezifikation.
Audiere bietet in seiner API auch nur sehr beschränkt Looping an. Und zwar als Teil des Sampleplaybacks... was aber vollständig dekodierte Samples im RAM voraussetzt, also kein Streaming.
Für manuelles Looping der Streams fehlt die genaue Timingkontrolle.
Was hingegen wahrscheinlich machbar ist, wäre Looping durch mehrere Dateien, also einen Anfangspart und dann der wiederholte Teil separat.
Callback ist vorhanden und das Prinzip hab ich schon mal mit SDL_mixer umgesetzt. Klappt dort ganz gut.
Die 1.5d die ich bei mir rumliegen habe spielt noch alles so ab wie sie soll, so doof das auch klingt (Windows 10, x64). Die Datei wird eigentlich auch nur an Audiere weitergeleitet und da gab's seit 2006 keinen neuen Release mehr.
Im OGG Container geht glaube ich auch nur Vorbis als Codec. Mit aktuellem FFMpeg encodierte Dateien werden bei mir abgespielt. Mehr fällt mir da nicht ein.
Kannst das gute Stück ja mal hochladen.
Wegen der Lautstärke kann ich jetzt auch nicht viel sagen. Im Schnelltest hab ich mal die Wiedergabe von Audieremony und der original Harmony aufgenommen und verglichen... klang eigentlich gleich laut. Lautstärke-slider geht auch wie er soll.
Musste selber das alte Zeug mal wieder rauskramen. Bei mir scheint aber alles noch halbwegs zu laufen, weshalb es etwas schwer zu sagen ist warum es bei dir nicht ganz so rund läuft. :\
Ja hab ich nach dem Post auch mitbekommen, dass das Kommentarfelder sind, dafür benutzen
aber auch alle Sachen außer Disharmony wie es aussieht den immergleichen Standard dafür,
also gleiche Bezeichnung und gleiche Art von Wert (Samplenummer).
Das erwähnte, das in 1.2, aber nicht in 1.5d läuft, kommt von hier:
http://wingless-seraph.net/material-music_boss.html ("The Song Of The End")
Zur Lautstärke: Ich lasse gerade alles auf 40% abspielen, was bei normaler Harmony und bei DisH
jeweils deutlich leiser ist als mit Audiere.
Mir ist bei dem Ausprobieren nach langer Zeit noch aufgefallen, dass bei mir kein FFDShow beim
Abspielen gestartet wird, was bei Mediaplayern und DisH allerdings immer der Fall ist und mich
hat hoffen lassen, dass die Dateien ohne DirectShow-Filter funktionieren. Das würde einiges für
die Spieler erleichtern, die immer noch keine installiert haben, bringt aber ohne andere wichtige
Funktionen nur unterm Strich dann doch nix.
Audiere an sich ist eigenständig und ist nicht an Systemcodecs angewiesen. Läuft auch in Wine ohne Probleme.
Deine verlinkten Tracks werden zwar nicht richtig geloopt, aber normal abgespielt bei mir.
Zur Lautstärke muss ich zugeben, bei niedrigeren Lautstärken ist der Unterschied wirklich gut zu hören. Wo genau das Problem hier ist weiß ich jetzt nicht direkt (die Prozente vom Maker werden durch 100 geteilt als float zu Audiere übergeben), aber eventuell kann ich das etwas anpassen um zu ähnlichen Ergebnissen zu kommen.
Entgegen der Audiere-Dokumentation könnte ich eventuell OGG-Loops auf der Kommentarbasis doch noch zum Laufen bringen. Mal schauen.
Hast mächtig was gut bei mir, wenn das was wird. °－°Zitat:
Entgegen der Audiere-Dokumentation könnte ich eventuell OGG-Loops auf der Kommentarbasis doch noch zum Laufen bringen. Mal schauen.
Download im Anfangspost.Code:Version 1.6, Build 371 (27.09.2016)
Neu:
- Ogg Tag-Loop Support
- Harmony-Lautstärkekompatibilität
- Optionale Stummschaltung bei Fokusverlust
- Fehler bei fehlenden Dateien sind jetzt stumm
- "Musik einmal durchgespielt" Abfrage funktioniert mit &noloop& Dateien
Fix:
- Audiere Streams werden bei (OFF) nicht gestoppt (Regression von 1.5b)
Ich hab das ganze jetzt nicht mit extrem vielen Dateien getestet und hoffe einfach mal dass es rund läuft.
Whoa cool! =D
Der Debuglog sagt, dass der Loop geladen wird, da geh ich mal davon aus, dass es funktioniert,
jedenfalls bei anderen, denn richtig testen ist mir nicht möglich, das generelle Abspielproblem von
1.5d das wer weiß seit welcher Version irgendwann nach 1.2 schon existiert auf meinem System
hat sich leider bislang nicht dazu bereiterklärt, sich zu verflüchtigen.
Liegt aber nicht am Format oder der Datei, denn alles, was nicht an OtherHarmony weitergereicht wird,
auch WAV-Hintergrundgeschwurbel aus dem RTP wie z.B. Regen, wird von Audieremony verschluckt,
genauer gesagt nach einem kurzen Ton oder Knacks abgebrochen. Was auch nur bei BGM passiert,
mit Sounds (WAV und OGG getestet, mit Stream sowie ohne) gibt es keine Pannen.
[Ergänzungen]
BGM mit FadeIn spielt für die Dauer des eigentlichen Fadings in Normallautstärke und stoppt direkt,
sobald dieser Timer abgelaufen ist.
・・・ Jetzt irgendwie nicht mehr, jetzt läuft der Fade korrekt, der Stop ist trotzdem vorhanden, wer weiß
was das für ein Schluckauf war.
・・・ Das scheint bei jeder Datei beim ersten Abspielversuch zu passieren.
・・・ Trackersachen streiken auch, in SdU1 damals haben sie genau wie der Rest noch funktioniert.
Wenn's noch Archivierungen der Versionen dazwischen gibt, würd ich mich auch daran machen,
genauer herauszufinden, ab welcher es nicht mehr geht, wenn das hilft.
Das generelle Abspielproblem hatte ich leicht verdrängt, da war ja was...
Ich würde gern einfach sagen, dass dein System komisch ist, aber das hilf ja niemanden :^)
Alte Version sind noch alle verfügbar:
Generell wäre es wohl auch nützlich was bei dir passiert wenn du das Testprogramm von Audiere selbst ausprobierst: http://prdownloads.sourceforge.net/a...2.zip?download
Im "bin" Ordner "wxPlayer.exe" ausführen und mit "Open Stream..." deine Lieblingsmusik auswählen die Audieremony nicht gebacken bekommt.
Wobei wie gesagt bei Audiere selbst es null Änderungen seit Audieremony 1.0 gab.
Die restlichen Probleme kann ich bei mir auf die Schnelle nicht reproduzieren.
Dass gestreamte Sounds gehen, aber die Musik nicht, kann gut mit den FadeIns zusammenhängen. Der Maker sendet auch bei 0 Sekunden ein FadeIn Befehl. Da schau ich nochmal drüber.
SdU 2 nutzt Audieremony 1.5c, ging da auch nichts bei dir?
Ich bin zuversichtlich, dass wir das noch irgendwie hingebogen bekommen. Bin ja froh, dass überhaupt jemand Nutzen daran findet.
Also dann!~
Wie versprochen alles nach 1.2 durchprobiert, bei 1.5c, und das ist später als ich jetzt erwartet hätte, ist Sense.
Da der im Changelog angegebene Fix an der Stelle mit FadeIns zu tun hatte, passt es ja aber irgendwie.
(Ja in SdU2 läuft es auch nicht, darüber war ich wieder darauf gekommen, mal die Trackerformate zu testen.)
wxPlayer klappt wunderbärchen, hätt mich sonst gewundert weil wie du gesagt hast, Audiere ändert sich ja nicht
über die Versionen hinweg, ich hab beim Testen eben auch nur immer Harmony ersetzt, da der Rest eh gleich ist.
Ich hab hier mal was zu Testen.
Hauptsächlich den alten Multithreading Code (also die Teile mit den Fades) gescheit abgesichert und was nen eigentlich irrelevanten Crash gefixt. Läuft bei mir wie vorher... mehr kann ich dazu erst mal nicht sagen.
Anhang 23637
Hm, das war's noch nicht.
Merke hier auch keinen Unterschied. =0
Nach wie vor ohne Fade ein Knacks, mit Fade stumm (oder vielleicht ganz weg, vom Hören her
ist das ja gleich) sobald der Timer um ist.
Und weiter geht's...
Anhang 23638
Tracks ohne Fade in sollen doch bitte damit abgespielt werden. Bei PlayMusic mit Fade in fände ich Logs ganz interessant, dann kann ich die Reihenfolge der Dinge nochmal genauer beobachten.
Yeeeaaah! Da läuft alles soweit nun paletti. So weit wie ich um die Zeit noch testen kann.Zitat:
Tracks ohne Fade in sollen doch bitte damit abgespielt werden.
Auch der Loop funktioniert.
So sei es denn.Zitat:
Bei PlayMusic mit Fade in fände ich Logs ganz interessant, dann kann ich die Reihenfolge der Dinge nochmal genauer beobachten.
Hab was dunkelrot markiert, das wegen nem fehlenden Zeichen komisch aussieht, weiß nichtCode:Audieremony Version 1.6a, Build 391
Debuglevel is 3
Runtime called HarmonyCreate()
Initialized Audiere audio device
Initialized otherharmony.dll
Runtime called HarmonyInitMidi()
Runtime called HarmonyInitWave()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyStopMusic()
Runtime called HarmonyStopSound()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyFadeOutMusic(1000)
Runtime called HarmonyStopMusic()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyPlayMusic('*:\********\Music\confront.ogg.wav')
Playing file with Audiere
Reading metadata...
Tag: vendor=Xiph.Org libVorbis I 20070622
Tag: Software=Sound Forge Pro 10.0
Tag: LOOPSTART=2044631
Tag: DATE=2014-01-27
Tag: LOOPLENGTH=4979089
Opened sample source
Adding loop point from 7023720 to 2044631
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic(1000)
Locking Stream Fade Mutex...
Runtime called HarmonySetMusicVolume((OFF)')
Runtime called HarmonyPlayMusic('*:\********\Music\confront.ogg.wav')
Playing file with Audiere
Reading metadata...
Tag: vendor=Xiph.Org libVorbis I 20070622
Tag: Software=Sound Forge Pro 10.0
Tag: LOOPSTART=2044631
Tag: DATE=2014-01-27
Tag: LOOPLENGTH=4979089
Opened sample source
Adding loop point from 7023720 to 2044631
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic(1000)
Locking Stream Fade Mutex...
Waiting for Stream Fade Mutex...
Thread got Stream Fade Mutex...
Runtime called HarmonyPlaySoundEx('*:\********\Sound\loctime.wav', 10, 150, 50)
Playing file with Audiere
Runtime called HarmonyPlaySoundEx('*:\********\Sound\hover.wav', 10, 100, 50)
Playing file with Audiere
Runtime called HarmonyRelease()
Freed otherharmony.dll
Stopping Audiere audio stream
Clearing sound list
Stopping Audiere audio stream
Closing Audiere audio device
Runtime called HarmonyRelease()
Freed otherharmony.dll
Stopping Audiere audio stream
Clearing sound list
Stopping Audiere audio stream
Closing Audiere audio device
ob das nur ein Missgeschick beim loggen ist oder irgendwas sonst bedeutet.
Die Logs sehen etwas komisch aus, zugegeben. Besonders das eine "(OFF)" sollte da eigentlich gar nicht erscheinen können. HarmonySetMusicVolume nimmt nur einen Int und falls das ne Race-Condition vom Multithreading ist, sieht der Rest ziemlich sauber aus...
Naja, der andere Thread wird in der Release Version eh nicht ins Log schreiben, also ignoriere ich das mal.
Die Reihenfolge der anderen Befehle ist auch ein wenig merkwürdig.
Bei mir sieht das immer so aus:
Wie dem auch sei, ich hab hier nochmal was zum Testen. Das sollte ziemlich nah am Verhalten von 1.5b sein aber trotzdem die richtige Lautstärke bei Fade-ins haben, wie 1.5c+.Code:Runtime called HarmonyPlayMusic('[Dateipfad]')
Playing file with Audiere
Reading metadata...
Opened sample source
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic([Fade-in in Millisekunden])
Locking Stream Fade Mutex...
Runtime called HarmonySetMusicVolume([Ziellautstärke in Prozent])
Unlocking Stream Fade Mutex...
Runtime called HarmonySetMusicSpeed([Geschwindigkeit in Prozent])
Runtime called HarmonySetMusicPanpot([Balance in Prozent])
Waiting for Stream Fade Mutex...
Thread got Stream Fade Mutex...
Anhang 23639
Falls das auch nicht geht, ist darin auch eine zweite Version, welche blockiert bis der Fade-in abgeschlossen ist. Dazu Logs, falls nötig wären gut.
Ich fänds ja selber schön wenn noch den Quellcode von den alten Versionen hätte. Dem Verantwortlichen sag ich, dass er in Zukunft Backups von sowas machen könnte.
Edit: Gehen eigentlich die Fade-outs bei dir?
FadeOut: Hatte ich vergessen mal zu nutzen, ja funktioniert bei der Version aus Post 93.
FadeIn klappt in der ersten Fassung vom neuen Paket, wenn ich versuche, das auszufaden, hängt sich allerdings
soweit ich das beobachten kann irgendein Teil der ganzen Verkettung von Spiel bis Audiere auf und ich kann das
Spiel nicht mehr normal schließen (Spielbildschirm schwärzt sich, Fenster bleibt), sondern nur noch killen.
Der Log zu genau diesem Vorgang:
In der zweiten Fassung kann ich keinen Unterschied zur ersten feststellen, es loggt auch genau gleich.Code:Audieremony Version 1.6a, Build 391
Debuglevel is 3
Runtime called HarmonyCreate()
Initialized Audiere audio device
Initialized otherharmony.dll
Runtime called HarmonyInitMidi()
Runtime called HarmonyInitWave()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyStopMusic()
Runtime called HarmonyStopSound()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyFadeOutMusic(800)
Runtime called HarmonyStopMusic()
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyReserveSound('(OFF)')
Runtime called HarmonyPlayMusic('*:\********\Music\confront.ogg.wav')
Playing file with Audiere
Reading metadata...
Tag: vendor=Xiph.Org libVorbis I 20070622
Tag: Software=Sound Forge Pro 10.0
Tag: LOOPSTART=2044631
Tag: DATE=2014-01-27
Tag: LOOPLENGTH=4979089
Opened sample source
Adding loop point from 7023720 to 2044631
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic(3000)
Locking Stream Fade Mutex...
(OFF)')
Runtime called HarmonyPlayMusic('*:\********\Music\confront.ogg.wav')
Playing file with Audiere
Reading metadata...
Tag: vendor=Xiph.Org libVorbis I 20070622
Tag: Software=Sound Forge Pro 10.0
Tag: LOOPSTART=2044631
Tag: DATE=2014-01-27
Tag: LOOPLENGTH=4979089
Opened sample source
Adding loop point from 7023720 to 2044631
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic(3000)
Locking Stream Fade Mutex...
Runtime called HarmonySetMusicVolume(Waiting for Stream Fade Mutex...
Nochmal gesondert als klarere Aussage:
Das Problem beim FadeOut taucht nicht auf, wenn kein FadeIn passiert ist, sondern er funktioniert genau so gut
wie in der erwähnten Version davor (Post 93).
Die zweite DLL war nur gedacht falls die erstere das selbe Verhalten zeigen sollte. Sie warted bis das Fade-in fertig ist, anstatt es im Hintergrund ablaufen zu lassen.
Wir nähern uns dem Ziel wie ich sehe. Den Beschriebenen Deadlock kann ich gut nachvollziehen, am Fade-out hab ich selbst nicht wirklich was geändert und nicht wirklich weiter getestet.
Schockierenderweise konnte ich das ganze nicht Nachbilden... die Hauptverdächtigen hab ich aber so angepasst, dass es sich mit Fade-out nicht mehr locken dürfte (also sollte schon so).
Anhang 23640
Die Befehlsreihenfolge ist mir aber trotzdem noch ein Rätsel (da fehlen auch Zeilen die gar nicht fehlen könnten...). Ist das vielleicht ne RPG_RT vom offiziellen englischen Release? Hab ich selbst nicht rumliegen, muss ich zugeben.
Nö, für 1.61 hätte auch erstmal der HarmonyPatcher portiert werden müssen, weil genau wie RPG2003 1.05+Zitat:
Ist das vielleicht ne RPG_RT vom offiziellen englischen Release?
auch RPG2000 1.50+ (am gleichen Tag damals rausgekommen) keine DLL mehr verwendet.
Ich bastel die Sachen, die ich im Moment mach, alle mit 2000-1.07.
Lock passiert noch weiterhin, sieht nur im Mitgeschreibsel jetzt so aus:
Code:[...]
Runtime called HarmonyPlayMusic('*:\********\Music\confront.ogg.wav')
Playing file with Audiere
Reading metadata...
Tag: vendor=Xiph.Org libVorbis I 20070622
Tag: Software=Sound Forge Pro 10.0
Tag: LOOPSTART=2044631
Tag: DATE=2014-01-27
Tag: LOOPLENGTH=4979089
Opened sample source
Adding loop point from 7023720 to 2044631
Setting Audiere audio stream loop state
Runtime called HarmonyFadeInMusic(2000)
Locking Stream Fade Mutex...
Runtime called HarmonySetMusicVolume(30)
Unlocking Stream Fade Mutex...
Runtime called HarmonySetMusicSpeed(100)
Runtime called HarmonySetMusicPanpot(50)
Runtime called HarmonyFadeOutMusic(5000)
Reihenfolge sieht jetzt relativ normal aus. Ins Log aus nem anderen Thread zu schreiben war wohl ne ganz schlechte Idee.
Nun gut.
Ich habe hier quasi meinen letzten Versuch. Im Archiv sind wieder 2 verschiedene Varianten. Einmal mit noch einem versuchten Fix für den Deadlock und eine andere ganz ohne Mutex Zeug.
Letzteres entspricht ungefähr dem was in den alten Versionen gemacht wurde. Das ist aber eigentlich verdammt anfällig für Data Races und jeder Programmierer würde mich wohl dafür hauen. Aber falls es anders wohl erst mal nicht geht und beim Testen trotzdem alles immer in der richtigen Reihenfolge geschieht, bleibt's erst mal dabei. Hat die Jahre ja auch gut funktioniert.
Anhang 23641
Logs brauche ich hier keine. Nur das Wissen ob und was davon funktioniert. Und wenn beide nicht funktionieren geh ich erstmal in die Ecke... und schau nochmal drüber.
Ist zwar schon wieder megaspät, aber hab eben mal noch die erste der beiden Fassungen getestet.
Ich glaub, wir haben's! Der FadeOut funktioniert (mit und ohne FadeIn getestet). °--°
Heißt dann wohl, Mutex kann bleiben. Ich spare mir dann mal, die ohne auch noch zu probieren.
Download im Startpost.Code:Version 1.6a, Build 420 (29.09.2016)
Fix:
- Crash bei Schließen des Spiels während eines Fade-in/out
- Crash bei versuchter Wiedergabe nicht unterstützter Formate
- Race-Condition bei Musikwiedergabe (resultiert in 0% Lautstärke) auf manchen Systemen (Danke an MagicMaker)
- Zugriffsverletzung beim Nutzen von Sound-Dateinamentag "&sPos&" bevor Musik wiedergegeben wurde
Das war's dann hoffentlich mal vorerst. Vielleicht.
Edit: SdU 2 enthält jetzt auch die neue Version, falls daran Interesse besteht.
Hi,
erstmal danke für die Arbeit.
Hab grad angefangen, den Patch zu benutzen, um mp3-Gebühren zu entgehen. Es scheint allerdings nur bedingt zu funktionieren.
Ich bin so vorgegangen:
1. habe die 3 Dateien ins Projekt kopiert
2. habe eine .mp3 in .ogg konvertiert, dann habe ich die Dateiendung in .wav umgeschrieben
Beim Testen mit dem normalen Testplay kam kein Ton. Könnte es sein, dass DynRpg da ein Strich durch die Rechnung macht?
Dann jedoch beim Testen mit easyrpg, auf welches ich auch gerade umsteige, funktionierte es. :D Insofern bin ich wohl erstmal zufrieden. Aber ich dachte, ich reporte es trotzdem mal.
Naja, nach meinem letzten Wissenstand war die Wiedergabe von OGGs funktionstüchtig. Soweit ich das sehe, ist sie das bei mir auch noch.
Sonst sind die Infos leider auch etwas dürftig, daher muss ich ins Blaue raten: 2k3 Projekt, richtig gepatcht? Codec ist Vorbis? Wird Audieremony überhaupt geladen (Debuglog einschalten und schauen ob da überhaupt etwas kommt)? DLLs richtig platziert?
Ansonsten Testdateien her. Ein Projekt oder halt Audiodateien, welche nicht funktionieren. Irgendwas wird sich finden.
EasyRPG ist natürlich auch keine schlechte Wahl wenn alles rund läuft. Hier nicht vergessen die GPLv3 zu befolgen wenn du was damit auslieferst.
Dessen OGG-Wiedergabe läuft übrigens über die selbe Bibliothek wie Audiere sie einkompiliert hat, auch wenn wohl etwas frischer. Daher denke ich, dass das Problem irgendwo anders liegt.
Ich bin strikt nach dem gegangen, was unter "Verwendung" stand. Falls noch weitere Handgriffe nötig sind, habe ich diese nicht getätigt. ^^ Vielleicht liegt ja da schon der Hund begraben.Zitat:
2k3 Projekt, richtig gepatcht?
Ja.Zitat:
Codec ist Vorbis?
Ich bin ehrlich gesagt nicht so sicher, wie man das macht. Ich nehme an, es hat mit der audieremony.cfg zu tun?Zitat:
Wird Audieremony überhaupt geladen (Debuglog einschalten und schauen ob da überhaupt etwas kommt)?
Da kann man ja nicht so viel falsch machen, wenn ich das richtig sehe. Hab sie einfach in den Projektordner kopiert.Zitat:
DLLs richtig platziert?
Das heißt, was tun/nicht tun? Ich will jetzt nicht sagen, dass ich zu faul wäre, dass hier http://www.gnu.de/documents/gpl.de.html zu lesen, aber ehrlich gesagt bezweifle ich, dass ich danach schlauer bin.Zitat:
Hier nicht vergessen die GPLv3 zu befolgen wenn du was damit auslieferst.
edit: Ein Quellcode muss online öffentlich gemacht werden?
RM2k3's Runtime benutzt ja nach 1.04 die harmony.dll nicht mehr. DynRPG läuft mit 1.08. Um dem entgegenzukommen kann man mit dem beiliegenden ForceHarmony Patcher die RPG_RT wieder dazu bringen die DLL zu verwenden. Steht so unter Hinweis weiter unten in der Readme.Zitat:
Ich bin strikt nach dem gegangen, was unter "Verwendung" stand. Falls noch weitere Handgriffe nötig sind, habe ich diese nicht getätigt. ^^ Vielleicht liegt ja da schon der Hund begraben.
Das klappt auch reibungslos mit DynRPG.
Debuglevel kann man in der "audieremony.cfg" setzen, ja.Zitat:
Ich bin ehrlich gesagt nicht so sicher, wie man das macht. Ich nehme an, es hat mit der audieremony.cfg zu tun?
Also einfach einer Textdatei mit "debuglevel=3" als Inhalt. Bei der Ausführung wird dann eine "audieremony.log" Datei generiert. Wenn das nicht passiert, dann stimmt was ganz anderes nicht.
Ich bin kein Anwalt und die Chance wegen EasyRPG irgendwie in Schwierigkeiten zu kommen ist letztendlich doch gering, aber hier mein Verständnis: Bei unveränderter digitaler Distribution musst du mindestens einen gleichwertig Zugänglichen Verweis auf den original Quellcode hinterlassen. Das beträfe in diesem Fall nur EasyRPG selbst. Du wärst außerdem verpflichtet sicherzustellen, dass dieser Verweis auf angemessene Zeit gültig ist. Idealerweise kannst du den Quellcode auch einfach beilegen. Außerdem muss an geeigneter Stelle auf EasyRPG und dessen Lizenz hingewiesen werden.Zitat:
Das heißt, was tun/nicht tun? Ich will jetzt nicht sagen, dass ich zu faul wäre, dass hier http://www.gnu.de/documents/gpl.de.html zu lesen, aber ehrlich gesagt bezweifle ich, dass ich danach schlauer bin.
edit: Ein Quellcode muss online öffentlich gemacht werden?
Keine Garantie darauf. Falls es kommerziell wird, sollte man sich damit intensiv auseinandersetzen.
Ich weiß nicht, ob ich das richtig gemacht habe. Ich hab eine Textdatei mit dem Inhalt "debuglevel=3" angelegt. Dann hab ich sie umbenannt in "audieremony.cfg". Eine Log-Datei wurde beim Test nicht angelegt.Zitat:
Debuglevel kann man in der "audieremony.cfg" setzen, ja.
Also einfach einer Textdatei mit "debuglevel=3" als Inhalt. Bei der Ausführung wird dann eine "audieremony.log" Datei generiert. Wenn das nicht passiert, dann stimmt was ganz anderes nicht.
Patch: Den Maker konnte ich patchen. Beim versuch die rpg_rt zu patchen kommt die Fehlermeldung "Die Exe konnte nicht gepatched werden."
Wird dann Zeug in der Musikvorschau vom maker abgespielt wenn du die DLLs ins Programmverzeichnis platzierst?
Ist außer DynRPG sonst noch etwas an der Runtime modifiziert?
Aber wie gesagt, am besten und wahrscheinlich am schnellsten wäre es wenn du mir einfach ein kleines Testprojekt (oder halt das ganze Spiel wenn dich das nicht stört) zukommen lassen würdest. Wäre zumindest zielführender als diese Rumfragerei.
Ich bin mir sicher, dass sich da was zurechtbiegen ließe.
Die Musikvorschau geht auch nicht.
Außer DynRPG sollte nichts modifiziert sein.
Ich hab mal ein Testprojekt erstellt, welches das Problem ganz gut simulieren sollte. Der Harmony-Patcher hat zunächst funktioniert. Damit ging dann auch die Musik zumindest im Testplay. Nach dem patchen mit DynRPG, kommt wieder ein Fehler beim Harmony-Patch.
http://share.cherrytree.at/showfile-...roject1xxx.rar
Der HarmonyPatcher läuft problemlos auf dem Projekt. Danach wird die Musik auch abgespielt.
HarmonyPatcher sollte nach DynRPG angewandt werden (ob es andersrum überhaupt geht weiß ich jetzt gar nicht).
Ich bin mir jetzt nicht sicher was bei dir da schiefläuft, aber hier mal vorsichtshalber deine Projekt RPG_RT nach dem HarmonyPatcher:
https://dl.dropboxusercontent.com/u/.../RPG_RT_IA.exe
Ich glaube, das war ein Missverständnis.
Das was ich dir geschickt habe, war eine rpg_rt, die ich vorher erfolgreich mit dem Harmony-Patch gepatcht habe. Dann ging die Musik. Ein Teststück liegt ja auch bei und sollte abgespielt werden, wenn man das Spiel startet.
Dann hab ich DynRpg drüber gepatched und ab da funktioniert der Harmony-Patcher bei mir nicht mehr. :)
Mit der Exe von dir funktioniert es allerdings auch.
Naja, wie gesagt: DynRPG -> ForceHarmony, in der Reihenfolge. Was anderes hatte ich vorher nie getestet und scheint ja sonst auch nicht zu klappen.
Was das Missverständnis angeht, jein. An dem Punkt hab ich mir einfach das Projekt angeschaut und möglichst lauffähig machen wollen. So mit Fehlernotiz "geht plötzlich nicht mehr". ForceHarmony hat mir derweil auch keinerlei Fehler ausgespuckt.
Ein klein wenig mehr Eigeninitiative hätte ich nett gefunden. Ich helfe ja gern, aber einfach mal andersherum patchen war ja jetzt nicht so weit hergeholt. ;)
Der Patcher stammt ja nicht von mir, daher kann ich eh nicht mehr machen als selber darin rumklicken.
Letztendlich ist's dann doch so, dass ich mich über jedes Projekt freue, in dem das Ding sich als nützlich erweist. Also noch viel Erfolg damit.
Nur um das noch zu klären, bzw. nicht in einem falschen Licht dazustehen: Ich habe es genau in der Reihenfolge "DynRPG -> ForceHarmony" versucht, aber es klappte nicht. Anders herum funktioniert es ja auch nicht, weil DynRpg beim Patchen alles wieder runter schmeißt. Warum es bei dir dann geklappt hat, weiß ich nicht.