Testbericht unter Linux

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#41 Beitrag von Johannes »

Dann werde ich mal versuchen, eine Zusammenfassung zum Thema „Ladeprobleme bei Sounds“ zu geben:

1. Absturz bei nicht existierenden Dateien

Wenn eine Sound-Datei umbenannt wird, z.B. „Bremse.wav“ in „XX_Bremse.wav“, friert Zusi beim Laden der Szene ein.

Das Problem tritt unter Windows nicht auf. Ebenso tritt es anscheinend nur bei Sounds auf (ich habe testhalber das Verzeichnis „RollingStock/Deutschland/Epoche3/Dieselloks/BRD/V160_Familie/V160/3D_Daten/Lod/Texturen/“ umbenannt, ohne dass es zu Problemen kam.

2. Absturz bei zu langen Dateinamen

Tritt beim Laden einer Sounddatei ein Dateiname von 156 Zeichen oder länger auf, so friert das Programm beim Laden ein. Dabei ist der absolute Dateipfad maßgeblich, auch die Verzeichnistrenner zählen mit (z.B. mit Datenverzeichnis „…/Daten123/“ funktioniert es, mit Datenverzeichnis „…/Daten1/2/3/“ nicht).

Auch dieses Problem tritt unter Windows nicht auf, ebenso nur bei Sounds (bei Texturen werden teilweise viel längere Pfade geladen, etwa

Code: Alles auswählen

/home/jojo/.wine/dosdevices/z:/Zusi3/Daten123/RollingStock/Deutschland/Epoche3/Gueterwagen/BRD/Kesselwagen/2-Achser/isolierte_Kesselwagen/3D_Dateien/Lod/Texturen/ikw_vtg4.dds
mit 174 Zeichen).

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#42 Beitrag von Johannes »

rayquaza hat geschrieben:
Johannes hat geschrieben:[Aktualisierung meiner Liste des Fehlerauftretens]
Danke für die Info. Die Tabelle kann nun hier (Google Docs) angesehen werden.
Eigentlich kannst du unter „Zugauswahl“ bei mir jetzt „alle“ hinschreiben, da die BR 216 nach Umgehung des Sound-Ladeproblems bei mir funktioniert.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#43 Beitrag von Carsten Hölscher »

Das klingt nach Problemen/Fehlern der DirectSound-Umsetzung unter Linux.

Carsten

rayquaza
Beiträge: 100
Registriert: 20.01.2012 18:11:29

Re: Testbericht unter Linux

#44 Beitrag von rayquaza »

Johannes hat geschrieben:Soviel ich weiß, gibt strace seine Informationen teilweise auch auf der Fehlerausgabe (statt auf der Standardausgabe) aus, die Kommandozeile müsste also noch um ein ergänzt werden.
Autsch, da hätte ich auch selbst drauf kommen können, danke!
Johannes hat geschrieben:
rayquaza hat geschrieben:Nachtrag: Jetzt bin ich komplett verwundert: Ich habe die "kurze" Installation wieder Deinstalliert und es nochmal unter der normalen Installation versucht - nun geht auch dort die 110, die 260 habe ich nicht probiert. ?(
Schon mal mit

Code: Alles auswählen

wine regedit
nachgeschaut, ob Zusi- und Datenverzeichnis korrekt eingetragen sind?
Ja, das "kurze" Verzeichnis existiert auch gar nicht mehr. In den Zusi-Einstellungen ist auch das "lange" Datenverzeichnis angegeben.
Johannes hat geschrieben:Ansonsten habe ich Version 2 meines Patches erstellt, die die betroffenen Dateien einfach direkt in das Datenverzeichnis verschiebt (statt eine leere Dummy-Datei zu erzeugen). Somit kommt man auch unter Linux in den Genuss des satten 216-er-Sounds :-)

Hier ist sie: http://pastebin.com/D27zWe09" target="_blank . Eventuell muss man mit dem MAXLEN-Parameter rumspielen (vor allem, wenn die Sache tatsächlich von der Pfadlänge ohne Leerzeichen abhängen sollte).
Ich werde es gleich mal ausprobieren, mache jetzt aber erstmal etwas Pause.
Carsten Hölscher hat geschrieben:Wenn sich die Linuxer auf gesicherte Erkenntnisse geeinigt haben, wäre eine kurze Zusammenfassung nett. Dann werde ich versuchen, die Erkenntnisse zu beachten, wenn es machbar ist.
@Carsten Hölscher: Was nicht funktioniert habe ich hier auf Google Docs in einer Tabelle zusammengefasst. Wenn du die Datei bearbeiten willst, kann ich sie dir auch zur Bearbeitung freigeben (sofern du einen Google-Account hast).
Warum das jeweils nicht funktioniert haben wir noch nicht herausgefunden. Für die teilweise nicht fahrbaren Tfz scheint dies am Pfad mancher Dateien zu liegen. Das inzwischen von Johannes verfasste Posting erläutert hierzu weiteres (@Johannes: Danke für den Überblick!). Hier müssten wir aber noch etwas experimentieren. Vielleicht könntest du (Carsten) etwas zu Johannes' Anfrage sagen:
Johannes hat geschrieben:Könnte es also sein, dass im Ladecode für den Sound irgendeine Anomalie steckt, die zufälligerweise nur unter Linux zu Tage tritt?
Die Google Docs-Tabelle werde ich nachher noch um einen Hinweis zum Shell-Script-WA ergänzen. Aber erstmal ist 'ne Bildschirmschutzpause (zum Schutze des Bildschirms *gg*) fällig.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#45 Beitrag von Carsten Hölscher »

Von meiner Seite aus ist beim Sound nichts besonderes. Die Fehler deuten wie gesagt eher darauf hin, dass bei der Schnittstelle, die DirectSound emuliert (oder wie auch immer man das nennen soll) irgendwas verbockt ist.

Carsten

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#46 Beitrag von Johannes »

Carsten Hölscher hat geschrieben:Von meiner Seite aus ist beim Sound nichts besonderes. Die Fehler deuten wie gesagt eher darauf hin, dass bei der Schnittstelle, die DirectSound emuliert (oder wie auch immer man das nennen soll) irgendwas verbockt ist.
Ja, da ist wohl ein Wine-Bugreport fällig. Ich habe es gerade kurz ausprobiert mit dem Beispiel „PlaySound.exe“ aus den DirectX-9-Samples. Da ist der gleiche Effekt (kurze Dateien laden problemlos, lange bringen die Fehlermeldung „Could not create sound buffer“). Immerhin stürzt das Programm nicht ab …

rayquaza
Beiträge: 100
Registriert: 20.01.2012 18:11:29

Re: Testbericht unter Linux

#47 Beitrag von rayquaza »

Johannes hat geschrieben:
Carsten Hölscher hat geschrieben:Von meiner Seite aus ist beim Sound nichts besonderes. Die Fehler deuten wie gesagt eher darauf hin, dass bei der Schnittstelle, die DirectSound emuliert (oder wie auch immer man das nennen soll) irgendwas verbockt ist.
Ja, da ist wohl ein Wine-Bugreport fällig. Ich habe es gerade kurz ausprobiert mit dem Beispiel „PlaySound.exe“ aus den DirectX-9-Samples. Da ist der gleiche Effekt (kurze Dateien laden problemlos, lange bringen die Fehlermeldung „Could not create sound buffer“). Immerhin stürzt das Programm nicht ab …
Dann müssen wir das wohl erstmal so hinnehmen. Hat von euch einer dort einen Account? Zumindest gibt es für Zusi 2 einen Eintrag in der Wine-AppDB. Der gleichnamige User hier war aber zuletzt vor ca. 3 Monaten online...

Ansonsten verbleibt noch der Fehler in der Auswertung ausreichen relevant um weiter nachzuforschen. Hat dazu jemand eine Idee?

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#48 Beitrag von Johannes »

Kurze Info: Ich habe einen Bugreport für Wine erstellt.

Edit: Link korrigiert
Zuletzt geändert von Johannes am 20.03.2012 21:09:30, insgesamt 1-mal geändert.

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#49 Beitrag von Johannes »

rayquaza hat geschrieben:Ansonsten verbleibt noch der Fehler in der Auswertung ausreichen relevant um weiter nachzuforschen. Hat dazu jemand eine Idee?
Ja. (Und eine Lösung.)

Die Unterstützung von GDI+ in Wine ist wohl nicht zu 100% ausgereift, insbesondere heißt es hier:
Many drawing operations do not work properly on Bitmap images that have an alpha channel or reference a user buffer.
Es kann gut sein, dass einer der beiden Punkte auf Zusi zutrifft. Man kann aber die native (Windows-)Version von GDI+ installieren, das geht folgendermaßen: Man führt zunächst den Befehl

Code: Alles auswählen

winetricks gdiplus
auf der Konsole aus. Das hat bei mir folgende Ausgabe produziert

Code: Alles auswählen

Executing wine WindowsXP-KB975337-x86-ENU.exe /extract:C:\windows\Temp\_gdiplus /q
fixme:advapi:DecryptFileA "C:\\windows\\Temp\\_gdiplus\\" 00000000
Executing cp /home/jojo/.wine/dosdevices/c:/windows/temp/_gdiplus/asms/10/msft/windows/gdiplus/gdiplus.dll /home/jojo/.wine/dosdevices/c:/windows/syswow64
Using native override for following DLLs: gdiplus
Executing winetricks_early_wine regedit C:\windows\Temp\_gdiplus\override-dll.reg
Als ich Zusi dann starten wollte, beklagte sich Wine über die fehlende gdiplus.dll. (Ich vermute, dass da irgendwelche Unstimmigkeiten zwischen 32- und 64-Bit-Version von Wine bestehen, weshalb die Datei nach SysWoW64 kopiert wird, wo sie das 32-Bit-Wine aber nicht findet.)

Jedenfalls genügt es, die gdiplus.dll von dem genannten Speicherort in dasselbe Verzeichnis wie die ZusiSim.exe zu kopieren, um wunderschöne Fahrtenschreiber-Grafiken zu bekommen :)

Benutzeravatar
Chrigu
Beiträge: 310
Registriert: 27.04.2005 11:49:13
Wohnort: Stettlen (CH)
Kontaktdaten:

Re: Testbericht unter Linux

#50 Beitrag von Chrigu »

rayquaza hat geschrieben:Ausserdem bitte ich noch um Bestätigungen für folgende Bugs:
  • Flimmern der Lichtsignale
  • Vorschau der Zugauswahl nicht direkt möglich
  • gleiche bzw. schlechtere Performance als unter Windows
  • "Gedenksekunde" nach Fensterwechsel
  • Tritt bei mir nicht auf
  • Kann ich bestätigen, der von Johannes genannte WA zeigt kein Wirkung
  • 3x schlechtere Performance
  • Tritt bei mir nicht auf
Der WA für das Diagramm (native GDI+) funktioniert bei mir auch. Das Benutzen der native DirectSound DLL (winetricks dsound) behebt das Soundproblem übrigens nicht.
Nachtrag: Ich musste die gdiplus.dll nicht herum kopieren

Gruss
Chrigu
Zuletzt geändert von Chrigu am 21.03.2012 18:38:35, insgesamt 1-mal geändert.

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#51 Beitrag von Carsten Hölscher »

Die Zugvorschau nutzt einen eingebetteten Internet-Explorer.

Carsten

Benutzeravatar
Chrigu
Beiträge: 310
Registriert: 27.04.2005 11:49:13
Wohnort: Stettlen (CH)
Kontaktdaten:

Re: Testbericht unter Linux

#52 Beitrag von Chrigu »

Carsten Hölscher hat geschrieben:Die Zugvorschau nutzt einen eingebetteten Internet-Explorer.
Das war der entscheidende Hinweis, nach Installation von IE7 funktioniert die Vorschau. Der in wine integrierte IE scheint nicht zu genügen.

Im "Demo Info" Fenster wird nun der Infotext grösser dargestellt, auch da eingebetteter IE?

Gruss
Chrigu

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#53 Beitrag von Carsten Hölscher »

Die Demo-Info ist kein IE, sondern eines normales, mehrzeiliges Eingabefeld.

Carsten

Benutzeravatar
Lockheed
Beiträge: 19
Registriert: 11.10.2011 21:05:52

Re: Testbericht unter Linux

#54 Beitrag von Lockheed »

rayquaza hat geschrieben:Dann müssen wir das wohl erstmal so hinnehmen. Hat von euch einer dort einen Account? Zumindest gibt es für Zusi 2 einen Eintrag in der Wine-AppDB. Der gleichnamige User hier war aber zuletzt vor ca. 3 Monaten online...
*winkt*

Ich hatte bisher noch nichts beizutragen, was nützlich wäre aber ich verfolg alles :)
Lockheed

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#55 Beitrag von Johannes »

Soo … nun wollte ich dem Soundproblem (Zusi hängt bei langen Dateinamen und nicht existierenden Dateien) doch mal auf den Grund gehen. Zusi spuckt ja keine Fehlermeldung aus, sondern das Programm hängt einfach. Ich habe mich ein paar Stunden mit Lupe und Schraubenzieher drangesetzt und folgendes herausgefunden:

1. Was passiert genau?
  • Die Funktion „mmioOpen“ wird aufgerufen, um die Sounddatei zu öffnen (obwohl sie nur für Dateinamen mit ≤ 128 Zeichen ausgelegt ist)
  • Wegen des zu langen Dateinamens (oder wegen der nicht existierenden Datei) kann die Funktion die Datei nicht öffnen und gibt NULL zurück
  • Zusi versucht auf diese Datei trotzdem in der Funktion „mmioDescend“ zuzugreifen, woraufhin Wine sich in einer Endlosschleife (http://source.winehq.org/source/dlls/winmm/mmio.c#L1182" target="_blank) aufhängt
2. Warum passiert das?
  • Die Funktion „mmioOpen“ ist nicht auf lange Dateinamen ausgelegt
    In der Dokumentation zu dieser Funktion heißt es
    [url]http://msdn.microsoft.com/en-us/library/windows/desktop/dd757331%28v=vs.85%29.aspx[/url]Note This function is deprecated. Applications should call CreateFile to create or open files.
    und vor allem
    [url]http://msdn.microsoft.com/en-us/library/windows/desktop/dd757331%28v=vs.85%29.aspx[/url]The file name should not be longer than 128 characters, including the terminating NULL character.
    Warum wird in Zusi dieser Aufruf trotz der Warnung, ihn nicht für Dateinamen mit >128 Zeichen Länge zu benutzen, verwendet? Ist es nicht eher pures Glück, dass er unter Windows reibungslos funktioniert?
  • Zusi versucht, auf eine nicht existierende Datei zuzugreifen
    Wenn ich es richtig verstanden habe, sieht der Code zum Laden der Sounddatei etwa folgendermaßen aus:

    Code: Alles auswählen

    handle = mmioOpen(fileName, …)
    if (handle == NULL) {
          Gib „Lade Sound: <Dateiname>“ als Fehlermeldung aus
    } else {
          Gib „Lade Sound: <Dateiname>“ als „Hilfe zur Fehlersuche“ aus
    }
    mmioDescend(handle, …)
    D.h. obwohl das Handle NULL ist, wird versucht, die Datei zu lesen. Unter Windows kann man das nachvollziehen, indem man eine Datei so umbenennt, dass Zusi sie nicht mehr findet. So sehen dann die Systemaufrufe aus:

    Bild

    In Zeile 208–215 wird die nicht existierende Datei versucht zu laden. mmioDescend wird hier mit dem Handle NULL aufgerufen und gibt „Out of memory“ als Fehler zurück. (An der gleichen Stelle würde sich die Wine-Implementierung aufhängen).

    In Zeile 216–239 sieht man zum Vergleich einen erfolgreichen Ladevorgang einer Sounddatei.

    Das kann natürlich alles furchtbar falsch sein, aber vielleicht könnte man doch nachschauen, ob hier versucht wird, auf eine nicht existierende Datei zuzugreifen? Andernfalls würde Zusi immerhin nicht abstürzen.

    Was das Problem der langen Dateinamen betrifft, so denke ich nicht, dass man die Wine-Entwickler dazu auffordern sollte, mehr als 128 Zeichen lange Dateinamen zu unterstützen, wenn es der Spezifikation klar widerspricht. Zumal die Ursache nicht im WinMM-System liegt, sondern im Dateisystem-Code, wo folgende Struktur benutzt wird:

    Code: Alles auswählen

    #define OFS_MAXPATHNAME 128
    typedef struct _OFSTRUCT
    {
        […]
        CHAR szPathName[OFS_MAXPATHNAME];
    } OFSTRUCT;
    (Quelle: http://source.winehq.org/source/include/winbase.h#L156" target="_blank)

    Eventuell könnte man also darüber nachdenken, in Zusi einen anderen Aufruf zu benutzen?


Der Vollständigkeit halber noch ein Trace, in dem man schön sieht, dass die Funktion „OpenFile“ von „RtlGetFullPathName_U“ nur Müll zurückbekommt („OpenFile found "f\x91\xc3{\x88\x14M\x04"“, eigentlich steht in den Anführungszeichen der Dateiname):

Code: Alles auswählen

trace:mmio:MMIO_Open ("Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav", (nil), 00010000, ansi);
trace:mmio:MMIO_ParseExtA ("Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav")
trace:mmio:MMIO_SetBuffer (0x4288bd8 (nil) 8192 0)
trace:mmio:mmioDosIOProc (0x4288bd8, 3, 0xe57c7fc, 0x0);
trace:file:OpenFile Z:\Zusi3\Daten123\RollingStock\Deutschland\Epoche3\Dieselloks\BRD\V160_Familie\Gemeinsame_Daten\Sounds\Luftpresser_74671_588638.wav OF_READ OF_SHARE_COMPAT
trace:file:OpenFile Z:\Zusi3\Daten123\RollingStock\Deutschland\Epoche3\Dieselloks\BRD\V160_Familie\Gemeinsame_Daten\Sounds\Luftpresser_74671_588638.wav 0000
trace:file:RtlGetFullPathName_U (L"Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav" 520 0x196e430 (
nil))
trace:file:RtlDosPathNameToNtPathName_U (L"Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav",0x196e3
80,(nil),(nil))
trace:file:RtlGetFullPathName_U (L"Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav" 520 0x196e100 (
nil))
trace:file:wine_nt_to_unix_file_name L"\\??\\Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav" -> "/
home/jojo/.wine/dosdevices/z:/Zusi3/Daten123/RollingStock/Deutschland/Epoche3/Dieselloks/BRD/V160_Familie/Gemeinsame_Daten/Sounds/Luftpresser_74671_588638.wav"
trace:file:RtlGetFullPathName_U (L"Z:\\Zusi3\\Daten123\\RollingStock\\Deutschland\\Epoche3\\Dieselloks\\BRD\\V160_Familie\\Gemeinsame_Daten\\Sounds\\Luftpresser_74671_588638.wav" 520 0x196e430 (
nil))
trace:file:OpenFile found "f\x91\xc3{\x88\x14M\x04"
trace:file:_lopen ("f\x91\xc3{\x88\x14M\x04",0000)
trace:file:CreateFileW L"f\2018\00c3{\02c6\0014M\0004" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE  creation 3 attributes 0x80
trace:file:RtlDosPathNameToNtPathName_U (L"f\2018\00c3{\02c6\0014M\0004",0x196e574,(nil),(nil))
trace:file:RtlGetFullPathName_U (L"f\2018\00c3{\02c6\0014M\0004" 520 0x196e2c0 (nil))
trace:file:CreateFileW returning 0xffffffff
(0xffffffff in der letzten Zeile ist der Wert für INVALID_HANDLE_VALUE)

Ach ja, die offensichtliche Lösung, einfach die winmm.dll eines nativen Windows-Systems zu benutzen, scheitert übrigens hieran:
[url]http://www.winehq.org/docs/winedev-guide/mm-high[/url]Note that native MMSYSTEM and WINMM do not currently work under Wine and there is no plan to support them (it would require to also fully support VxD, which is not done yet).
Grüße
Johannes

F(R)S-Bauer
Beiträge: 6281
Registriert: 09.11.2002 02:00:47

Re: Testbericht unter Linux

#56 Beitrag von F(R)S-Bauer »

erledigt
Zuletzt geändert von F(R)S-Bauer am 12.04.2012 23:45:12, insgesamt 1-mal geändert.
Verstehe die IT, heute: IoF -> Internet over Fax, eine Deutsch Erfindung...

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#57 Beitrag von Carsten Hölscher »

Der Versuch, die Datei nach dem fehlerhaften Öffnen noch irgendwie zu bearbeiten ist natürlich nicht sinnvoll. Das habe ich gerade mal geändert.
Dass mmioOpen wird in entsprechenden DirectSound-Programmieranleitungen so benutzt (darum wohl auch der Absturz der offiziellen MS-Beispiele). Da es da nie Probleme gab, hatte ich auch noch keinen Anlass, das Kleingedruckte durchzulesen.
Createfile kann ich aber mal probieren.

Carsten
Zuletzt geändert von Carsten Hölscher am 12.04.2012 23:26:24, insgesamt 1-mal geändert.

Benutzeravatar
Max Senft
Administrator
Beiträge: 3004
Registriert: 04.11.2001 14:01:40
Aktuelle Projekte: Dies und das
Wohnort: Blieskastel, Saarland, Deutschland
Kontaktdaten:

Re: Testbericht unter Linux

#58 Beitrag von Max Senft »

Hi,

funny: http://www.zusi.de/delphi/soundtutorial.pdf" target="_blank - Dort auf Seite 4 Funktion "TSound2D.StreamLaden". ;)

Grüße
Max
PS: Laut Dokumenteninfo ist das Dokument von 2006? Damals evtl. Standard? Heute nicht mehr?
Zuletzt geändert von Max Senft am 12.04.2012 23:38:06, insgesamt 1-mal geändert.
Administrator, Programmierer, Ansprechpartner bei Problemen mit dem Board

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#59 Beitrag von Johannes »

Carsten Hölscher hat geschrieben:Der Versuch, die Datei nach dem fehlerhaften Öffnen noch irgendwie zu bearbeiten ist natürlich nicht sinnvoll. Das habe ich gerade mal geändert.
Dass mmioOpen wird in entsprechenden DirectSound-Programmieranleitungen so benutzt (darum wohl auch der Absturz der offiziellen MS-Beispiele). Da es da nie Probleme gab, hatte ich auch noch keinen Anlass, das Kleingedruckte durchzulesen.
Createfile kann ich aber mal probieren.
Danke! Wäre natürlich schön, wenn dadurch dieser bislang hartnäckigste Bug beseitigt würde :)

Nebenbei gesagt finde ich es toll, dass trotz fehlender „offizieller“ Unterstützung hier Rücksicht auf andere Plattformen genommen wird. Oder, um mich mal von einer Seite vorher selbst zu zitieren:
Johannes hat geschrieben:Könnte es also sein, dass im Ladecode für den Sound irgendeine Anomalie steckt, die zufälligerweise nur unter Linux zu Tage tritt?
:D
Max Senft hat geschrieben:funny: http://www.zusi.de/delphi/soundtutorial.pdf" target="_blank - Dort auf Seite 4 Funktion "TSound2D.StreamLaden". ;)
Das ist ja mal ein Ding ;) War das irgendwo verlinkt (außer hier)? Da hätte ich mir wohl so einiges an Assembler-Durchwühlen sparen können …

Um aber noch was Produktives beizutragen … es wurde bislang noch nicht vermerkt, aber die DirectX-Zeichenfläche überdeckt in Wine immer das ganze Fenster, auch Menü, Toolbars, Statusleiste (im 3D-Editor) etc. werden dabei überdeckt. Da das auch im Screenshot im ersten Beitrag auftaucht, wird das wohl ziemlich sicher eine Limitierung von Wine sein, trotzdem die Frage: Tritt das bei irgendjemand sonst unter Linux nicht auf?

Grüße
Johannes

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Testbericht unter Linux

#60 Beitrag von Carsten Hölscher »

Hättest auch fragen können, statt Dich durch assembler zu wühlen.
Das mit dem Überdecken habe ich nicht ganz verstanden. Kannst Du das mal an dem Screenshot verdeutlichen?

Carsten

Antworten