Forum64

Ich hab hier (http://www.uploadyourfiles.de/b2c79e7c38…j/Download.html ) eine Version von WinVice, die ruckelfrei laufen kann. Die kann ich nun uneingeschränkt empfehlen.


Benutzung:
- Datei entpacken in einem vorhandenen WinVice1.20 Ordner.
- x64e.exe starten
- einen VideoModus in "Video Settings .../FullScreen" auswählen, der möglichst nahe bei 50Hz oder 100 Hz ist (z.B. 800x600@56Hz, oder 800x600@100Hz)
- auf FullScreen schalten (z.B. mit ALT+D) und ruckelfreie Bewegungen genießen.
- zum Vergleich mal wieder das originale WinVice starten x64.exe und kotzen

Probleme:
- Falls man keine 50 oder 100 Hz einstellt, läuft der emulierte C64 zu schnell, d.h. bei 56 Hz 112% Geschwindigkeit, bei 60 Hz und 120 Hz auf 120% usw.
- Falls der C64 zu schnell ist z.B. bei 60 Hz, kann der Sound etwas knacksen (Bitte um Rückmeldung, welches Spiel/Demo usw.)
evtl. läuft die Version nicht ganz so performant (zieht also etwas mehr CPU-Zeit) wie das Original (vieleicht liegt es an meinem Compiler).
Es gibt leider noch kein GUI-Option zum ein und ausschalten dieses Modus!

Tipps, falls es doch ruckeln sollte:
- Video Modus von 32Bit auf 16 Bit runter schalten (das bringt Geschwindigkeit und die Bild-Qualität ist eigentlich noch genau so gut), notfalls auch auf 8 Bit.
- Scale2x abschalten
- DoubleScan abschalten
- Pal Emulation abschalten
- Sound Playback abschalten (nur in extremen Fällen)
- DoubleSize abschalten (auch nur in extremen Fällen)
- evtl. mit dem TaskManager x64.exe auf Priorität Hoch stellen

Tipp für Leute mit TFT ohne 100Hz Modus:
folgendes Programm installieren: PowerStrip
Damit kann man einen VideoModus auf 50Hz stellen, das geht so:
- Rechts-Klick auf PowerStrip im SystemTray
- Anzeige-Profile->Konfigurieren
- Auflösung auswählen in dem man WinVice laufen lassen möchte (z.B. 800x600)
- erweiterte Timing Optionen
- So lange ändern bis man 50Hz oder 100 Hz für diesen Modus hat
- auf OK klicken (sonst falls man aus Versehen einen Modus eingestellt hat, der der Monitor nicht kann einfach auf ESC drücken)
- Bitte mal antworten, ob das geklappt hat oder wo Probleme aufgetaucht sind

Für alle (es waren immerhin ganze 5 Leute, nach der Anzahl der Downloads), die schon die vorherige Testversion ausprobiert haben, folgende Bugs wurden behoben:
- falls Alt+Tab gedrückt wurde lief alles zu schnell
- diverse Refresh-Fehler behoben (einer ist zwar noch drin, aber das fällt sowieso niemandem auf)
- Dialoge werden im Full-Screen Modus korrekt dargestellt (z.B. mit Alt+x oder Alt+8 )
- Priorität blieb manchmal auf Hoch.
- Video-Cache funktioniert nun immer und korrekt
- seltene Ruckler in unter 100Hz Modi wurden eliminiert (wegen Fehler im Timing-Logik)

Features:
- nutzt bessere Sleep-Time-Auflösung (es läuft auf manchen Systemen also auch im FensterModus ruckelfreier)
- synchronisiert im FullScreenModus an der Bildschirmfrequenz
- als einziges (?) Programm blockiert dieses WinVice nicht die CPU komplett so lange er auf den nächsten VerticalBlank wartet. CCS64 kann auch ruckelfrei laufen (aber nicht so gut )
Zum Vergleich folgende CCS64 Einstellung benutzen:
ScreenMode: 800x600x16
RefreshRate: 100Hz
UpdateMode: Frame
SkipFrame: Repeat 1
SyncRate: Screen
Der CCS64 hat übrigens auch Probleme mit dem Sound falls man 60Hz und SkipFrame auf 0 setzt, weil er logischerweise auch zu schnell läuft.

Todo:
- Option in GUI
- Vice-Team meine Änderungen geben
- Debug-Ausgaben in Log-File entfernen
- Sound knacksen minimieren (vieleicht)

und irgendwann vieleicht mal folgendes (vieleicht findet sich ja auch jemand anders):
- Linux-Version (hab keine Ahnung wie man auf den VBlank wartet) dauert also noch sehr lange! Es gibt zwar Alternativen, wie etwa OpenGL, oder ein Kernel-Modul selber schreiben aber das erscheint mir ein bisschen aufwendig. Also irgendwer wird doch wissen wie das geht!
- OpenGL -Modus (ja da könnte man auch 2 Frames halbtransparent übereinander legen um Interlace-Flimmer zu vermeiden oder den schwarzen Rand im Fenstermodus weg machen usw.)

Weitere Hinweise:
Für technische Hinweise hier schauen: ruckelfreier WinVice (Timing-Problem) / funzt VSync?
einige Bugs, die auch im originalen WinVice1.20 drin sind, sind nicht behoben, siehe auch Bugs und Verbesserungen in Vice

Viel Spaß bei den jetzt ruckelfreien Animationen in WinVice!
- Chrille

Ich habe leider noch einen kleinen Fehler gefunden.

Deshalb in 'Video Settings ...' / 'FullScreen' / 'VBLANK Synchronization' deaktivieren!

Der Fehler ist eigentlich nicht schlimm, kann aber diesen WinVice zum Ruckeln bringen.
Das kann nur passieren, wenn der emulierte C64 und der PC-Monitor eine ähnlich Frequenz haben. Beispielsweise man emuliert einen Pal C64 bei 50Hz Monitor-Frequenz oder eben einen Ntsc-C64 bei 60 Hz Monitor-Frequenz. Die Einstellung dieser Option ist z.B. egal wenn ein Pal-C64 emuliert und 60 oder 100 Hz Monitor Frequenz hat.

Ach ja, wenn ich schon schreibe, hat jemand eigentlich einen TFT bei dem man über PowerStrip 50 Hz erzwingen kann? Und wenn ja welches Modell? Falls ich mir einen TFT kaufe wäre mir das wichtig. Bei meinem Röhrenmonitor kann ich auf jeden Fall 50 Hz einstellen.

Ach noch was, ich würde ja mal gerne wissen, ob Leute erkennen das der Original Vice ruckelt, oder ob sie den direkten Unterschied bemerken. Ich würde ja mal eine Umfrage starten, aber ich möchte halbwegs repräsentative Ergebnisse, deshalb hat wer einen Idee, wie man so was aufziehen könnte? Ich hab zwar mal auf Lemon64 eine Umfrage gestartet (in Bezug auf diese Version und den Verbesserungen). Aber erstens sind 5 Stimmen nicht wirklich aussagekräftig und zweitens werde ich wohl kaum ein Durchschnittsergebnis bekommen, da ja wahrscheinlich Leute eher abstimmen, die den Unterschied sehen. Oder hat mal irgendwer ein Studie oder ähnliches in der Richtung gelesen? Wenn ja würde ich gerne wissen wo man so was bekommt.

Quoted

Original von Pollux
Habe die Version grade mal kurz angetestet, sieht wesentlich besser aus als das originale WinVice, vielen Dank für die Mühe.

Japp, danke!

Quoted

Bei Scrollern mit großem Charset (z.B. 4x4) mußte ich allerdings die PAL-Emulation ausschalten, damit das Ruckeln (eher Zucken) verschwindet, bei kleinen Scrollern ist´s perfekt. Liegt das an meinem Uralt-Rechner (XP 1900+ und Geforce 4 Ti) ?

Vermutlich liegt das irgendwie an deinem Uralt-Rechner. Ich hab übrigens auch ein ähnlich altes System (XP1600+ und Ati-Radeon 9800 Pro). Ich hab manchmal auch Zucken drin (falls ich sozusagen die besten WinVice-Einstellungen nehme). Naja, also man könnte da evtl. was optimieren, da es sicherlich auch Möglichkeiten gibt, die Performance von WinVice zu verbessern, z.B. die Pal-Emulation über die Grafik-Hardware zu beschleunigen (OpenGl, DirectX). Das läuft zur Zeit über den Prozessor. Ich glaube, da geht viel Zeit drauf Sachen in den Grafikspeicher zu schreiben.
Es könnte auch sein, dass meine kompilierte Version etwas weniger performant ist. Evtl. muß ich das mal mit einer neueren Version von MinGW ausprobieren oder VisualStudio. Ich glaube, das original kompilierte läuft etwas schneller.

Vieleicht solltest Du auch alle Programme, die nebenher laufen, versuchen zu beenden, weil auch ein inaktiver Browser leider schon mal dazwischen funken kann (z.B. Ausführung von Java-Script Programmen). Sonst kann man auch versuchen über den Task-Manager x64e.exe hohe Priorität zu geben. Vieleicht sollte ich auch ganz nebenher eine Option einbauen, die sich etwas aggressiver verhält, was die CPU-Zeit anbelangt. Nur dann könnte möglicherweise schon mal das System hängen, falls irgendwas schief läuft.

Ach noch was, es bringt auch einiges den Grafikmodus auf 16 Bit zu stellen und das bringt keine wesentliche Verschlechterung der Optik. Edit, ach ja falls sich nicht zu viel am Bilschrim ändert, die Video-Cache Option (im Options-Menü) sollte dann auch was bringen.

Würde mich freuen, wenn Du das Verhalten genauer erläutern könntest, und ob es mit oben genannten Tipps besser läuft. Falls das alles nicht hilft, ich hoffe, ich hab keinen weiteren Fehler. Im schlimmsten Fall kannst Du dich auch per PN an mich wenden und mir evtl. das Log-File zu kommen lassen, denn dann kann ich vieleicht sehen, ob es wirklich ein Fehler ist.

Quoted

Außerdem haben große Scroller einen Nachzieh-Effekt, sieht wie auf einem TFT mit bescheidener Reaktionszeit aus.

Ich denke, dieser Effekt kommt daher, dass Du einen 100 Hz Modus benutzt, oder?
Super, dass Dir das aufgefallen ist. Ich dachte schon fast, das würde nur mir auffallen
Naja, jedenfalls ist dieser Effekt schon interessant, das ist sozusagen 50FPS@100Hz Ruckeln. (Ähnliche Effekte kann man, glaube ich, auch bei 100Hz Fernsehern sehen.) Und dagegen kann man leider nichts machen, außer halt einen 50Hz Modus nehmen.

Quoted

Original von Pollux
Bei Scrollern mit großem Charset (z.B. 4x4) mußte ich allerdings die PAL-Emulation ausschalten, damit das Ruckeln (eher Zucken) verschwindet, bei kleinen Scrollern ist´s perfekt. Liegt das an meinem Uralt-Rechner (XP 1900+ und Geforce 4 Ti) ?

Hmm, okay, ich hab mir das Verhalten bei mir noch mal angeschaut und da läuft was schief. Zum einen liegt es zwar daran, dass WinVice am Limit läuft, sprich mehr als 90% CPU-Auslastung, aber ich glaube das kann man verbessern.

Der Grund ist der folgende, ich versuche dem System immer soviel Zeit wie möglich zu überlassen (über Sleep()) und es gibt so etwas wie einen unsynchronierten Status, bei dem ich dann gewisse Sachen abschätze. Dieser unsynchronierten Status bleibt aber 1/50stel für 1/50stel. Deshalb kommt es irgendwann zu diesem Zucken, weil die Abschätzung irgendwann ungenau wird. Ich sollte also evtl. eine Abfrage einbauen, wenn dieser unsynchronisierte Status zu lange dauert, keine Sleep()s mehr zu machen und mich wieder zu synchronisieren. Ich denke, das würde helfen. Also schiebe ich wahrscheinlich demnächst noch mal eine neue Version nach, wird aber noch dauern, da ich im Moment nicht so viel Zeit hab und ich diese Sache mal genau untersuchen muß.

Auch wenn ich im Moment eigentlich keine Zeit habe.
Wenn Ihr Lust habt probiert doch mal PowerStrip aus.
Das gibt es bei http://www.entechtaiwan.com/util/ps.shtm oder http://www.chip.de/downloads/c1_downloads_12997992.html

Damit könnt Ihr austesten, ob eure Monitore wirklich keine 50 Hz könen, denn die Grafikkarten-Treiber bieten meistens einfach keinen 50 Hz Modus an! Ich kann über PowerStrip mein CRT-Monitor (Highscreen 19" / Vobis MS1996 DF) einstellen. Ich hab z.B. 720x576 immer auf 50 Hz stehen (auch wenn ich z.B bei WinVice 100 Hz aussuche wird 50 Hz erzwungen), man kann natürlich auf einen anderen Modus nehmen für den man 50 Hz erzwingt.

Oben im ersten Post ist eine kleine Anleitung, wie man PowerStrip bedient ...

Apropos, es wäre toll, wenn es für TFT-Monitore eine Positiv-Liste geben würde, die bis auf 50Hz runter gehen. Es gibt definitiv TFTs die sowas können!

Es gibt angeblich auch eine Software NVidia Forceware, mit dem man angeblich Modi erzwingen kann bei 50 Hz. Sind das die Standard-Treiber oder kann man das wirklich erzwingen? Ich hab keine Nvidia GraKa ...

iirc, bei Matrox-Karten gab es auch ein Tool bei denen man die Frequenz genau einstellen konnte, kann aber sein, dass das nur unter win9x lief.

@Pollux: Wäre gut wenn Du mir das Demo/Spiel sagst bei dem das Ruckeln auftritt. Sonst bei Gelegenheit (ich hab im Moment auch keine Zeit), wäre es gut wenn Du mir mal das Log-File von WinVice irgendwie schicken könntest. Dann kann ich wahrscheinlich sehen, ob dein Rechner zu langsam ist oder es ein Fehler ist. Achtung das Logfile wird recht schnell groß, also WinVice nicht zu lange laufen lassen! Vieleicht eine Minute? (vieleicht beim Programm bei dem es zuckt Alt+s für SaveState drücken - dann noch mal laufen lassen und am Anfang gleich alt+l drücken - dann wird das ganze Lade-Zeit etc. übersprungen und das Log-File bleibt kleiner).
Außerdem bedenken, dass bei mir auch was schief läuft bei 800x600@100Hz/32Bit mit 16Bit Farbtiefe läuft es allerdings ohne Probleme.
Noch mal kurz bestätigen, ohne Pal-Emulation läuft es aber ruckelfrei, richtig?
Aber super für den guten Fehlerbericht.

@Logan: Das Sound knacksen, passiert nur bei bestimmten Soundsequenzen. Bei Giana-Sisters kommt es selten vor, bei Killerwatt ständig. Hat was mit Wellenformen abschneiden zu tun ... denke ich.

Ach noch was, wenn man nicht gerade einen NTSC-C64 emuliert und ungefähr einen 60 Hz Modus hat (oder für Pal 50Hz), bringt VBlank Sync nichts und außerdem bitte nicht mit meiner Version verwenden, da es, wenn es was bringt, meine Version zum Ruckeln bringen kann.

Na toll, meine Antwort ist wieder total unübersichtlich ... Ich muß weg, ich hab doch keine Zeit

Ich schreibe wieder was Vernünfitiges und übersichtlicher und wenn ich weiß, was schief läuft und wenn ich wieder mehr Zeit habe.

läuft bei mir auf den notebook ganz toll im vollbildmodus, kein flimmern usw.
habe eine asm-routine wo ein sprite von rechts nach links geschickt wird und zurück.

beim originalen sieht man ein flimmern und ruckeln.

mfg

hallo chrille, kannst du die neue x64.exe von vice1.21 auch ändern, der ruckelt immer noch , haben die immer noch nicht erkannt und beseitigt. wäre toll.

ich arbeite erstmal mit den vice1.2 weiter.

danke.

mfg peter

Quoted

Original von super_castle
hallo chrille, kannst du die neue x64.exe von vice1.21 auch ändern, der ruckelt immer noch , haben die immer noch nicht erkannt und beseitigt. wäre toll.

Möglicherweise habe ich es ja übersehen, aber: Wo finden sich eigentlich die Quelltexte zu den Änderungen, die Chrille eingebaut hat? Ohne diese Änderungen dürfte es sehr schwer sein, diesen Patch in Vice einzubauen, oder?

Gruß,
- Spiro.

kontakte ihn mal....

mfg peter

Hallo Spiro, hallo super_castle!

Quoted

Original von strik

Quoted

Original von super_castle
hallo chrille, kannst du die neue x64.exe von vice1.21 auch ändern, der ruckelt immer noch , haben die immer noch nicht erkannt und beseitigt. wäre toll.

Möglicherweise habe ich es ja übersehen, aber: Wo finden sich eigentlich die Quelltexte zu den Änderungen, die Chrille eingebaut hat? Ohne diese Änderungen dürfte es sehr schwer sein, diesen Patch in Vice einzubauen, oder?

Ja, richtig. Die Quelltextänderungen sind nirgendwo zum runterladen. Falls jemand die Änderungen haben will, kann ich natürlich den Source per Mail weiter geben oder notfalls irgendwo hoch laden.

Ich würde allerdings lieber erst mal folgende Dinge tun, bevor ich die Änderungen veröffentliche:

Quoted

Original von chrille (erster Beitrag)
Todo:
- Option in GUI
- Vice-Team meine nderungen geben
- Debug-Ausgaben in Log-File entfernen
- Sound knacksen minimieren (vieleicht)

Eine Option in der GUI ist wohl das Allerwichtigste um diese Änderungen in die nächste offizielle Vice Version einzubauen, denn schließlich läuft der Emulator ja nicht mehr mit Original-Geschwindigkeit, sondern synchronisiert sich an der PC-Monitor-Frequenz.
Vieleicht kann mir ja mal jemand einen kleinen Tipp geben, wie man neue Menüs oder Felder in die Einstellungen einbauen kann. Falls nicht auch nicht schlimm, ich hab mich damit ehrlich gesagt noch nicht wirklich auseinander gesetzt.

Außerdem sind da noch kleine Fehler drin die zwar selten auftreten aber manche Leute doch stören könnten. Z.B. gibt es wohl Probleme bei NVidia-Karten. Da beim DoubleBuffering, der eine Buffer nicht korrekt gelöscht oder aufgebaut wird. Leider sind die Fehlerberichte meist nicht sehr präzise. Also läuft es im Moment eher schleppend - mal abgesehen davon, daß ich meist auch nur am Wochenende Zeit hab irgendwas am WinVice zu machen.

Naja, ich habe wenigtens einen möglichen Grund für das Zucken-Problem gefunden. Wenn er gezuckt hat, hat er sich nicht mehr richtig synchronisiert, das macht er jetzt. Trotzdem ist da noch ein Ruckeln drin, aus mir noch unbekannten Gründen. Das passiert bei mir auch nur bei 32 Bit Farbtiefe mit Pal-Emulation. Leider sind diese Timing-Sachen echt schwierig - naja eher nervig - zu debuggen, vor allem da ja viele Probleme nur manchmal auftreten, das erfordert Geduld und viel Zeit. Außerdem muß ich ständig dieses lange langweilige Log-File durchsuchen um auf Timing-Probleme zu stoßen. Dummerweise kann ich ja nicht sofort sehen, wenn es geruckt hat, woran es lag. Vieleicht sollte ich mal Ausgaben direkt auf den Bildschirm machen ...

Apropos falls sich jemand mit DirectX/DirectDraw auskennen sollte - vieleicht hab ich ein Problem mit IDirectDrawSurface_Lock(c->back_surface, NULL, &desc, DDLOCK_WAIT, NULL). Denn ich glaube, wenn er ruckt braucht er relativ lange um das Surface zu locken, iirc so ca. 2ms, sonst braucht er praktisch nur ein paar Microsekunden. Woran könnte das liegen? Vieleicht kann mir auch irgendwer nen Hinweis geben, wo ich entsprechende Dokumentation dazu finde. Die "normale" Beschreibung der Funktion ist ein bisschen wenig um das Verhalten zu erklären.

- Chrille

Hallo Chrille,

zuerst einmal ein kleiner Kommentar: Ruby (der manchmal hier rumhängt) und ich sind vom VICE Team.

Quoted

Original von Chrille
Ja, richtig. Die Quelltextänderungen sind nirgendwo zum runterladen. Falls jemand die Änderungen haben will, kann ich natürlich den Source per Mail weiter geben oder notfalls irgendwo hoch laden.

Ok, wenn du noch dran arbeiten willst, kann ich das verstehen. Beachte allerdings auch, dass du nach GPL auch verpflichtet bist, die Quelltexte herauszurücken - offenbar renne ich bei dir damit offene Türen ein (was ich gut finde), ich will aber trotzdem kurz darauf hingewiesen haben.

Quoted

Ich würde allerdings lieber erst mal folgende Dinge tun, bevor ich die Änderungen veröffentliche:
[...]
Eine Option in der GUI ist wohl das Allerwichtigste um diese Änderungen in die nächste offizielle Vice Version einzubauen, denn schließlich läuft der Emulator ja nicht mehr mit Original-Geschwindigkeit, sondern synchronisiert sich an der PC-Monitor-Frequenz.

Nun ja, wenn die Änderung "sauber" ist, würde sich bei uns bestimmt jemand finden, der die GUI-Änderungen dafür macht.

Quoted

Vieleicht kann mir ja mal jemand einen kleinen Tipp geben, wie man neue Menüs oder Felder in die Einstellungen einbauen kann. Falls nicht auch nicht schlimm, ich hab mich damit ehrlich gesagt noch nicht wirklich auseinander gesetzt.

Für Windows mußt du in src/arch/win32/ schauen. Ich schätze mal, dass dies in Einstellungen/Video gehört, also wäre dort die Datei resc64.rc zuständig. Damit änderst du die Dialogbox. Falls du neue Einstellungen ergänzt (hier wohl ja), mußt du eine ID dafür in res.h erzeugen.

Nun mußt du noch die Implementierung machen. Für die Video-Einstellungen wäre das uivideo.c (und evtl. uivideo.h), wobei du vor allem ui_video_settings_dialog() ändern müßtest.

Quoted

Außerdem sind da noch kleine Fehler drin die zwar selten auftreten aber manche Leute doch stören könnten. Z.B. gibt es wohl Probleme bei NVidia-Karten. Da beim DoubleBuffering, der eine Buffer nicht korrekt gelöscht oder aufgebaut wird. Leider sind die Fehlerberichte meist nicht sehr präzise. Also läuft es im Moment eher schleppend - mal abgesehen davon, daß ich meist auch nur am Wochenende Zeit hab irgendwas am WinVice zu machen.

Ich würde dir wirklich den Vorschlag machen, uns auf der VICE-Mailingliste zu kontaktieren. Wir können dann gemeinsam ausloten, welche Möglichkeiten da sind. Du mußt nicht als Einzelkämpfer durch alles gehen um dann eventuell festzustellen, dass wir - z.B. wegen "Formalien" - den Patch so nicht haben wollen. Möglicherweise kann auch der eine oder andere, der regelmäßig viel für Windows programmiert, brauchbare Inputs zuliefefern.

Da gerade 1.21 rausgekommen ist ist die Wahrscheinlichkeit für die Aufnahme der Änderung eh größer, da jetzt maximal viel Zeit bis zum nächsten Release bleibt.

Am besten nimmst du deine Sourcen, erzeugst ein "unified diff" (diff-Tool kensnt du hoffentlich? Dann "diff -u ...") gegenüber der offiziellen 1.21, und schickst es erst einmal an unsere Mailingliste. Diskutieren kann man dann immer noch.

Quoted

Apropos falls sich jemand mit DirectX/DirectDraw auskennen sollte - vieleicht hab ich ein Problem mit IDirectDrawSurface_Lock(c->back_surface, NULL, &desc, DDLOCK_WAIT, NULL). Denn ich glaube, wenn er ruckt braucht er relativ lange um das Surface zu locken, iirc so ca. 2ms, sonst braucht er praktisch nur ein paar Microsekunden. Woran könnte das liegen? Vieleicht kann mir auch irgendwer nen Hinweis geben, wo ich entsprechende Dokumentation dazu finde. Die "normale" Beschreibung der Funktion ist ein bisschen wenig um das Verhalten zu erklären.

Ich bin in Bezug auf die GUI eher rückständig, mein Wissen basiert zumeist noch auf Win 3.0/3.1, daher kann ich da nicht so direkt weiterhelfen. Tibor Biczo hingegen kennt sich da sehr gut aus, der kann da bestimmt gute Tipps und Hinweise geben.

Gruß,
- Spiro.

.....Da gerade 1.21 rausgekommen ist ist die Wahrscheinlichkeit für die Aufnahme der Änderung eh größer, da jetzt maximal viel Zeit bis zum nächsten Release bleibt.....

bevor das vice-team den c64 emulator mit zuvielen schnickschnack überfüllt "mmc usw."
sollten doch erst mal die grafikmacken beseitiget werden. in den letztten jahren hat sich viel getan hinsichtlich grafikkarten, aber eine vollkommende auseinandersetzung damit wurde nicht so richtig realisiert.

also, die grafikmacken beseitigen und dann den zusätzlichen schnickschnack. denkt daran es ist ein c64.

mfg

Quoted

Original von super_castle
.also, die grafikmacken beseitigen und dann den zusätzlichen schnickschnack. denkt daran es ist ein c64.

Das sind deine Prioritäten. Andere Leute haben andere Prioritäten.

Beispielsweise ist das MMC64 eine externe Entwicklung. Da sie gut programmiert ist und nichts anderes dabei kaputt geht (zumindest nichts, was gefunden wurde. ), wurde es dann eingebaut.

Wie vielleicht schon gemerkt, VICE ist Open-Source. Wenn jemandem etwas nicht paßt, und das wird auch nicht korrigiert, dann soll er sich doch bitteschön hinsetzen und versuchen, das zu beseitigen. Alternativ könnte manchmal ein ordentlicher Bugreport helfen.

Gruß,
- Spiro.

....wenn keine probleme macht...

die mmc macht doch noch grosse probleme.
auch bei meiner avr-proggerei mit winavr-c macht die mmc immer noch probleme.

für den c64 ist diese etwas zu schnell freigegeben worden. ihr werde euch noch wundern, wie verschieden die fabrikate der karten reagieren, die haare werdet ihr euch noch raufen.
so einfach ist das nicht. der zeitzyklus spielt eine der entscheidenden rollen.


mfg

Hallo Spiro,

Quoted

Original von strik
zuerst einmal ein kleiner Kommentar: Ruby (der manchmal hier rumhängt) und ich sind vom VICE Team.

Ja, ich weiß, Ihr habt mir ja auch wertvolle Hinweise und Hilfe für diese Version gegeben

Quoted

Ok, wenn du noch dran arbeiten willst, kann ich das verstehen. Beachte allerdings auch, dass du nach GPL auch verpflichtet bist, die Quelltexte herauszurücken - offenbar renne ich bei dir damit offene Türen ein (was ich gut finde), ich will aber trotzdem kurz darauf hingewiesen haben.

Das ich die Änderungen raus geben muß, weiß ich, da ich es ja veröffentlicht habe. Leider gibt es ja auch viele Leute, die so was nicht beachten ...

Quoted

Nun ja, wenn die Änderung "sauber" ist, würde sich bei uns bestimmt jemand finden, der die GUI-Änderungen dafür macht.

Super Das könnte mir einiges an Arbeit ersparen. Mal schauen ...

Quoted

Für Windows mußt du in src/arch/win32/ schauen. Ich schätze mal, dass dies in Einstellungen/Video gehört, also wäre dort die Datei resc64.rc zuständig. Damit änderst du die Dialogbox. Falls du neue Einstellungen ergänzt (hier wohl ja), mußt du eine ID dafür in res.h erzeugen.

Nun mußt du noch die Implementierung machen. Für die Video-Einstellungen wäre das uivideo.c (und evtl. uivideo.h), wobei du vor allem ui_video_settings_dialog() ändern müßtest.

Werde ich mir mal anschauen ... diese oder nächste Woche, aber vieleicht brauche ich das ja auch gar nicht ...

Quoted

Ich würde dir wirklich den Vorschlag machen, uns auf der VICE-Mailingliste zu kontaktieren. Wir können dann gemeinsam ausloten, welche Möglichkeiten da sind. Du mußt nicht als Einzelkämpfer durch alles gehen um dann eventuell festzustellen, dass wir - z.B. wegen "Formalien" - den Patch so nicht haben wollen. Möglicherweise kann auch der eine oder andere, der regelmäßig viel für Windows programmiert, brauchbare Inputs zuliefefern.

Da gerade 1.21 rausgekommen ist ist die Wahrscheinlichkeit für die Aufnahme der Änderung eh größer, da jetzt maximal viel Zeit bis zum nächsten Release bleibt.

Gut, werde ich machen. Ich werde euch über die VICE-Mailingliste kontaktieren, irgendwann diese Woche. Ich hoffe, ich bekomm dann auch Antwort. Ich hab mal am wegen TimeBeginPeriod() gemailt, hab da aber keine Rückmeldung bekommen ... Wäre super, wenn ich da mehr Unterstützung bekommen würde. Naja, wollen wir mal sehen ...

Quoted

Am besten nimmst du deine Sourcen, erzeugst ein "unified diff" (diff-Tool kensnt du hoffentlich? Dann "diff -u ...") gegenüber der offiziellen 1.21, und schickst es erst einmal an unsere Mailingliste. Diskutieren kann man dann immer noch.

Ja, diff kenne ich, hab damit aber noch nicht wirklich viel gemacht. Aber der '-u' Hinweis sollte ausreichen um diff und patch zu nutzen. Hab bisher nur CVS oder Subversion benutzt um Änderungen von Sourcen zu machen.

Quoted

Quoted

Apropos falls sich jemand mit DirectX/DirectDraw auskennen sollte - vieleicht hab ich ein Problem mit IDirectDrawSurface_Lock(c->back_surface, NULL, &desc, DDLOCK_WAIT, NULL). Denn ich glaube, wenn er ruckt braucht er relativ lange um das Surface zu locken, iirc so ca. 2ms, sonst braucht er praktisch nur ein paar Microsekunden. Woran könnte das liegen? Vieleicht kann mir auch irgendwer nen Hinweis geben, wo ich entsprechende Dokumentation dazu finde. Die "normale" Beschreibung der Funktion ist ein bisschen wenig um das Verhalten zu erklären.

Ich bin in Bezug auf die GUI eher rückständig, mein Wissen basiert zumeist noch auf Win 3.0/3.1, daher kann ich da nicht so direkt weiterhelfen. Tibor Biczo hingegen kennt sich da sehr gut aus, der kann da bestimmt gute Tipps und Hinweise geben.

Also ich hab heute noch was an WinVice gemacht und ich denke es hat sich so mehr oder weniger erledigt. Denn es läuft nun (hoffentlich) immer ruckelfrei auch bei starker CPU-Last bzgl. WinVice, soweit nicht irgendwelche anderen Programme laufen (Andere Programme können auch nebenher laufen, nur dann ruckt es um so wahrscheinlicher, je mehr Zeit WinVice zieht, bzw. die nebenher laufenden Programme). Und es ruckt auch nur noch höchstens und das Zucken ist komplett weg. Ich frage mich zwar warum IDirectDrawSurface_Lock() manchmal länger braucht, aber das scheint auch nicht so wichtig zu sein. Vieleicht sollte ich dann ja noch mal eine Version zum Testen raus geben, mal sehen. Denn die Fehlerberichte waren manchmal wirklich hilfreich.

Gruß,
- Chrille