...und wieder SDL-Probleme


Modran

Member
Joined
Jan 11, 2007
Messages
218
Location
NRW
Website
voynich-ms.de
WEBSITE
http://voynich-ms.de/Merlin
LOCATION
NRW
Hurra!
Ich habe es geschafft, CodeBlocks mit allem Krempel aufzusetzen (http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,45,2023) und sogar ein kleines Testprogramm für den GP2X erfolgreich compilieren und starten können (einfach ein Bild per SDL_LoadBMP angezeigt).

Nun wollte ich dasselbe mit einem jpg machen, habe die SDL_image eingebunden und bekomme dutzende Fehlermeldungen ausgeworfen, alle in der Form von:
IMG_png.c: (.text+0x60) undefined reference to 'png_sig_cmp'
Leider habe ich zu wenig Erfahrung mit C++, CodeBlocks und SDL, daher finde ich keinen Ansatz, wo ich den Fehler suchen muß. Kann mir jemand helfen?
 
hallo,

meine c++ kenntnisse sind auch ziemlich gering... der fehlermeldung nach zu urteilen hast du vergessen, die anweisung so umzuschreiben, das statt der png lib, die jpg lib verwendet wird...
IMG_png.c: (.text+0x60) undefined reference to 'png_sig_cmp'
zeigt, das die png lib nix mit der jpg datei anfangen kann...

mehr tips kann ich grad nicht geben... evtl kan man dir helfen, wenn du uns mal dein source zeigst :)

lg gp
 
Naja, wenn du es mit "allem Krempel" aufgesetzt hast dann musst du leider auch "allen Krempel"
mit einbinden der in einer von dir verwendeten Bibliothek eine Abhängigkeit hat
(glaub ich zumindest .. wenn vielleicht auch nur bei "-static").

Sprich du hast SDL_image mit JPG und PNG kompiliert.
Dann musst du auch zu SDL_image auch noch jpg und png linken.

Wie immer.. alle Angaben ohne Gewähr
:wink:
 
Ich vergaß zu erwähnen: wenn ich es für Windows compiliere, dann funzt es. Also entweder benötigt die GP2X-Version vom SDL andere Dateien, oder irgendeine davon ist defekt. Ich weiß nur nicht, wo ich in dem ganzen Wust anfangen soll zu suchen. Man kann sich als Einsteiger von den ganzen Bibliotheken ganz schön erschlagen fühlen, vor allem wenn man sie auch noch für zwei verschiedene Systeme benötigt. :)

Rein theoretisch (laut SDL-Tutorial) habe ich nur die SDL_image (und SDL_image.h) einzubinden. Für Windows reicht das auch - aber für Windows linke ich nicht -static. Mhhhh ...

Edit:
Bin einen Schritt weiter. Hab in den Linker-Optionen "-lpng12" hinzugefügt (obwohl ich nur jpg laden will, aber SDL_image benötigt die wohl trotzdem). Nun sieht die Fehlermeldung etwas anders aus:
pngrtran.c: (.text+0x1088) undefined reference to 'pow'
Ich habe keine Idee, welche Datei da nun schon wieder fehlen könnte. :(
 
Die Reihenfolge ist auch wichtig, bewege mal dein -lm testweise vor -lpng12. Ich habe kein Plan wie die Reihenfolge richtig ist, sorry.
 
Mit der Reihenfolge hatte ich auch schon herumgespielt, da ich in einem älteren Thread sowas schonmal gelesen hatte, aber ohne Erfolg.

Ich hab es jetzt trotzdem hinbekommen. Fragt mich nicht, woran es lag. Ich habe Code::Blocks nochmal völlig gesäubert und neu eingerichtet (diesmal anhand einer anderen Anleitung) - daraufhin compilierte es sauber für den GP2X, aber nicht mehr für Win32. Doch nach ein bischen gefriemel und neucompilation einiger dlls ging auch das wieder.
Hurra, jetzt kanns endlich losgehen mit dem Entwickeln. :)

Danke für die Ratschläge, ich werde sicher bald neue brauchen. ;)
 
Welche Version von Code::Blocks nutzt du? Die nightly builds stuerzen naemlich bei mir oft ab. Hast du da auch solche Erfahrungen gemacht?

Kannst du mal was zu der Performance von ~400 Blits (16x16) +300 Alphablits (16x16) sagen?

Sprich testweise einfach 2 Surfaces (png,16x16, einmal mit sowie ohne alphakanal) jweils 400/300 mal auf den screen blitten?
 
Ich hab jetzt die nightly build von vorgestern (7.3.) - bisher keine Abstürze (toi toi toi).

Grafik muß ich noch ein wenig testen, aber bisher wirkt es ziemlich langsam (wobei 256-color-Bilder deutlich schneller sind als truecolor), obwohl ich eigentlich dachte, meine SDL-Version wäre bereits Hardware-optimiert. Für einen Scrolltext auf dem GP2X brauch ich jedenfalls keine Wartezyklen, ganz im Gegenteil.
 
wie kann das sein das eine 8bit oberfläche schneller als die eigentliche 16bit oberfläche ist... hast du eine autoconversion der sdl oberfläche eingeschalten ?
 
Moment... Er hat was von Truecolor gesagt, also 24/32 Bit. Klar, dass das langsamer ist das auf die nativen 16 Bit umzurechnen, als bei 8 Bit mal kurz in der Palette nachzuschauen.
 
Back
Top