Anmerkung
-
betreffend http://www.c-plusplus.net/forum/viewtopic-var-t-is-109028.html
Wofür Strings in einer 64k Demo? Was gibts da für dynamische Texte? 'ne FPS Anzeige?
64k komplett in ASM zu schreiben wäre wohl ziemlich bescheuert. Mit C/C++ kriegt man ja auch ordentliche 4ks hin, also Größe ist nicht das Problem.
@volkard: Ziemlicher Unsinn für 'ne 64k Demo new zu überladen. Bei einer Demo weiss ich genau was passiert und kann daher gleich am Anfang alle Speicher mit new holen. Und im Init interessieren die gesparten 3ms kein Schwein. Und an dem Speicher für die new Funktion scheitert die 64k sicher nicht.
kkrieger kenn ich lange. Die Namen sind nicht dynamisch, also irrelevant. Und dezimale Anzeige geht simpel per (zahl / 10 ^ Stelle ) % 10.
Bye, TGGC (Wähle deine Helden)
-
TGGC_work schrieb:
Wofür Strings in einer 64k Demo? Was gibts da für dynamische Texte? 'ne FPS Anzeige?
meistens haben echt dynamische strings keinen sinn. deswegen schlug ich ja auch auch einen null-kosten-wrapper um char* vor, der nur == und sowas anbietet. natürlich auch kein bedarf, wenn es extrem selten vorkommet, aber dann wenigstens typedef char* String.
@volkard: Ziemlicher Unsinn für 'ne 64k Demo new zu überladen. Bei einer Demo weiss ich genau was passiert und kann daher gleich am Anfang alle Speicher mit new holen.
vielleicht will man zur laufzeit des games polymorphe objkete haben, monster, helden, kekse, waffen und alle erben von einer gemeinsamen basisklasse. werden in listen aufgehobe. listen auf basisklassenzeiger. naja, new wäre da nett.
Und im Init interessieren die gesparten 3ms kein Schwein. Und an dem Speicher für die new Funktion scheitert die 64k sicher nicht.
1k gespart am code macht 1k mehr frei für obergeile texturen.
-
volkard schrieb:
meistens haben echt dynamische strings keinen sinn. deswegen schlug ich ja auch auch einen null-kosten-wrapper um char* vor, der nur == und sowas anbietet. natürlich auch kein bedarf, wenn es extrem selten vorkommet, aber dann wenigstens typedef char* String.
Nutzlos.
volkard schrieb:
@volkard: Ziemlicher Unsinn für 'ne 64k Demo new zu überladen. Bei einer Demo weiss ich genau was passiert und kann daher gleich am Anfang alle Speicher mit new holen.
vielleicht will man zur laufzeit des games polymorphe objkete haben, monster, helden, kekse, waffen und alle erben von einer gemeinsamen basisklasse. werden in listen aufgehobe. listen auf basisklassenzeiger. naja, new wäre da nett.
Und warum genau soll ich dafür jetzt new überladen?
volkard schrieb:
Und im Init interessieren die gesparten 3ms kein Schwein. Und an dem Speicher für die new Funktion scheitert die 64k sicher nicht.
1k gespart am code macht 1k mehr frei für obergeile texturen.
1k sind nichtmal 2%. Uninteressant. Um 1k zu sparen, musst du auch wesentlich mehr als 1k Code sparen, da alles gepackt wird. Ich habe eben in eine bisher "new"-lose 4k eins eingefügt. Da war sie nichtmal 100 Byte größer. Dafür kann man bestimmt noch 2 Siten geilen Scrollertext einfügen, damit man dann genau die 64k erreicht (fr08 lässt grüssen).
Bye, TGGC (Wähle deine Helden)
-
TGGC schrieb:
volkard schrieb:
meistens haben echt dynamische strings keinen sinn. deswegen schlug ich ja auch auch einen null-kosten-wrapper um char* vor, der nur == und sowas anbietet. natürlich auch kein bedarf, wenn es extrem selten vorkommet, aber dann wenigstens typedef char* String.
Nutzlos.
du hast halt keine erfahrung mit größerem ärger. es ist für dich nutzlos. es ist für mich kostenlos.
wenn ich mich später entscheiden sollte, doch eine String-klasse zu nehmen, und ich immer String (typedef) genommen habe, kann ich wirklich *alle* vorkommen, wo Strings gemeinbt waren, ersetzen. char* ist nicht automatisch findbar. naja, das ist für mich wirklich großer nutzen.
außerdem trennt es begrifflichkeiten. es trennt zwischen der abschicht einen zeiger auf einen chat zu haben (char*) und der absicht, einen string zu haben (String). bei dir waren beide nur char*. mehr begriffe mit möglichst kleinen bedeutungen, das ist ein ganz wesentlicher aspekt der OOP. und wenn du mir nicht glaubst, frag Hume und Marc++us.volkard schrieb:
@volkard: Ziemlicher Unsinn für 'ne 64k Demo new zu überladen. Bei einer Demo weiss ich genau was passiert und kann daher gleich am Anfang alle Speicher mit new holen.
vielleicht will man zur laufzeit des games polymorphe objkete haben, monster, helden, kekse, waffen und alle erben von einer gemeinsamen basisklasse. werden in listen aufgehobe. listen auf basisklassenzeiger. naja, new wäre da nett.
Und warum genau soll ich dafür jetzt new überladen?
wir erinnern und unter umständen, wie new mit konstruktoren verwachsen ist in c++?
volkard schrieb:
Und im Init interessieren die gesparten 3ms kein Schwein. Und an dem Speicher für die new Funktion scheitert die 64k sicher nicht.
1k gespart am code macht 1k mehr frei für obergeile texturen.
1k sind nichtmal 2%. Uninteressant. Um 1k zu sparen, musst du auch wesentlich mehr als 1k Code sparen, da alles gepackt wird. Ich habe eben in eine bisher "new"-lose 4k eins eingefügt. Da war sie nichtmal 100 Byte größer. Dafür kann man bestimmt noch 2 Siten geilen Scrollertext einfügen, damit man dann genau die 64k erreicht (fr08 lässt grüssen).
meine überlegungen sind nur überlegungen, wie man es perfekt kriegt. selbstverständlich runden normale linker die exe-size auf ganzahlige vielfache von 4096 byte auf. aber das ist doch kein argument, bei jedem teilaspekt 4093 byte wegzuwerfen, weil es ein beispielprogramm gibt, wo es nix ausmacht. du musst dir überlegen, dass man 100 einsparmöglichkeiten hat und jede macht nur 100 byte aus.
-
volkard schrieb:
du hast halt keine erfahrung mit größerem ärger. es ist für dich nutzlos. es ist für mich kostenlos.
wenn ich mich später entscheiden sollte, doch eine String-klasse zu nehmen, und ich immer String (typedef) genommen habe, kann ich wirklich *alle* vorkommen, wo Strings gemeinbt waren, ersetzen. char* ist nicht automatisch findbar. naja, das ist für mich wirklich großer nutzen.Vielleicht hast du halt keine Erfahrung mit 64k Demos. Du möchtest mit den Strings was machen. Die anderen aber nicht. Die werden nur an eine Ausgabefunktion übergeben und das wars. Entweder kommt die Funktion vom System und brauch dann sowieso char*. Oder man gibt den Text selbst aus, wo ich dann keine strings brauch, sondern ein Array mit Offsets in eine Bilderliste. Das könnte man optimieren. Nicht durch eine Stringklasse. Das würde sich aber wohl erst ab 10000+ Zeichen lohnen.
volkard schrieb:
volkard schrieb:
@volkard: Ziemlicher Unsinn für 'ne 64k Demo new zu überladen. Bei einer Demo weiss ich genau was passiert und kann daher gleich am Anfang alle Speicher mit new holen.
vielleicht will man zur laufzeit des games polymorphe objkete haben, monster, helden, kekse, waffen und alle erben von einer gemeinsamen basisklasse. werden in listen aufgehobe. listen auf basisklassenzeiger. naja, new wäre da nett.
Und warum genau soll ich dafür jetzt new überladen?
wir erinnern und unter umständen, wie new mit konstruktoren verwachsen ist in c++?
Und warum genau soll ich dafür jetzt new überladen?
volkard schrieb:
Ich habe eben in eine bisher "new"-lose 4k eins eingefügt. Da war sie nichtmal 100 Byte größer. Dafür kann man bestimmt noch 2 Siten geilen Scrollertext einfügen, damit man dann genau die 64k erreicht (fr08 lässt grüssen).
meine überlegungen sind nur überlegungen, wie man es perfekt kriegt. selbstverständlich runden normale linker die exe-size auf ganzahlige vielfache von 4096 byte auf. aber das ist doch kein argument, bei jedem teilaspekt 4093 byte wegzuwerfen, weil es ein beispielprogramm gibt, wo es nix ausmacht. du musst dir überlegen, dass man 100 einsparmöglichkeiten hat und jede macht nur 100 byte aus.[/quote]Hiermit zeigst du leider: du hast keine Ahnung von 4k Intros oder 64k Demos. Was der normale Linker so linkt, ist uninteressant. Wo er hinrundet auch. Glaub mir, dein new spart nix und wenn du mir nicht glaubst, frag nufan und pro.
Selbst wenn du 100*100 Byte sparst, hast du nichts davon. Das reicht nichtmal für eine 64*64 Textur mit 32Bit Farbtiefe, eine 128x128 Heightmap oder ein 3D Modell mit 400 Vertizen + Texturkoordinaten und Normalen. Die Probleme liegen also an anderen Stellen.
Nochmal die genauen Daten: Die Datei ist genau 34 Byte größer geworden. Abzüglich der Benutzung des news, bleiben damit etwa 25 Byte um new zur Verfügung zu stellen.Bye, TGGC (Wähle deine Helden)
-
TGGC schrieb:
Du möchtest mit den Strings was machen. Die anderen aber nicht. Die werden nur an eine Ausgabefunktion übergeben und das wars. Entweder kommt die Funktion vom System und brauch dann sowieso char*. Oder man gibt den Text selbst aus, wo ich dann keine strings brauch, sondern ein Array mit Offsets in eine Bilderliste. Das könnte man optimieren. Nicht durch eine Stringklasse.
eben doch durch eine string-klasse! ehemals class String{char const* data;...}; und dann hat man sich überlegt, daß man die bilderliste selber packt statt sich auf den exe-packer zu verlassen. class String(size_t index;...};. und nichs am sonstigen programm muss geändert werden.
volkard schrieb:
wir erinnern und unter umständen, wie new mit konstruktoren verwachsen ist in c++?
Und warum genau soll ich dafür jetzt new überladen?
lies meine postings nochmal. die erklärung ist ausführlich genug. oder frag was konkretes.
Hiermit zeigst du leider: du hast keine Ahnung von 4k Intros oder 64k Demos. Was der normale Linker so linkt, ist uninteressant. Wo er hinrundet auch. Glaub mir, dein new spart nix und wenn du mir nicht glaubst, frag nufan und pro.
aber du versucht mir gerade unterzugubeln, daß man nie was sparen muss, weil die gepackte exe kaum größer wird, wen man 4k einsen anlegt. logo, 4k gleiche zeichen sind sehr gut packbar. ich rede davon, ausführbaren code einzusparen. und den packt der exe-packer nicht tausend zu eins.
Selbst wenn du 100*100 Byte sparst, hast du nichts davon. Das reicht nichtmal für eine 64*64 Textur mit 32Bit Farbtiefe, eine 128x128 Heightmap oder ein 3D Modell mit 400 Vertizen + Texturkoordinaten und Normalen. Die Probleme liegen also an anderen Stellen.
wenn ich 100*100 byte spare, sind das 10k. nach dem exe-packer noch 6k. das ist von 64k ein erheblicher batzen, den man sinnvollen verwendungen zuführen kann.
Nochmal die genauen Daten: Die Datei ist genau 34 Byte größer geworden. Abzüglich der Benutzung des news, bleiben damit etwa 25 Byte um new zur Verfügung zu stellen.
hä?
keines deiner argumente ist auch nur ein wenig in die tiefe gedacht. vermutlich programmierst du auch so. immerhin startet auch keines deiner programme bei mir außer dem schiffchenfahren, was aber grafikfehler hat. und deswegen diskutiere ich auch nicht weiter mit dir darüber. es ging hier um c++ mit 64k-demos. da du keinen schimmer von c++ hast, solltest du nicht so laut argumentieren.
-
volki, danke für die Antwort. Ich habe noch einige Anmerkungen dazu.
Wie schon gesagt, wäre die Textausgabe (würde man eine eigene nutzen) in einer 64k Demo lediglich eine Anzeige von Bildern. Einige dieser würde, etwas mehr als zufällig, Buchstaben zeigen. Diese wäre schwerlich als String anzusehen und eine Klasse die es täte schwerlich als Stringklasse. Die Aufgaben einer Stringklasse, Zusammenfügen, Auseinanderschneiden und Umwandeln von Strings, sind in einer 64k Demo nicht existent.
Ich versuche dir nicht unterzujubeln, das man nichts sparen muss. Klar muss man sparen, aber an der richtigen Stelle. Wenn ich 30kb Code, 5Mb Musik und 20Mb Grafiken habe, wo fange ich dann das Sparen an? Das wollte ich damit sagen und hoffe, das es Dir nun klarer ist.
Weiterhin bleibst du leider den Beweis oder wenigstens ein Argument, welches untermauern würde, wie du 1kb oder auch nur 100 Byte sparen möchtest, schuldig. Ich habe lediglich in der Annahme, das jede deiner Lösungen auch mindestens 0 Byte benötigt, die Obergrenze einer potentiellen Einsparung aufgezeigt.
Bedauerlicherweise muss ich dir mitteilen, das deine Argumente nicht in die Tiefe gedacht sind. Es geht hier um 64k Demos. Das ist klein, aber nicht so klein. Ein Problem hab ich erst, wenn ich tollen Content einbauen will. Eine kleine Textur oder 1s Sound können allein schon 64k belegen. Wenn ich meinen gesamten Code wegoptimier, kann ich als 'ne halbe Sekunde lang 'ne halbe Textur zeigen. Hmm, man möchte aber 20 grosse Texturen und 100s Sound. Soviel Code kann man nicht sparen. Dazu kommt, Code ist ziemlich "unique". Optimiert man einen Teil davon, bringt das für den Rest nichts, weil der einfach anders ist. Interessanter ist es also, wie man eine relativ große Menge Code benutzt, um aus wahnwinzig wenig Speicher den Content zu erzeugen (welch Wortspiel). Um so ausgetüftelter und vielleicht auch größer der Code ist, um so kleiner kann man den Content repräsentieren.Fassen wir zusammen: Es ist unklar, ob deine Methode 100 Byte oder gar 100 * 100 Byte sparen könnte. Selbst 10k wären nichts im Vergleich zu dem was ich für den Content brauche und dort sparen muss. Codegröße ist nicht das vordergründige Problem in einer 64k Demo.
Ich hätte da auch noch eine konkrete Frage: Warum genau soll ich jetzt new überladen?
Ich finde es sehr schade, das du meine Programme nicht starten kannst. Da verpasst du ja wirklich was. Vielleicht hast du ja im Bekanntenkreis jemand, der weiss wie man Programme startet und dir weiterhelfen kann?
Und immer dran denken: fein oktal lernen, sons wird er mal schwule kinder bekommen. (volkard)
Bye, TGGC (Keine Macht den Dummen)
-
Tschuldigung, musste meine Posts im Originalthread entfernen, weil volkard seine Felle davonschwimmen sieht.
Bye, TGGC (Wähle deine Helden)
-
TGGC schrieb:
Tschuldigung, musste meine Posts im Originalthread entfernen.
Das ist der Beweis. TGGC = Marc++us
-
User987658756 schrieb:
TGGC schrieb:
Tschuldigung, musste meine Posts im Originalthread entfernen.
Das ist der Beweis. TGGC = Marc++us
Bye, TGGC (Wähle deine Helden)
