Neue Grafik-Formate

Es gibt 49 Antworten in diesem Thema, welches 2.412 mal aufgerufen wurde. Der letzte Beitrag (1. Oktober 2025 um 23:19) ist von atomcode.

  • Dabei hatte ich mich auch gefragt, ob nicht noch weitere UFLI-Formate möglich wären, die dann eben etwas kleiner sind, z.B. mit nicht vergrößerten Sprites oder mit Multicolor-Sprites.

    Ich denke ja. Das war ja die Grundidee bei meiner Raster-Trick-Bildern, dass man mit kleineren Bildern arbeitet. Dann ist man mit den Sprites flexibler. Ob man das dann noch mit FLI-Technik kombinieren kann, hängt vermutlich davon ab, was man sonst noch so auf dem Bildschirm haben will. Ich hab' aber noch nie was mit FLI programmiert. Müsste man sich mal mit ganz konkreten Vorgaben ansehen, denke ich.

  • Für kleinere Bilder würde ich die ersten 24px im wahren Sinne links liegen lassen. Dahinter ließe sich dann UFLI-mäßig einiges anstellen, wobei ich HiRes-FLI beibehalten würde. Dazu dann normal breite Mulitcolor-Sprites (also bis zu 192px), oder 2 Lagen normal breite HiRes-Sprites, sind 96px und einfach zu berechnen.

    Geht das, mit dem links liegen lassen? Ich dachte immer, bei FLI kommen da irgendwelche Artefakte. Wenn man die nicht auf dem Bildschirm haben will, braucht man mindestens ein Sprite um sie zu überdecken. Aber evtl. kann man es hinbekommen, dass die Artefakte die selbe Farbe haben, wie der Hintergrund oder sowas.

    Wenn man HiRes-Sprites verwendet, schätze ich mal, dürfte MC-FLI sinnvoller sein. Irgend eines dieser FLI-Formate macht das so, ich hab' aber vergessen wie es hieß (hier wurde das besprochen: Bitte melde dich an, um diesen Link zu sehen.). Da hat man dann zwei Vordergrundfarben und zwei Hintergrundfarben und die Sprites sind "dazwischen".

    Man braucht dazu ja auch einen dafür spezialisierten Konverter, den man erst mal programmieren muss.

    Ja, klar. Das wäre dann ein Projekt, dass man mal angehen müsste (Lust hätte ich, Zeit kann ich grad nicht abschätzen, gibt einfach zu viele C64-Projekte, die ich gerne mal machen würde...). Aber dafür muss man natürlich vorher klar wissen, was man will.

    Vorschläge (aus deinen Vorgaben):

    a1) Bildgröße: 192x126 (=8x6 Sprites), HiRes-Grafik, MC-Sprites

    a2) Bildgröße: 168x105 (=7x5 Sprites), HiRes-Grafik, MC-Sprites (falls 1 Sprite für die Artefakte benötigt wird)

    b1) Bildgröße: 96x84 (=4x4 Sprites), HiRes-Grafik, HiRes-Sprites (doppelt)

    b2) Bildgröße: 96x84 (=4x4 Sprites), HiRes-Grafik, HiRes-Sprites (einmal voll, einmal um 12px versetzt, dann nur 3 Sprites in der Breite, falls 1 Sprite für die Artefakte benötigt wird)

    c1) Bildgröße: 96x84 (=4x4 Sprites), MC-Grafik, HiRes-Sprites (doppelt)

    c2) Bildgröße: 96x84 (=4x4 Sprites), MC-Grafik, HiRes-Sprites (einmal voll, einmal um 12px versetzt, dann nur 3 Sprites in der Breite, falls 1 Sprite für die Artefakte benötigt wird)

    Dann kommt noch die Frage dazu, wo die Grafik anfangen soll: Am oberen Rand? Oder sollen 1/2 Zeilen für irgendwelche Titel frei bleiben? Oder mittig im Bildschirm? In Links-Rechts-Richtung würde ich vermutlich zentrieren.

    (Und eigentlich beginnen wir her gerade ein neues Thema; sollte vielleicht in einen eigenen Thread?)

  • Ich hänge mich mal ran an die Nufli-Formatdiskussion. Ihr scheibt Euch damit beschäftigt zu haben. :)

    Mir würde ein "einfacher" 3-Farb-Modus gefallen.
    Also einfach 3-farbiges Hires plus eine zusätzliche Farbe für Anti-Alias.

    Ein "HiresPlus" quasi.

    Programmierende Grafiker nehmen dafür individuelle Sprites. Ich bin beides nicht, daher hab ich z.B. für

    Bitte melde dich an, um diesen Link zu sehen.

    einfach Nufli verwendet.

    Das ist natürliich mit Kanonen auf Spatzen geschossen. Weil Farbe muss da ja nirgends umgeschaltet werden in einer Zeile oder gar Char.

    Könnte man da einen passenden, effizienten Modus kreieren?

  • Könnte man da einen passenden, effizienten Modus kreieren?

    Da war doch in den 90ern schonmal ein "Super Hires" mit 3 Farben. Ich erinnere mich an ein Compobild in dem Grafikmodus auf einer größeren Party, wenn sich keiner erinnert, dann könnte das ein Anfang für eine Suche sein.

    Dein konkretes Meleemount könnte in Hires mit weißem Vordergrund, grauem Hintergrund und dazwischen Xpanded Hires-Sprites in Blau gehen.

    Dabei kann sich eine Beschränkung ergeben, sobald 3 Farben je Char benutzt werden: Es sind keine einzelnen blauen Pixel zwischen grauen Pixeln möglich. Zwischen weißen Pixeln kein Problem, aber mit grauen in der Nachbarschaft kann die halbe Auflösung spürbar werden.

  • kann die halbe Auflösung spürbar werden

    Bei der Breite müssen ja x-panded Sprites eingesetzt werden. Dass das irgendwo sichtbar sein wird, leuchtet ein. :)
    In meinem Fall wäre die Interpolationsfarbe hellblau. Hintergund (paper) weiß und Vordergrund (ink) blau.

    Schlimmstenfalls würde man an einer Stelle nicht interpolieren, wenn der 2x1 Spritepixel nicht halb hinter dem Vordergrund liegt.

    Super Hires

    Super Hires can theoretically generate pictures in resolution of 96*200 pixels/16 colors. Though standard size of the pictures is only 96*167 pixels.

    One 8*8 pixels big attribute area can contain 4 colors. 2 colors are same in the whole picture, and 2 can be set individually for each attribute area. (Background color, and foreground color, as in hires mode)

    Realisation is quite simple:

    Picture consists of 2 layers of multiplexed hires sprites. Hires sprite is 24*21 pixels big/1 color. Each layer consist of 4*8 hires sprites of the same color.

    Two layers give us 2 colors, and Hires picture lying behind them give us another two, which can be set separately for each 8*8 pixels big attribute area.

    Ist nicht für die komplette Bildbreite.

    Bitte melde dich an, um diesen Link zu sehen.

    Algotech

    Danke. Das sollte zu 100 % das sein, was ich gemeint habe. :)
    Der hat wirklich sehr viel an Konvertern und Formaten gemacht. Auch für Audio. Leider schon eine Weile sehr ruhig bei ihm.

  • Im Bitte melde dich an, um diesen Link zu sehen.-Thread kam die Idee auf, sich ein paar neue Grafik-Formate zu überlegen, ähnlich dem NUFLI-Format, aber für kleinere Bilder.

    Die Grundidee: Ein HiRes- oder MC-Bild mit einer oder zwei Schichten (nicht expandierter) Sprites dazwischen und das ganze mit FLI-Technik verknüpfen.

    Grundsätzliche hätte ich Lust, einen Konverter für so ein neues Format zu programmieren (vermutlich in Java). Wichtig wäre mir aber, das vorher klar ist, was man genau haben möchte. Und ich kann auch nicht versprechen, dass das schnell geht; meine Zeitreserven reichen bei weitem nicht für alles aus, was ich gerne im Zusammenhang mit dem C64 machen würde... :D

    Damit der oben erwähnte Thread nicht damit zugeballert wird, hab' ich das Thema hier mal ausgelagert.

  • Damit das nicht unter geht, sollten Eure Überlegungen vielleicht einen eigenen Thread bekommen?

    Ich hab' mal einen entsprechenden Thread aufgemacht: Bitte melde dich an, um diesen Link zu sehen.

  • Postings 734-737 aus dem Nachbarthread "Heute so konvertiert" auf Wunsch von Tobias hierher verschoben.

    Arroganz ist die Kunst, auf seine eigene Dummheit stolz zu sein.
    Gruß - cp2

    Bitte melde dich an, um diesen Link zu sehen.

  • Um ein Gefühl dafür zu bekommen, was das heißt, hier mal ein paar Bilder und Gedanken:

    In der 96x96-Variante würde der schwarze Bereich im folgenden Bild für die Grafik zur Verfügung stehen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bei 192x96 wäre es dieser:

    Bitte melde dich an, um diesen Anhang zu sehen.

    In beiden Fällen müsste es möglich sein, den Bereich in 8-Pixel-Schritten zu verschieben, allerdings nicht beliebig weit nach links.

    Bei FLI mit allen Sprites kann man meines Wissens nur jede zweite Zeile FLI anwenden(*). Die HiRes- oder MC-Bildkacheln wären damit 8x2 Pixel groß. Hinzu kommt noch der Sprite-Layer bzw. die beiden Sprite-Layer. Wenn man es einfach hält und alle Sprites HR-Sprites mit der gleichen Farbe sind, hat man dann zusätzlich noch 1 oder 2 weitere Farben, die man für jedes Pixel einzeln setzen kann. Also zusammengefasst: 3 oder 4 Farben beliebig wählbar, wobei zwei davon in jedem 8x2-Bereich einzeln gewählt werden können und die anderen 1 oder 2 Farben fix sind.

    (*) FLI erzwingt eine sogenannte Badline, bei der 43 CPU-Taktzyklen wegfallen. Durch die Sprites fallen weitere 19 CPU-Taktzyklen weg und es bleibt nur noch ein Taktzyklus über, zu wenig, um FLI überhaupt durchführen zu können. Wenn das Bild weiter rechts steht, könnte man den FLI-Effekt auch erst in der Mitte des Bildschirms starten, damit würde die Badline etwas kürzer und man hätte ein paar Taktzyklen mehr über; aber ob das für ein 1-Zeilen-FLI reichen würde, kann ich nicht sagen.

  • Bitte melde dich an, um diesen Link zu sehen. aus Bitte melde dich an, um diesen Link zu sehen. meinte ich. Ich glaube, in den Jahren danach hätte es noch ein paar Bilder mit diesem Grafikmodus gegeben, finden tu ich aber keine, und ein passendes Tool wurde damals auch nicht released. War wohl eher was für den Zweck am PC zusammenprogrammiert, das Algotech-Tool dürfte aber das Gleiche machen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Um ein Gefühl dafür zu bekommen, was das heißt, hier mal ein paar Bilder und Gedanken:

    Was stellst Du Dir links und rechts von der Grafik vor? Leere, oder Grafik in einfachem Grafikmodus?

    Nach Deinen ersten Gedanken wären die Farbbeschränkungen "einheitlich", im ganzen Bereich die gleichen Möglichkeiten und Beschränkungen.

    Als ich damals Bitte melde dich an, um diesen Link zu sehen. wollte, habe ich anhängig vom Motiv an manchen Stellen mehr gezaubert, an anderen einfach nur MC genommen.


    Ich hatte mit Paletten angefangen: Was flackert wenig, was macht sich für Haut und Haare gut. Dann gerechnet, wie viele Sprites ich nebeneinander verwursten darf. Und erst dann kamen das Motiv und freies Pixeln mit den Paletten am PC. Da wäre im Nachhinein bestimmt mehr Breite gegangen, aber das Motiv stand, und das war furchtbar viel Handarbeit.

    Wäre vielleicht ne Option für den Grafikmodus: An Hand von Masken oder Paletten festlegen, welche Bildteile mehr Aufmerksamkeit brauchen und dort mehr Sprites investieren.

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Dieses Bild aus Higher Love meinte ich.

    Hab' ich mir mal angeguckt, das scheint relativ einfach gestrickt zu sein: Hires (braun (Vordergrund) und grau (Hintergrund)), mit breiten Sprites (schwarz) dazwischen, also die Sprites vor dem grau aber hinter dem braun. Kein FLI.

    Was stellst Du Dir links und rechts von der Grafik vor? Leere, oder Grafik in einfachem Grafikmodus?

    Für den Anfang auf alle Fälle erst mal Leere. Das ist einfacher.

    Was flackert wenig,

    Alles was flackert werde ich nicht anfassen. Mir wird von dem IFLI-Zeugs regelmäßig schlecht. Da bin ich auf alle Fälle raus.

    Wäre vielleicht ne Option für den Grafikmodus: An Hand von Masken oder Paletten festlegen, welche Bildteile mehr Aufmerksamkeit brauchen und dort mehr Sprites investieren.

    Ja, das war ja so ein bissl die Idee bei den Raster-Trick-Bildern, dass man den Programmcode an die Grafik anpasst. Ich glaube, hier geht's aber eher erst mal um was einfacheres. Wenn das steht, können wir immer noch überlegen, wie man es noch weiter ausbauen kann. Ich möchte jedenfalls lieber kleine Schritte machen.

    Insbesondere muss ich ja erst mal rausfinden, wie der Spritemultiplexer zu bewerkstelligen ist. Bei FLI ist das nämlich ziemlich kompliziert, denn jeder zweite Spritewechsel fällt in eine Badline und da fehlen dann schlicht die Taktzyklen um die Spritedatenzeiger zu verändern. NUFLI verwendet da in den oberen zwei Dritteln Spritestretching stattdessen und nur im unteren Drittel einen Spritemultiplexer. Was der Grund für den Wechsel war, weiß ich nicht. Vermutlich ging beides nur für eine gewisse Zeit gut und die große Schwierigkeit war dann der Übergang vom einen zum anderen.

  • Das hier ist recht straight-forward von vor ein paar Jahren als Test mal :)
    Bitte melde dich an, um diesen Anhang 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.

  • Das hier ist recht straight-forward von vor ein paar Jahren als Test mal :)
    Bitte melde dich an, um diesen Anhang zu sehen.

    5 Graustufen, Hell/Dunkelgrau als Hires-Sprites, die andren Farben in MC?

    ch glaube, hier geht's aber eher erst mal um was einfacheres. Wenn das steht, können wir immer noch überlegen, wie man es noch weiter ausbauen kann

    Dann würde ich FLI und nicht-FLI getrennt betrachten. Ohne FLI, bei beschränkter Palette bringen die Sprites schon einiges an Auswahl für die Pixel, und man kann ohne die fiesen Nebeneffekte am Grafikformat herumexperimentieren.

    Another workaround? Stay a while... STAY FOREVER!!

    2 Mal editiert, zuletzt von Hoogo (25. September 2025 um 17:30)

  • Geht das, mit dem links liegen lassen? Ich dachte immer, bei FLI kommen da irgendwelche Artefakte. Wenn man die nicht auf dem Bildschirm haben will, braucht man mindestens ein Sprite um sie zu überdecken. Aber evtl. kann man es hinbekommen, dass die Artefakte die selbe Farbe haben, wie der Hintergrund oder sowas.

    Jain. Bei MC-FLI braucht man dafür (sofern ich alles richtig verstanden habe) nicht unbedingt Sprites zum Abdecken unerwünschter Farben. Die Farbe des Bereichs ergibt sich dabei aus dem Byte, das dem entsprechenden Schreiben in $D011 folgt; das ist in der Regel der Opcode eines Ladebefehls für eine Spritefarbe. Wenn also nach einem LDA #$3C : STA $D011 ein LDY #$05 : STY $D028 folgt, um die freie Farbe für Sprite 1 auf Grün zu setzen, wird der Rand schwarz, weil der LDY-Opcode #$A0 ist, und da nur das Lo-Nibble relevant ist, entspricht das Schwarz. Da Schwarz vermutlich der häufigste Anwendungsfall ist, ist das durchaus brauchbar. Mit einem LDA hätte man #$A9 = braun, mit einem LDX = #$A2 = rot.

    Na ja, und dann stellt sich die Frage, ob man da zeitlich noch einen anderen Befehl, nur des Farbcodes wegen, unter bekommt. Angenommen, ich wollte für den Bug-Bereich Weiß haben: Weiß = #$x1; das sind die Befehle mit den beiden indirekten Indizierungsarten. Man könnte also ein LDA (zp),Y nehmen; das ist der Opcode #$B1. Aber der braucht 3 TZ mehr, und das könnte evtl. zeitlich nicht mehr passen. Fazit: Mit Schwarz, Braun oder Rot für den Rahmen kein Problem, ansonsten aber schwierig oder ohne ein Abdeck-Sprite nicht möglich. Man hätte dann noch 7 Sprites übrig.

    Und ja, bei HR-FLI aka AFLI kommt man um ein mit der gewünschten Farbe gefülltes Abdeck-Sprite nicht herum. Es erscheinen da sonst hellgraue Balken, die man dort eher nicht sehen möchte. Allerdings wäre das auch noch eine Art "links liegen lassen", da auf diese Weise der Bereich nicht für das Bild zur Verfügung steht.

    Aber ich hatte gestern meine Meinung noch geändert, nämlich den Rand so zu lassen, wie er im NUFLI-Format behandelt wird, also mit zwei übereinander liegenden Sprites für Grafik. Technisch soll es also kein wirklich neues Format werden, sondern nur eines mit geringerer Höhe. Die ganze Breite muss ja nicht zwingend fürs Image benutzt werden. Wie gesagt, man kann ja etwas (in die Bildfläche) daneben schreiben. Oder man macht das Motiv mittig und etwas schmaler, z.B. auf 272 px, wodurch die beiden linken Bug-Sprites homogen werden und gut komprimiert werden können, und mit dem rechten eingeschränkten AFLI-Streifen ohne Sprites hätte man nichts mehr zu tun. Was heißt "hätte", so habe ich es eigentlich vor.

    Im C64-Wiki wurde die Höhe der oberen gestreckten Sprites mit 120px angegeben. Habe aber schon festgestellt, dass es 128px sind. Eine Beschneidung an der Stelle bedeutet dann, dass es kein Multiplexing mehr in dem kleineren NUFLI-Format geben wird. Die Sprites behalten während der gesamten Anzeige ihre X- und Y-Positionen und werden lediglich gestreckt.

    Dann kommt noch die Frage dazu, wo die Grafik anfangen soll: Am oberen Rand? Oder sollen 1/2 Zeilen für irgendwelche Titel frei bleiben? Oder mittig im Bildschirm?

    Guter Punkt. In meinem Fall brauche ich das zwar nur ganz oben, aber es wäre natürlich schön, wenn sich das versetzen ließe. Werde ich dann mal überprüfen. Die originale Routine nutzt die Inaktivität des VICs im oberen Rahmen, wo die Sprites bereits beginnen. Wird sich zeigen, was da geht.

  • btw .. Nicht-FLI-Formate haben natürlich den Vorteil, dass sie nicht so viel CPU-Zeit fressen und dass man da zur Laufzeit auch mal drin herummalen kann. Somit auch als Spielplattform geeignet, siehe Lemmings für C64, das genau darum nur 192 px breit ist.

    FLI oder Nicht-FLI, das hängt halt auch etwas vom jeweiligen Anwendungsfall ab. Ich habe mich jetzt auf NUFLI verspitzt, weil es nur der statischen Illustration dienen und dabei möglichst detailliert aussehen soll.

  • Was stellst Du Dir links und rechts von der Grafik vor?

    In voller Breite wäre es wie superbreites Kinoformat, also bis zu 2,5 (320/128). Das wäre geeignet für Intros u.ä., mit Storytext darunter. Ansonsten möchte ich die ungefähr quadratische Grafik weiter nach rechts haben, und links daneben soll ein Beschreibungstext stehen. Es sind ca. 60-80 Bilder, von denen sich allerdings manche nur teilweise unterscheiden. Da könnte man evtl. mit einem Diff-File arbeiten.

    Ich habe mich jetzt auf NUFLI verspitzt

    Was genau möchtest Du eigentlich mit den Grafiken dann machen? :)

    Ins Spiel einbauen. Um die kleinen Spritegrafiken einmal so darzustellen, wie sie wirklich aussehen würden, also wie man sich das vorstellen sollte. Evtl. auch für Zwischenszenen, z.B. wenn der Player die Arena betritt. Oder auch von anderen Räumlichkeiten, Gefängniszellen, Cafeteria, Serverraum, Holoraum. Es bietet halt eine gute Möglichkeit, den Player dabei zu unterstützen, sich in die Gesamtsituation zu versetzen und die Fantasie anzuregen, um nicht lediglich ein arcade-mäßiges 2D-Spiel zu sein, wo es sich oft nur auf das Titelbild beschränkt, so wie bei WoW.