huhu da bin ich aber definitiv anderer meinung ...
gute assembler programmierer wissen wann sie besser als der compiler sind..

die wirklich guten kompressionsalgos sind aber nicht nur auf datenebene (wie huffman) sondern die grafiken werden sowieso prozedural erstellt, was in einem wenigen byte großen algorithmus in assembler resultiert..

Gut bei der affigen alten x86 Architektur wird ein guter Assemblerprogger noch Chancen haben, obwohl moderne Compiler mit mehreren Optimierungsalgos da doch warscheinlich sehr gut sind. Aber sieh dir allein mal die Architektur eines DEC Alpha oder Intel Itanium an, da glaube ich kaum das jemand die ganzen Befehle zur Strukturierung der Pipeline kennt, und gerade die sind das was ein Compiler auf den ersten Blick hinbekommt und welche einen Großteil der Performance herausschlagen.

Wie war der nachsatz bei .the Produkt: And remember, ASCII packs quite well. Pack die Daten als Strings irgendwohin, vereinfache dabei die floats, und jag das durch nen LZ... das sind auch nich mehr als ein paar Bytes und doch viel mehr als ein kleiner Tunnel oder sowas...

ok danke das mit der codeoptimierung hatte ich noch gar nichgt gesehen, looke ich ma ein bissel rund.
Aber in klartext gehts nicht so leicht(oder gar nicht).
Trotzdem danke für die hilfe.

man kann sich auch totoptimieren...
und selbst einen superoptimierender compiler kann unfähigkeit nicht wegoptimieren..

es gilt immer noch: the best optimizer is between your ears!!

habs jetzt geschafft keine ahnung warum mein vorhaben vorher nicht geklappt hat(falsche formel oder so) aufjeden fall hab ich den tunnel jetzt mit ner for schleife gemacht also in jeder runde 1vertex in sinus die zählvariable positioniert, und siehe das ergebnis ein langer unendlichtunnel in 34,8kb ^^(ohne optimierung) .
Trotzdem danke für hilfe.