   Windows API verses SDL
  I like SDL and i wish i didn't have to use the Windows API at all, but i found that reimplementing my code for creating a window using the Windows API was easier than trying to resolve a linking error with SDL. I want SDL to handle events, but i find if i don't use the Windows API for that, the window won't respond. Maybe i don't understand that a Windows message is not an SDL event, or maybe i should shut up and ask y'all to look at the code:(All functions are defined, by i took out irrelevant code.)class Window{    HWND hWnd;    HDC  hDC;    static void on_close( HWND );    static LRESULT CALLBACK WindowProc( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam )    {   switch( message ) {  HANDLE_MSG( hWnd, WM_DESTROY, on_close );   }   return DefWindowProc( hWnd, message, wParam, lParam );    }  public:    Window( HINSTANCE hInstance, int nCmdShow, int w, int h )    {   WNDCLASSEX wc;   // clear out the window class for use   ZeroMemory(&wc, sizeof(wc));   // fill in the struct with the needed information   wc.cbSize = sizeof(wc);   wc.style = CS_HREDRAW | CS_VREDRAW;   wc.lpfnWndProc = WindowProc;   wc.hInstance = hInstance;   wc.hCursor = LoadCursor(NULL, IDC_ARROW);   wc.hbrBackground = (HBRUSH)COLOR_WINDOW;   wc.lpszClassName = "WindowClass1";   // register the window class   RegisterClassEx(&wc);   // create the window and use the result as the handle   hWnd = CreateWindowEx (  NULL, // Style.  "WindowClass1", // name of the window class  "Our First Windowed Program", // title of the window  WS_OVERLAPPEDWINDOW, // window style  300,  // x-position of the window  300,  // y-position of the window  w,    // width of the window  h,    // height of the window  NULL, // we have no parent window, NULL  NULL, // we aren't using menus, NULL  hInstance, // application handle  NULL  // used with multiple windows, NULL   );   hDC = GetDC( hWnd );   ShowWindow(hWnd, nCmdShow);    }    void paint();    ~Window();};int WINAPI WinMain( HINSTANCE hInstance,HINSTANCE hPrevInstance, LPSTRlpCmdLine,int  nCmdShow ){    bool quit = false;    // ...   while( ! quit )    {   static SDL_Event event;   while( SDL_PollEvent( &event ) )   {  if( event.type == SDL_QUIT ) quit = true;   }   // ...    }}Since SDL didn't create the window, can it possibly handle what my WindowProc function is supposed to? After all, i register the WNDCLASS myself and tell it to call my function and it seems like that's where SDL would be unable to perform.   
  As it seems you're already aware, SDL isn't really meant to be used alongside raw WinAPI code like that. I suppose it might be possible to get it to work somehow, but I certainly wouldn't want to try it.I imagine that solving whatever linker error you were encountering earlier would be much easier than doing what you're trying to do now. What error was it exactly that you were stuck on?   ;  The linking error depends on what order i specify the arguments to g++:Quote:C:\...>g++ main.cpp -mwindows -lSDL -lSDLmain -lopengl32 -lmingw32c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined reference to `WinMain@16'collect2: ld returned 1 exit statusC:\...>g++ main.cpp -mwindows -lmingw32 -lSDLmain -lSDL -lopengl32c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libSDLmain.a(SDL_win32_main.o): In function `console_main':/Users/hercules/trunk/SDL-1.2/./src/main/win32/SDL_win32_main.c:315: undefined reference to `SDL_main'collect2: ld returned 1 exit statusI spent half a week with no progress because of this and i've already rewritten my code to replace SDL--it only took two days. Using SDL is only a convenience. If what i want to do is impossible, i can live with not doing it. Though, honestly, if there's anything i'm missing, using SDL would be a lot nicer. I still don't really understand how to set up an openGL rendering context or whatever, but with that as well, given time (maybe only one hour) i will probably learn and replace my need for SDL--at least for Windows developement.   ;  It seems SDL wants programmers to use their SDL_Main instead of the traditional entry point; by using SDL_Main and linking with SDLmain, SDL has a platform independent way of presenting the SDL application the same across platforms.  The main/WinMain symbol is provided in SDLmain.o/SDLmain.lib, which internally calls an external symbol, SDL_Main, in which your application is supposed to provide.  In order to side step this, just don't link with SDL_Main.  [smile]That being said, what are you using SDL for?  By using win32, you're pretty much crippling one of the major features of SDL:  Platform-independence.  Why not go raw Win32?   ;Quote:Original post by Splinter of ChaosThe linking error depends on what order i specify the arguments to g++:Quote:C:\...>g++ main.cpp -mwindows -lSDL -lSDLmain -lopengl32 -lmingw32c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libmingw32.a(main.o):main.c:(.text+0xd2): undefined reference to `WinMain@16'collect2: ld returned 1 exit statusC:\...>g++ main.cpp -mwindows -lmingw32 -lSDLmain -lSDL -lopengl32c:/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../libSDLmain.a(SDL_win32_main.o): In function `console_main':/Users/hercules/trunk/SDL-1.2/./src/main/win32/SDL_win32_main.c:315: undefined reference to `SDL_main'collect2: ld returned 1 exit statusI spent half a week with no progress because of this and i've already rewritten my code to replace SDL--it only took two days. Using SDL is only a convenience. If what i want to do is impossible, i can live with not doing it. Though, honestly, if there's anything i'm missing, using SDL would be a lot nicer. I still don't really understand how to set up an openGL rendering context or whatever, but with that as well, given time (maybe only one hour) i will probably learn and replace my need for SDL--at least for Windows developement.I haven't built an SDL application using this particular tool set (Windows, GCC, MinGW, etc.), so I can't say off the top of my head what's causing the linker errors shown above.However, I think it's highly likely that the problem can be solved. Many people use SDL with no problem, and I'm sure some of them are using the same toolset you are.With any luck, someone here can point you in the right direction. If not, you might try Googling/searching for 'sdl mingw' (it's even one of Google's 'search term' suggestions) or posting to the SDL developer forums.If you're interested in writing portable applications and feel like SDL would be a good solution for this, then I would recommend persevering a bit and trying to get this linker error sorted. Another option would be to look at other, similar frameworks, such as SFML or GLFW.If portability isn't important to you, then I'd just go with straight WinAPI code. I wouldn't, however, recommend mixing and matching SDL and WinAPI code as shown in your first post, as I imagine it is unlikely to work correctly.   ;Quote:Original post by _fastcallIt seems SDL wants programmers to use their SDL_Main instead of the traditional entry point; Eh... some more googling reveled that the problem was needing to useint main( int argc, char** argv )instead of regular int main().I'm primarily a Linux developer (by preference) and it seems SDL isn't so picky about main's arguments on other platforms. I've read on a few different programming blogs that the Windows API is one of Microsoft's biggest assets, so i wonder if stuff like this becomes harder than necessary on purpose...That's a serious question if anyone has the answer.Anyway, thanks all. Ironically, all i needed was to be told to try google one last time.Quote:That being said, what are you using SDL for?  By using win32, you're pretty much crippling one of the major features of SDL:  Platform-independence.  Why not go raw Win32?Using Win32 code doesn't cripple my code's platform independence at all, it just makes the code harder to maintain and look ugly.#ifdef _WIN32use_win32_code();#elseuse_sdl_code();#endifBut, now i know that's not necessary. Too bad, too. Right before checking this thread again, i had actually set up my rendering environment and was about to focus on actual programming! And then my problem got fixed. :)   ;  That linking error annoyed the hell out of me until I found a nice and simple solution: #undef main   ;Quote:That linking error annoyed the hell out of me until I found a nice and simple solution: #undef mainUm...are you sure that works? If I'm not mistaken, that'll circumvent the internal cross-platform code that's required for SDL to work correctly.I tried adding #undef main before main() in a simple SDL-based program, but (as expected) it just caused a linker error (unresolved external symbol _SDL_main).In any case, I'd be curious to know how exactly you got this to work.   ;Quote:Original post by jykQuote:That linking error annoyed the hell out of me until I found a nice and simple solution: #undef mainUm...are you sure that works? If I'm not mistaken, that'll circumvent the internal cross-platform code that's required for SDL to work correctly.I tried adding #undef main before main() in a simple SDL-based program, but (as expected) it just caused a linker error (unresolved external symbol _SDL_main).In any case, I'd be curious to know how exactly you got this to work.If you check SDL_main.h, you'll see it redefines main there. I'm not sure why it won't work for you, but this compiles and runs fine for me:#include <SDL/SDL.h>#undef mainint main(){ return 0; }And as for it circumventing cross-platform code, I fail to see how it'd affect anything, given the fact you can initialise different parts of SDL at different times (hence the SDL_Init() and SDL_Quit() functions). I've even used it on both Linux and Windows without any problems. These days though, it goes largely unused (unless I'm playing around with joystick code, or I'm playing with other code I've found online), because I wrote my own cross platform window handling classes that allow me to do a little more with the windows than SDL currently allows.   ;  LRESULT CALLBACK WindowProc( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam )is the function signature for a Windows event handler. All you have to do is handle the events in that function instead of forwarding them to SDL and you'll be golden. Hope that helps.