Ich schreibe aktuell mein Computer Grafik Beleg.
Ziel meines Belegs ist eine OpenGL Demo die maximal 64KB groß ist.

Aktuell hab ich ein Player und ein Track dazu(thx @ Bero) sowie OpenGL Header, eigene RTL für FreePascal und ein bischen mehr.
Interessant sind dinge wie Texture Operation Stacking.
Dies sollte einigen von Farbrausch her bekannt sein.
Man baut sich eine hand voll funktionen und verbindet sie über ein case mit Konstanten zahlenwerten.
Dann kann man über const byte arrays z.b. texturen generieren.
Gleiches kann man auch mit Meshes machen oder Animationen.

Wenn man eine leeres fpc progg compiliert, dann ist man bei ca 36kb wenn man sich selber ne kleine rtl baut ist sie ca 4kb groß.
FPC und Delphi wollen ja ne System.pas und ne SysInitPas.pas, darin muss nun link auf startcode, funktionen für heap und ne handvoll typen.
Das bekommt man ganz einfach aus dem Quellcode der orginale.
Windows.pas und MMSystem.pas werden einfach aus dem Delphisource genommen und OpenGL hab ich mir stück für stück selber nen Header zusammen gefummelt.

Dann hat man schon mal alles was man so von aussen braucht und kann anfangen den eigenen Code zu schreiben.

Genau an diesem Punkt bin ich aktuell und man lernt da viele dinge.

Wer von euch hat sich schon mal an der Thematik probiert,versucht oder sogar was hin bekommen ?

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Im Projekt-Forum findest du ein 64k Tetris. Frag doch mal den Schöpfer.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich arbeite aktuell an algotex, so heisst die Texturunit.
Algotex erlaubt mir aus konstanten arrays die Texturen zu generieren.
Momentan kann es PerlinNoise,Pixels,Gaussion Blur und Text.
Es werden noch ne Handvoll Funktionen folgen aber das Ende ist nah.
Der ganze Code mit einer Testtextur,der Musik und einem drehenden Sphere, bestehend aus Cubes, ist 27KB groß und gepackt 9KB.
Was ich in der Demos darstellen will ist mein aktuell größtes Problem, denn ich hab keinen Plan.

Ich könnte auch ein Spielprinzip aufgreifen und realisieren aber ich glaube, dass dies zu aufwendig wird.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hmm, mit Demos hab ich keinerlei Erfahrung. Im Java forum findet jedes Jahr ein 4KB bzw 16KB Contest statt und die Aufgabe ist immer ein Spiel als Ziel.

In wie weit man das nun auf binär Programme umwandeln kann weiß ich nicht, da wir den ByteCode noch entsprechend strippen können. Das ist bei ASM denke ich nicht so wirklich möglich, oder?

_________________
(\__/)
(='.'=)
(")_(")

Meine Erfahrung liegt im Jahre 1999. Damals habe ich mit Pascal ein 32k-Spiel zusammengeschustert. Siehe hier: http://www.2ndmoon.de/cdb.html.
Viel ist glaub ich von damals nicht hängen geblieben. Oder ich betrachte das mittlerweile als Standard, kann auch sein.
Ich weiß nicht ob Du nun wirklich auf 64k reines Kompilat kommen willst, oder ob Du (wie üblich) noch einen EXE-Packer nutzen willst. Wenn Du einen Exe-Packer nutzen willst, dann würde ich vorschlagen, dass Du Dir erstmal eine beliebige EXE baust und die packst. Danach kannst Du abschätzen wie groß Deine Exe wirklich werden darf, damit sie nach dem Packen in die 64k passt.
Eines ist mir damals doch aufgefallen. Alle Grafiken, Fonts, Sounds, $irgendwas habe ich letztlich als dumme Arrays direkt in die Exe kompiliert. Jeder Exe-Packer bekommt das effektiver gepackt als irgendwelche integrierten Packalgorithmen. (Stand 1999, BP7, Apack).

Viel Erfolg wünsche ich Dir mit diesem Projekt. Hätte ich eine gute Idee und ein Ziel für sowas (gibts noch 32k-Gamekompetitions auf irgendwelchen Szeneparties?) würde mir das auch mal wieder Laune machen.

Grüße, DNA

_________________
Heute code ich, morgen debug ich, und übermorgen caste ich die Königin auf int.
http://www.2ndmoon.de

Unter Windows kann man z.b. Masm32 verwenden und das ist wie bei Delphi und Freepascal stark verkleinerbar.
Ist auch bei näherem betrachen klar, denn Freepasal generiert asm code, der vom gnu compiler und linker gepackt wird.
Nur ist es nicht so platzverschwenderig wie Delphi oder Freepascal. Am ende wird ja sowieso ein packer drüber gejagt.
Dieser Packer erstellt eine Exe die ein dropper enthält und dann hängt man die binary gepackt an die exe ran.
Bero sein Packer striped die unwichtigen Daten raus, resized die PageSize und nutzt ein simplen zip algo und fügt des an ein dropper ran.

Java kann man nicht mit asm oder einer normalen Programmiersprache vergleichen.
Java bringt ja für jedes nur erdenkliche Problem code mit aber man versucht ja nur mit den nötigsten aus zu kommen.
64K Demos dürfen keine nicht schon im system vorhandenen libs verwenden.
Alleine schon Java VM zu installieren wäre nicht erlaubt.

Aber vieleicht inspiriert es mich ja, kannst mal link geben ?

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bitte sehr: http://www.javagaming.org/forums/index.php?board=46.0

Naja, die VM ist für uns betrachtet soviel wert wie bei den Demos Direct X. Das ist zwar gleich im System dabei, aber ohne läuft selten eine Demo und Java läuft nur auf der VM, somit bringen wir nicht zwangsläufig etwas mit. DIe VM ist nur die Laufzeitumgebung.

_________________
(\__/)
(='.'=)
(")_(")

Der Versuch Java demos mit 64k demos zu vergleichen ist nicht sinnvoll.
Bei 64k Demos werden nur schon existierende dinge verwendet, dies ist eine lib zum ansteuern der graka und der soundkarte.
Java bringt neben unzähligen libs für gui,sound,3d grafik, algorythmen, wie gauss, noch viel mehr mit.
Stell dir mal ein leeres Blatt vor, dass wäre eine 64k demo mit gcc,fpc,delphi und co daneben stellst du nun eine Glossary z.B. Brockhaus und ein Blatt, welches schon fertig eingeteilt ist und ledeglich mit passenden Wörter gefüllt werden muss. Das wäre eine Java demo. Unter FPC und Delphi müssen selbst Strings, Klassen und so weiter erst programmiert werden, wenn man sowas nutzen will. 4KB Java games scheinen wohl ein gutes Equivalent zu 64K demos zu sein.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

OK, da geb ich dir recht. Da hat man einen gewissen Vorteil bei Java. Allerdings ist man beim 4K Kontest auf JFrame, Graphics und die Datentypen beschränkt. Hier und da vielleicht noch eine Image und ein Zufallsgenerator, mehr ist oft nicht drin. Bytecode ist leider sehr viel größer als ASM und das JAR selbst nochmal zu packen ist nicht erlaubt.

_________________
(\__/)
(='.'=)
(")_(")

Ich glaub, da muss ich wohl eingreifen, und was richtig stellen . Mein Packer ist kein Dropper, sondern erzeugt Executables, die on-the-fly direkt im Arbeitsspeicher entpackt werden und dort sofort ausgeführt werden, ohne irgendeine Tempdatei, können. Und das ganze funktoniert so:
Mein Packer lädt erstmal das Speicherabbild der Quell-EXE, die komprimiert werden soll, 1 zu 1 in den Speicher, dann wird alles unnötige aus dem Speicherabbild rausgeschmissen und anschließend mithilfe dem LZMA Algo auf Stufe Ultra komprimiert, und dann erzeugt mein Packer einen neuen MZ EXE Header mit einer neuer Sektiontabelle, die 2 oder 3 (3 wenn mit Resourcen, wegen einem Bug im PE EXE Loader "aller" Win32 Versionen) Sektionen hat. Die erste Sektion ist quasi leer, denn dahin wird am Ende das komprimierte Speicherabbild aus der zweiten Sektion entpackt. Die zweite Sektion enthält den Entpackercode und das komprimierte Speicherabbild. Und die dritte Sektion, falls vorhanden, enthält den Resourcenheader (wo der Resourcencontent (ausser das MainIcon, das Manifest und die Versioninfos, denn das muss unkomprmiert sein) sich selbst aber mit in dem komprimiertem Speicherabbild in komprimierter Form befindet).
Also wenn man nun die komprimierte EXE aufruft, lädt der PE EXE Loader von Windows diese 2/3 Sektionen in den Arbeitsspeicher/virtuellen Speicher und springt dann den Entpackerstubcode im Speicher an. Der Entpackerstubcode dekomprimiert dann das Originalspeicherabild der ursprünglichen Quell-EXE in die erste leere PE EXE Sektion im Arbeitsspeicher, und verarbeitet dann noch die Imports (die wurden ja mitkomprimiert, so dass ja der PE EXE Loader von Windows die selbst nicht verarbeiten kann) und sowie den TLS Kram, und dann springt der Entpackercode direkt im Arbeitsspeicher den ursprünglichen Entrypoint der ursprünglichen Quell-EXE an, und schon läuft das Original-Prg, ohne zu irgendeine Tempdatei beim Entpackvorgang zu erzeugen. Der Packer an sich ist in Delphi implementiert, und der Entpackerstubcode in Assembler.

_________________
Behindert ist man nicht, behindert wird man.