Tortoise Git, Dateien und Icons

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein.

Ich verwende als C-Library picolibc und bei dieser werden auch nicht sonderlich viele Symbole mit in die Executable gelinkt, sofern man die Funktionen nicht nutzt. Wie gesagt, in C war "Hallo Welt" nur um die 30-40 KiB gross. Das war hauptsächlich die dlmalloc-basierte malloc-Implementierung von picolibc. picolibc macht für printf & Co bei der Initialisierung einen kleinen malloc-Aufruf (500 Bytes oder so). Ohne den könnte der malloc-Code wegfallen (tut er auch, wenn man printf nicht aufruft. Mit purem write(stdout, ...) schafft man auch unter 10 KiB.). Ich hab da noch einen in Assembler geschriebenen Loader-Code mit drin, der so gelinkt wird, dass er als erstes gestartet wird. Der detektiert den Speicher, wechselt in den 32-Bit Protected Mode, lädt mit DOS-Systemaufrufen das mit GCC kompilierte Hauptprogramm (damit dessen Größe nur durch den Speicher und nicht durch DOS-Funktionen limitiert wird) und implementiert von der libc benötigte OS-Aufrufe (open, close, read, write, sbrk, etc). Der Loader ist auch nochmal etwa 3 KiB.

Das ist alles soweit kein Problem. Gross wird es erst mit C++. Dann landen nämlich auch mit -fno-exceptions Exception-Handling-Tabellen in der EXE (.eh_frame_hdr und .eh_frame_entry.*-Sektionen im Linker). Die sind in Relation ziemlich groß und enthalten Daten zu jeder Menge Objekten und Funktionen der libstdc++. Das bläht das Ganze dann auf etwa 200 KiB auf und ich habe noch nicht herausgefunden, ob und wenn ja warum die benötigt werden (ich habe in GCC DWARF-Exception Handling aktiviert, das sind die "zero cost"-Exceptions von GCC, also mit fetten Tabellen fürs EH+Unwinding statt setjmp/longjmp). Dazu kommt dann auch noch der Stack Unwinding Code aus der libgcc, der auch noch einen nicht unerheblichen Anteil an der Größe hat. Ich muss allerdings auch erwähnen, dass ich einen Teil des Loaders in C++ geschrieben habe und dort schamlos moderne Features nutze wie std::span, std::string_view, Ranges, Views und Algorithmen. Mein Verdacht ist, dass vor allem daher die ganzen EH-Daten kommen. Ich werd's demnächst nochmal mit einer Multilib-Variante der libstdc++ versuchen, die ich dann ebenfalls mit -fno-exceptions baue.

Alles in allem jedenfalls ein lustiges Hobbyprojekt, bei dem man ne Menge über die Funktionsweise des Compilers lernt und was alles benötigt wird, damit so ein C++-Programm ausgeführt werden kann

Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

Eine lustige Eigenschaft in diese Richtung hat mein Projekt schon: Ich verwende ein flaches Speichermodell ohne Paging (virtueller Adressraum), d.h. der physische Speicher lässt sich direkt adressieren und die Speicheradresse 0x0 ist eine gültige Adresse, die keine CPU-Exception oder sowas auslöst. Dort befindet sich bei x86 standardmäßig der Interrupt Vector Table für den 16-bit Real Mode ... auto ivt = reinterpret_cast<ivt_entry*>(0); ... ich mach solche Zugriffe dann aber doch lieber in Assembler. Keinen Bock, dass mir der Optimizer da irgendwann ein Bein stellt, weil nicht sein kann, was nicht sein darf ... und ja, da hab ich eine ganze Menge Code drin, bei dem mir bezüglich C++ sehr unwohl wird. Ich Versuchs aber nach bestem Wissen und Gewissen standardkonform zu halten.

@john-0 sagte in Tortoise Git, Dateien und Icons:

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.

Doch, ich hab das schon mit LTO gebaut und auch mit -ffunction-sections/-fdata-sections und -Wl,--gc-sections. Ich weiss schon, wie ich unnötigen Code aus der EXE heraushalte. Immerhin hab ich das Linker-Skript geschrieben, mit dem ich überhaupt erst MZ-Executables erzeugen kann (GCC kann das nicht von Haus aus) und ich schau mir mit -Wl,--print-map genau an, was alles wo in der EXE landet. Das Problem scheint tiefer zu liegen. Da bin ich noch dabei herauszufinden, warum das so ist... wenn ich wieder Zeit für das Projekt finde

Finnegan

@Tyrdal sagte in Tortoise Git, Dateien und Icons:

Man könnte im diff auch einfach die whitespaces ignorieren lassen.

Hah! Auch ne gute Idee. Danke. Werd ich mir merken, falls irgendwann doch mal so ein Commit duchkommen sollte

SeppJ

Wo wir über Embarcadero/Borland zu dem Thema gekommen sind: Weiß jemand, wie groß so eine minimale mit Turbo C++ erzeugte Executable war? Konnte Turbo C++ überhaupt Exception Handling? Bei der GNU Implementierung von C++ kann ich ja voll verstehen, dass sich niemand die Mühe gemacht hat, die Größe von DOS-Executables zu optimieren, aber für das Borland-Produkt war das ja sicherlich wichtig. Die erste Version ist von 1990, da mussten Programme noch mit allem drum und dran auf Disketten passen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Wo wir über Embarcadero/Borland zu dem Thema gekommen sind: Weiß jemand, wie groß so eine minimale mit Turbo C++ erzeugte Executable war?

Meine Erinnerung ist sehr trübe und bezieht sich auch nur auf Turbo Pascal ... da müsste "Hallo Welt" eigentlich so grob zwischen 2-4 KiB gelegen haben. Auf jeden Fall ein, zwei Größenordnungen unter dem, was heutige Compiler so fabrizieren... vielleicht teste ichs nochmal aus die Tage.

SeppJ

Aber Pascal braucht ja keine Laufzeitumgebung für Exceptions, RTTI und so, um die volle Sprachdefinition voll umzusetzen, oder? Ist aber auch ewig her, dass ich Pascal gemacht habe, und dann auch nur auf primitivem Niveau, daher verzeiht, wenn ich mich da irre.

Turbo C++ kann solche Sprachfeatures natürlich auch weggelassen haben, oder optional gemacht haben, um Platz und/oder Laufzeit zu sparen. Selbst in heutigen Implementierungen ist RTTI ja noch abschaltbar, für wenn man sie nicht braucht und nicht dafür bezahlen möchte.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

Aber Pascal braucht ja keine Laufzeitumgebung für Exceptions, RTTI und so, um die volle Sprachdefinition voll umzusetzen, oder? Ist aber auch ewig her, dass ich Pascal gemacht habe, und dann auch nur auf primitivem Niveau, daher verzeiht, wenn ich mich da irre.

Pascal ist bei mir auch zu lange her, dass ich das sicher beantworten könnte.

Ich war zu neugierig und habs grad ausprobiert: Borland Turbo C++ 3.0:

// TEST.CPP
#include <iostream.h>

int main()
{
    cout << "Hallo Welt!\n";
    return 0;
}

-> TEST.EXE 23.156 Bytes

Schon etwas größer als erwartet.

Hingegen:

// TEST2.C
#include <stdio.h>

int main()
{
    printf("Hallo Welt!\n");
    return 0;
}

-> TEST2.EXE 8.675 Bytes

Alles mit Default-Settings direkt nach Installation. "Optimization" war für "size".

Nachtrag: Debugging war aktiv. Ohne sind es nur 9.478 Bytes für C++ und 6.446 Bytes für C.

Exceptions scheint Turbo C++ 3.0 nicht zu können: Undefinded symbol 'try'.

Turbo C++ kann solche Sprachfeatures natürlich auch weggelassen haben, oder optional gemacht haben, um Platz und/oder Laufzeit zu sparen. Selbst in heutigen Implementierungen ist RTTI ja noch abschaltbar, für wenn man sie nicht braucht und nicht dafür bezahlen möchte.

Ich hab bei meinem DOS-Projekt schon einiges an Arbeit reingesteckt, um überhaupt Exceptions ans laufen zu bekommen, aber genau aus dem Grund wurmt es mich, dass ich die ganzen Tabellen immer noch drin habe, wenn ich Exceptions ausschalte. Ich denke aber mal, dass ich das irgendwann noch in den Griff bekomme. Gut möglich, dass es nur daran liegt, dass die C++-Standardbibliothek mit Exception-Support gebaut wurde. Ich hätte aber vermutet, dass ich hauptsächlich Header-Only-Teile davon verwende, wo das egal sein sollte.

Nachtrag für Turbo Pascal 7.0:

program hello;
begin
    writeln('Hallo Welt!');
end.

-> HELLO.EXE 2.192 Bytes

hustbaer

Probier nochmal puts statt printf. Ich würde mich nicht wundern wenn's damit nochmal kleiner wird.

Ich meine mich zu erinnern dass der Hauptgrund warum Echsen von Miniprogrammen mit modernen Compilern so gross werden der ist, dass es da kreuz und quer Dependencies beim ganzen IO Zeugs gibt, inklusive Locale Support. Ich vermute dass man das besser entkoppeln könnte, wenn man gezielt auf kleine Programme optimieren will. Nur dass zahlt sich bei Runtime Libs für moderne Compiler halt kaum aus mMn. - und daher wundert es mich nicht dass ein "Hello World" Programm vergleichbar riesig wird.

Bei älteren Compilern könnte das aber u.U. noch ein wichtiger Faktor gewesen sein. Und vor allem war's vermutlich auch einfacher, weil die Libs viel weniger konnten (älterer Standard, weniger supportete Locales etc.).

hustbaer

@Finnegan verwendest du auch "moderne" Compiler für DOS? Also vielleicht Open WATCOM oder gar irgendwas auf Clang- bzw. GCC-Basis?

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

@Finnegan verwendest du auch "moderne" Compiler für DOS? Also vielleicht Open WATCOM oder gar irgendwas auf Clang- bzw. GCC-Basis?

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

Haha OK, sorry, hab ich verpennt
Aber cooles Projekt!
DOS 16 Bit oder 32 Bit oder beides? Falls 32 Bit, welcher Extender?

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

Probier nochmal puts statt printf. Ich würde mich nicht wundern wenn's damit nochmal kleiner wird.

// TEST3.C
#include <stdio.h>

int main()
{
    puts("Hallo Welt!\n");
    return 0;
}

-> TEST2.EXE 4.956 Bytes

Ich meine mich zu erinnern dass der Hauptgrund warum Echsen von Miniprogrammen mit modernen Compilern so gross werden der ist, dass es da kreuz und quer Dependencies beim ganzen IO Zeugs gibt, inklusive Locale Support. Ich vermute dass man das besser entkoppeln könnte, wenn man gezielt auf kleine Programme optimieren will. Nur dass zahlt sich bei Runtime Libs für moderne Compiler halt kaum aus mMn. - und daher wundert es mich nicht dass ein "Hello World" Programm vergleichbar riesig wird.

Ja. Auch der printf-Code dürfte relativ gross sein. Schließlich weiß man ja nicht ob man nur nen blanken String oder ne komplexe Formatierung bekommt. Ich denke da landet bei so nem "Hallo Welt" ne menge toter Code in der EXE.

Bei älteren Compilern könnte das aber u.U. noch ein wichtiger Faktor gewesen sein. Und vor allem war's vermutlich auch einfacher, weil die Libs viel weniger konnten (älterer Standard, weniger supportete Locales etc.).

Wenn ich das direkt in Assembler schreibe komme ich locker unter 100 Bytes. Da macht das der MZ-EXE-header mit seinen 32 Bytes den größten Teil aus. Der eigentliche Code ist lediglich ein paar Register auf Länge, File Handle und Adresse des Strings setzen und eine INT 0x21-Instruktion um den String nach stdout zu schreiben. Dann noch nen weiterer INT 0x21 um das Programm zu beenden. Das sind nur eine Handvoll Bytes an Code.

Noch kleiner gehts mit ner COM-Datei. Das ist direkt der Maschinencode ohne Header. Maximal 64 KiB, der wird dann direkt in ein Segment geladen und ausgeführt. Da macht dann der String den größten Teil aus. Ich denke das könnte man durchaus auf 20-30 Bytes drücken

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Als Hobbyprojekt baue ich gerade ne GCC14-Toolchain zum crosscompilen auf DOS. Darüber hab ich in meinen längeren Abschweifungen hier berichtet.

Haha OK, sorry, hab ich verpennt
Aber cooles Projekt!
DOS 16 Bit oder 32 Bit oder beides? Falls 32 Bit, welcher Extender?

Kein Extender. Ein eigener Loader-Code in einer Bibliothek, die per Default dazu gelinkt wird. Der Loader startet in 16-Bit und versetzt die CPU dann in 32-Bit Protected Mode ohne Rücksicht auf Verluste. DOS-Calls werden über Interrupt Thunks gemacht, die für den Aufruf kurzzeitig wieder in den Real Mode wechseln. Das hat gewisse Ähnlichkeiten mit einem DOS Extender ist aber wesentlich simpler und kleiner (~3KiB, direkt in die EXE integriert). Dafür aber auch nicht "kompatibel" mit irgendwas. Unter nem DOS-Ära-Windows würde das nicht laufen.

GCC kann keinen 16-Bit Code erzeugen (lediglich der Assembler hat rudimentären Support mit dem ich z.B. den Loader implementieren kann) und erwartet auch ein "Flat" Memory Model. D.h. ich brauche 32-bit Protected Mode, damit der GCC-kompilierte Code überhaupt lauffähig ist. Speicher wird auch ohne Paging (Virtueller Speicher) konfiguriert und die Programme laufen alle in Ring 0. Da hat man dann direkten Zugriff auf alles zum rumspielen... Pointer adressieren direkt den physischen Speicher

Funktioniert recht gut bisher. Modernes C++ und Exceptions laufen. malloc und libc-Funktionalität kommt von picolibc. bin aber noch mit Details im Loader beschäftigt. Die Hardware-Interrupts machen noch ein paar Probleme. Man soll eigene IRQ-Handler definieren können (für Hardware-Zeug wie Soundkarten und sowas), aber per Default soll an die von DOS definierten Interrupt-handler weitergeleitet werden (auch wieder switch in Real Mode für den Aufruf). Das ist alles schon ein wenig fummelig, macht aber Spass.

Wenn das einigermaßen rund läuft, lad ich es mal auf Github hoch für Leute, die auch Spaß an sowas haben. Meine ursprüngliche Motivation war, dass ich nen modernen C++-Compiler wollte mit dem man die ganzen coolen Hardware-Spielereien aus DOS-Zeiten machen kann, ohne gleich ein eigenes OS entwickeln zu müssen. Diese "Spielereien" sind ja heutzutage nur noch kernel-Entwicklern vorbehalten

hustbaer

Haha, ja, ist schon klar. Hab damals selbst sowohl mit C(++) Compilern als auch x86 Assembler für DOS gespielt. Schnell mal mit int-keine-Ahnung-mehr-welche-Nummer in den 8 Bit 320x200 Mode wechseln und mit ein paar wenigen Instruktionen Pixel auf den Bildschirm klatschen. Und das .COM File hatte dann gerade ein paar hundert Byte.

War schon cool irgendwie. Und um Welten einfacher als das selbe am Amiga zu machen
Wobei der Amiga natürlich viel viel cooler und kultiger war. Aber die ganze Plackerei mit den Bitplanes, Copperliste, Blitter-Registern & Co. hab ich nicht vermisst.

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Meine ursprüngliche Motivation war, dass ich nen modernen C++-Compiler wollte mit dem man die ganzen coolen Hardware-Spielereien aus DOS-Zeiten machen kann, ohne gleich ein eigenes OS entwickeln zu müssen. Diese "Spielereien" sind ja heutzutage nur noch kernel-Entwicklern vorbehalten

Haha, cool!

Ich hab mir seit Jahren vorgenommen mal was mit der Amiga GCC-Toolchain zu machen. Also irgend ein kleines Spiel. Aber irgendwie ist mir die Einstiegshürde zu hoch. Also kombiniert mit meiner Faulheit.

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

Haha, ja, ist schon klar. Hab damals selbst sowohl mit C(++) Compilern als auch x86 Assembler für DOS gespielt. Schnell mal mit int-keine-Ahnung-mehr-welche-Nummer in den 8 Bit 320x200 Mode wechseln und mit ein paar wenigen Instruktionen Pixel auf den Bildschirm klatschen. Und das .COM File hatte dann gerade ein paar hundert Byte.

MOV AX, 0x13; INT 0x10

Die Pixel liegen dann bei 0xa0000 ... auto pixels = reinterpret_cast<std::byte*>(0xa0000);

War schon cool irgendwie. Und um Welten einfacher als das selbe am Amiga zu machen
Wobei der Amiga natürlich viel viel cooler und kultiger war. Aber die ganze Plackerei mit den Bitplanes, Copperliste, Blitter-Registern & Co. hab ich nicht vermisst.

Ich wage zu behaupten, dass nicht zuletzt dieser direkte, lineare Pixelzugriff dazu führte, das sich der PC letztendlich als "Spielekiste" durchgesetzt hat. Das war extrem simpel wie auch schnell. Die ersten 3D-Spiele wie Doom oder Quake wären mit solchen umständlichen Grafikmodi nicht wirklich möglich gewesen. Zu langsam IMHO und der Hardware-Blitter taugt für Sprites, aber um texturierte Dreiecke zu zeichnen ist der keine große Hilfe.

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

Ich hab mir seit Jahren vorgenommen mal was mit der Amiga GCC-Toolchain zu machen. Also irgend ein kleines Spiel. Aber irgendwie ist mir die Einstiegshürde zu hoch. Also kombiniert mit meiner Faulheit.

Vielleicht ist mein Projekt ja ne Alternative. Das kann aber noch was dauern, so oft komme ich nicht dazu. Bisher läufts aber alles ganz ansehnlich unter DOSBox, QEmu und Bochs (mit MS-DOS 6.22 und FreeDOS). Wenn ich was vorzeigbares habe, poste ichs mal unter "Projekte". Das wird im Prinzip ne fertige GCC-Toolchain die per Default den Loader linkt und MZ-Executables erzeugt. Real Mode Switches sollen "transparent" erfolgen. D.h. Ziel ist es, dass man einen INT 0x10 (ein BIOS-Call in Real Mode Code) direkt im Inline-Assembler absetzen kann, ohne sich Gedanken darüber machen zu müssen, dass man sich eigentlich gerade im 32-Bit Protected Mode befindet.

wob

Ach wie schön. Ich habe damals mit Turbo Pascal 6.0 programmieren gelernt (in irgendeinem Buchladen (!) als Sonderangebot gekauft, weil es schon "Borland Pascal 7.0" gab) und bin dann irgendwann auf Ralf Browns Interruptliste gestoßen. Dann habe ich mir selbst mit interrupt-Calls die Maus eingeschaltet und die Zeigerposition abgefragt - am Ende hatte ich eine maus.pas, die voll mit (einfachem) Assembler-Code war. Ich weiß gar nicht, wie oft ich meinen PC damals gecrasht habe. Mit DOS war das ja noch so, dass wenn man was mit Assembler falsch gemacht hat, meist gleich das ganze System abgestürzt ist... Das waren noch Zeiten!

Finnegan

@wob sagte in Tortoise Git, Dateien und Icons:

Mit DOS war das ja noch so, dass wenn man was mit Assembler falsch gemacht hat, meist gleich das ganze System abgestürzt ist... Das waren noch Zeiten!

Ich weiß auch nicht mehr, wie man das damals alles hinbekommen hat. Ich finde es derzeit schon die 5 Sekunden um die Qemu VM mit DOS neu zu booten nervig und bin froh, wenn der Lowlevel-Kram endlich ordentlich läuft. Und dazu hab ich noch so nen Luxus wie GDB Remote Debugging in die VM am laufen und kann das ganze Zeug direkt im Code-Editor durch-steppen. So sehr mir die alten Sachen Spass machen, ich bin heilfroh das heute mit modernen Tools machen zu können

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Ich wage zu behaupten, dass nicht zuletzt dieser direkte, lineare Pixelzugriff dazu führte, das sich der PC letztendlich als "Spielekiste" durchgesetzt hat.

Weiss nicht. Möglich. Wenn AGA nen "chunky" Mode gehabt hätte, hätte der Amiga vielleicht bessere Karten gehabt, ja. Ich glaube aber nicht dass es gereicht hätte.

Vielleicht ist mein Projekt ja ne Alternative.

Haha, weiss nicht. Möglich. Es wäre vermutlich etwas einfacher, klar. Aber dafür halt auch weniger ... cool
Die Idee ist irgendwas wie nen einfachen Platformer oder Shmup zu machen. Aber auf "AGA mit Fast-RAM" Basis - also Ausnutzen von 32 Bit RAM Zugriffen um z.B. Tile-Daten aus dem Fast-RAM zu laden und dann ins Chip-RAM zu schreiben, parallel dazu sollte der Blitter laufen. Vielleicht ein bisschen tüfteln wie man mit wenig CPU Overhead nen brauchbaren Sprite-Multiplexer hinbekommt. Sowas in der Art.

Aber jedes mal wenn ich mich hinsetzen und anfangen will einfach mal ein paar einfache Experimente zu machen, fällt mir wieder ein was ich dazu noch alles brauche. Also z.B. irgend ein Programm mit dem ich vernünftig indexed Sprites und Tiles in z.B. 16 Farben malen kann, dann ein Programm mit dem ich das in ein ausreichend einfach zu lesendes Format konvertieren kann etc.
Klar, ich könnte auch einfach DPaint verwenden. Hab' ich mir sogar gekauft, lol. Aber ich würde dann doch gerne mit "modernen" Tools arbeiten.

Naja, ich hör jetzt mal lieder auf. Davon dass ich beschreibe was ich gern machen würde, aber im Endeffekt zu faul bin wirklich zu machen, hat ja doch keiner was

Finnegan

@hustbaer sagte in Tortoise Git, Dateien und Icons:

Die Idee ist irgendwas wie nen einfachen Platformer oder Shmup zu machen. Aber auf "AGA mit Fast-RAM" Basis - also Ausnutzen von 32 Bit RAM Zugriffen um z.B. Tile-Daten aus dem Fast-RAM zu laden und dann ins Chip-RAM zu schreiben, parallel dazu sollte der Blitter laufen. Vielleicht ein bisschen tüfteln wie man mit wenig CPU Overhead nen brauchbaren Sprite-Multiplexer hinbekommt. Sowas in der Art.

Man merkt, dass du anscheinend nen Amiga hattest. Mir fehlt da ein wenig der Bezug, ich war eines dieser PC-Kids, schon zu Zeiten wo der Amiga noch deutlich besser für solche Dinge geeignet war ... mit dem Amiga-GCC hab ich auch mal kurz experimentiert, nachdem ich mich allerdings durch ne Reihe Dokus zur Amiga-Grafik gewühlt hatte, war mir das das doch zu umständlich. Ich wollte "chunky mode". Mir hat schon damals ein einziges Projekt in einem "banked" SVGA-Modus gereicht. Und das ist nicht mal so fummelig wie Bitplanes oder sowas.

Aber jedes mal wenn ich mich hinsetzen und anfangen will einfach mal ein paar einfache Experimente zu machen, fällt mir wieder ein was ich dazu noch alles brauche. Also z.B. irgend ein Programm mit dem ich vernünftig indexed Sprites und Tiles in z.B. 16 Farben malen kann, dann ein Programm mit dem ich das in ein ausreichend einfach zu lesendes Format konvertieren kann etc.

PGM ist ein nettes Format für simple Experimente. Textdatei mit Pixel-Farbwerten. Weiss aber nicht, ob das auch ne Palette und Index-Farben unterstützt, könnte also für diesen Zweck nicht optimal sein.

Klar, ich könnte auch einfach DPaint verwenden. Hab' ich mir sogar gekauft, lol. Aber ich würde dann doch gerne mit "modernen" Tools arbeiten.

Zu DOS-Zeiten hab ich viel mit DeluxePaint Animation gemacht. Besonders für animierte Sprites war das klasse. Mich würde allerdings auch interessieren, ob es da was gutes modernes gibt, mit dem man gut Pixel Art machen kann. Es gibt ja etliche neuere Spiele im Retro-Stil. Vielleicht mal recherchieren, was die so verwenden. Geht natürlich auch mit Photoshop oder sowas, stell ich mir aber fummelig vor, weil es nicht wirklich für sowas ausgelegt ist.

Naja, ich hör jetzt mal lieder auf. Davon dass ich beschreibe was ich gern machen würde, aber im Endeffekt zu faul bin wirklich zu machen, hat ja doch keiner was

Ich finde schon die Diskussion darüber unterhaltsam genug. Keine Sorge zumindest von meiner Seite