Virtual C64 nun im Web und mit CSDB-Browser

Retrofan · Nov 18th 2020

Quote from captain_buck_rogers

Wir können jetzt zwei Dinge machen ... ersten wir schreiben dem csdb-amin eine Mail damit er den unzulässigen Protokollwechsel repariert ... zweitens wir versuchen zu Erfahren ob es mithilfe der Download-ID irgendwie Möglich ist an die Release-ID zu kommen ...

Da das Problem ja zumindest teilweise ein Server-Problem ist, sollte man das meines Erachtens auch dort beheben. Ich kann auch ganz gut ohne Drag und Drop des Links leben und werde die Funktion einfach solange ignorieren, bis sie auch auf Safari funktioniert (und ich bin zu träge, um FF oder Chrome zu starten). Ist ja kein Drama, ich wollte den Bug halt nur gemeldet haben. Es wäre vielleicht noch ganz gut, wenn man in den File-Slot auch per C&P einen, manuell kopierten, Link absetzen könnte.

Quote from Snoopy

... oder Drittens: Wir verwenden Firefox oder Chrome ...

Firefox, der nach deiner Statistik einen noch geringeren Marktanteil hat als Safari? Ich weiß nicht – nur weil da speziell dieser Bug nicht auftritt, auf so einen Exoten setzen?

Ich habe mir mal die Browser-Anteile auf Netmarketshare angesehen: Über alle Systeme hinweg (Mobile wie Desktop) ergibt sich weltweit folgende Verteilung – Chrome: 66%, Safari 18%, Edge 4%, Firefox 3% (jeweils gerundet). Welche 2 Browser sollte man also unterstützen, wenn man möglichst viele Leute erreichen will?

emulaThor · Nov 18th 2020

Hallo captain_buck_rogers und dirkwhoffmann,

ich verfolge diesen Thread mit Interesse, bin begeistert von dem WASM-kompilierten Ansatz von vc64web und Eurem Elan, eine nutzerfreundliche Shell drumrumzubasteln! Jetzt musste ich wegen dieser HTTPS-Geschichte schmunzeln und melde mich hier auch mal zu Wort. An diesem Phänomen bin ich nämlich auch schon vorbeigekommen:

Quote from captain_buck_rogers

da steht z.B. der Downloadlink http://csdb.dk/getinternalfile.php/205981/short_escort.prg
das ist aber nur die Anzeige, verlinken tut er aber tatsächlich auf die Adresse https://csdb.dk/release/download.php?id=244134

[...]
die zweite Adresse https://csdb.dk/release/download.php?id=244134 (der vorgeschaltete Counter ) macht nämlich einen Redirect (dynamische Umleitung) wieder auf die erste Adresse dem eigentlichen Link mit dem sprechenden Namen ...eigentlich kein Problem für vc64web bloß sie wechselt dabei das Protokoll sie geht von https auf das unsichere unverschlüsselte http ... Dieses verweigert

Ich kann das bestätigen, dass hier die Protokolle gewechselt werden, ich glaube sogar, auf den Klick folgen 3 HTTP-Requests (303/301/200) und der mittlere ist plötzlich unverschlüsselt:

Ich arbeite auch an einem CSDb-Browser/Launcher, aber keine Angst, es ist nicht im Web, sondern direkt auf einem C64 (der Netzwerk bekommt via Sidekick64-Expansion). Dort war ich froh, dass ich überhaupt soweit kam, dass ich via HTTPS/TLS kommunizieren kann und testete meinen ersten HTTPS-CSDB-Download, und merkte: Es funktioniert nicht. Weil mein HTTP-Client keine Redirects kann (bisher). Dann dachte ich: OK, baue ich mal Redirects ein und stellte dann fest: Moment mal, der springt von HTTPS zu HTTP! Solche "Schweinereien" wollte ich nicht unterstützen und habe dann rumprobiert, bis ich rausgefunden habe, dass man eben alle Dateien über eine URL-Variante auch via HTTPS bekommen kann.

Ich baue mir in meinem Coding dann einen Request auf: https://csdb.dk/getinternalfile.php/205981/short_escort.prg

Damit habe ich einen einzigen Request via HTTPS und keine unnötigen Redirects. So einen Hack kann man dem Browser natürlich nicht vorschreiben.

Bisher hatte ich den CSDB-Admin nicht kontaktiert, weil ich mit meiner Lösung zufrieden war. Wenn Du eh mit ihm in Kontakt bist, würde ich mich freuen, wenn Du das thematisieren könntest.

Ansonsten finde ich halt die offenen Schnittstellen der CSDB gut gemacht, diesen CSDB-WebService musste ja auch erstmal einer bauen und mir ist gar nicht klar, wer den bisher in der Vergangenheit schon verwendet hat. (EDIT: Ich parse aber im Endeffekt auch HTML, das heißt, ich nehme RSS + WebService + HTML Advanced Search results als Datenquelle)

captain_buck_rogers · Nov 18th 2020

Quote from emulaThor

Ich baue mir in meinem Coding dann einen Request auf: https://csdb.dk/getinternalfile.php/205981/short_escort.prg

Damit habe ich einen einzigen Request via HTTPS und keine unnötigen Redirects. So einen Hack kann man dem Browser natürlich nicht vorschreiben.

der Request den du dir in deinem Coding aufbaust ist genau das was Chrome und Firefox dem vc64web im DropEvent zusätzlich mit übergeben (und was bei Safari fehlt) ... D.h. ich verwende beim Laden genau den gleichen Zugriff wie du ... übrigens nicht nur beim "drag and drop" sondern auch wenn vc64web aus seiner CSDb-Browser-Komponente heraus die Downloads lädt ... weil das gehopse zwischen den Protokollen für eine Javascript-Anwendung von der Browser-Polizei 👮 verboten/verweigert wird.

Übrigens ... cooles projekt ... kannst du denn da echt was aus der CSDb laden ... ist ja unglaublich ... gehen nur .prg und .t64 Dateien oder auch zips und d64? ... gibt es da einen youtube-link wo man sich das mal anschauen kannst wie du auf dem C64 was lädst und wie es startest ? Das ist echt abgefahren und super cool

Quote from emulaThor

Bisher hatte ich den CSDB-Admin nicht kontaktiert, weil ich mit meiner Lösung zufrieden war. Wenn Du eh mit ihm in Kontakt bist, würde ich mich freuen, wenn Du das thematisieren könntest.

ich schreib ihm das ...

Ich habe noch drei Sachen auf der Todo-Liste für die nächsten Wochen:

* für kleine Smartphones wäre es nett wenn die Navbar (oben) horizontal scrollbar wäre, dann wäre sie auf den Mini-Smartphones einzeilig und nähme nicht so viel Platz weg (momentan bricht sie um)

* Lösung für das Drag and Drop von Downloadlinks aus der CSDB.dk heraus für Safari erforschen ...

* Vibrations-API für XBox/Playstation4-Controller u.a. ansprechen. Das habe ich mir so vorgestellt, das wenn der VIC Sprite-Collisionen detektiert, dass dann Vibrationen im Controller ausgelöst werden können ... es rumbelt ... z.B. Pitstop 2 wenn die Rennwagen kollidieren oder man von der Straße abkommt oder Archon wenn man einen Schuss abkriegt, etc.. habt ihr noch mehr Spieleideen wo das cool wäre ? Am besten wäre es natürlich, wenn man das gamespezifisch wie bereits die Actionbuttons einstellen/konfigurieren kann ...

was meint Ihr dazu ? Oder gibt es andere Punkte die wichtiger sind ?🤔

Retrofan · Nov 18th 2020

Quote from captain_buck_rogers

Vibrations-API für XBox/Playstation4-Controller u.a. ansprechen.

Ginge das auch für Smartphones?

Quote from captain_buck_rogers

was meint Ihr dazu ? Oder gibt es andere Punkte die wichtiger sind ?

Ich fände es noch super, wenn man alternative Farbpaletten laden könnte.

Endurion · Nov 18th 2020

Gibt es den Emulator eigentlich auch als kleines Komplettpaket für eigenes Embedden? Ich möchte gerne einige C64-Spiele im Browser spielbar haben, und da alles, wie es sich gehört, von meinem Webspace laden.

dirkwhoffmann · Nov 18th 2020

Quote from Retrofan

Ich fände es noch super, wenn man alternative Farbpaletten laden könnte.

Das Farbmanagement von VirtualC64 ist Teil des Core-Emulators, d.h., es ist vergleichsweise einfach, in der Web-Version die gleichen Farbeinstellungen anzubieten wie in der Desktop-Version.

captain_buck_rogers: Die Farbpalette wird im 4.0er Core über die Option OPT_PALETTE konfiguriert. Zur Auswahl stehen:

Code

COLOR_PALETTE,
BLACK_WHITE_PALETTE,
PAPER_WHITE_PALETTE,
GREEN_PALETTE,
AMBER_PALETTE,
SEPIA_PALETTE

Wird die Color-Palette gewählt (was in den meisten Fällen getan wird), so werden die Farben anhand von „Brightness“, „Contrast“ und „Saturation“ berechnet. Die Swift-API macht in der Desktop-Version das Folgende:

Die gleichen Funktionen können in der Web-Version in JavaScript aufgerufen werden.

Code

var palette: Int {
get { return c64.getConfig(OPT_PALETTE) }
set { c64.configure(OPT_PALETTE, value: newValue) }
}
var brightness: Double {
get { return c64.vic.brightness() }
set { c64.vic.setBrightness(newValue) }
}
var contrast: Double {
get { return c64.vic.contrast() }
set { c64.vic.setContrast(newValue) }
}
var saturation: Double {
get { c64.vic.saturation() }
set { c64.vic.setSaturation(newValue) }
}

Display More

captain_buck_rogers · Nov 18th 2020

Quote from Retrofan

Quote from captain_buck_rogers

Vibrations-API für XBox/Playstation4-Controller u.a. ansprechen.

Ginge das auch für Smartphones?

Retrofan

ich hab derzeit drei APIs für Vibration gefunden ... falls noch jemand weitere findet immer her damit ...

1.API: ein Vibrieren des Host-Gerätes auf dem vc64web ausgeführt wird ...

https://developer.mozilla.org/…ocs/Web/API/Vibration_API

oder https://w3c.github.io/vibration/

2.API: GameController Vibration bei Firefox

https://developer.mozilla.org/…API/GamepadHapticActuator

3.API: GameController Vibration bei Chrome

https://gamepad-tester.com/for-developers

mein XBoxController vibriert am Mac unter Chrome auf der Seite https://gamepad-tester.com/ ... siehe auch das angehängte Bild ... probiere mal mit dem MFI aus ...

Der Plan ist wir würden aus Javascript den VIC II bei der Emulation jedes Frame abfragen ob es Collisionen Sprite zu Sprite oder Sprite zu Grafik gibt, wenn die Kollisionsmuster feststehen, würde man dann irgendwie einfach per Dialog oder so diese dem Benutzer sichtbar machen ... er kann sich dann einfach anhaken (Checkbox) auf welche Art von Kollision er für dieses Spiel eine Vibration haben möchte ... das Ergebnis der Konfiguration würd vc64web sich dann in seiner Datenbank für den jeweiligen Spieletitel merken ...

Das Spiel läuft dann an und der Benutzer spielt ... wenn jetzt vc64web ein Kollisionsmuster, welches der Benutzer ausgewählt hat (z.B. Sprite1 kollidiert mit Sprite5) detektiert, dann befeuert es einfach alle drei APIs zugleich mit dem Vibrations/Rumble Kommando ...

Da APIS sind noch ziemlich frisch und leading-edge. Safari z.B. kann glaub ich erst seit der letzten Version GamePads überhaupt erkennen ... wenn später in ein paar Monaten ... Jahren alle andern Browser hinterherziehen oder sich alle auf einen gemeinsamen Standard seitens der w3c geeinigt haben, dann füge ich deren BAPI efeurerung einfach hinzu ...

wegen der Farbpaletten frag ich mal Dirk ...

captain_buck_rogers · Nov 18th 2020

Quote from Endurion

Gibt es den Emulator eigentlich auch als kleines Komplettpaket für eigenes Embedden? Ich möchte gerne einige C64-Spiele im Browser spielbar haben, und da alles, wie es sich gehört, von meinem Webspace laden.

da gibt es verschiedene Ansätze ...

wenn du dein Spiel von deinem WebSpace zur Verfügung stellen willst, dann kannst du einfach auf den vc64web verlinken oder ihn z.B. in einem iFrame auf deiner HTML-Seite einbetten ... er ist extra mit einer sogenannten "Direktstart" Aufrufschnittstelle ausgestattet worden (direct start call interface 😎) ... du musst dieser natürlich auch die Adresse von deinem Spiel irgendwie mitgeben, damit vc64web weiß von wo er dein Spiel laden soll ... dies machst du indem du der Adresse von vc64web https://dirkwhoffmann.github.io/virtualc64web/ einfach das # Zeichen anhängst und danach die Adresse auf dein Spiel mitgibst

schau mal hier ist ein Beispiel ...

vc64web gehostet auf dirkwhoffmann.github.io lädt automatisch eine Demo per Direktstart von csdb.dk ...

https://dirkwhoffmann.github.i…p/205280/gp_quadrants.prg

vc64web versucht dann das C64er Programm nachdem er gestartet ist zu laden und auch automatisch zu starten (es geht auch .zip, .d64, .crt, etc... eine Endung ist jedoch wichtig anhand der Endung weiß vc64web wie er die Datei mounten soll)

Damit die Browser-Polizei "ja ... ok ... du darfst durch ..." sagt, muss der Webserver der dein Spiel zur Verfügung stellt der origin: https://dirkwhoffmann.github.io/ auch das CORS im Response-Header freigeben. Also der webserver der den fetch request auf deine Spieledatei beantwortet muss entweder den http-response header auf "Access-Control-Allow-Origin: *" oder "Access-Control-Allow-Origin: https://dirkwhoffmann.github.io/" setzen, damit die Browser-Polizei in dem Browser in dem vc64web läuft diesem erlaubt das Spiel zu laden.

Falls du das nicht hinkriegst kannst du auch das kostenlose github pages verwenden, die CORS für alle gh-pages gehosteten freigibt ...

Ansonsten kannst du dein Spiel natürlich auch auf die Szene-Seite csdb.dk hochladen. Diese erlaubt vc64web ebenfalls der origin dirkwhoffmann.github.io das CORS.

Als Alternative kannst du aber auch deinen eigenen vc64web bauen und auf deinem Webserver deployen, dazu musst du den Quellcode von https://github.com/dirkwhoffmann/virtualc64web laden und das Projekt selber builden ... die Anleitung dazu steht auf der Projektseite ... in diesem Falle brauchst du dich um CORS gar nicht zu kümmern, da die Browser-Polizei nicht aktiv wird, weil die Anfragen vom selben Webserver kommen von dem vc64web geladen wurde ... der sogenannte Same-Site-Policy Reisepass ...

Retrofan · Nov 19th 2020

Quote from captain_buck_rogers

ich hab derzeit drei APIs für Vibration gefunden ... falls noch jemand weitere findet immer her damit ... [...]
Da APIS sind noch ziemlich frisch und leading-edge. [...] wenn später in ein paar Monaten ... Jahren alle andern Browser hinterherziehen oder sich alle auf einen gemeinsamen Standard seitens der w3c geeinigt haben, dann füge ich deren BAPI efeurerung einfach hinzu ...

Ich habe auch erstmal keine weiteren gefunden.

Quote from captain_buck_rogers

mein XBoxController vibriert am Mac unter Chrome auf der Seite https://gamepad-tester.com/ ... siehe auch das angehängte Bild ... probiere mal mit dem MFI aus ...

Habe ich. Allerdings wäre ich verwundert gewesen, wenn da was vibriert hätte, denn meines Wissens hat mein MFI-Controller kein "Rumble" eingebaut. Von daher: Die Analogsticks wurden korrekt ausgewertet aber die Seite meinte auch, da gäbe es nichts zu vibrieren.

Snoopy · Nov 19th 2020

Quote from Retrofan

Quote from Snoopy

... oder Drittens: Wir verwenden Firefox oder Chrome ...

Firefox, der nach deiner Statistik einen noch geringeren Marktanteil hat als Safari? Ich weiß nicht – nur weil da speziell dieser Bug nicht auftritt, auf so einen Exoten setzen?

Ich habe mir mal die Browser-Anteile auf Netmarketshare angesehen: Über alle Systeme hinweg (Mobile wie Desktop) ergibt sich weltweit folgende Verteilung – Chrome: 66%, Safari 18%, Edge 4%, Firefox 3% (jeweils gerundet). Welche 2 Browser sollte man also unterstützen, wenn man möglichst viele Leute erreichen will?

Solange Firefox alles macht, wie es sein soll, kann man den auch mit 0,1% Marktanteil gut verwenden. Es geht ja.

Mein Tipp wäre: Beim Entwicklen würde ich mich ausschließlich auf Chrome konzentrieren. Sonst "verrennt" man sich leicht und "verliert" Zeit für Bugfixes, die für die breite Maße keine große Relevanz haben. Lieber erstmal mit Chrome auf die Kernfunktionen konzentrieren. Und falls die auf irgendwelchen anderen Browsern Probleme machen, dann kann man das immer noch später mal angehen, wenn einem mal "ganz langweilig" sein sollte.

Retrofan · Nov 19th 2020

Quote from Snoopy

Mein Tipp wäre: Beim Entwicklen würde ich mich ausschließlich auf Chrome konzentrieren. Sonst "verrennt" man sich leicht und "verliert" Zeit für Bugfixes, die für die breite Maße keine große Relevanz haben.

Erst einmal sind knapp 1/5 der User keine Kleinigkeit, sondern durchaus relevant (im Gegensatz zum FF-Marktanteil). Und dann habe ich das immer so gemacht (ich mache Webdesign ja nun auch schon seit – es das Web gibt), dass ich mich am schwächsten Browser, den ich unterstützen wollte – also jahrelang den Internet Explorer – grob orientiert habe, weil es umgekehrt unendlich aufwending/teuer war, Sachen nachträglich noch auf IE zum Laufen zu bekommen. Den Browser, den rund 2/3 der User verwenden (Chrome), muss man natürlich perfekt unterstützen aber man sollte dabei schon nach links und rechts gucken. Ich denke, unser "Captain Rogers" wird es schon richtig machen.

Snoopy · Nov 19th 2020

Quote from Retrofan

Erst einmal sind knapp 1/5 der User keine Kleinigkeit ...

... die sich alle kostenlos Chrome oder Chromium oder Iron als Browser installieren können.

Klar kann das jeder Webentwickler so machen, wie er es möchte.

Bei mir gibt es als Entwickler die zwei Varianten:

- falls mir jemand den Auftrag gibt und mich dafür bezahlt, dann wird das Projekt an exakt den Browser angepasst, den der Auftraggeber wünscht. Und wenn es der selbstentwickelte Browser des Dr. Xaver Müller aus Timbuktu sein sollte. Ist mir dann egal.

- falls ich kein Geld dafür bekomme, sondern ich das unentgeltlich in meiner Freizeit mache: Da suche ich mir den Browser meiner Wahl aus und wer was anderes haben will: Pech gehabt, solange man sich nicht den geeigneten Browser dafür installieren möchte.

Aber ich bin mir - genau wie du - sicher, dass captain_buck_rogers das auch weiterhin so gut macht, wie bisher.

Retrofan · Nov 19th 2020

Quote from Snoopy

... die sich alle kostenlos Chrome oder Chromium oder Iron als Browser installieren können.

was sie aber nicht tun wollen oder werden, nur um Drag&Drop in einem einzigen Emulator im Web genießen zu können. Wie gesagt, tolle Zusatzfunktion – aber ich komme auch ohne zurecht und bleibe erstmal bei meinem Default-Browser (obwohl ich alle anderen natürlich auch installiert habe).

ZeHa · Nov 19th 2020

Fairerweise muss man hier anmerken dass es ein Unterschied ist, ob es um ne Website geht, die potentiell jeder sehen können soll, oder obs um ne spezielle Web-Applikation für Enthusiasten geht, die bereit sind für ihren Enthusiasmus auch mal nen speziellen Browser installieren, um diese Applikation nutzen zu können.

Ihr habt folglich beide so n bisschen recht, aber es ist definitiv kein normales Website-Design worum es hier geht.

captain_buck_rogers · Nov 19th 2020

Retrofan Snoopy ZeHa

ihr habt eigentlich alles schon gesagt und jeder liegt mit seiner Argumentation vollkommenen richtig ...

Dann sag ich jetzt auch mal was dazu ...

Bei dem HTML5-UI Wrapper (Benutzeroberfläche von vc64web) zum Core-Emulator habe ich versucht darauf zu achten, dass nur die modernsten APIs verwendet werden ... Da wo es teilweise eine alte API und neue API gab, habe ich vorzugsweise die moderne API zu verwendet... Ich habe also nie versucht möglichst viele und auch "alte" Webbrowser "onzuboarden" ... mit der Konsequenz, dass alte Browserinstallationen ... alles vor 2015 ... gar nichts mit vc64web anfangen können

Das Thema Web-Browser beobachte ich schon seit langer Zeit ... seit Netscape2.0 Gold Edition und AWeb (Amiga-Webbrowser) 😍

Wie den Älteren von Euch längst bekannt ist, haben wir hier bei den modernen Webbrowsern tatsächlich eine ganz andere Situation ... so stellt es sich mir jedenfalls dar ... als noch vor 10 -20 Jahren ... wo die Browser wesentlich bezüglich API und Verhalten und Darstellung und teilweise völlig voneinander abgewichen sind ... und man teilweise zwei verschiedene Apps bauen musste 🙄 oder Kompatibilitätsschichten einbauen musste, etc., etc. ...

Beim Thema API und Darstellung konvergieren die Browser heutzutage viel schneller auf eine gemeinsame Linie ... (der letzte Dinosaurier "Internet Explorer/Edge" wurde ja glücklicherweise durch eine Chromiumvariante ersetzt, diesen Schachzug macht Microsoft beim Windowskernal vielleicht auch bald ... und wir bekommen ein Linuxunterbau mit einer Wine/WinAPI-Schicht obendrauf ).

Dadurch nun, dass alles viel schneller auf eine gemeinsame Linie konvergiert, sollte es eigentlich egal sein ... wenn ein Feature von vc64web auf einem bestimmten der verbleibenden drei modernen Browser nicht geht, dann kann man davon ausgehen, dass es in Zukunft schon laufen wird ... natürlich sollten die wesentlichen Sachen laufen ... (aber da bin ich auch bei Retrofan, das Drag and Drop nicht unbedingt eines ist dieser wesentlichen Punkte ist) ...

Insgesamt habe ich immer darauf geachtet, dass alle Features auf allen drei verbleibenen modernen Browsern laufen. D.h. Chrome, Safari und Firefox.

Tatsächlich sind mir bisher nur vier Punkte aufgefallen, bei denen es nicht so richtig läuft. Alle vier sind meiner Einschätzung nicht wesentlich ...

1. Pixelart geht bei Safari nur wenn zugleich die Hardwarebeschleuning/WEBGL unter vc64web->Settings abgeschaltet wird. Da Safari kein CSS auf beschleunigten WebGL Kontext anwendet (wegen Metal??)

2. drag and drop von CSDB-Downloadlinks gehen bei Safari nicht, Releaselinks können aber aus der CSDb.dk heraus gerdroppt werden

3. manchmal stürzt der Safari hart ab, wenn man einen verbundenen physikalischen Joystick rauszieht ...

4. bei Safari und Chrome muss man um den C64-SID-Sound zu aktivieren erstmal in den Emulator reinklicken bzw. touchen

Mhh tja alle vier Punkte bei Safari ... die Safari Entwicklungs-Abteilung könnte ein bisschen mehr Entwickler/Kohle zugewiesen bekommen... die ganz Kohle ist in den letzten Jahren anscheinend nur in den M1 gegangen ... den ich super finde ... ich finde auch die vertikale Integration von Apple ziemlich mutig und richtig gut ... (ein bisschen so wie früher bei Commodore) ...

Warum sollte uns aber die Unterstützung von Safari (insbesondere der mobile Safari für vc64web) sehr wichtig sein?

1. es gibt keine Emulatoren im iOS Appstore, dafür gehen aber PWAs (progressive web apps) die fast nativ wirken wie vc64web ...

2. iOS hat eine hohe Verbreitung gerade bei Tablets und die Kisten sind super schnell (Prozessormäßig ca. zwei Jahre Vorschprung gegenüber Qualcomm denke ich ... siehe Geekbench-Ergebnisse)

3. Unter iOS/iPadOS gibt es zwar auch Firefox/Chrome, aber die sind dazu verdonnert die Safari-Rendering-Engine WKWebkitView im Unterbau zu verwenden.

4. ich habe auf meiner Entwicklungsmaschine einen 13 Jahre altem MacBookPro2007 2.2Ghz neben Firefox und Chrome einen Safari 11 aus 2016 (höher geht nicht, weil der Safari nur mit dem OS-Update daher kommt und ich nach 9 Jahren in 2016 aus dem Support rausgefallen bin😔)...

* auf Safari (aus 2016) läuft vc64web mit sagenhaften 60FPS ... aber einige Features gehen nicht ...

* Firefox kommt auf 56FPS

* Chrome nur auf 26FPS

* Safari mobil auf einem iPhone 6s Plus aus 2015 kommt auf 60FPS

d.h. für mich stellt sich das so dar

FAZIT:

* Chrome hat die beste API und Entwickler Unterstützung (macht richtig Spaß), ist aber viel lahmer bei WASM als Firefox und Safari (spielt bei modernen Maschinen sicherlich keine sehr große Rolle ...)

* Safari hat die Performance-Krone, aber einige (nicht wesentliche) Features gehen noch nicht so

* Firefox ist so das Mittelding, Performance sehr gut und API-Unterstützung auch LeadingEdge

Ich denke, daher ist es für uns wichtig, Snoopy (ja ich weiß die Entwicklungs-Aufwände sind höher😔 ) dass vc64web auf allen drei modernen Browsern gut laufen muss.

Euer Captain Buck Rogers

Snoopy · Nov 19th 2020

Quote from captain_buck_rogers

Ich denke, daher ist es für uns wichtig, Snoopy (ja ich weiß die Entwicklungs-Aufwände sind höher😔 ) dass vc64web auf allen drei modernen Browsern gut laufen muss.

Von meiner Seite aus gibt es hierzu keine Einwände.

Wenn du eh beim Bugfixen bist, auf meinem alten Lynx-Browser bockt vc64web manchmal bisschen rum, wenn ich die ROMs laden will.

captain_buck_rogers · Nov 19th 2020

Ein Kumpel von mir meint ich soll dir sagen, er kennt da jemand dem seine Schwester hat sone Uhr und dass du vc64web auf die Apple-Watch portieren sollst 😂

LightSide · Nov 20th 2020

Mal eine Frage, das Nutzen von .d64 die auf anderen beliebigen Hosts liegen geht nicht, oder? Denke da z.B. an GB64 usw.?

captain_buck_rogers · Nov 20th 2020

LightSide warte ich schau mal nach ...

hmm auf http://www.gamebase64.com sind nur ftp links .... das könnte echt schweren Ärger mit der Browserpolizei geben 😬

eh komm egal ... lass mal einen ActionButton mit Benutzerdefiniertem-Javascript in vc64web schreiben ...

der erste mit // auskommentierte Link ging übrigens ... aber der war ja auch https (will die Polizei immer sehen) ...

ich hab jetzt mal den ftp Link von gb64 aktiviert

so soll ich drücken ? 🙈

ich drück 3...2...1..

🔥

Error: failed to fetch

in der Browserkonsole steht ...

Code

vc64_browser.js:975 Fetch API cannot load ftp://8bitfiles.net/gamebase_64/Games/c1/CHOPLI-E_01459_02.zip. URL scheme must be "http" or "https" for CORS request.

vielleicht eine andere Seite wie z.B. https://c64games.de ?

da ist der Link so..

https://www.c64games.de/hugo.p…ges=/c/choplifter_crt.zip

oh das Protokoll stimmt 😍 sogar https ... super sicher !! Das müsste der Browser-Polizei gefallen ...

ok ich drück jetzt drauf oder ?

los jetzt ...

Autsch

😬

Code

Access to fetch at 'https://www.c64games.de/hugo.php?art=c&fil=35&cartridges=/c/choplifter_crt.zip' from origin 'http://daniels-mini-3.fritz.box:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Boahh die blockieren uns ... die Browser-Polizei sagt nein ... und meint die Response von c64games soll uns Access-Controll-Allow-Origin in der Antwort setzten... so gemein ... das mit dem opaque == leer response ist Quatsch was die vorschlagen ContentLenght==0

aber Moment da gibt es ein PlugIn in Chrome und Firefox ... namens Allow CORS ... https://mybrowseraddon.com/access-control-allow-origin.html

damit kann man für die Polizei einen falschen Pass ausstellen ... naja ... so ähnlich das PlugIn schreibt nämlich in die Response von c64games.de einfach den fehlenden Access-Control-Allow-Origin header rein ...

mal probieren ob es damit geht

3....2....1

ja damit geht es ... keine Protokoll-hopsereien schönes sicheres https und ein mit dem Plugin selbstgedruckter Pass ...

man könnte also drag and drop von c64games.de machen, wenn entweder der Betreiber der Seite CORS für alle oder unsere Origin setzt (also einen echten Pass setzt) ... oder man das Plugin im Browser aktiviert... das war bei der csdb.dk auch so die haben uns auch den echten Pass in den Header reingesetzt...

hier der funktionierende Code des ActionButtons zum selber ausprobieren ... falls jemand Lust dazu hat

Code

js:
//var parameter_link="https://csdb.dk/getinternalfile.php/133476/Uncensored.zip";
//var parameter_link="ftp://8bitfiles.net/gamebase_64/Games/c1/CHOPLI-E_01459_02.zip";
var parameter_link="https://www.c64games.de/hugo.php?art=c&fil=35&cartridges=/c/choplifter_crt.zip";
get_data_collector("csdb").run_link("call_interface", 0 ,parameter_link);

captain_buck_rogers · Nov 20th 2020

Quote from LightSide

Mal eine Frage, das Nutzen von .d64 die auf anderen beliebigen Hosts liegen geht nicht, oder? Denke da z.B. an GB64 usw.?

LightSide also zusammengefasst ... siehe Post oben ... beliebiger Host ja aber zwei Bedingungen müssen erfüllt sein ...

1. https

2.der Header 'Access-Control-Allow-Origin' in der https-Response muss für CORS (cross origin resource sharing) gesetzt sein... (oder halt mit dem Allow CORS-Plugin ... wie oben im vorherigen Post beschrieben)

ist der Moderator von c64games.de auch hier im Forum unterwegs ? dann könnte man ihn ja mal fragen ober er uns den den Header reinklebt... weiß jemand was über ihn ... heißt auch snoopy, steht auf der Seite c64games.de ... ist aber nicht unser Snoopy hier oder ?

Tags