Posts by Mr Crayfish

    Dann stimmt etwas mit deine Zeitmessung nicht.

    Seufz. Hier sind aber auch Sturköpfe, weil Programmierer, unterwegs. ;) Ich werde 'mal beide Compilate bzw. Spiele eines Blitz v1 und dann noch 'mal eines Blitz v2 von c64-online.com anhängen. Dann kann jeder den

    Geschwindikeitsunteschied sehen und messen, und glaubt mir eindlich.

    Ich schätze mal, dass du eine Austro-Comp Version getestet hast, den dazu würden auch die von dir gemesenen Werte passen.

    Nein, das sind eben nicht nicht die Werte des normalen Austro-Comp. . Die Mess-Werte des Austro Comp stehen in Post #7 und sind nochmal um weitere ca. 2 Sekunden langsamer.

    Vlt. erstmal den Thread lesen und studieren, bitte, bevor man sowas postet. Sorry, aber so langsam verliere ich die Geduld.

    Messergebnisse vom Redblitz64 sind nun auch da, die Werte sind immer so +-10ms genau (mit meiner Handy-Stoppuhr) reproduzierbar:


    a) Mit dem RedBlitz Compiler komme ich auf 11,23 Sek .

    b) Mit dem Blitz! Compiler komme ich auf 17,72 Sek. .

    Zeile b) sollte natürlich, wie in a), auch "RedBlitz" heissen, nicht "Blitz!". Denn darin, in dem Post, ging es ja um Messwerte mit dem Redblitz Compilat und keine anderen.

    Kleine Tippfehler-Korrektur am Rande, um die geht's aber gerade gar nicht. Nur falls das sonst verwirrend zu lesen gewesen sein sollte.

    Deine Blitz-Compiler v1-v3. Diese habe ich bei v2 defreezed und bei v3 decruched. Alle 3 Versionen sind untereinander völlig identisch

    Keiner versteht wasd ich hier schreibe.
    Dass die identisch waren, in meinen Zeitmessungen, habe ich ja auch schon ganz weit am "Anfang" im Thread festgestellt. Die kommen alle auf (die Werte in Post #7):

    a) Mit dem Blitz! Compiler komme ich auf 13,30 Sek. .

    b) Mit dem Blitz! Compiler komme ich auf 20,60 Sek. .


    Sie (die in meinem Anhang) sind aber eben nicht identisch schnell mit dem Blitz! v2 aus c64-online.com, Reblitz64, Sauron - Blitz, Austrospeed, mit denen ich auf diese Werte komme:

    a) Mit allen derer vier genannten komme ich auf 11,23 Sek .

    b) Mit allen derer vier genannten komme ich auf 17,72 Sek. .


    [Was ich da stoppe, steht ja schon in Post #7, nur falls jmd. gerade neu in den Thread einsteigen sollte.]



    Irgendetwas muss also anders laufen, und sei es erst beim Ausführen des Compilats. Da ja ggf. irgendwas mit den Variablen, wie schon von user 1570 in Post#19 als eine Änderung in bestimmten Versionen von Blitz! geäußert,

    anders gemacht wird. Und daher beim zweiten a) + b) Beispiel schneller darauf zugegriffen oder ausgelesen werden kann = alles was mit Var.-Werteveränderungen, wie Spritebewegungen X + Y Achse, zu tun hat schneller abläuft.

    Nur eine Vermutung.

    Hört sich auf jeden Fall interressant an.

    Komplex ist es nicht übermäßig (aber in der Gesamtheit mit allem Text und allen Optionsmöglichkeiten durchaus genügend) und "nur" für 2 Spieler. Wird aber sicher ein paar Fans haben, die das Spiel ganz witzig (und sympathisch)

    finden werden. Plus: Ist "open source", weil der Basic-Sourcecode liegt dem .d64 image mit dabei (also nicht nur das Compilat) ;) .

    was ist das für ein Spiel "Virtual Space War" bei Deinen Screenshots bzw. wo findet man es?

    Das werde ich die nächsten Tage auf csdb 'mal hochladen. (Dummerweise ist gerade der account abgelaufen, der genau für sowas an doch schon relativem Qualitätsspiel gedacht war. Also 'mal sehen, wie nun uppen.. .)

    Das ist von mir, schon geschrieben (Basic V2, compiliert) in 2002 + ein zusätzliches Vehikel in 2003 hinzugefügt. Seitdem hat sich das Spiel selbst nicht mehr verändert.

    Auf der letztjährigen und auf der diesjähirgen 4-Tages-DoReCo dann nur Das Ladebild (den Namen) geändert und den langen, mehrseitigen ingame Infotext hier und da (fehelde Kommata) korrigiert. Sonst ist's gleich geblieben.


    Hat bis jetzt, ohne dass er es genau weiß, nur Hucky. :) Da aber noch kompiliert mit Blitz! [v1] = eine um ein Mü "langsamere" Version des Spiels. Blitz! [v2] von c64-online.com / Reblitz64 / Austrospeed / Sauron - Blitz wäre

    jeweils nochmal um ein Mü schneller gewesen, wie ich aber nach der DoReCo erst feststellte. (Meine Blitz! [v2], die ich zwar u.a. auf der DoReCo auch schon mit dabei hatte, war faktisch noch eine ältere Blitz! Version. Auch wenn

    die optisch in allen Belangen genau identsich zu der auf c64-online.com aussieht.)

    Nimm 'mal den Blitz! Compiler von dieser schönen Seite hier: https://c64-online.com/?page_id=4454. Damit wir auch vom selben Compiler reden.

    Das ist identsich zu denen, die ich hier von skyles benutzt habe. Bedeutet: Der müsste etwas langsamer als Redblitz64, Austrospeed, und Sauron-Blitz sein.


    Also ich habe jetzt mal den Floodfiller aus Kidelyneen mit "meinem" Blitz!, dem von Mr Crayfish und Reblitz64 übersetzt...und die Resultate sind identisch (d64 hängt an).

    Der Compiler, den ich dir zum testen und vergleichen (2. Zitat, Zitat von dir) verlinkt habe (1. Zitat hier), war und ist doch nicht identisch zu meinen sonst benutzten Blitz Versionen*.

    Mit dem verlinkten Blitz! [v2] -die einzige Versionsnummer die die Seite in dem "blitz_compiler.d64" anbietet- von c64-online.com bekomme ich nämlich ebenfalls identische Ergebnisse von den bekannten schnellen eines Redblitz64,

    Saurus - Blitz, und Austrospeed:

    a) Mit allen derer vier genannten komme ich auf 11,23 Sek .

    b) Mit allen derer vier genannten komme ich auf 17,72 Sek. .


    [Was ich da stoppe, steht ja schon in Post #7, nur falls jmd. gerade neu in den Thread einsteigen sollte.]



    * Der sieht aber identisch zu meinem in v2, der ja dieselben Ergebnisse wie der v1 brachte, aus - in der Hintergrundfarbe und dem Macher Namen "skyles".

    Ist er aber innen drin dann wohl nicht.



    Damit erklärt das also nun (alles), dass du mit dem von mir verlinkten Compiler identische Compilate zum RedBlitz64 bekommst.


    Habe unten 'mal meinen in v1 + in vermeintlicher v2 + in v3 von blade runner als .zip angehängt, mit dem (v2) und denen müsstest du dann wirklich andere (= meine Ur-) Ergebnisse und checksummen des

    kreierten Compilat-Codes eines normalen Blitz! Compilers (in dann seiner Urversion) bekommen.

    Heute Abend kurz vor oder kurz nach 24 Uhr (Mitternacht) werden meine Fotos auch im Ordner "upload" sein. Ab dann kann das jmd. in die bzw. den DoReCo Ordner einorden.

    Die beiden .zip Dateien (1x Fotos, 1x Rundgangvideo*) gebe ich nämlich gleich 'nem Freund mit, der bei sich Glasfaser (=extremen 'Uploadspeed / Durchsatzrate) hat.

    Der wird das in ein paar Min. uppen können.


    Da ist im Speziellen die gestrickte grandma Brotkasten-Haube in extra bemühten Fotos dabei, ebenso gut sind vlt. die Landschaftfotos und die Großaufnahmen aller Aufkleber auf Fahrzeugen mit Commodore Bezug (etc.).


    In der Halle ohne Tagenlicht (alle Fr. Fotos aus der Halle) ist natürlich immer das Problem, bei fast jedem (auch in Videos, sofern nicht extra pur auf den Bildschirm gehalten wird), dass die Kamera sich auf die eher dunklen

    Lichtverhältnisse der Halle an sich einstellt und dadurch im Gegenzug aber die Bildschirmdarastellungen aller Monitore udn Flachbildschirme zu hell wirken (bis hin zu fast alles weiß).

    Bei Tageslicht (alle Sa. Fotos aus der Halle) in der Halle fiel und fällt sowas an ungewolltem Effekt dann natürlich weg.


    *Beim Rundgangvideo ist das timing an ein paar Stellen zumindest rein zufällig ganz witzig / gut getroffen. Z.B. komme ich genau in dem Moment zu Captain Future '75s Platz, als er gerade beim Endboss zu

    Universal Soldier (Turrican II auf SNES) ankommt, mit samt dem Abspanntext. :)

    [Nur so gleitend wackelfrei, wie Videofreaks Apparatur und ruhige Hand ist mein erstes Rundgangvideo natürlich (noch) nicht geworden. Ist eher wie von einem Roboter gehalten (aber das passt ja auch, also zur DoReCo.. ;) ).

    Auch weil die Kamera das so roboterartig etwas stabilisiert, und nicht nur weil meine Hand derart zackig roboterartig sich bewegt.]

    Solche Sachen gehen schon seit Win98 oder so...

    Früher ja, aber FTP Support bei Firefox abgeschaltet seit 2021 + Filezilla bricht Uploads ab (s.o.) + nur Probleme heutzutage (wird einem nicht einfach gemacht).

    Sagt ja selbst andi6510.


    Unter WinXP würde alles laufen, aber ab spätestens Win10 läuft nichts mehr so greifbar wie es soll. Die kicken einen von MS dann fast schon absichltich heraus, wenn man 'was uploaden will. So in der Art.

    Weil geschätzt irgendwas an tausendfach integrierten vermeintl. Schutzmaßnahmen dazwischenfunkt. So muss man sich das hautzutage vorstellen, will ich damit jetzt nur sagen.

    Echt zum k***, Lebenszeitverschwedung (da man ja z.T. Tage davorsitzt) und mehr.

    Wie geht das ? Der Windows Explorer ist doch nur ein Dateien-auf-dem-Rechner-Explore-Programm und kann keine I-Net bezogenen Adressen öffnen.

    Edit: Achso, der Internet-Explorer 11 ist gemeint, der ist neben dem Browser Edge selbst in Win10 noch immer enthalten, wie ich gerade sehe.

    Aber dann kann ich nur in den ftp hineinschauen, aber scheinbar eher nichts uploaden - oder geht das auch irgendwie ?

    Das von mir genannte Security-Zeugs, eine Anmerkung von filezilla, wäre nur das hier: "The Server does not support FTP over TLS. Your files and password will be send in clear (= visible) over the Internet."


    Jetzt läuft mein Upload aber erstmal. Mal sehen wie lange diesmal.

    Habe Fotos und das Video jetzt getrennt und je in ein eigenes .zip zum jeweiligen hochladen gepackt. Das macht das dann nun zumindest schonmal handlicher.

    Dein Upload ist heute morgen um 3:25 Uhr hängengeblieben.
    Kannst du den bitte nochmal anwerfen?

    Hatte ich noch bemerkt, dann das File gelöscht und den Upload nochjmal neu gestartet.

    In diesem Moment lade ich das File 1x komplett herunter, um zu sehen, ob es diesmal denn komplett in seiner Gesamtgröße und -Inhalt hochgeladen wurde.

    (Edit: Nee, hat wieder nicht geklappt, ist wohl nach 300MB abgebrochen. Und nun kann ich gar nichts mehr hochladen - weil Immer ein "all Transfers finished" kommt, auch nach Neubenennung des Files.)


    Bzgl. diversen secure Anmerkungen meckert filezilla auch (TLS tauglich oder nicht, und sowas), aber damit muss es ja nichts zu tun haben, da der Upload ja über Stunden durdchaus erstmal läuft.


    Beim Kollegen kann ich, wenn's sein muss, 48h am Stück 'was auf 'nen Server hochladen. Das klappt von meienr Seite also prinzipiell (das ist dann aber nicht über filezilla).

    Lade gerade auch Fotos über den filezilla client in den "upload" Ordner hoch (dauert ab jetzt noch über 10 Std. bei meinen 70KB/s .., der Provider-Vertrag gibt nicht mehr her),

    chronologisch durchnummeriert und auch die Kamerabezeichnungen stehen bei jedem Foto mit dabei. Sowie jeweils die Tagesanfänge und -enden (z.B. "_Sa start", "_Sa end").

    Knapp 3,5GB, inkl. ein ca. 1,5GB großes Rundgangvideo von Fr. Abend 22:37Uhr in einem separaten Unterordner desselben Archivs.


    [Die Hallenfotos vom Sa. am Tage mögen besser (schärfer etc.) als einige von Fr. Abend/Nacht sein, weil sie halt bei Tageslicht gemacht wurden, und damit

    eine zu lange Belichtungszeit, die bekanntlich leicht zu leichtem Verwackeln führt, wegfällt.]


    Von Anröchte und Altenmellrich (Umgebung) sind auch ein paar bzw. gar so einige Fotos mit dabei. Die habe ich 'mal mit drin gelassen, aus Gewohnheit*.

    *Denn so in dieser Art sehen alle meine Ausflugsarchive aus, wenn ich sie bei einem Kollegen hochlade.

    Kann ja auch sein, dass die Änderung erst beim Ausführen des Spiels quasi "aktiv" wird.

    Weil Variablen anders gestored werden, irgend so etwas halt. Solche Unterschiede bemerke ich selbst bei demselben Compilate (Blitz!): Dass nämlich der Spieletitelname beim allerersten Mal schneller hereinscrollen tut,

    als wenn ich im Spiel später wieder zum Titelbild zurückspringe und mir die Animation ein weiteres Mal angucke. Obwohl ich alle Variablen vorher im Programm mit CLR lösche*, so dass eigentlich wieder

    alles gleich frisch wie beim ersten Mal des Ausführens der Sektion im Code sein sollte.


    *Sofern das Compiliat das beachtet, ggf. streicht es das ja weg, weil es eh anders funktioniert und das nicht mehr braucht bzw. in Maschinensprache gar nicht als Befehlt funktioniert.



    Also ihr wisst schon *in welche Richtung ich das meine*.

    [Das Programm (Spiel) ist nunmal groß, und eben kein nur eher kleines Integer- etc. Testprogramm, wie es die anderen Programme bei solchen Tests + hier sicherlich immer sind. Was da dann im Spiel insg. vor und zurück alles abgeht,

    verlangsamt die ein oder andere Stelle dann halt (also im Vgl. zum selben Code würde man ihn / die Stelle extrahieren und nach einen Kaltstart neu bzw. pur/einzeln als Compilat ausführen).]

    Allein vom je cracker und Macher anderem Header (in der Basiczeile bei Eingabe von List) her, müsste die checksum aber ja schon anders sein.

    Und auch im Kerncode, weil die drei genannten sind nunmal wirklich schneller, als der von skyles und blade-runner.

    Im Spiel und auch schon bei simplen For..Next Schleifen, wenn der Spieletitel in Wörtern von r+l hereinscrollt, bemerkt man das sofort - dass Redblitz, Sauron und austrospeed da fixer sind.


    Nimm 'mal den Blitz! Compiler von dieser schönen Seite hier: https://c64-online.com/?page_id=4454. Damit wir auch vom selben Compiler reden.

    Das ist identsich zu denen, die ich hier von skyles benutzt habe. Bedeutet: Der müsste etwas langsamer als Redblitz64, Austrospeed, und Sauron-Blitz sein.



    Vom Spiel lade ich gff. 'mal einfach beide Compilatversionen (1x vom skyles Blitz!, 1x Sauron - Blitz / oder Austrospeed) bald [auf csdb] hoch, dann werden Ungläubige selbst nur gefühlt bemerken können,

    dass der Sauron etc. wirklich schneller ist, als der normale Blitz! es ist. Und das auch selber nachstoppen können.

    Ist aber so. Der Skyles - Blitz ist ja auch der Älteste. Irgendwas haben Sauron, Austrospeed und Redblitz in ihren Releases "gemeinsam" daran ja nunmal sicher noch verändert / "verbessert" / verschnellert. :)


    [Was mir noch auffällt: Alle Compilate (.prg) haben eine andere checksum*, bis auf der skyles blitz in v1 (blauer Hintergrund) und der skyles blitz v2 (hellroter Hintergrund). Klar, beide sind ja auch von skyles, und bis

    auf die Hintergrundfarbe hat sich bei seinen zwei releases da wohl nicht viel bis gar nichts getan. Der blitz "v3" von blade-runner (ebenfalls hellroter Hintergrund) liefert dann aber andere cheksummen im fertigen .prg Compilat, ist

    aber identisch schnell zu den anderen beiden in "v1" + "v2". *Liegt aber z.T. natürl. einfach an einem anderen Header, je cracker und "Macher", in der Sys xxxx Basiczeile - daraus ergibt sich dann jeweils natürlich eine individuelle cheksum.]


    [Was auch noch "interessant" ist: Die Dateigröße aller Compilate, minus die von dem austro compiler in der normalen Standardversion (das ja nur 102 Blocks, statt 110 Blocks hat), beträgt 27.820 Bytes.

    Bis auf das Compilat vom austrospeed, welches 27.794 Bytes groß ist, und damit also ein paar Bytes kleiner ist.

    Das kann natürlich auch an kleinerem/weniger Gesülze im Header oder sowas liegen, wenn es denn nur kleiner wäre (ist es nämlich gar nicht 'mal.. :) ).]


    Der Astrospeed und der Reblitz64 sind genau identisch schnell (beide, also auch den Austrospeed getestet mittlerweile), dann erst kommt der Blitz [v1] von skyles / von blade-runner.

    Das "etc." ganz am Ende konnte nun weg, denn mehr gibt's (bei mir) nicht von der Urversion.

    Der Sauron - Blitz ist nun ebenfalls getestet und liefert ebenfalls die exakt gleichschnellen Ergebnisse eines Austrospeed und Redblitz64.. .

    Aber das sah man ja btw. auch schon bei den Testpages von user "muffi", dass der Sauron und Austrospeed soweit dieselben Ergebnisse bringen.. .

    Schleifen zur Verzögerung sind nicht ideal. Besser wäre es, du nutzt einen Timer wie z.B. TI für das Warten. Dann passt das immer und ist nicht von irgendwelchen äußeren Umständen abhängig.

    Ja natürlich, das kam mir jetzt auch schon in den Sinn - für solche Fälle. Sind aber nur Warteschleifen in den Menües, wie schnell der "Cursor" blinktr und wie schnell er auf die nächste Einstelloption umswitcht (so etwas),

    also nicht so wild. Plus eine nach jeder Spielsession / -Ende, wenn "Time Up" is'. Den Wert in letztgenannter Schleife passe ich für schnellere Compiler noch etwas nach oben an, der Rest aber könnte auch so bleiben.

    igentlich sind die Kompilate von Reblitz64 und Blitz! exakt gleich schnell und sollten sogar binär (meist) identisch sein.


    Hast Du vielleicht Integer-Variablen im Webinterface von Reblitz64 eingetragen? Das ist nur Komfort: Blitz! wäre ebenso schnell, wenn sie direkt im Code als %-Integer-Variablen angegeben wären.

    Nein, nichts eingetragen bei Reblitz64.

    Der Astrospeed und der Reblitz64 sind genau identisch schnell (beide, also auch den Austrospeed getestet mittlerweile), dann erst kommt der Blitz [v1] von skyles / von blade-runner / etc. .. .

    Da wäre dann noch https://c1570.github.io/Reblitz64/reblitz64.html , das auf Austro/Blitz! basiert und direkt im Browser ausgeführt wird.


    Redblitz eben probiert. Ja, das compilieren damit geht gefühlt in 1/10 Sekunden und das Ergebnisfile ist alsbald automatisch im Download-Ordner vorzufinden. :)


    Messergebnisse vom Redblitz64 sind nun auch da, die Werte sind immer so +-10ms genau (mit meiner Handy-Stoppuhr) reproduzierbar:


    a) Mit dem RedBlitz Compiler komme ich auf 11,23 Sek .

    b) Mit dem Blitz! Compiler komme ich auf 17,72 Sek. .


    Der ist also schonmal nicht schlecht, der beste bisher. (Siehe Post #7 für Werte anderer Compiler.)

    Jetzt laufen die For..Next Pausenschleifen natürlich auch schneller durch = alle gewollten non-ingame Pausen im Programm sind jetzt kürzer, da ich sie ja auf die Geschwindigkeit des

    standard Blitz! Compilers [y1] feingetuned hatte. :) Müsste also diverse Werte nun um x% verlängern bzw. vergrößern.



    [Was ich da stoppe, steht ja schon in Post #7, nur falls jmd. gerade neu in den Thread einsteigen sollte.]

    Den Sauron Blitz! Compiler hatte ich scheinbar schon als in meinem File dann "Blitz Compiler [v3]", unter meinen drei Blitz Compiler"versionen", getestet.

    Sehe ich nur gerade, als ich nach dem Sauron Compiler suchte. Denn nur der hat dieses Titelbild mit "Blitz" und "by Saron".

    Negativ, meine v3 ist doch nicht von Sauron, sondern von Blade-Runner ("broke by blade runner"). Aber auch mit dem ansonsten gleichen Titelbild.

    Also doch noch 'mal den von Sauron testen, der müsste sehr gut sein.

    besten bzw. identischen Ergebnisse zum

    z.B. Blitz! von Sauron

    Das hier ist damit also auch negativ / hinfällig.. :).

    --

    Editieren bzw. löschen konnte ich nun nach nur ein paar Minuten und neuem Einloggen (daher: verlängert das Zeitlimit bitte doch 'mal..) in meinem Vorpost nichts mehr. Daher die Korrektur nun so, per Zitat.

    Redblitz eben probiert. Ja, das compilieren damit geht gefühlt in 1/10 Sekunden und das Ergebnisfile ist alsbald automatisch im Download-Ordner vorzufinden. :)


    Den Sauron Blitz! Compiler hatte ich scheinbar schon als in meinem File dann "Blitz Compiler [v3]", unter meinen drei Blitz Compiler"versionen", getestet.

    Sehe ich nur gerade, als ich nach dem Sauron Compiler suchte. Denn nur der hat dieses Titelbild mit "Blitz" und "by Saron".

    Der bingt / brachte ja bei mir jedoch keinen Vorteil zum Blitz! [v1] mit 72 Blocks von meiner o.g. 20 Jahre alten Tooldisk. Die Datei auf der Disk hat btw. dieselbe checksum wie ein aktueller download einer sogenannten Blitz! [v1]

    mit natürlich ebenfalls 72 Blocks.. . Jetzt weiß ich also, dass das auf meiner Disk wirklich v1 des Blitz! war und ist. U. bei der bleibe ich wohl auch, bringt in meinem Spiele-Programm die besten bzw. identischen Ergebnisse zum

    z.B. Blitz! von Sauron, + in dem Titlescreen von meinem Spiel steht eh schon seit 20 Jahren (= schon immer) "Blitz! Compiler" unter "used utilities:". Das macht sich am besten :).


    Aber den Austrospeed teste ich dennoch nochmal, der der evtl. identsich zum Blitz! sein soll.