Posts by GoDot

    Quote

    Original von natac64
    Bin gestern schon auf xRay gestoßen, aber keine der Links (unteranderem die offizielle Homepage) haben mehr funkioniert.


    Auf der GoDot-Homepage ist ein funktionierender Link dorthin (unter News). Das einzige mir bekannte Windows-Programm, das JPG nach C64 wandelt ist ConGo (auch erreichbar von der GoDot-Page, im Eingangbildschirm).


    Arndt

    Wie Hucky schon sagt: Mit GoDot konvertierst du JPGs auf dem C64 nach IFLI. Du brauchst dafür eine REU und natürlich die entsprechenden GoDot-Module (von der GoDot-Support-Page, Link siehe unten) plus das an GoDot angepasste JPZ-Programm von Steve Judd und Adrian Gonzalez (Schöne Screenshots hier). Vorteil von GoDot gegenüber XRay: Du kannst dir ein Bild sofort in IFLI anschauen. Nachteil: GoDot skaliert nicht, sondern du musst Ausschnitte laden bzw. die Bilder müssen gleich 296x200 groß sein. GoDot kann das JPG speichern als FunpaintII, als Gunpaint oder als XRay (was einen eigenen IFLI-Viewer enthält, du brauchst dann kein Anzeigeprogramm auf dem C64). Noch'n Vorteil von GoDot: Du kannst das Bild damit bearbeiten (bevor du es speicherst). In FLI kannst du es auch speichern, hätt ich fast vergessen... Sogar in Koala, wenn du das willst. :D


    Tja. Ach ja, hier ein Beispiel (Tecm0! Weggucken!) 8)


    Quote

    Original von mayhem
    Habe mich nun für den IFLI Mode entschieden und auch schon ein Bild konventiert. Bei google keine code schnipsel gefunden, wie ich mein Interface nun laden kann...


    Du kannst mit GoDot und dem Saver svr.XRay64 beliebige Grafiken nach IFLI wandeln und sie ohne weitere Vorkehrung auf dem C64 in IFLI anschauen (kein Programm erforderlich). Wenn dir die Ergebnisse dann gefallen, savest du sie in einem zweiten Durchgang als FunPaint2 ab (die sind gepackt) oder wandelst sie einfach in Multi (was mit GoDot meist gut gelingt) und brauchst dir über Timing usw. keine Köpfe mehr zu machen...


    Arndt

    Quote

    Original von Hucky
    GoDot !!


    Super Programm wenn man erstmal durchgeblickt hat...


    Und unten in meiner Signatur ist auch der Link dahin... ;)


    Arndt

    Quote

    Original von maxandmolly
    Und auf dieser Seite gibt es das eine oder andere was ich sonst noch nicht so in einer Zusammenstellung gefunden hatte.


    Zum Beispiel die allerälteste Version von GoDot (die, die damals in der 64'er Programm des Monats war). Muss sagen, die find ich inzwischen beinahe peinlich... ;)


    Was nicht da zu finden war, ist der Basic Boss (Compiler). Geiles Teil. Weiß einer, wo's den gibt?


    Arndt

    Quote

    Original von Retrofan
    Mit meinem Verfahren sieht das folgendermaßen aus:


    Super! Bei dir ist die volle Auflösung erhalten geblieben, da wird der Effekt natürlich voll sichtbar. Scheint der ideale Weg für IFLIs zu sein, nicht nur für Anaglyphenbilder. Wie kriegst du die beiden Halbbilder getrennt? Per Zufall? Oder gibt's da eine eingebaute VICE-Funktion, die keiner kennt? Mit welcher Palette arbeitest du?


    Arndt

    Quote

    Original von sauhund
    1) sieht das als gif exportierte bild unter umständen anders ... aus


    Dann hab ich noch diesen Vorschlag. Ich hab unter GoDot einen Saver geschrieben, der den Farbeindruck, den IFLI macht, am originalgetreusten rüberbringen sollte, nämlich den Saver svr.PCX-VGA. Der wandelt die IFLI-Farbkombinationen (je ein Doppelpixel aus den beiden Halbbildern) um in eine der 136 IFLI-Farben (basierend auf der GoDot-Palette). Das Ergebnis kommt dem C64-Eindruck wirklich nahe, hat aber den Nachteil, dass es nur eine Auflösung von 160x200 hat. Vielleicht hilft dir das aber. Hier das Bild mit svr.PCX-VGA gespeichert (und auf dem PC nach JPG konvertiert, Tecm0) :



    Arndt


    PS: Das Bild ist aus Huckys Willow-Demo. Es ist ein Anaglyphen-Bild. ;-)

    Quote

    Original von bugjam
    zu 2): ...genau das ist das Problem. Es geht um ein uraltes Compopic von mir, das ich nur noch als prg greifbar habe und den Screenshot auf csdb hochladen will.


    Hm, da wäre noch GangEd, mit dem kann man die Teile, aus denen das Bild besteht (als die einzelnen RAM-Bereiche), die du vielleicht nach einem Freeze abgespeichert hast, wieder zu einem fertigen Bild zusammensetzen und dann als JPG oder BMP abspeichern. Der Link zu GangEd ist gerade auf http://www.c64.sk ganz oben (also frisch).


    Arndt

    In diesem Zusammenhang sicher interessant ist, was Todd Elliott mit der SuperCPU rausgetüftelt hat. Hier sein Artikel über FLI und über Fullscreen-FLI auf der SuperCPU im Besonderen:


    Commodore Currents #1


    Arndt

    Quote

    Original von Hucky
    Aber ich denke es lag mit daran, dass die Compo erst um 3.00 Uhr anfing anstelle 0 Uhr und mein Beitrag einfach "vergessen" wurde.


    Dann haben sie eine Weltpremiere verpennt... Da sind sie direkt da, wo die Zeit den Atem anhält, und haben es nicht gesehen. Echt tragisch. :(


    Arndt

    Quote

    Original von tecM0
    zufallszahlen waren aber geklärt.


    Genau lesen! Was sagte ich? "...zur Vollständigkeit die Methode..."


    Quote

    und wie bekomme ich jetzt eine 16bit zahl dezimal auf den screen?


    Highbyte im Akku, Lowbyte in x:


    sta $62
    stx $63 ; (!)
    ldx #$90
    sec
    jsr $bc49
    jsr $bddf


    Ergebhis liegt an $0100 und sollte mit $00 enden (bin nicht mehr sicher, so aus dem hohlen Kopf...)


    Arndt

    Quote

    Original von alectronix
    1.) Wie kann ich eine Zufallszahl zwischen $00 und $FF erzeugen?


    Auch, wenn manche das nicht hinkriegen, hier zur Vollständigkeit die Methode mit dem SID-Rauschen wie GoDot das macht (und da funktioniert's, es wird damit das Noise-Dithering erzeugt):


    lda #$80
    sta $d418 ; Filter aus
    sta $d40e
    sta $d40f ; Oszillator 3 vorbesetzen
    lda #0
    sta $d412 ; Wellenform aus, Steuerbits aus
    lda #$81
    sta $d412 ; Rauschen an, KEY-Bit an (Lautstärke aktivieren)


    Später holst du dir dann deinen Bytewert aus dem Register $d41b (das ist das Rauschen-Register des Oszillator 3).


    lda $d41b ; Zufallswert


    Wie gesagt, in GoDot funktioniert das, wie jeder sich überzeugen kann (irgendein buntes Bild sollte im Speicher sein):


    Im Fenster "Screen Controls" zuerst von "Multi" auf "Hires" umschalten, dann die Anzahl Farben im Gadget darunter auf 2 einstellen ("Colors: 2"). Zum Einstellen des Ditherings danach im Fenster "Color Controls" zweimal ins Gadget "Dith" klicken (auf der linken Seite) bis "Noise" erscheint. Und schließlich Rendern über das Gadget "Palette". Dort "Default" einstellen (damit die Farben schwarz und weiß verwendet werden) und mit dem Display-Button das auf Rauschen umgerechnete Bild anzeigen. Die Grundeinstellung des Rauschens ist sehr grob, wenn du mehr erkennen können willst, erhöhst du unter "Balancing"den Kontrast auf 5 oder noch viel mehr.


    Arndt

    Quote

    Original von sauhund
    äh ja, die frage war eigentlich was du gegen selbstmodifizierenden code hast... denn wie du ja schon sagst soll godot ja nicht ausm rom laufen (was ein grund dagegen wäre).


    Selbstmodifizierender Code ist wie als wenn ich mir die Nase abbeißen muss, damit mein Kopf durchs Bullauge passt, nur damit ich die schöne Aussicht auf meinem Dampfer genießen kann. ;)


    GoDot läuft schon aus dem ROM, aber wer packt schon (nicht mal) 4 KB in ein ROM, das hinterher weitere 16 KB nachlädt... (Kernel von $800 bis $1fff, nachgeladen - abhängig vom INI-File - wird der Lader $c000, der Saver $d000, der Modifier $e000 und die Renderroutinen $f000, wenn REU angeschlossen ist, noch die REU-Routinen, in die REU). Das lohnt sich nicht. Im Betrieb läuft alles Modulare (also alles außer dem Kernel) an $c000 ab, es wird also ständig umgeschichtet. Selbst die Daten für die Grafikanzeige sind im System verteilt (die Farben).


    Was anderes: Hoogo, du solltest Sauhund deinen Avatar abgeben... ;)


    Arndt

    Quote

    Original von hoogo
    Ganz ganz selten gehts sogar nicht ohne. Nur meine Meinung dazu.


    Darum sind Selbstmodifikationen ja auch ein paarmal in GoDot zu finden (z.B. im Test, welche Peripherie angeschlossen ist, im mod..FileCopy und wo noch...? Ah ja, in der REU-Unterstützung muss am GoDot-Kernel gepatcht werden).


    @Sauhund:

    Quote

    vom rom soll godot doch nicht laufen, oder was gibts sonst noch für gründe die dagegen sprechen?


    Das liegt nicht an selbstmodifizierendem Code, sondern daran, dass GoDot das ganze System dauernd ummodifiziert (ist halt modular, das Ganze, selbst während des Betriebs). Ein GoDot auf Eprom ist wie eine Sahnetorte im Kino, völlig nutzlos und daneben.


    Arndt