schnelles farbiges Apfelmännchen

Es gibt 46 Antworten in diesem Thema, welches 2.403 mal aufgerufen wurde. Der letzte Beitrag (28. März 2025 um 21:54) ist von ivettaB.

  • Dein C code :smile:
    Du bist da sicher versierter als wir andere ?

    Ich hänge noch im Floodfill von vorhin geistig fest.

    Während mein anderer Rechner die Hintergrundgrafik hackt vom SWIV.

    Code ist nicht optimal. aber soweit schonmal...

    Mein Code verfolgt dein Video frame by frame und rechnet die Sprites weg indem er mehrere Frames durchrechnet danach wartet bis neuer Bildinhalt (alle 3 Sek) geliefert werden - dann den CUT Punkt sucht und die Bilder aneinander klebt.

    Code 115 Zeilen Python bis jetzt.

    Fazit: Kompliziert im Detail

  • Warum nur? Am Ende wirst Du die Grafik ja doch nicht auf den c64 übernehmen können, weil der c64 die Anzahl der Bitplanes gar nicht kann

  • Fürs Floodfill gibt es sicherlich wieder verschiedene Ansätze, so wie es ja auch viele verschiedene Floodfill-Algorithmen für Malprogramme gibt. Es soll schnell sein, aber es darf auch nichts von dem bunten Bereich übersehen werden. So was mache ich gern in BASIC, und erst, wenn ich den Algorithmus nicht mehr schneller machen kann, setze ich das in Asm um.

  • Ich hab zu PC (-AT) Zeiten mal ein Apfelmännchen geschrieben, in das ich etwas Arbeit investiert hab, um es schneller zu bekommen. Das hat dann z.B. Linien gezeichnet. Aber das gcc Apfelmännchen war ja eher als Compilertest gedacht und weniger zum schnellen Apfelmännchen malen.

    Aber diese Sources hab ich evtl. nur noch auf alten Disketten, für die ich gerade kein Laufwerk eingebaut hab.

  • Na aber absolut. Das ist wie gemacht für den C64. Wurde bisher wohl nicht gemacht, weil sich wohl niemand so richtig vorstellen konnte, dass das Ergebnis gut aussieht.

    Doch, Amica Paint kann das. Bitte melde dich an, um diesen Link zu sehen. zur Funktionsweise.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Fürs Floodfill gibt es sicherlich wieder verschiedene Ansätze, so wie es ja auch viele verschiedene Floodfill-Algorithmen für Malprogramme gibt. Es soll schnell sein, aber es darf auch nichts von dem bunten Bereich übersehen werden. So was mache ich gern in BASIC, und erst, wenn ich den Algorithmus nicht mehr schneller machen kann, setze ich das in Asm um.

    hast du was in Basic ?

    ich habe nur einen Dreieckfüller für mein 3d System gemacht und der war schon hart.


  • mal sehen ob cc65 das frisst - ansonsten ist es shitty den gcc will ich nicht auch noch am laptop haben....
    oh shit ... ich bin raus:

    D:\c64\cc65\samples\ColorMandel>..\..\bin\cl65 mandel2.c -o mandel2.prg

    mandel2.c:10: Fatal: Floating point type is currently unsupported

  • hast du was in Basic ?

    bin zwar nicht atomcode, aber ja, hier: Bitte melde dich an, um diesen Link zu sehen.

    So ein Floodfill arbeitet übrigens grundsätzlich anders als etwa ein Dreieck-Füll-Algorithmus. Letzteres geht rein von den Geometrie-Informationen aus, berechnet in dem umfassenden Rechteck auf dem Bildschirm für jede Zeile die äußersten Koordinaten links und rechts und zieht dann entsprechend die Linien.

    Ein Floodfill hat diese Geometrie-Informationen nicht, nur die Bitmap. Als zusammenhörend gilt (im Regelfall) was von jedem leeren Pixel in der Fläche aus gesehen, waagerecht oder senkrecht verbunden ist und auch leer ist. Versucht man auf diese Weise ein Dreieck zu füllen, indem man zuerst mit einer Linienziehroutine die Umrisse zeichnet und dann einen Floodfill darauf losläßt, kann es gerade bei spitzwinkligen Dreiecken passieren, daß der Floodfill nicht in die Ecken "reinkommt".

  • ivettaB,

    zu deinem Beitrag Bitte melde dich an, um diesen Link zu sehen.: eine Queue herzunehmen ist schon mal ganz prima; die naive Methode, alle 4 Nachbarpixel zu speichern ist allerdings speichertechnisch relativ ineffizient. Die Füllregion läuft in Form eines Diamants vom Ausgangspunkt weg, und es wird jeder Punkt am Rand im Regelfall 2x auf die Queue geworfen.

    Mein in Bitte melde dich an, um diesen Link zu sehen. gegebenes Verfahren arbeitet mit horizontalen Spännen und braucht erheblich weniger Speicher für die Queue. Mit etwa so vielen Einträgen wie der Bildschirm horizontale Pixel hat kommt man in 99,999%+ aller Fälle aus. Das BASIC Programm nimmt dazu einfach zwei Zeichenketten her, eine für x, eine für y. Mit + wird hinten angehängt, mit MID$(...,2) vorne abgeschnitten. :D

  • mc hires

    Das widerspricht sich – entweder Multicolor ODER Hires. Ich nehme an, du meinst MC Bitmap.

    MC vs. Hires, Bitmap vs. Charset.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • hast du was in Basic ?

    Ich leider nicht. Das "so was" war mehr allgemein gemeint, also dass ich Algorithmen immer erst in BASIC konzipiere. Hab mich zwar schon oft durch Pixelwüsten gehangelt, aber Füllen von völlig unregelmäßigen Flächen habe ich noch nicht gemacht. Hätte ich durchaus Lust zu, aber ich habe noch genug andere Baustellen. ^^

  • hast du was in Basic ?

    Ich leider nicht. Das "so was" war mehr allgemein gemeint, also dass ich Algorithmen immer erst in BASIC konzipiere. Hab mich zwar schon oft durch Pixelwüsten gehangelt, aber Füllen von völlig unregelmäßigen Flächen habe ich noch nicht gemacht. Hätte ich durchaus Lust zu, aber ich habe noch genug andere Baustellen. ^^

    das ist gar nicht easy das füllzeug.

    Habe mir extra den cc65 installiert weil ich am assembler gescheitert bin.... ich habe jetzt einen Triangle fillercode welcher immer funktioniert egal wie das dreieck steht solange es 3 ecken hat.


    in c wo ich mich nicht gut auskenne:

    im meinem 3d Thread am c64 habe ich ja irgendwo ein rotierendes Dreieck das weiss gefüllt wird. Das ist der Source. Das muss ich jetzt mit assembler verkleben denn ich habe schnellere Routine in Assembler (bruteforce Speedcode) aber ich habe hier probleme den übergang vom C code in den Assemblerteil...


  • mal sehen ob cc65 das frisst - ansonsten ist es shitty den gcc will ich nicht auch noch am laptop haben....
    oh shit ... ich bin raus:

    D:\c64\cc65\samples\ColorMandel>..\..\bin\cl65 mandel2.c -o mandel2.prg

    mandel2.c:10: Fatal: Floating point type is currently unsupported

    Das ist ja eben der Hauptvorteil des gcc6502. Ich hab aber irgendwo auch einen Code hier geposted, wo ich Floats mit dem cc65 gemacht hab. Ich glaub, das basierte auf ner Idee von Sauhund, wenn ich mich recht entsinne.

    Bitte melde dich an, um diesen Link zu sehen.

  • Na aber absolut. Das ist wie gemacht für den C64. Wurde bisher wohl nicht gemacht, weil sich wohl niemand so richtig vorstellen konnte, dass das Ergebnis gut aussieht.

    Doch, Amica Paint kann das. Bitte melde dich an, um diesen Link zu sehen. zur Funktionsweise.


    Arndt

    Ich check nicht worauf du hinaus willst ? FLI ?

  • ok habe anderen PC mit Win7 64bit

    Was brauche ich alles damit der gcc rennt ?

    Ich hab den ganzen Kram in einer VirtualBox mit Linux laufen. Mit Windows möcht ich mir lieber nix anfangen?