Sign in to follow this  

C++ SDL 2.0.3 Very Basic Help STUMPED

This topic is 1104 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. As of recent, I am very very frustrated with SDL2. Out of options here, so looking from some help from someone knowledgeable. I'm trying to get this darn thing working on Windows 8.1.
I had no problems using the first SDL on Windows 7 which went by with a breeze. However, SDL2 is just not the same case.
 
I'm following the tutorials on "http://lazyfoo.net/tutorials/SDL/01_hello_SDL/windows/codeblocks/index.php" using the most recently updated codeblocks + minGW32 release. I've also tried it on Orwell Dev C++ + minGW32.
However, something very very odd is happening, something I've never before seen in programming. My compiler is not giving me any errors. However, when the program runs, nothing happens. A window should be created and delayed for a few seconds. I've also tried the part 2 tutorial to show an image, and again, nothing happens. 
 
 
-I've made sure that neither program is blocked by Windows Firewall and ran the program and the .exe as an administrator.
-The compiler gives no errors.
-SDL2.dll is in the folder of the .exe.
-I've downloaded SDL2.0.3 from the link on the website and downloaded and applied the fix for that one wonky .h file that gives compiler errors in SDL2.0.3 but not SDL2.0.0 downloaded at https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h
-I've added the lib and include folder in the Compiler Options for SDL2.0.3.
-I've added the linker string: -lmingw32 -lSDL2main -lSDL2   (also tried -lmingw32 -lSDL2 -lSDL2main and like 10 other things found on forums). 
-I've tried using both the Debug and the Release compilers.
-I've tried building the program as a GUI application and a Console application. In SDL1, I compiled as a GUI application. In SDL2, this simply compiles, but when ran, it does absolutely nothing. When ran as a console application, a console windows pops up, the program stops responding, and then the console shows Process exited after 6.357 seconds with return value 255.
 
I've followed all instructions exactly using both Code::Blocks and then Dev C++ IDE and I still am not getting anything, same results. Been working at and googling this for 2 days. What in god's name is happening to cause me all this stress?
If you have any suggestions or have experienced this tragedy, please help! T.T
 

The code is very basic as shown:

 

 
//Using SDL and standard IO
#include <SDL.h>
#include <stdio.h>
 
//Screen dimension constants
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
 
int main( int argc, char* args[] )
{
//The window we'll be rendering to
SDL_Window* window = NULL;
 
//The surface contained by the window
SDL_Surface* screenSurface = NULL;
 
//Initialize SDL
if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
printf( "SDL could not initialize! SDL_Error: %s\n", SDL_GetError() );
}
else
{
//Create window
window = SDL_CreateWindow( "SDL Tutorial", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_SHOWN );
if( window == NULL )
{
printf( "Window could not be created! SDL_Error: %s\n", SDL_GetError() );
}
else
{
//Get window surface
screenSurface = SDL_GetWindowSurface( window );
 
//Fill the surface white
SDL_FillRect( screenSurface, NULL, SDL_MapRGB( screenSurface->format, 0xFF, 0xFF, 0xFF ) );
 
//Update the surface
SDL_UpdateWindowSurface( window );
 
//Wait two seconds
SDL_Delay( 2000 );
}
}
 
//Destroy window
SDL_DestroyWindow( window );
 
//Quit SDL subsystems
SDL_Quit();
 
return 0;
}
 
 
This is the compiler output from Dev C++:
 
 
    Compiling Project Changes...
    --------
    - Project File: C:\Users\Giovanni\Desktop\test\GioGame\GioGame.dev
    - Compiler Name: MinGW GCC 4.8.1 32-bit Debug
    
    Building makefile...
    --------
    - Filename: C:\Users\Giovanni\Desktop\test\GioGame\Makefile.win
    - Output File: C:\Users\Giovanni\Desktop\test\GioGame\GioGame.exe
    
    Processing makefile...
    --------
    - Makefile Processor: C:\Program Files (x86)\Dev-Cpp\MinGW32\bin\mingw32-make.exe
    - Command: mingw32-make.exe -f "C:\Users\Giovanni\Desktop\test\GioGame\Makefile.win" all
    
    g++.exe -c 01_hello_SDL.cpp -o 01_hello_SDL.o -I"C:/Program Files (x86)/Dev-Cpp/MinGW32/include" -I"C:/Program Files (x86)/Dev-Cpp/MinGW32/mingw32/include" -I"C:/Program Files (x86)/Dev-Cpp/MinGW32/lib/gcc/mingw32/4.8.1/include" -I"C:/Program Files (x86)/Dev-Cpp/MinGW32/lib/gcc/mingw32/4.8.1/include/c++" -I"C:/Users/Giovanni/Desktop/test/SDL2.0.3/include/SDL2" -g3
    
    g++.exe 01_hello_SDL.o -o GioGame.exe -L"C:/Program Files (x86)/Dev-Cpp/MinGW32/lib" -L"C:/Program Files (x86)/Dev-Cpp/MinGW32/mingw32/lib" -L"C:/Users/Giovanni/Desktop/test/SDL2.0.3/lib" -static-libstdc++ -static-libgcc -lmingw32 -lSDL2main -lSDL2 -g3
    
    
    Compilation Results...
    --------
    - Errors: 0
    - Warnings: 0
    - Output Size: 143.41796875 KiB
    - Compilation Time: 2.86s
 
 
Edited by spark1313

Share this post


Link to post
Share on other sites
Did you try to debug the application? Set a breakpoint on the first line or "step into" the execution.

You're linking against SDL2_main but you're not including SDL_main.h in the file with your main() function or spelling the function as SDL_main. I'm not sure how GCC will handle that, but it could cause the behavior you're seeing. You might be ending up with two entry points into the executable.

Aside: why are you suffering through things like Code::Blocks or Dev-C++? Visual Studio has had free versions for years and the recently-released Visual Studio 2013 Community Edition is the full Professional Suite with plugins, graphics debugger, the whole shebang. Plus I can personally guarantee that SDL 2.0.3 works right out of the box with it. smile.png

Share this post


Link to post
Share on other sites
Finally solved. As I had a feeling, it was some problem with Windows or Windows 8.1 just shafting me for fun. I was very careful and redownloaded SDL2.0.3 and reapplied that patch thing for SDL_platform.h.
THEN I completely uninstalled ALL of the IDEs that I tried, reinstalled Dev C++ in Windows 7 compatibility mode AS an administrator ON the desktop (ie not in Program Files x86).
Then, I setup everything again and bam it worked.
 
Could be a problem with Windows 8.1 administrator BS shenanigans, or compatibility mode, or a corrupt download earlier, or the SDL I was using OR even the fact that it was installed to program files x86 which has a space in the file path and limited rights because windows.
 
So problem: because windows.

Share this post


Link to post
Share on other sites

Did you try to debug the application? Set a breakpoint on the first line or "step into" the execution.

You're linking against SDL2_main but you're not including SDL_main.h in the file with your main() function or spelling the function as SDL_main. I'm not sure how GCC will handle that, but it could cause the behavior you're seeing. You might be ending up with two entry points into the executable.

Aside: why are you suffering through things like Code::Blocks or Dev-C++? Visual Studio has had free versions for years and the recently-released Visual Studio 2013 Community Edition is the full Professional Suite with plugins, graphics debugger, the whole shebang. Plus I can personally guarantee that SDL 2.0.3 works right out of the box with it. smile.png

SDL_main.h is included in SDL.h.

It makes the word "main" a macro that actually changes the definition to SDL_main.

#define main SDL_main

int main(int argc, char** argv) // <- Is actually SDL_main!!!
{
    return 0;
}

Share this post


Link to post
Share on other sites

Glad you found a work-around for your problem, but just a comment on your solution:

 


Could be a problem with Windows 8.1 administrator BS shenanigans

You know when people complain that Windows is "insecure"?  Those "BS shenanigans" are part of the solution to that, and can help to keep your PC free of malware/viruses.  They've also been a well known part of Windows since at least Windows Vista, and if you find any software (obviously excluding very old software that hasn't been updated) that does not work properly because of it that's a flaw in the software rather than a flaw in Windows.

 


So problem: because windows.

Not "because Windows", but rather "because crappy software".

Share this post


Link to post
Share on other sites

This topic is 1104 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this