Tortoise Git, Dateien und Icons

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

*john 0

@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? Konnte Turbo C++ überhaupt Exception Handling?

Exception Handling (und auch Templates) kam erst recht spät in C++. Definiert wurde das zuerst im Annotated Reference Manual (1990). cfront 2.1 setzte das als erstes um, wurde aber nicht so häufig kopiert. Weite Verbreitung fand das erst nach dem erscheinen von cfront 3.0 (September 1991), da cfront 3.0 stärker Vorbild für andere Compiler war. Bei Wikipedia steht, dass der erste Turbo C++ 1.0 Compiler (Mai 1990) cfront 2.0 umsetzte, was eben kein Exception Handling oder Templates konnte. Wenn man den Artikel weiter liest, dann erfährt man dass mit Turbo C++ 4.0 (November 1993) eine sehr stabile vorbildliche Implementation von Templates erfolgte.

*john 0

@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.

Wenn wir über normales Pascal reden, hast Du sicherlich Recht. Borland hat aber TurboPascal total aufgebohrt und beständig erweitert, so dass das nur noch dem Namen nach Pascal war. Und natürlich wurde von Borland OO-Programmierung in Pascal integriert.

DocShoe

Also von mir aus könnt ihr ruhig weitermachen, das Eingangsthema wurde ausreichend behandelt. Wir finden uns damit ab, dass Embarcadero den Ball hat und wir keinen Handstand machen möchen, um die Projektdateien vernünftig zu pflegen.

Ich hab aufm C64 angefangen Assembler zu programmieren, mit nem symbolischen Assembler, keine Ahnung, wie das Ding hieß. Turbo Assembler oder so? Bei einem Projekt (ich nenn's mal so, war bestimmt ne Spielerei ohne praktischen Nutzen) war der Quelltext dann so lang, dass der Assembler den Output in den Quelltextspeicher geschrieben hat und mir die letzten Zeilen Quelltext überschrieben hat. War dann sehr überrascht, dass der Assembler beim nächsten Übersetzen Fehlermeldungen ausgegeben hat, nachdem ich das Programm gestartet habe. Und beim Angucken des Quellcode- Bereichs standen da lustige PETSCII Zeichen.

Aufm Amiga hab ich`s mit C probiert, bin aber nie über nen 5 Zeiler hinausgekommen. Hatte ein Erlebnis, das mich traumatisiert hat, und als Jugendlicher hatte man iwann auch andere Interessen, die wenig mit Computern zu tun haben. Im besagten C-Miniprogramm wollte ich ein Fenster öffnen, für 10 Sekunden anzeigen, und dann wieder schließen. Anzeigen hat geklappt, zum Schließen ist es nie gekommen. Viiiiiel später habe ich dann rausgefunden, dass der Aufruf

Sleep( 10000 ); // hier das Amiga-OS Pendant einsetzen, kA, wie der hieß

aus der 10000 nen short gemacht hat und die oberen 16bit des 32bit Wertes zufällig waren. Also hat der Sleep länger gedauert als geplant, damit habe ich ein paar Tage gekämpft und es dann sein gelassen. Gab damals noch kein Internet, wo man sowas hätte nachfragen können.

Hier nochn Video von Jason Turner und nem Hobbyprojekt, wo er mit GCC für nen C64 Pong programmiert hat:
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

PS:
Hab in der dänischen C64 Datenbank 4 Demos von mir gefunden. Ich wunder mich, wie die dahin gekommen sind, bin aufm Land groß geworden und viel Kontakt außerhalb des Dorfes hatten wir nicht.

Finnegan

@DocShoe sagte in Tortoise Git, Dateien und Icons:

Ich hab aufm C64 angefangen Assembler zu programmieren, mit nem symbolischen Assembler, keine Ahnung, wie das Ding hieß. Turbo Assembler oder so? Bei einem Projekt (ich nenn's mal so, war bestimmt ne Spielerei ohne praktischen Nutzen) war der Quelltext dann so lang, dass der Assembler den Output in den Quelltextspeicher geschrieben hat und mir die letzten Zeilen Quelltext überschrieben hat. War dann sehr überrascht, dass der Assembler beim nächsten Übersetzen Fehlermeldungen ausgegeben hat, nachdem ich das Programm gestartet habe. Und beim Angucken des Quellcode- Bereichs standen da lustige PETSCII Zeichen.

Das ist ein schönes Beispiel dafür, weshalb ich für sowas heute moderne Tools bevorzuge, anstatt mich nochmal an die Original-Hardware zu setzen. Da wäre meine Motivation schnell am Ende

@DocShoe sagte in Tortoise Git, Dateien und Icons:

PS:
Hab in der dänischen C64 Datenbank 4 Demos von mir gefunden. Ich wunder mich, wie die dahin gekommen sind, bin aufm Land groß geworden und viel Kontakt außerhalb des Dorfes hatten wir nicht.

Ist ja witzig. Ich hab vor ein paar Jahren exakt dasselbe Erlebnis gehabt, und auch ich bin auf dem Land groß geworden

War ne "Auftragsarbeit" für Leute, die ich von nem BBS damals kannte, mit denen ich mich hin und wieder zu Parties und Netzwerksessions getroffen habe. Ist witzigerweise in Turbo Pascal geschrieben, bzw. genauer etwa 10% Pascal und 90% Inline-Assembler:

https://www.pouet.net/prod.php?which=75644

Ist leider ziemlich CPU-lastig, DOSBox muss schon für mindestens für nen guten i486 konfiguriert werden

hustbaer

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Man merkt, dass du anscheinend nen Amiga hattest.

Haha, ja, hatte ich. Erst nen A500, dann nen A500+ mit HDD und dann nen A3000. Hab ich aber damals alles wieder verkauft.

Vor ein paar Jahren hab ich mir nen neu aufgebauten A1200 gekauft. Neues Mainboard, neue 030er + 882 Turbokarte mit Compact-Flash IDE, neuer Flicker-Fixer, neues Gehäuse, neues Netzteil, neue Standardbauteile, new-old-stock Laufwerk - nur Custom Chips, Abschirmblech und Tastatur aus nem originalen A1200.

Es gibt ja etliche neuere Spiele im Retro-Stil. Vielleicht mal recherchieren, was die so verwenden.

Pixel-Art Editoren gibt es einige. Unter denen die ich bisher probiert habe bin ich aber noch mit keinem warm geworden. Hab aber auch nicht sehr viel rumprobiert. Und die meisten unterstützen Pallette Grafiken nur so halb. D.h. intern ist alles True-Color, und die eingeschränkte Pallette wird nur mehr oder weniger emuliert.

Mit genug Motivation und Zeit könnte ich da sicher was brauchbares finden. Aber das was mich wirklich interessiert, ist Code schreiben. Und so konnte ich mich bisher noch nicht ausreichend motivieren. Andrerseits könnte ich natürlich auch einfach ein paar Werte in ein Source-File eintippen und quasi mit Pixel-Schrott testen. Im Endeffekt scheitert es halt wirklich an der Motivation.

Naja, mal sehen. Falls ich jemals wirklich anfange, werde ich auf jeden Fall berichten.