spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ist eigentlich auch nichts anderes, nur dass sf::Texture die Bilder auf der Grafikkarte speichert.

Richtig. Wie Du sicher weißt, kannst Du in C/C++ so ein Array auch als Zeiger auf das erste Element benutzen. Die loadFromMemory()-Funktion nimmt einen Zeiger und eine Größe in Bytes - die solltest Du dann bei der Erzeugung des Array-Quelltextes am besten mit speichern. Oder Du nimmst gleich ein std::array, dass Dir die Handarbeit rund um die Größe erspart.

Ich habe bei meinen Spielen immer einen Ordner, in dem die ganzen Grafiken landen. Das Spiel gebe ich dann in einer zip oder rar-Datei weiter. Das Fenstericon wurde bei mir über VC++ eingebunden und darüber direkt in die .exe eingebettet. Wenn man alles in den Quellcode mit reinschreibt, dann ist es natürlich schwer, diese Grafiken auszutauschen. Man sollte deshalb möglichst nicht mit Platzhaltergrafiken sondern mit den Fertigen arbeiten.

Du könntest die Datei mit z.B. Base64 Codieren/Decodieren. Und dann in einem eigenen Header und dazu kompilieren.
Base64 ist sehr einfach zu implementieren. Und es ist so möglich beliebige Dateien im Ganzen als Zeichenkette in seinen Programmtext einzubinden. Nachteil ist eine ca. 35% Größenzunahme durch die Codierung. Aber dir ging es ja eh nur um wenige Daten.

Ich habe mal das Beispiel von Wikipedia genommen.

Wikipedia Base64
RFC 3548

Da ist die Hex-Variante aber schlanker, kompiliert vermutlich nur länger.

Im Grunde genommen macht es das Ressourcensystem von Qt genau so. Die haben ja bekanntlich diesen leicht fragwürdigen zusätzlichen Schritt vor dem eigentlichen Compilieren, aber man muss sagen, dass damit sehr nette Dinge gehen. Der Workflow ist ungefähr so:

Man klickt sich eine Ressourcendatei zusammen, in der all die relativen Pfaden zu deinen Dateien stehen, die später mit in die exe sollen. Beim compilieren wird daraus dann eine Sourcedatei (mit Header) erzeugt, die in der Idee dem Beispiel von H5:: entspricht. Über die Variablennamen kann man dann an die Daten kommen, aber alle Qt Funktionen, die irgendetwas aus einer Datei laden können über bestimmte Pfadtypen (":/images/cut.png") auch direkt aus Ressourcen laden, ohne irgendeine 'LoadFromMemory'-Funktion.

Das eigentlich nette daran ist natürlich, dass die Code-Dateien bei jedem Compilieren neu erstellt werden und somit Änderungen in deinen Dateien direkt übernommen werden können. Garantiert gibt es schon Tools, die aus einer Dateien z.B. die Base64-Kodierung erzeugen, vermutlich gibt es sogar welche, die dir direkt die entsprechenden Source-Dateien erzeugen. Wenn du dir ein wenig Mühe gibts, und deine Projekteinstellungen anpasst, könntest du ein solches Tool auf vor jedem Compilieren automatisch starten lassen.

Achja: Qt benutzt statt Base64 folgendes:

Durch diese Notation mögen zwar vielleicht die Quellcodedateien etwas länger werden, aber die Daten stehen später 1zu1 in der exe und sind kein Base64-String, der erst noch geparst werden müsste. Dadurch hast du also quasi keinen Overhead.

Ja stimmt. Ich musste grad selbst ein bisschen schmunzeln. Ich glaube das liegt daran, dass ich berufsbedingt Schweißausbrüche bekommen wenn jemand Plattformunabhängig sagt. Da bedeutet dann auch mal ein Byte != 8Bit u.A.
Ich denke so würde ich auch zur einfachen Byte-Repräsentation greifen. Aber die Kanone würde den armen Spatz auch treffen.