Danke Arndt ! ja das cycling habe ich gesehen - dachte nur es bezieht sich auf die 2 Paletten umschaltungen vom Atari wo ich FLI effekt antwortete ... klarer fall von überkreuzung
Beiträge von ivettaB im Thema „schnelles farbiges Apfelmännchen“
-
-
ja zuwenig ram und dann müsste ich im Bios diese virtualisierung noch freischalten
keine exe im archiv ? sicher das da ein binary drinnen ist ?
ok habe readme gelesen. jetzt weiss ich genau warum du die finger von windos lässt...
da muss ich wohl und übel das Linux raufziehen.... brrr -
ok ich suche mal den gcc6502 im Netz....
braucht sicher eine cygwin umgebung ?
-
welchen gcc soll ich denn von wo installieren / im thread steht vbcc?? und gcc6502 ... welcher denn nun ?
-
-
mc hires
Das widerspricht sich – entweder Multicolor ODER Hires. Ich nehme an, du meinst MC Bitmap.
MC vs. Hires, Bitmap vs. Charset.
stimmt - ich kanns mir nicht merken ... DANKE
-
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.
ArndtIch check nicht worauf du hinaus willst ? FLI ?
-
ok habe anderen PC mit Win7 64bit
Was brauche ich alles damit der gcc rennt ?
-
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.
Code
Alles anzeigenin python war es einfach: def fill_triangle(vertices, color): vertices.sort(key=lambda v: v[1]) # Sort vertices by y-coordinate v1, v2, v3 = vertices def interpolate(y1, y2, x1, x2, y): if y2 == y1: # Prevent division by zero return x1 return int(x1 + (x2 - x1) * (y - y1) / (y2 - y1)) # Fill upper part for y in range(v1[1], v2[1] + 1): x_start = interpolate(v1[1], v2[1], v1[0], v2[0], y) x_end = interpolate(v1[1], v3[1], v1[0], v3[0], y) pygame.draw.line(screen, color, (x_start, y), (x_end, y)) #pygame.time.wait(1) pygame.display.flip() # Fill lower part for y in range(v2[1], v3[1] + 1): x_start = interpolate(v2[1], v3[1], v2[0], v3[0], y) x_end = interpolate(v1[1], v3[1], v1[0], v3[0], y) pygame.draw.line(screen, color, (x_start, y), (x_end, y)) #pygame.time.wait(1) pygame.display.flip()in c wo ich mich nicht gut auskenne:
Code
Alles anzeigenvoid fill_triangle(FixedPoint v[3], unsigned char color) { int i; FixedPoint tmp; FixedPoint v1, v2, v3; int y, x; int x1, x2; // Sort vertices by Y for (i = 0; i < 2; ++i) { if (v[i].y > v[i + 1].y) { tmp = v[i]; v[i] = v[i + 1]; v[i + 1] = tmp; i = -1; } } v1 = v[0]; v2 = v[1]; v3 = v[2]; tgi_setcolor(color); for (y = v1.y; y <= v2.y; ++y) { if (v2.y != v1.y && y >= 0 && y < SCREEN_Y) { x1 = v1.x + ((v2.x - v1.x) * (y - v1.y)) / (v2.y - v1.y); x2 = v1.x + ((v3.x - v1.x) * (y - v1.y)) / (v3.y - v1.y); if (x1 > x2) { int t = x1; x1 = x2; x2 = t; } if (x1 < 0) x1 = 0; if (x2 >= SCREEN_X) x2 = SCREEN_X - 1; for (x = x1; x <= x2; ++x) tgi_setpixel(x, y); } } for (y = v2.y; y <= v3.y; ++y) { if (v3.y != v2.y && y >= 0 && y < SCREEN_Y) { x1 = v2.x + ((v3.x - v2.x) * (y - v2.y)) / (v3.y - v2.y); x2 = v1.x + ((v3.x - v1.x) * (y - v1.y)) / (v3.y - v1.y); if (x1 > x2) { int t = x1; x1 = x2; x2 = t; } if (x1 < 0) x1 = 0; if (x2 >= SCREEN_X) x2 = SCREEN_X - 1; for (x = x1; x <= x2; ++x) tgi_setpixel(x, y); } } }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...
-
C
Alles anzeigenso ? #include "graphics.h" #include <stdio.h> #include <limits.h> #include <stdlib.h> #include <string.h> #define WIDTH (getMaxX()+1) #define HEIGHT (getMaxY()+1) const float xCentre = -0.75; const float yCentre = +0.0; const float dxy = 0.005; // Buffer to store iteration count per pixel unsigned char iterations[200][160]; // Enough for 160x200 mode unsigned char visited[200][160]; // Floodfill marker // Simple queue structure for floodfill #define QUEUE_SIZE (WIDTH * HEIGHT) typedef struct { int x, y; } Point; Point queue[QUEUE_SIZE]; int qhead = 0, qtail = 0; void enqueue(int x, int y) { if (qtail < QUEUE_SIZE) { queue[qtail].x = x; queue[qtail].y = y; qtail++; } } Point dequeue() { return queue[qhead++]; } int queue_not_empty() { return qhead < qtail; } int in_bounds(int x, int y) { return x >= 0 && x < WIDTH && y >= 0 && y < HEIGHT; } void floodfill_from_edges() { // Initialize queue with all edge pixels where iterations[y][x] == 255 for (int x = 0; x < WIDTH; x++) { if (iterations[0][x] == 255) enqueue(x, 0); if (iterations[HEIGHT-1][x] == 255) enqueue(x, HEIGHT-1); } for (int y = 0; y < HEIGHT; y++) { if (iterations[y][0] == 255) enqueue(0, y); if (iterations[y][WIDTH-1] == 255) enqueue(WIDTH-1, y); } // Floodfill while (queue_not_empty()) { Point p = dequeue(); int x = p.x; int y = p.y; if (!in_bounds(x, y)) continue; if (visited[y][x]) continue; if (iterations[y][x] != 255) continue; visited[y][x] = 1; enqueue(x+1, y); enqueue(x-1, y); enqueue(x, y+1); enqueue(x, y-1); } } int main() { float cx, cy; float zx, zy, new_zx; unsigned char n; grafmode(GRAFMODE_160_200_4); // Step 1: Berechne Iterationen pro Pixel for (int j = 0; j < HEIGHT; ++j) { cy = yCentre + (j - HEIGHT/2)*dxy; for (int i = 0; i < WIDTH; ++i) { cx = xCentre + (i - WIDTH/2)*dxy*2; zx = 0.0; zy = 0.0; n = 0; while ((zx*zx + zy*zy < 4.0) && (n != 255)) { new_zx = zx*zx - zy*zy + cx; zy = 2.0*zx*zy + cy; zx = new_zx; n++; } iterations[j][i] = n; } } // Step 2: Floodfill von Rand aus floodfill_from_edges(); // Step 3: Ausgabe for (int j = 0; j < HEIGHT; ++j) { for (int i = 0; i < WIDTH; ++i) { if (visited[j][i]) { // Außengebiet (kein Mandelbrot): zeichne mit n plot(i, j, iterations[j][i] & getMaxColor()); } else { // Inneres der Mandelbrot-Menge: direkt schwarz plot(i, j, 0); } } } textmode(); return 0; }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
-
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.
-
mc hires. Bitplanes egal. Stream vom Laufwerk oder aus EPROM CRT
wäre ein Test wert. -
Dein C code

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
-
Boah ! KRASS bin geflashed vom Atari !
"
Die Darstellung profitiert meiner Meinung nach sehr von dem Ansatz, der sehr einfach ist. Die Farbenpalette wird Zeilenweise geändert (gewechselt)"
FLI mode also wenn ich es richtig verstehe ?
-
Wer das Apfelmännchen bei guter Strukturauflösung richtig schnell haben will, der muss es schaffen, möglichst effektiv den rechenintensiven inneren Bereich zu überspringen, ohne dabei die Ränder in Mitleidenschaft zu ziehen.
Das geht mit einem Floodfill von allen(!) Randpunkten des Bildschirms aus, mit den Iterationen=Maximum (-> schwarz, "Mandelbrot-Punkt") als Stop-Bedingung. Man nutzt hier aus, daß die Mandelbrot-Menge einfach zusammenhängend ist - insbesondere heißt das, daß sie keine Löcher hat.
Ich hatte das seinerzeit bereits kombiniert mit einer Anzeigemethode, welche die Filamente hervorhebt. Hier zwei Beispiele vom VC-20:
Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.
hast du code ?
unter floodfill verstehe ich einen pixelfiller der zeilenweise füllt bis er ein pixel erkennt und stoppt. habe ich das richtig verstanden ?
also meinst du ich soll von rechts nach links(319->pix) eine zeile füllen und auch von links nach rechts (0->pixel) bis was kommt ?der c code von daybyter :
-
An Coma Light 11 kommt es nicht ganz ran
Das lässt sich aber nicht vergleichen, weil in der Demo eine viel schlechtere Zahlenauflösung benutzt wird. Das sieht man sofort an den groben Rändern. Und besonders tief kommt man damit auch nicht. Wer das Apfelmännchen bei guter Strukturauflösung richtig schnell haben will, der muss es schaffen, möglichst effektiv den rechenintensiven inneren Bereich zu überspringen, ohne dabei die Ränder in Mitleidenschaft zu ziehen.
erzähl mir mehr darüber bitte
-
V3 mit Colorcycler - EPILEPSIE WARNUNG
-
An Coma Light 11 kommt es nicht ganz ran: (ab 7:24)
Bitte melde dich an, um dieses Medienelement zu sehen.
bin geflasht, wenn ich nicht sitzen würde müsste ich am boden liegen...
-
danke brotkasten ! sollte mir eine Brille besorgen...
ok das Ende des Programs ändern....
Das V2 bleibt in einer Endlosschleife stehen... bis man Reset macht....
Danke für die tollen Beispiele muss ich mir raussuchen..... Sehr sehr hübsch !! muss ich mir raussuchen...
-
an coma light kommt eh kein hobby programierer wie wir ran.... das sind meister