spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Jonathan_Klein«

Und zu guter Letzt natürlich wo es nur irgendwie geht auf so einen Rotz wie DLLs am besten ganz verzichten (-> statisch Linken). Spart eine Menge Ärger.

Das als generellen Tipp zu einem Anfänger zu sagen, halte ich für nicht sehr gut. DLLs haben ihre Gründe. Manchmal ist es aufgrund von Lizenzen sogar gar nicht erlaubt statisch zu linken. Und so viele Fehler, wie ich bei SFML sehe, die nur durch den Wunsch des statischen Linkens entstehen... da ist die DLL-Variante oft einfacher zu konfigurieren. Kann mir nicht vorstellen, dass das bei SDL groß anders aussieht.

Richtig, das war etwas zu emotional und vermutlich nicht objektiv genug, und auf jeden Fall überhaupt nicht belegt.

Darum vielleicht noch eine kurze Erklärung, warum ich die Dinger nicht mag:

Soweit ich das sehe, Erfüllen DLLs 3 Ziele: Verringerung des Speicherverbrauches durch Mehrfachnutzung, Patchbarkeit einzelner Komponenten, Plugins. Ich würde einfach mal behaupten, dass Binary-Größes seit Jahrzehnten kein Problem mehr sind, zumindest in den typischen Fällen (wie ein C++-Hobbyprojekt unter Windows). Wiederverwendbarkeit ist etwas, das ich in der Praxis einfach nicht sehe, auf meinem Rechner finden sich z.B. 34 verschiedene zlib1.dll's - in vielen unterschiedlichen Versionen. Patchbarkeit ist etwas zweischneidiger, für einen Entwickler macht es keinen Unterschied, ob der eine große, oder 20 kleine Dateien patcht, aber LGPL schreibt z.B. vor, dass der User seine DLLs selber patchen können muss. Wer auch immer sowas jemals macht, aber nun gut. Zu Plugins gibt es wenig zu sagen, da gibt es wohl oft keinen anderen Weg.

Auf der Kehrseite hatte ich schon ungefähr eine Milliarde mal Probleme mit dlls, die mich viel Zeit gekostet haben. Es fängt schon damit an, dass man ständig Dateien hin und her kopieren muss. Das wäre jetzt nicht weiter schlimm, aber es ist halt doch jedes mal eine nervige Suche und wenn in deinem Programm Ordner immer noch 5 QT-Dlls liegen, ist das auch nicht gerade übersichtlich.
Dann kommt man vielleicht auf die Idee, Umgebungsvariablen zu benutzen. Und das funktioniert auch erstmal gut und man muss nicht kopieren doch dann installiert man irgendein Programm (MikTeX oder so), das so nett ist und sämtliche Abhängigkeiten per dll in seinem Verzeichnis zu haben, und obendrein so nett ist, sich in die Umgebungsvariablen einzutragen, damit man es von überall benutzen kann und dann noch so nett ist, und sich ganz oben einträgt, damit es selber auf jeden Fall und immer funktioniert, weil ihm alle anderen Programme egal sind. Und plötzlich stürzt dein Programm beim starten ab, weil es eine falsche DLL-Version lädt, aber du kriegst keine Fehlermeldung die irgendwie weiter hilft. Und dann willst du Debuggen (hast ja ne Kleinigkeit am eigenen Programm geändert, die eigentlich funktionieren müsste), aber die Debug-Version läuft super (Weil andere DLLs), und dann versuchst du die Release-Version zu debuggen, aber dein Programm stürzt vor der ersten Zeile schon ab, und zwei Stunden später kriegst du raus, dass du von Anfang an alles richtig gemacht hattest, aber DLLs einfach vollkommen kaputt sind. Nur ein Beispiel von vielen.

Früher dachte ich mal, es wäre cool, sein Projekt in kleine Bibliotheken aufzuteilen und als DLLs zu linken. Weil das alle so machen und es sich irgendwie erwachsen anfühlt. Heute bin ich nicht mehr 12 Jahre alt und meide DLLs wo es irgendwie nur geht. Weil ich mich nicht erinnern kann, auch nur ein einziges mal davon profitiert zu haben, aber sehr wohl schon hunderte male Probleme damit hatte.

Zitat von »chris22«

Ich musste zwar jetzt als x86 kompilieren statt x64 (konnte ich im sourcecode nicht ändern, warum auch immer)

Das ist keine Source-Code-Sache, sondern eine Einstellung in Visual Studio.

Zitat von »chris22«

Ich habe mir nun die source dateien der SDL geladen und diese unter Visual Studio 2015 neu kompiliert.

Ich hab auch denselben Fehler, den du gehabt hast:
1>sdlmain.lib(SDL_win32_main.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__fprintf".
1>sdlmain.lib(SDL_win32_main.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp____iob_func".

Kannst du mir erklären, was die source Dateien der SDL sind und wie man die kompiliert (Muss man sie einfügen, und dann das Projekt neu kompilieren?)

DANKE!!!
Jetzt kann ich endlich stundenlang mein supertolles Spiel spielen
Schaut gar nicht mal so schlecht aus, wie gedacht

Hallo, ich stand vor demselben Problem:

Meine Lösung:

in die main.cpp folgende Zeilen einfügen:


und in den projekteigenschaften -> Linker -> Eingabe -> Zusätzliche Abhängigkeiten -> "legacy_stdio_definitions.lib" einfügen (unter sdl.lib und sdlmain.lib)

achso, und bei Visual Studio 2017 gibt es diese ominöse include datei "pch.h", achtet darauf, dass diese IMMER am Anfang steht und danach die anderen includes kommen, hat mich ca 2 Stunden gekostet...

vielleicht hilft es einem!
gruß
totem