[OpenGL]GLaux-Ersatz?

[Gast]

Hi Leute,

In den Nehe OpenGL Tutorials wird zum Laden von Texturen aus Grafikdateien ja immer die GLaux-Bibliothek verwendet, die für diesen Zweck die Funktion auxDIBImageLoad anbietet.
Jetzt habe ich anderswo gehört, man sollte GLaux nicht mehr verwenden, weil die schon sehr veraltet sei.
Nun gut, aber was soll man denn stattdessen nehmen? Texturen laden wir ja schließlich noch müssen.

Ich hatte mal angenommen, GLUT würde eine solche Funktion anbieten, aber dem scheint nicht so zu sein: in den mir bekannten GLUT-Tuts wird eine selbstgebastelte LoadImage-Funktion verwendet, die mit low-level-Dateioperationen (in C) wie fopen, getc, fseek und fread arbeitet.

Irgendwo habe ich auch mal eine Konstruktion mit SDL gesehen:
SDL_Surface *temp = IMG_Load(...); aber da ist IMG_Load auch nur eine selbstgeschriebene Funktion und nicht Bestandteil von SDL.

[Simon]

IMG_Load() gehört zu SDL_Image und dieses unterstützt eine Reihe von Formaten wie tga, png, jpeg, bmp, etc. ;)

[Trap]

Da gibts genug Alternativen, z.B.:
http://openil.sourceforge.net/
oder http://freeimage.sourceforge.net/
oder http://corona.sourceforge.net/
oder http://www.libsdl.org/projects/SDL_image/

[Gast]

jo, danke Leute :)

[Gast]

ich hab mir jetzt mal SDL_Image angeguckt.
Schlechte Nachricht Nummer 1: die zugehörige Dokumentation ist nur für Unix. Vielleicht könnte man da mit dem Unix-Emulator MSys was reißen, aber den packe ich auf gar keinen Fall ein weiteres Mal an.
Schlechte Nachricht Nummer 2: die Win32-Distribution enthält nur DLLs, keine Import-Libs. Man darf sich also erstmal ne eigene Funktion schreiben, die mit LoadLibrary und GetProcAddress hantiert :(

[del_4901]

http://tgtl.sourceforge.net/

[Simon]

Gast[/POST]']ich hab mir jetzt mal SDL_Image angeguckt.
Schlechte Nachricht Nummer 1: die zugehörige Dokumentation ist nur für Unix. Vielleicht könnte man da mit dem Unix-Emulator MSys was reißen, aber den packe ich auf gar keinen Fall ein weiteres Mal an.
Ähm #1: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fimage - sieht ja nicht sehr nach Unix aus? :confused:

Schlechte Nachricht Nummer 2: die Win32-Distribution enthält nur DLLs, keine Import-Libs. Man darf sich also erstmal ne eigene Funktion schreiben, die mit LoadLibrary und GetProcAddress hantiert :(
Ähm #2: Das SDK enthält doch Libs und Header Files: http://www.libsdl.org/release/SDL-devel-1.2.10-VC6.zip
:confused:

[Gast]

Simon[/POST]']Ähm #1: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fimage - sieht ja nicht sehr nach Unix aus? :confused:unter dem von Trap angegebenen
http://www.libsdl.org/projects/SDL_image/
findet man als Link zu Documentation:
http://jcatki.no-ip.org/SDL_image/
Das wiederum verlinkt nach
http://jcatki.no-ip.org/SDL_image/SDL_image_frame.html
und dort steht unter Getting started:
./configure
make
make installund das sieht auf jeden Fall nach Unix aus.

Simon[/POST]']Ähm #2: Das SDK enthält doch Libs und Header Files: http://www.libsdl.org/release/SDL-devel-1.2.10-VC6.zip
:confused:in http://www.libsdl.org/projects/SDL_image/release/SDL_image-1.2.5-win32.zip
finde ich nur folgende Dateien:
jpeg.dll
libpng12.dll
libtiff.dll
Readme.txt (da steht aber irgendwelchem Lizenz-Kram nichts drin)
SDL_Image.dll
zlib.dll

Der von dir genannte Link ist - wie sein Name schon erahnen läßt - nur für Visual C++.

Allerdings habe ich etwas herausgefunden: SDL_Image ist Bestandteil des normalen SDL-Paketes, indem auch eine libSDL_image.a drin ist.

Allerdings führt das nur auf schlechte Nachricht Nummer 3: SDL_Image kollidiert mit GLUT. Sobald ich die SDL_Image.g include, findet der Linker keine WinMain mehr. Ich schätze das hängt damit zusammen, daß SDL darauf ausgelegt ist, ebenso wie GLUT die Applikation in eigener Regie zu kapseln. D.h. man kann SDL_Image nur dann benutzen, wenn das Hauptprogramm auf die Basis von SDL gestellt wird.

Fazit: unbrauchbar :(

[Gast]

Simon[/POST]']Ähm #1: http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fimage - sieht ja nicht sehr nach Unix aus? :confused:ich hab mir deinen Link noch einmal angeguckt, da steht doch überhaupt gar nichts zur Installation???

[Simon]

Gast[/POST]']unter dem von Trap angegebenen
http://www.libsdl.org/projects/SDL_image/
findet man als Link zu Documentation:
http://jcatki.no-ip.org/SDL_image/
Das wiederum verlinkt nach
http://jcatki.no-ip.org/SDL_image/SDL_image_frame.html
und dort steht unter Getting started:
und das sieht auf jeden Fall nach Unix aus.
Jo. Aber deswegen ist das noch lange keine Dokumentation für Unix :|
Wie du mit deinem Compiler compilierst und linkst, ist halt deine Sache. Kann doch die Doku nicht wissen.

in http://www.libsdl.org/projects/SDL_image/release/SDL_image-1.2.5-win32.zip
finde ich nur folgende Dateien:
jpeg.dll
libpng12.dll
libtiff.dll
Readme.txt (da steht aber irgendwelchem Lizenz-Kram nichts drin)
SDL_Image.dll
zlib.dll
Ist klar. Ist schließlich nur die Runtime und kein SDK ;)

Der von dir genannte Link ist - wie sein Name schon erahnen läßt - nur für Visual C++.
Du hast ja nicht gesagt, welchen Compiler/IDE du verwendest. Also bin ich mal von VS 2005 EE ausgegangen ;)

Allerdings führt das nur auf schlechte Nachricht Nummer 3: SDL_Image kollidiert mit GLUT. Sobald ich die SDL_Image.g include, findet der Linker keine WinMain mehr. Ich schätze das hängt damit zusammen, daß SDL darauf ausgelegt ist, ebenso wie GLUT die Applikation in eigener Regie zu kapseln. D.h. man kann SDL_Image nur dann benutzen, wenn das Hauptprogramm auf die Basis von SDL gestellt wird.
Nö. Also hier funktioniert SDL_Image mit vielen versch. Compilern und Programmen. SDL ist nicht darauf ausgelegt, "die Applikation in eigener Regie zu kapseln.". Wie kommst du darauf?

Fazit: unbrauchbar :(
Nö. =)

[Simon]

Gast[/POST]']ich hab mir deinen Link noch einmal angeguckt, da steht doch überhaupt gar nichts zur Installation???
Äh, ja. Das ist die API Referenz. Wie du Bibliotheken installierst, steht im Handbuch/Hilfe zu deinem Compiler/IDE. Was benutzt du denn?

[Trap]

Ich würd mich nicht von vornherein auf SDL_Image festlegen, SDL ist zwar bekannt, das muss aber nicht heißen, dass die anderen Bibliotheken schlechter sind.

[Gast]

Simon[/POST]']Jo. Aber deswegen ist das noch lange keine Dokumentation für Unix :|doch, weil es dokumentiert, wie SDL_Image unter Unix installiert wird.

Simon[/POST]']Wie du mit deinem Compiler compilierst und linkst, ist halt deine Sache. Kann doch die Doku nicht wissen.ich rede von der Installation, sprich: wie ich es ermögliche, daß mein Compiler und Linker in die Lage versetzt werden, SDL_Image verwendende Programm zu compilieren und zu linken. Wenn die Doku weiß, wie das für Unix geht, warum sollte sie es für Windows nicht wissen?

Simon[/POST]']Ist klar. Ist schließlich nur die Runtime und kein SDK ;)also unbrauchbar.

Simon[/POST]']Du hast ja nicht gesagt, welchen Compiler/IDE du verwendest. Also bin ich mal von VS 2005 EE ausgegangen ;)ich habe glaube ich deutlich gemacht, daß ich die SDL_Image Version für Win32 benötige. Und wenn ich Win32 meine, meine ich auch Win32. Wenn ich VS will, werde ich das schon sagen.

Simon[/POST]']Nö. Also hier funktioniert SDL_Image mit vielen versch. Compilern und Programmen. das nützt mir wenig, solange es das bei mir nicht tut.

Simon[/POST]']SDL ist nicht darauf ausgelegt, "die Applikation in eigener Regie zu kapseln.". Wie kommst du darauf?z.B. weil man mit SDL ein Programm wie dieses schreiben kann:
/* The screen surface */
SDL_Surface *screen = NULL;

int
main (int argc, char *argv[])
{
char *msg;
int done;

/* Initialize SDL */
SDL_Init (SDL_INIT_VIDEO);

/* Set 640x480 16-bits video mode */
screen = SDL_SetVideoMode (640, 480, 16, SDL_SWSURFACE | SDL_DOUBLEBUF);
SDL_WM_SetCaption ("SDL MultiMedia Application", NULL);

done = 0;
while (!done)
{
SDL_Event event;

/* Check for events */
while (SDL_PollEvent (&event))
{
switch (event.type)
{
case SDL_KEYDOWN:
break;
case SDL_QUIT:
done = 1;
break;
default:
break;
}
}

/* Draw to screen */
draw ();
}

return 0;
}Die WinMain, WndProc und sämtliche Win32-API Funktionsaufrufe (z.B. CreateWindow) sind von SDL gekapselt.

[del_4901]

Armer Simon .. tust mir echt Leid ... *im Ernst jetzt*

[Simon]

Gast[/POST]']doch, weil es dokumentiert, wie SDL_Image unter Unix installiert wird.
Tut es nicht. Da benutzt man für gewöhnlich einen Paketmanager. Aber du weißt ja anscheinend alles besser :|

ich rede von der Installation, sprich: wie ich es ermögliche, daß mein Compiler und Linker in die Lage versetzt werden, SDL_Image verwendende Programm zu compilieren und zu linken.
Warum sagst du das nicht gleich? :|
Normalerweise versteht man unter "Dokumentation" nicht: "Wie installiere ich dieses Stück Software für meinen Compiler?". Und da die Autoren von SDL_image sicherlich nicht für jeden erdenklichen Compiler Dokumentation schreiben, steht das dort auch nicht. Ich wiederhol mich: Bibliotheken installiert man für einen bestimmten Compiler. Und solange du den nicht kundtust, kann dir hier nur schwerlich jemand helfen...

Wenn die Doku weiß, wie das für Unix geht, warum sollte sie es für Windows nicht wissen?
Weiß sie nicht! Sie zeigt nur, wie es mit den GNU autoconf/automake Tools geht und das hat mal gar nix mit Unix zu tun.

ich habe glaube ich deutlich gemacht, daß ich die SDL_Image Version für Win32 benötige. Und wenn ich Win32 meine, meine ich auch Win32. Wenn ich VS will, werde ich das schon sagen.
:confused: Häh?
Bibliotheken installiert man für einen spezifischen Compiler...und wie das geht, steht im Handbuch/Hilfe zu deinem Compiler/IDE.
Ich kenne jedenfalls keinen Compiler der sich "Win32" nennt. Ich kenne ICC, GCC und MS VC++ für Win32...

@AlphaTier: Man tut, was man kann ;)

[Gast]

Simon[/POST]']Tut es nicht.dann steht da vermutlich nur zum Spaß:

Generally, in UNIX-like environments, installation consists of:
./configure
make
make install


Simon[/POST]']Warum sagst du das nicht gleich? :|habe ich.

Simon[/POST]']:confused: Häh?
Bibliotheken installiert man für einen spezifischen Compiler...das ist jetzt aber sehr blöd, weil das nämlich bedeutet, daß SDL_Image nur unter VC funktioniert. Für andere Compiler ist auf
http://www.libsdl.org/projects/SDL_image/
nämlich nichts angegeben, nur für Betriebssysteme.

[Simon]

Benutz einfach DirectX, ich hab keine Lust mehr...

[Gast]

Simon[/POST]']Nö. Also hier funktioniert SDL_Image mit vielen versch. Compilern und Programmen. hm, bei nem Programm wo das Applikationsgrundgerüst direkt über die Win32-API verwaltet wird (also mit WinMain und CreateWindow) tritt der Linker-Error nicht auf, jedenfalls nicht beim bloßen Includen der SDL_Image.h, nur halt wenn ich's mit GLUT mache. Vielleicht liegt's ja an GLUT.
Hast du bei dir getestet, ob SDL_Image mit GLUT zusammenarbeitet?

[Gast]

Simon[/POST]']Benutz einfach DirectXwarum?

[del_4901]

Weil du ihn mit deinem [Halb]wissen vergrault hast.

[GastNr2]

Junge, sag einfach welchen Compiler/IDE du benutzt.

BorlandC++? DevCpp?

[Gast]

AlphaTier[/POST]']Weil du ihn mit deinem [Halb]wissen vergrault hast.und warum sollte ich deswegen DirectX verwenden?

[Xmas]

Gast[/POST]']das ist jetzt aber sehr blöd, weil das nämlich bedeutet, daß SDL_Image nur unter VC funktioniert. Für andere Compiler ist auf
http://www.libsdl.org/projects/SDL_image/
nämlich nichts angegeben, nur für Betriebssysteme.
Der Quellcode und die Makefiles sind da, daraus kann man sich in der Regel ableiten wie man die Bibliotheken für den gewünschten Compiler (den du ja immer noch nicht genannt hast) bauen muss.

Gast[/POST]']hm, bei nem Programm wo das Applikationsgrundgerüst direkt über die Win32-API verwaltet wird (also mit WinMain und CreateWindow) tritt der Linker-Error nicht auf, jedenfalls nicht beim bloßen Includen der SDL_Image.h, nur halt wenn ich's mit GLUT mache. Vielleicht liegt's ja an GLUT.
Hast du bei dir getestet, ob SDL_Image mit GLUT zusammenarbeitet?
Könnte es vielleicht daran liegen dass dein GLUT-Programm gar keine WinMain-Funktion besitzt, weil es mit main einfacher ist die Kommandozeilenparameter argc/argv an glutInit zu übergeben?

[Gast]

Xmas[/POST]']Könnte es vielleicht daran liegen dass dein GLUT-Programm gar keine WinMain-Funktion besitztd.h. es ist wie ich vermutet habe, daß SDL_image nicht mit GLUT zusammenarbeitet, weil es entweder eine WinMain oder ein von SDL selbst gekapseltes Applikationsgerüst (das ja ebenso wie GLUT ohne sichtbare WinMain auskommt) haben will?

[Simon]

Gast[/POST]']d.h. es ist wie ich vermutet habe, daß SDL_image nicht mit GLUT zusammenarbeitet, weil es entweder eine WinMain oder ein von SDL selbst gekapseltes Applikationsgerüst (das ja ebenso wie GLUT ohne sichtbare WinMain auskommt) haben will?
NEIN!

[Gast]

Simon[/POST]']NEIN!sondern? XMas hat ja offenbar schon bestätigt, daß eine SDL_image eine WinMain sehen will.
Die Ausnahme muß natürlich der Fall sein, daß SDL die Applikation kapselt, um den Sourcecode plattformunabhängig zu machen und dazu logischerweise ohne sichtbare WinMain auskommen zu lassen.

[Simon]

Weil ich gerade ne totlangweilige Vorlesung habe, habe ich dir mal den Gegenbeweis zusammengetippt (Dank an lighthouse3d.com für das GLUT Source Gerüst):


#include <cstdio>
#include <iostream>
#include <SDL_image.h>
#include "glut.h"


#ifdef WIN32
#undef main
#pragma comment(lib, "SDL_image.lib")
#pragma comment(lib, "SDL.lib")
#endif

using std::cout; using std::endl;

float angle = 0.0;

void changeSize(int w, int h) {

// Prevent a divide by zero, when window is too short
// (you cant make a window of zero width).
if(h == 0)
h = 1;

float ratio = 1.0* w / h;

// Reset the coordinate system before modifying
glMatrixMode(GL_PROJECTION);
glLoadIdentity();

// Set the viewport to be the entire window
glViewport(0, 0, w, h);

// Set the correct perspective.
gluPerspective(45,ratio,1,1000);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(0.0,0.0,5.0,
0.0,0.0,-1.0,
0.0f,1.0f,0.0f);

cout << "Loading files with SDL_Image..." << endl;
SDL_Surface *img0 = IMG_Load("test.bmp");
if(!img0)
{
cout << "Failed to load first image!" << endl;
return;
}
SDL_FreeSurface(img0);

SDL_Surface *img1 = IMG_Load("test.png");
if(!img1)
{
cout << "Failed to load second image!" << endl;
return;
}
SDL_FreeSurface(img1);

cout << "Both files loaded successfully!" << endl;
}


void renderScene(void) {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

glPushMatrix();
glRotatef(angle,0.0,1.0,0.0);
glBegin(GL_TRIANGLES);
glVertex3f(-0.5,-0.5,0.0);
glVertex3f(0.5,0.0,0.0);
glVertex3f(0.0,0.5,0.0);
glEnd();
glPopMatrix();
angle++;
glutSwapBuffers();
}

int main(int argc, char **argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA);
glutInitWindowPosition(100,100);
glutInitWindowSize(320,320);
glutCreateWindow("Lighthouse 3D - GLUT Tutorial");
glutDisplayFunc(renderScene);
glutIdleFunc(renderScene);
glutReshapeFunc(changeSize);
glutMainLoop();

return 0;
}


Wehe es sagt jetzt einer was zum Code Stil oder so ;D

So, und jetzt erzähl mir nochmal, man kann GLUT und SDL_Image nicht zusammen verwenden :P
XMas hat übrigens was anderes gesagt, als du hier behauptest...

[Gast]

Simon[/POST]']
So, und jetzt erzähl mir nochmal, man kann GLUT und SDL_Image nicht zusammen verwenden :Pdas freut mich für dich, daß es bei dir funktioniert, aber dadurch hört mein Linker nicht auf, über das Fehlen einer WinMain zu meckern, sobald ich in ein GLUT-Programm die SDL_image.h include.

Simon[/POST]']XMas hat übrigens was anderes gesagt, als du hier behauptest...und zwar was? Egal wie oft ich XMas' Post auch lese, lese ich da immer folgendes raus:
Der Linker Error kommt daher, daß mein Programm keine WinMain hat.
Mein Programm hat keine WinMain, weil es ein GLUT-Programm ist, und GLUT eine main anstelle einer WinMain verwendet, da es auf Plattformunabhängigkeit ausgelegt ist (die WinMain existiert vermutlich irgendwo gekapselt in der Win32-Distribution von GLUT, aber eben nicht im Sourcecode, da dieser plattformunabhängig gehalten werden soll).

[del_4901]

Gast[/POST]']das freut mich für dich, daß es bei dir funktioniert, aber dadurch hört mein Linker nicht auf, über das Fehlen einer WinMain zu meckern, sobald ich in ein GLUT-Programm die SDL_image.h include.

und zwar was? Egal wie oft ich XMas' Post auch lese, lese ich da immer folgendes raus:
Der Linker Error kommt daher, daß mein Programm keine WinMain hat.
Mein Programm hat keine WinMain, weil es ein GLUT-Programm ist, und GLUT eine main anstelle einer WinMain verwendet, da es auf Plattformunabhängigkeit ausgelegt ist (die WinMain existiert vermutlich irgendwo gekapselt in der Win32-Distribution von GLUT, aber eben nicht im Sourcecode, da dieser plattformunabhängig gehalten werden soll).

Poste einfach deinen Quellcode, damit ich auch mal was zum lachen hab.

[del_4901]

Naja werd ich ihm mal von seinem Leiden befreien.. obwohl ich noch nichts mit der SDL gemacht habe ... vermute ich mal das dir entweder das:

#undef main

fehlt ... oder deine main nicht so aussieht:

int main(int argc, char **argv)

Wenn du dann immernoch einen Linker fehler bekommst ... dann solltest du wirklich DirectX nehmen ^^

[Gast]

AlphaTier[/POST]']Naja werd ich ihm mal von seinem Leiden befreien.. obwohl ich noch nichts mit der SDL gemacht habe ... vermute ich mal das dir entweder das:

#undef mainund wo kommt das hin?

[Gast]

hab mal ein bißchen gegoogelt.
Soll ich also davon ausgehen, daß du, Simon und XMas mir diese wichtige Präprozessoranweisung in arglistiger, böswilliger Absicht verschwiegen habt?

[del_4901]

Gast[/POST]']hab mal ein bißchen gegoogelt.
Soll ich also davon ausgehen, daß du, Simon und XMas mir diese wichtige Präprozessoranweisung in arglistiger, böswilliger Absicht verschwiegen habt?

Wir wollten nur das du mal richtig die Dokumentation ließt, und nicht nur "überfliegst"

[Simon]

Gast[/POST]']und wo kommt das hin?
Also bei mir ist es Zeile 8 (wenn ich mich nicht verzählt habe ;D ). Vielleicht solltest du mal schauen, was drumherum steht...

Gast[/POST]']hab mal ein bißchen gegoogelt.
Soll ich also davon ausgehen, daß du, Simon und XMas mir diese wichtige Präprozessoranweisung in arglistiger, böswilliger Absicht verschwiegen habt?
Jep, wir haben deine nicht vorhandenen Fehlermeldungen sowie Umgebungsbeschreibungs eiskalt ignoriert und dir die ganze Zeit was falsches erzählt :|

[Xmas]

Gast[/POST]']und zwar was? Egal wie oft ich XMas' Post auch lese, lese ich da immer folgendes raus:
Der Linker Error kommt daher, daß mein Programm keine WinMain hat.
Mein Programm hat keine WinMain, weil es ein GLUT-Programm ist, und GLUT eine main anstelle einer WinMain verwendet, da es auf Plattformunabhängigkeit ausgelegt ist (die WinMain existiert vermutlich irgendwo gekapselt in der Win32-Distribution von GLUT, aber eben nicht im Sourcecode, da dieser plattformunabhängig gehalten werden soll).
GLUT verwendet weder main noch WinMain, es ist lediglich einfacher GLUT mit den Parametern von main zu initialisieren. Und ob die eine oder die andere Funktion beim Start des Programmes aufgerufen wird, entscheidest du anhand der Linkeroptionen.

[Gast]

AlphaTier[/POST]']Wir wollten nur das du mal richtig die Dokumentation ließt, und nicht nur "überfliegst"in der Doku auf
http://jcatki.no-ip.org/SDL_image/
steht nichts von #undef main

[Trap]

Gast[/POST]']in der Doku auf
http://jcatki.no-ip.org/SDL_image/
steht nichts von #undef main
Da steht auch nix von GLUT. Geht trotzdem, wenn man weiß was die Fehlermeldungen bedeuten und dann 1-2 Minuten investiert um die Ursache zu suchen.

[Gast]

Trap[/POST]']Da steht auch nix von GLUT. womit du also AlphaTier's These, ein genaues Lesen der Doku wäre nützlich gewesen, negierst?

Trap[/POST]']Geht trotzdem, wenn man weiß was die Fehlermeldungen bedeutenund wenn man's nicht weiß?
Ich hatte ja eine Idee, was sie vielleicht bedeuten. Xmas gab einen Kommentar dazu ab, der meine Idee zu bestätigen schien, Simon widersprach ihr, jedoch ohne einen Hinweis darauf zu geben, was sie denn stattdessen bedeuten.

Trap[/POST]']und dann 1-2 Minuten investiert um die Ursache zu suchen.ich wußte nicht, wo ich hätte suchen sollen. Nach "#undef main" googeln konnte ich ja erst, nachdem mir AlphaTier mit erheblicher Verzögerung den entsprechenden Hinweis gegeben hatte.
Ansonsten blieb mir nur die Option, in der Doku meiner IDE nachzusehen, was dort zu der Linker-Fehlermeldung steht. Was aber nicht notwendig war, da ich dies schon vor Jahren getan habe und daher wußte, daß dort stand, daß die Fehlermeldung wahrscheinlich bedeutete, daß mein Programm keine main oder WinMain habe. Was aber nicht zutraf, mein Prog hat ja eine main.

[Gast]

Xmas[/POST]']GLUT verwendet weder main noch WinMain, es ist lediglich einfacher GLUT mit den Parametern von main zu initialisieren.ich dachte GLUT sei auf Plattformunabhängigkeit ausgelegt und erwartet daher Sourcecode, der betriebssystemunabhängig ist und folglich keine WinMain enthalten kann?

Xmas[/POST]']Und ob die eine oder die andere Funktion beim Start des Programmes aufgerufen wird, entscheidest du anhand der Linkeroptionen.es gibt eine Linkeroption, mit der ich festlegen kann, ob main oder WinMain erwartet wird?
Meine IDE bietet in den Projektoptionen "Win32 GUI" und "Win32 Console" an, und wenn ich Win32 GUI auswähle, zeigt das Compile Log für den Linkervorgang "-mwindows" an, ist es das?
Kann aber eigentlich nicht, denn mit beiden Optionen funktionieren sowohl Win32-API Programme mit WinMain als auch GLUT- oder SDL-Programme mit main.

[Simon]

Gast[/POST]']Ich hatte ja eine Idee, was sie vielleicht bedeuten. Xmas gab einen Kommentar dazu ab, der meine Idee zu bestätigen schien, Simon widersprach ihr, jedoch ohne einen Hinweis darauf zu geben, was sie denn stattdessen bedeuten.
So langsam reichts aber :mad:
Wie sollen wir dir denn helfen, wenn du nichtmal auf einfache Fragen antworten kannst? Wie soll dir jemand Rat bei einem Fehler geben, den DU nicht genannt hast. "Linker Fehler" kann alles mögliche sein, z.B. "Unknown Error", wie ich den des öfteren sehe :|

ich wußte nicht, wo ich hätte suchen sollen. Nach "#undef main" googeln konnte ich ja erst, nachdem mir AlphaTier mit erheblicher Verzögerung den entsprechenden Hinweis gegeben hatte.
Mein Beispiel, Zeile 8. Und AlphaTier hat nach eigener Aussage noch nie was mit SDL gemacht. Komischerweise wußte er Hilfe (nach meinem Beispiel natürlich ;D )... na klingelts?

Ansonsten blieb mir nur die Option, in der Doku meiner IDE nachzusehen, was dort zu der Linker-Fehlermeldung steht. Was aber nicht notwendig war, da ich dies schon vor Jahren getan habe und daher wußte, daß dort stand, daß die Fehlermeldung wahrscheinlich bedeutete, daß mein Programm keine main oder WinMain habe. Was aber nicht zutraf, mein Prog hat ja eine main.
Hättest du mal doch nachgesehen...hast ja selber gesagt, du weißt es nicht...

Ach nochwas: Das ist keine Installationsdokumentation, wie du sie eigentlich suchst (ich verweise mal auf deine eigenen Aussagen, zitier ich dir noch gerne hier rein). Sondern das ist schon Benutzen, was mit Installieren nicht wirklich was zu tun hat. Nur so am Rande...

[Simon]

Gast[/POST]']ich dachte GLUT sei auf Plattformunabhängigkeit ausgelegt und erwartet daher Sourcecode, der betriebssystemunabhängig ist und folglich keine WinMain enthalten kann?
Wenns nicht so früh am morgen wäre, würde ich in mein Beispiel noch ne WinMain reinschreiben, nur um dich zu ärgern :P

es gibt eine Linkeroption, mit der ich festlegen kann, ob main oder WinMain erwartet wird?
Ja, steht in jedem Handbuch, ziemlich am Anfang.

[del_4901]

Und was ist die Mähr von der Geschicht? Der Simon hilft jetzt (in Zukunft) niemanden nicht. :|

[Gast]

Simon[/POST]']So langsam reichts aber :mad:
[b]Wie sollen wir dir denn helfen, wenn du nichtmal auf einfache Fragen antworten kannst? Wie soll dir jemand Rat bei einem Fehler geben, den DU nicht genannt hast.ich habe den Fehler genannt. In Posting #8. Dort habe ich geschrieben, daß der Linker die Fehlermeldung ausgibt, daß er keine WinMain findet.

Simon[/POST]']Mein Beispiel, Zeile 8. du meinst ich soll jede einzelne Zeile deines Programmes, deren Bedeutung mir nicht klar ist, hinterfragen? Ok, dann fangen wir erstmal mit den beiden #pragma comment Zeilen an. Was machen die? Mir ist auch nicht klar, warum du using std::cout; using std::endl statt einfach using namespace std machst, warum tust du das? Und was in der Unterschied zwischen der glutDisplayFunc und der glutIdleFunc?

Im Unterschied zu mir wart AlphaTier und du in der Lage, die Wichtigkeit der #undef main Zeile zu erkennen. Dennoch habt ihr mir sie nicht mitgeteilt.

Simon[/POST]']Hättest du mal doch nachgesehen...welchen Sinn sollte das haben wenn ich wußte was dort stand?

Simon[/POST]']hast ja selber gesagt, du weißt es nicht...was in der Hilfe stand wußte ich. Nur die Lösung des Problems wußte ich dadurch nicht, da sie dort nicht stand.

Simon[/POST]']Ach nochwas: Das ist keine Installationsdokumentation, dann hätten die auch nicht

Generally, in UNIX-like environments, installation consists of:
./configure
make
make install

mit der Überschrift "Getting started" da rein schreiben sollen, die anderes suggeriert.

Simon[/POST]']wie du sie eigentlich suchstich habe sie nicht gesucht. Erst die genannte Passage erweckte in mir den Eindruck, eine solche sei erforderlich.

[del_4901]

Infomationen zur Glut gibt es in der Glut Doku
http://www.opengl.org/documentation/specs/glut/spec3/node63.html#SECTION000818000000000000000
Informationen zu #pragma Präprozessor Macro gibt es in der MSDN

Und zu using Namespace ... das setzt ja genau den Sinn von Namensräumen außer Kraft (MSDN unter Namespaces)


... pass blos auf ... bring du mich nicht auch noch zur Weißglut ... sonnst setzt es ein paar warme Ohren!

[anderer Gast]

Was ist denn hier los, das kann ja wohl garnicht sein. Gast, ohne dir nahetrweten zu wollen, ich rate dir das programmieren lieber ganz zu lassen so wie du dich anstellst. Und dein Benehmen geht offen gesagt auf keine Kuhhaut, vergiss nicht du kommst hierher mit einem Problem und die Member opfern dir ihre Zeit, da ist eine gewisses Maß an Umgang sehr wohl angebracht.

ich habe den Fehler genannt. In Posting #8. Dort habe ich geschrieben, daß der Linker die Fehlermeldung ausgibt, daß er keine WinMain findet.
Du hast bis jetzt weder die genaue Fehlermeldung gepostet noch ein Stück von deinem Source Code. Wie soll dir denn gehlofen werden wenn niemand weiß worum es geht. Und nein, eine Beschreibung des Problems reicht nicht, da muss schon handfester Code her.

du meinst ich soll jede einzelne Zeile deines Programmes, deren Bedeutung mir nicht klar ist, hinterfragen?
Ja. Das nennt man lernen.
Ok, dann fangen wir erstmal mit den beiden #pragma comment Zeilen an. Was machen die?
Steht in der Doku von deinem Compiler.

Mir ist auch nicht klar, warum du using std::cout; using std::endl statt einfach using namespace std machst, warum tust du das?
Weils schönerer Stil ist. IMHO.
Und was in der Unterschied zwischen der glutDisplayFunc und der glutIdleFunc?
Steht in der Doku von glut.

lg

[Gast]

Simon[/POST]']Wenns nicht so früh am morgen wäre, würde ich in mein Beispiel noch ne WinMain reinschreiben, nur um dich zu ärgern :Pich zweifle nicht, daß GLUT eine WinMain akzeptieren würde. Da es aber auf Plattformunabhängigkeit ausgelegt ist, ist es darauf getrimmt, GUI-Programme, die unter Win32 für gewöhnlich einer WinMain bedürfen, mit einer main zum laufen zu kriegen. Ich war bislang davon ausgegangen, GLUT und SDL würden dies dadurch hinbekommen, daß sie die main zu einer WinMain umbiegen. Wie ich beim googeln nach #undef main herausgefunden habe, tut SDL so was ähnliches tatsächlich.

Simon[/POST]']Ja, steht in jedem Handbuch, ziemlich am Anfang.sofern es existiert.

[del_4901]

Nur als kleiner Tipp am Rande, wenn man schon selber keine guten Ideen hat, dann sollte man sich wenigstens gute Ideen anderer (die es besser können) zum Vorbild nehmen. Und Sie nicht damit zu vergraulen, ihnen ihre Fehler zu "unterstellen".

Ich hab ja nichts dagegen wenn zu mir jemand sagt ... ey du hast da echt einen gewöhnungsbedürftigen Programmierstil ... Wiso machst du denn das an der Stelle, so und nicht anders. Ist denn das eine so gute Idee/Design? In den allermeißten Fällen hab ich dann eine Antwort parat wiso, so und nicht anders. In einigen Fällen war ich mir auch selbst nicht einig wiso, gerade so und nicht anders. Und in anderen Fällen sage ich mir, ey du hast Recht, gute Idee, danke.

Aber wer von vornherrein sagt "So macht man das nicht!" Insbesondere wenn Derjehnige nun überhaupt keinen/kaum Plan hat. Der zieht sich meinen Zorn zu.

[Gast]

anderer Gast[/POST]']Was ist denn hier los, das kann ja wohl garnicht sein. Gast, ohne dir nahetrweten zu wollen, ich rate dir das programmieren lieber ganz zu lassen vermerkt. Ich muß deinen Rat ja nicht befolgen.

anderer Gast[/POST]']und die Member opfern dir ihre Zeit, da ist eine gewisses Maß an Umgang sehr wohl angebracht.habe sie nicht. Zeit geopfert mögen sie haben, aber nicht mir. Eher haben sie meine und ihre Zeit vertrödelt, indem sie mir den entscheidenden Hinweis (den mit dem #undef main) vorenthalten haben. Das wäre ok gewesen, wenn sie nicht gewußt hätten, daß dieser Hinweis der entscheidende sein würde. Aus Posting #30 von AlphaTier geht aber hervor, daß sie es offenbar wußten.

anderer Gast[/POST]']Du hast bis jetzt weder die genaue Fehlermeldung gepostetalso bitte, wenn du meinst daß dir
undefined reference to WinMain@16
mehr nützt als die Information, daß der Linker die Fehlermeldung ausgibt daß er keine WinMain findet.

anderer Gast[/POST]']noch ein Stück von deinem Source Code. Wie soll dir denn gehlofen werden wenn niemand weiß worum es geht.nun, es muß wohl irgendwie möglich sein, AlphaTier hat es in Posting #30 - wenn auch reichlich verspätet - ja schließlich geschafft.

anderer Gast[/POST]']Ja. Das nennt man lernen.Beim Lernen gibt es etwas, das man Effizienz nennt. Das gilt insbesondere, wenn man durch das Zutun anderer lernt. Mir den Hinweis auf #undef main zu geben, wäre weitaus effizienter gewesen, als mir einen Sourcecode hinzuknallen, der diese Anweisung in irgendeiner Zeile unter vielen anderen stehen hat.

[del_4901]

Zu #33 Ironie ist nicht deine Stärke oder?

Du musst noch viel lernen kleiner Padawan, denn nicht für die Schule lernt man, sondern für das Leben.

Ok, ich muss mir eingestehen, das ich deine Paranoia nicht noch nähren hätte dürfen. Das war ein unfeiner Zug von mir. ^^

Edit: 33 natürlich ... das hat man davon wenn man einfach nur abschreibt. ^^

[Gast]

AlphaTier[/POST]']Nur als kleiner Tipp am Rande, wenn man schon selber keine guten Ideen hat, dann sollte man sich wenigstens gute Ideen anderer welche meinst du? Die, mir den Hinweis mit den #undef main nicht zu geben? Die war nicht gut.
Oder die Idee mit dem #undef main selbst? Der bin ich ja sogleich nachgegangen. Nachdem du sie mir dann endlich mal mitgeteilt hast.

AlphaTier[/POST]']Ich hab ja nichts dagegen wenn zu mir jemand sagt ... ey du hast da echt einen gewöhnungsbedürftigen Programmierstil ... Wiso machst du denn das an der Stelle, so und nicht anders. Ist denn das eine so gute Idee/Design? In den allermeißten Fällen hab ich dann eine Antwort parat wiso, so und nicht anders. In einigen Fällen war ich mir auch selbst nicht einig wiso, gerade so und nicht anders. Und in anderen Fällen sage ich mir, ey du hast Recht, gute Idee, danke.

Aber wer von vornherrein sagt "So macht man das nicht!" Insbesondere wenn Derjehnige nun überhaupt keinen/kaum Plan hat. Der zieht sich meinen Zorn zu.war das an mich gerichtet? Dann weiß ich nicht was du meinst. Ich kann mich nicht erinnern, einen Programmierstil von dir kritisiert zu haben.

[del_4901]

Metaphern sind auch nicht seine Stärke ... sagmal kannst du überhaupt was? (Außer flamen/trollen natürlich)

[Gast]

AlphaTier[/POST]']Zu #30 Ironie ist nicht deine Stärke oder?ach du hattest gar nicht die Absicht gehabt, mir mit diesem Hinweis zu helfen? Hähä, Pech gehabt sag ich da nur :D

AlphaTier[/POST]']Du musst noch viel lernen kleiner Padawan, denn nicht für die Schule lernt man, sondern für das Leben.genau, und im Leben wollte ich gerne GLUT mit SDL_image zu laufen kriegen.

AlphaTier[/POST]']Ok, ich muss mir eingestehen, das ich deine Paranoia nicht noch nähren hätte dürfen.he?

[Xmas]

Gast[/POST]']ich dachte GLUT sei auf Plattformunabhängigkeit ausgelegt und erwartet daher Sourcecode, der betriebssystemunabhängig ist und folglich keine WinMain enthalten kann?
GLUT interessiert es nicht ob dein Code eine main-Funktion, WinMain-Funktion, beide oder keine davon beinhaltet (auch das ist möglich). GLUT ruft keine der beiden jemals auf und hat von ihrer Existenz auch keine Kenntnis. GLUT selbst ist auf Plattformunabhängigkeit ausgelegt, aber das heißt nicht dass du es nicht in plattformabhängigen Programmen verwenden könntest.

main oder WinMain sind nur insofern speziell dass eine von beiden die erste Funktion ist, die nach der C Runtime-Initialisierung mit bestimmten Parametern aufgerufen wird. Danach sind beides völlig normale Funktionen die sich nicht von anderen unterscheiden und ganz friedlich koexistieren können.

es gibt eine Linkeroption, mit der ich festlegen kann, ob main oder WinMain erwartet wird?
Meine IDE bietet in den Projektoptionen "Win32 GUI" und "Win32 Console" an, und wenn ich Win32 GUI auswähle, zeigt das Compile Log für den Linkervorgang "-mwindows" an, ist es das?
Kann aber eigentlich nicht, denn mit beiden Optionen funktionieren sowohl Win32-API Programme mit WinMain als auch GLUT- oder SDL-Programme mit main.
Ja, das könnte die Option sein (genauer würde ich das wissen wenn du schreiben würdest welchen Compiler/Linker du überhaupt verwendest). Dass es mit beiden Optionen funktioniert könnte daran liegen dass das Programm vielleicht sowohl main als auch WinMain beinhaltet, oder dass der Linker bei fehlender WinMain automatisch auf main zurückfällt.

[Gast]

Simon[/POST]']Weiß sie nicht! Sie zeigt nur, wie es mit den GNU autoconf/automake Tools geht und das hat mal gar nix mit Unix zu tun.hm, wie ich inzwischen rausgefunden habe, geht das mit dem make und make install auch unter Windows, weil es dafür eine extra make.exe gibt (der Ming-W32 Compiler bringt eine solche z.B. mit). Aber wie soll die ./configure-Geschichte funktionieren (ohne Unix-Emulator)?

@AlphaTier: wieso #33?? Der Hinweis mit dem #undef main war in #30.

[Gast]

wie ist das eigentlich, wenn man von dem mit IMG_Load() geladenen SDL_Surface die Größe verändern will, z.B. damit die Höhe und Breite Potenzen von 2 sind? Direkt die Member der SDL_Surface struct zu manipulieren erscheint mir ein bißchen gefährlich, und ist laut hier:
http://wiki.delphigl.com/index.php/SDL_Surface
auch gar nicht möglich, da z.B. Breite und Höhe read-only sind.
Man könnte zwar hingehen und mit SDL_CreateRGBSurface() ein leeres Surface der gewünschten Größe allokieren, und das Surface mit der Textur auf dieses blitten. Laut hier:
http://wiki.delphigl.com/index.php/SDL_CreateRGBSurface
ist SDL_CreateRGBSurface() aber leider nur dann verfügbar, wenn man SDL_Video benutzt, also nicht nur das Texturenladen, sondern die ganze Anwendung auf SDL aufbaut.