Hello, Guest the thread was called7.4k times and contains 169 replays

last post from AW182 at the

Wo finde ich beim VICE Emulator Infos zu den "experimental binaries", bzw was in welcher Version geändert wurde?

  • Also meiner Meinung nach hört sich das gut an. Probleme, wie etwa im SID "Klogge", sind dann verschwunden. Ob sich nun das hier oder der V2.4 SID-Filter besser anhören, ist wirklich nicht einfach zu sagen, da schwanke ich noch hin und her. Was mir aber gleich auffiel, die Soundausgabe insgesamt, scheint in dieser kompilierten Win32-Version leiser zu sein als in den anderen WinVICE Versionen, da muss ich die Lautstärke dann immer etwas mehr aufdrehen, damit es wieder passt. Ob das aber nun mit dem neuen SID-Filter zusammenhängt oder an irgendetwas anderem, kann ich nicht sagen. Der neue Filter hört sich auf jedenfall gut an, finde ich, habe verschiedene SID's durchprobiert und verglichen.

  • Mal was zum testen.


    Eig. dasselbe wie in #161, aber mit Lipti Patch... eventuell. :D


    http://vicebuilds3.bplaced.net…er_mai_2020_plus_lipti.7z

    Prima Sache, bin gerade am rumtesten damit. Der Speed passt schonmal, das Clock-Tool läuft schon seit fast einer halben Stunde und meine Armbanduhr stoppt mit. Wird definitiv auf eine Abweichung von um die 4 Sekunden rauslaufen in 30 Minuten, somit läuft der Emu schonmal mit 50,000Hz.


    Wenn das fertig ist, probiere ich ein paar Spiele und achte auf Scrolling und Kompatibilität. Dann schaue ich, ob der 50Hz Soundbug auch wirklich ganz verschwunden ist und dann melde ich mich später nochmal.


    Diese Version hier hat den 8-SID Support jetzt zusätzlich mit drin, was mein Testbuild nicht hat bislang. Welcher SID-Filter besser klingt, der von der V2.4 oder dieser neue jetzt hier, ist wirklich schwer zu sagen. Klingt beides gut in den allermeisten SID's.


    Was sich so alles tut in Sachen C64 Emulation ist schon beeindruckend, man kommt ja kaum mit dem testen der ganzen Sachen hinterher:


    - RunAhead im Denise

    - Ruckeln weg im GTK3 VICE

    - neue HOXS64 Versionen am Start seit circa einer Woche (unter anderem mit neuem Vollbild-Menue)

    - neuer WinVICE Build hier, mit 50,000Hz, neuem SID-Filter und 8-SID Support

    - und nebenbei probiere ich noch mit dem Emu64 herum seit ein paar Tagen

  • Hab rumprobiert damit, "Angryking". Läuft einwandfrei hier bei mir auf der Hardware mit diesen 50,000Hz Speed von "Lipti". Was das weiche Scrolling unter 50Hz Vollbild angeht, genauso schön und sauber wie in meinem Testbuild von ihm.


    Nur im Fenstermodus, wenn dazu im Windows ein 50Hz Modus läuft, bricht manchmal der Speed etwas ein, was aber auch im Testbuild so ist und was ja auch schon mal ausführlich durchgekaut wurde in verschiedenen Threads. Aber im 50Hz Vollbild, und darauf kommt es mir an weil ich immer im Vollbild zocke, läuft alles perfekt und ich hab auch immer Fullspeed.


    Wie läuft die Version bei dir auf der Hardware "Angryking", da sind ja etwas andere Voraussetzungen gegeben als etwa bei mir hier, wie wir inzwischen wissen? Du schriebst ja auch mal, dein Monitor läuft mit 50,125Hz, dann ist diese Version für dich wahrscheinlich nicht wirklich optimal, oder? Aber auf vielen Monitoren sollte sie es sein.


    Jetzt müsste hier in diese Version nur noch sowas wie ein vereinfachter "Dink Mod" mit rein, mit zwei neuen Funktionsfeldern im "Joystick-Settings" Menue. Eines davon, um die SPACE Taste auf einen beliebigen Button am Controller legen zu können und das andere, um zusätzlich zum normalen hochlenken, einen Button am Controller für "hoch" festlegen zu können, damit man auf Gamepads dann mit einem Button springen kann in den ganzen Jump and Run Spielen. Das würde schon genügen, denn das sind die beiden Funktionen, die man in den meisten Fallem auf einen Button remappt, während andere Tasten eher seltener dafür genutzt werden. Wenn das noch mit drin wäre, dann wäre es perfekt.

  • Wie läuft die Version bei dir auf der Hardware "Angryking", da sind ja etwas andere Voraussetzungen gegeben als etwa bei mir hier, wie wir inzwischen wissen? Du schriebst ja auch mal, dein Monitor läuft mit 50,125Hz, dann ist diese Version für dich wahrscheinlich nicht wirklich optimal, oder? Aber auf vielen Monitoren sollte sie es sein.

    Hm, nie probiert. Macht ja jetzt auch nicht wirklich Sinn?


    "Angryking", würdest du es hinbekommen, den "Lipti" speed-patch in den source-code vom letzten GTK3VICE zu übertragen, oder ist der code so vollkommen unterschiedlich aufgebaut, dass dies ausgeschlossen ist?

    Das ist an sich simpel, aber wie wir ja wissen, hat der Patch so einige Probleme.


    1.) Laut Lipti selbst "REALLY dirty". Es werden einfach zu viele Audio Samples erzeugt, z.B. bei mir anstelle von 48000 deren 48119. Das zwingt dann den Emu dazu, langsamer zu laufen. Das kann durchaus unerwünschte Nebeneffekte haben.

    z.B. habe ich folgenden Text gefunden im Code:

    Quote

    /* FIXME: handshake with a 2031 disk drive has a timing issue, where
    the CBM-II is slightly too fast. Reducing speed for about 1.3% from
    the real 2MHz seems to help here...

    Hat jetzt nichts mit dem Patch zu tun, zeigt aber, dass Peripherie Probleme machen kann wenn da Timing/Speed nicht passen.

    2.) Der Patch ist ausgelegt für PAL @ 50.124Hz. Alle anderen Modelle (PAL-N, alle NTSC, TED) laufen mit einem Speed, der weder dem verwendeten Bildschirm noch dem realen Gerät entspricht. Das wird man kaum wollen.

    3.) Der Patch geht von einem 50.000Hz Bildschirm aus. Nur wird das nicht immer stimmen. Ich habe mal meinen Desktop Moni mit Nvidia Graka und den Laptop mit Intel getestet (so eingestellt ab Werk): Das sind ~50.6Hz und 60.2Hz.

    Das müsste der User gegebenenfalls auch noch eingeben können.


    4.) Kein GUI


    Punkt 2 und 3 sind natürlich für einen brauchbaren Programmierer kein Problem. Punkt 4 schon mal gar nicht.

    Bleibt aber Punkt 1, und das ist irgendwie ja der echte Pferdefuß.


    Unter diesen Umständen ist kaum anzunehmen, dass dieser Patch Aufnahme findet im offiziellen Repository. Bestenfalls flickt das jemand sonst rein und erstellt GTK3 Binaries (nächste Testversion :D), wenn auch ohne Punkt 2, 3 und 4.

  • Unter diesen Umständen ist kaum anzunehmen, dass dieser Patch Aufnahme findet im offiziellen Repository. Bestenfalls flickt das jemand sonst rein und erstellt GTK3 Binaries (nächste Testversion :D), wenn auch ohne Punkt 2, 3 und 4.


    Als AN und AUS schaltbare Funktion finde ich den Patch auf jedenfall sinnvoll, da er auf einigen Rechnern/Monitoren einfach ein saubereres Scrolling verursacht und wenn er sowieso zu und weg schaltbar ist, hätte es ja keinerlei Nachteile, ihn mit aufzunehmen. Ehrlich gesagt, nutze ich Liptis Testbuild jetzt als Haupt-VICE-Version schon seit ich ihn habe (Ende Januar) und hab darauf inzwischen etliches an Software (Demos/Games) darauf laufenlassen. Auf eine Inkompatibilität bin ich dabei noch auf keine einzige gestossen. Bislang lief darauf alles einwandfrei. Wobei ich jetzt aber nicht mit Sicherheit sagen kann, ob "Lipti" da beim letzten Testbuild (die V5 welche ich hier habe) nicht noch mehr geändert hat als das was veröffentlicht wurde. Fragen kann man ihn auch nicht so leicht, weil er leider so gut wie nie mehr hier ist.


    "Angryking", würdest du es hinbekommen, den "Lipti" speed-patch in den source-code vom letzten GTK3VICE zu übertragen

    Das ist an sich simpel, aber wie wir ja wissen, hat der Patch so einige Probleme.

    Auch wenn es dann in diesem Fall nicht abschaltbar wäre, würde es mich doch sehr interessieren, wie das Scrolling in der GTK3 Version damit dann wäre, ob dann auch dieser eine Ruckler, der bei mir dort circa alle 30 Sekunden einmal kommt, auch noch weg wäre. Ich vermute ja, weil es im WinVICE hier ebenfalls eine Verbesserung brachte. Also einen Testbuild wäre es vielleicht wert, wenn es nicht zuviel Aufwand darstellt. Dann können die User das mal antesten und wenn es das Scrolling bei vielen Leuten verbessert, was man dann ja sieht im Testbuild, dann könnte man es als zuschaltbare Option ja mit in den GTK3VICE aufnehmen.

  • 3.) Der Patch geht von einem 50.000Hz Bildschirm aus. Nur wird das nicht immer stimmen. Ich habe mal meinen Desktop Moni mit Nvidia Graka und den Laptop mit Intel getestet (so eingestellt ab Werk): Das sind ~50.6Hz und 60.2Hz.

    Das müsste der User gegebenenfalls auch noch eingeben können.

    Vielleicht sollte man es immer zum jeweiligen Monitor syncen lassen, das wäre eine Option. Oder drei Umschalt-Modi, die normalen 50,125, dann 50,000 und eben Monitor-Sync. Wäre vielleicht eine Möglichkeit, die meiste Hardware die umherschwirrt, gut abzudecken?