Hello, Guest the thread was called11k times and contains 205 replays

last post from compyx 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?

  • 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

    Das zeigt doch mal den Vorteil von Open Source :-)


    Bin die letzten Monate überhaupt nicht diesem Teil des Hobbys nachgegangen, beruflich viel zu tun und habe mich in meiner Freizeit einfach mit anderen Dingen beschäftigt.


    Ich hatte vor Veröffentlichung von Binaries der von mir modifizierten Version (inkl. der Modifikationen anderer) noch auf der Agenda, den About-Dialog zu überarbeiten, um die Arbeit des VICE-Teams und der anderen Modifikationen zu würdigen, sowie eine exakte Versionsangabe zu integrieren, so dass man genau zu dem Sourcecode-Stand im Repo kommt, mit dem das Binary erstellt wurde. Nicht wirklich viel Arbeit, hatte aber andere Prioritäten, deshalb noch kein Binary von mir.


    Wäre es meinerseits überhaupt noch sinnvoll, jene Version zur Veröffentlichung zu ergänzen und da noch Arbeit reinzustecken? Hätte auch genug andere Themen mit denen ich mich gerne beschäftigen würde, falls das eh keinem mehr was bringt.

  • Wäre es meinerseits überhaupt noch sinnvoll, jene Version zur Veröffentlichung zu ergänzen und da noch Arbeit reinzustecken? Hätte auch genug andere Themen mit denen ich mich gerne beschäftigen würde, falls das eh keinem mehr was bringt.


    Ich denke, es würde auf jeden Fall noch Sinn machen. Um nur ein Beispiel zu nennen - beim Integrieren des Dink Mods, beziehungsweise erstellen von Funktionsfeldern im WinVICE Menue, die es erlauben, Keyboard-Tasten auf einen Controller-Button zu legen.


    Da würden zumindest zwei neue Funktions-Felder im Joystick-Settings Menue, eines um die SPACE-Taste und eines um HOCHLENKEN auf einen Button legen zu können, schon eine klare Verbesserung bringen. Das geht bislang ja nicht, was ein klarer Nachteil ist, wenn man beispielsweise Jump and Run Games mit einem Gamepad im WinVICE spielt, weil man dort nach wie vor mit "hoch" springen muss.


    Und was natürlich auch toll wäre, das wäre eine Umschaltmöglichkeit zwischen 50,125Hz und 50,000Hz und dazu vielleicht, wie hier schon angesprochen, noch eine "sync to Monitor" Variante. Mit diesen drei Möglichkeiten würde man nahezu die ganze verschiedene Hardware der User abdecken, denn einer der drei Modi würde dann bei jedem ein gutes Resultat liefern in der Emulation. Der 50,000Hz Patch wird sicherlich bei vielen Usern das Soundbug-Problem beheben, so wie er es auch auf meiner Hardware macht und diejenigen Leute, die vorher mit 50,125Hz kein derartiges Problem hatten, könnten dann weiterhin ihre 50,125Hz nutzen. Und wenn beides bei einem User nicht zum erwünschten Ergebnis, wie etwa sauberem Scrolling führt, dann hätten solche User noch die Möglichkeit den Emulator zum Monitor syncen zu lassen, ähnlich wie bei dieser alten Version hier:

    https://www.lemon64.com/forum/viewtopic.php?t=22546


    Da hatten damals immerhin 43% der User gemeldet, dass diese Version bei ihnen eine Verbesserung bringt.


    Schätze, mit diesen drei auswählbaren Arten, vereint in einer Version und der Möglichkeit dazu, Keys auf den Controller mappen zu können (oder zumindest SPACE und HOCH), wäre dann alles abgedeckt, was man in der Hinsicht in den nativen WinVICE Versionen machen könnte. Eigentlich könnte man damit dann auch vollkommen zufrieden sein.

  • LR

    ....dann hätten solche User noch die Möglichkeit den Emulator zum Monitor syncen zu lassen, ähnlich wie bei dieser alten Version hier:

    https://www.lemon64.com/forum/viewtopic.php?t=22546


    Da hatten damals immerhin 43% der User gemeldet, dass diese Version bei ihnen eine Verbesserung bringt.

    43% sind ja jetzt nicht die Menge. Ehrlich gesagt, ich verstehe den ganzen Stress nicht so ganz mit dem Scrolling. Ich selber habe nicht mal ein Problem, WinVICE auf einem 60Hz Bildschirm zu betreiben.

    Wenn ich da die ganze Liste an Voraussetzungen und Nebenwirkungen sehe (z.B. in oben verlinktem Thread), die man in Kauf nimmt, um irgend ein Nanostottern alle 8 Sekunden zu vermeiden... Ist doch echt den Aufwand nicht wert.

  • 43% sind ja jetzt nicht die Menge. Ehrlich gesagt, ich verstehe den ganzen Stress nicht so ganz mit dem Scrolling. Ich selber habe nicht mal ein Problem, WinVICE auf einem 60Hz Bildschirm zu betreiben.


    Naja, das genaue Abstimmungsergebnis war ja so damals:


    This version runs totally smooth - 43%

    I can't see any difference - 34%

    Runs smoother than the official version - 21%


    was dann letztendlich bedeutet, dass es bei 64% der User, also knapp zwei Drittel, eine Verbesserung brachte und bei 43% dann auch noch "absolut weich" scrollte.


    Schon ein gutes Ergebnis finde ich für eine neue Funktion.

  • Schon ein gutes Ergebnis finde ich für eine neue Funktion.

    Ansichtssache. Bei DQH's threaded UI würden wohl annähernd 100% sagen dass es besser ist als "standard GTK3".


    Übrigens habe ich mal kurz seine Implementierung von "50 FPS" angesehen, das geht sehr ähnlich wie bei Lipti.

    Mit demselben unschönen Nebeneffekt (in WinVICE!), dass die Speedanzeige unbrauchbar ist. In seinen GTK3 Builds ist es wohl besser.

  • Ansichtssache. Bei DQH's threaded UI würden wohl annähernd 100% sagen dass es besser ist als "standard GTK3".

    Naja, ALLES zu haben und daraus auswählen zu können als klickbare Funktion, empfinde ich immer als das Nonplusultra, denn dann kann sich jeder User genau das raussuchen, von dem er der Meinung ist, dass es auf seiner jeweiligen Hardware am besten läuft. Vielleicht auch Geschmackssache, wie man dazu steht?


    Übrigens habe ich mal kurz seine Implementierung von "50 FPS" angesehen, das geht sehr ähnlich wie bei Lipti.

    Mit demselben unschönen Nebeneffekt (in WinVICE!), dass die Speedanzeige unbrauchbar ist. In seinen GTK3 Builds ist es wohl besser.

    Ist die schon fertig und erhältlich diese Version? Hab ich noch gar nicht mitbekommen, dass es die schon gibt. Dachte bislang wären das nur Screenshots, wie es dann aussehen soll, wenn es fertig ist.


    Wobei sich im tagtäglichen Gebrauch diese angeblichen Nebeneffekte aber wirklich extrem in Grenzen halten. Hunderte verschiedene Demos und Games liefen in den letzten knapp vier Monaten, in denen ich "Lipti's" Testbuild habe, schon mit seiner WinVICE Version hier bei mir durch und auf eine wirkliche Inkompatibilität, bin ich noch nicht gestossen wenn der Emu mit 50.000Hz läuft. Weder in einem Spiel bislang, noch in einem Demo. Für "Gaming" und "Demos schauen" ist das wirklich sehr gut geeignet, finde ich deshalb.


    Und vor der Nutzung solcher Sachen, die wirklich unbedingt ganz genau die 50.125Hz als Speed benötigen um zu funktionieren, kann man dann ja einfach vorher auf diese Geschwindigkeit wieder umschalten im Menue des Emu's. Hat man solche Hz-Wert Sachen als AN und AUS schaltbare Funktionen, sehe ich eigentlich nur Vorteile in der Integration dieser.


    Dass man sich dann nicht mehr hundertprozentig auf die Speedanzeige verlassen kann, ist natürlich nicht ideal, nehme ich aber gerne hin, wenn dadurch dann, wie etwa in Lipti's WinVICE Testbuild, der 50Hz Soundbug verschwindet, den ich als viel störender empfand, als eine ungenaue Speedanzeige, die man im Vollbild ja sowieso nicht sieht. Aber klar, ideal wäre, wenn auch diese wieder einwandfrei korrekt den Speed anzeigen würde.

  • "Angryking", siehst du


    VICE 3.x experimental Gtk3 threaded-UI build


    dachte ich es mir doch, dass "Lipti's" Patch auch bei anderen Leuten das gewünschte Ergebnis erzielt in Sachen "50Hz Soundkratzen weg" und "Scrolling perfekt", ebenso wie es ein ähnlicher Patch nun auch im GTK3VICE macht. Somit hat Lipti's Testbuild, den es ja leider immer noch nicht offiziell gibt (aber dafür ja deine Version die das auch mit enthält) seinen Zweck definitiv schon erfüllt.


    Wenn dort im "WinVICE Plus" jetzt noch sowas wie ein "Dink Mod" mit Funktionsfeldern direkt im Menue mit reinkäme und vielleicht noch diese schon erwähnte Umschaltmöglichkeit der Emulations-Geschwindigkeiten zwischen 50,000Hz, 50,125Hz und Sync-zum-Monitor, dann wäre das die ultimative native WinVICE Version und ein toller Abschluss der nativen WinVICE Versionen. Mit der Version könnte man dann super zufrieden sein. Alles was danach noch kommt zukünftig, könnte dann in die fortführenden GTK3VICE Versionen, die ja nun das Ruckelproblem nicht mehr haben und nun ebenfalls sehr gut laufen auf Windows Rechnern. Das ist alles eine sehr sehr gute Entwickling, ein C64 Emu besser als der andere und als User hat man echt eine gute Auswahlmöglichkeit. :)

  • Ja wenn es um die Anzeige geht, stimmt das schon. Aber das mit der Speedanzeige im Fenstermodus empfinde ich jetzt als zweitrangige Sache. Nicht ideal, aber doch irgendwie locker verschmerzbar, Hauptsache unter 50Hz Vollbild läuft nun alles perfekt, was Scrolling plus Sound betrifft und das ist ja damit nun der Fall. Vielleicht nicht auf allen Monitoren, aber scheinbar doch auf sehr vielen. "DX primary surface..." hilft, wie wir ja inzwischen wissen, bei vielen Leuten nicht wirklich, weil es das eine Problem durch ein anderes, weitaus schlimmeres ersetzt, dass dann deutlich am Screen zu sehen ist. Aber gut, dass diese Funktion zumindest auf einiger Hardware einen Sinn macht und dort Verbesserung bringt, dann hat auch diese zuschaltbare Funktion ihre Berechtigung. Auf meinem alten PC mit der älteren Geeforce Grafikkarte, muss ich die auch aktivieren, damit der Emu (VICE 2.3, da die neueren Versionen dort nicht mehr laufen) besser läuft.