I’ve never tried SDL before seeing this post, but LNK1561 is a Visual Studio error, so I thought I’d try to build your code and see if I could help point out something. I used Visual Studio 2015. I looked at the SDL wiki to do the build, and a few StackOverflow sites when I had trouble with errors.
The only major error I got was LNK2019. If I remember right, that was because of issues with the “main” function definitions. I never got LNK1561 while doing this. If you want, I can take a look at your solution and see if I can get anything out of that. You can post a link here in a reply, or you can pm me if you’re uncomfortable with public posting. It has to be in VS 2015 though, nothing higher. Also, linking that youtube tutorial would be helpful too, so I can see what you’re trying to base your solution on.
The only thing I can guess so far from your post is maybe you forgot to include main.cpp with “Include In Project”. And if you still had display.cpp included, on solution build, VS would still try to put your files together, notice that there’s no main function, and generate an error like LNK1561 saying that there’s no “entry point” function available.
For now, I thought a good way I could respond to this post is to describe how I got my solution working with your code, at least give you a chance to see something running. Here’s a dropbox link to my solution. I’ve edited the Project Properties so that include/lib directories are relative, so you should be able to just download the folder, open the solution, and build/run. I’ve only built it in Debug mode on x86, not Release. If you want Release mode, you’re going to have to build the GLEW and SDL libraries yourself in Release versions so that you won’t see warnings in your Output window while your building and so you get a cleaner build. Anyways, I’ve kept the exe’s I built there for convenience.
To start off talking about the solution, from looking at your source code, it looks like you wanted to use GLEW with dll files, so I did my VS solution based on that. If you’re using a static library instead, you must “#define GLEW_STATIC” before including “glew.h”, else you’ll get errors (maybe that’s causing the LNK1561 error, if you’re using a GLEW static lib? Though that wouldn’t make any sense, since that error’s talking about an entry point. Anyways, just a thought.)
I’ll talk first about the ConsoleTest project I made based on a VS console application project. I’ve built GLEW and SDL to use .dll files. You’ll see the .dll files next to the .exe files in the Debug output folder. The import .lib libraries I used to reference in the solution projects are in the Lib32 folder. Code-wise, for my convenience, I moved the #include’s for GLEW and SDL into display.h so I could think about them better.
I found using some StackOverflow posts that in a console application here, you need to undefine the “main” redefinition that SDL does in SDL_main.h (you’ll see the redefinition around line 100). My guess is that the purpose of that redefinition for Windows applications is to overwrite the WinMain entry point function that’s required in those apps, so it can do some special setting up. This is probably for some cross-platform purposes.
But since with a console application you’re not considering any overwriting of some WinMain function, you don’t want that redefiniton to happen, else you’re “main” function will just turn into something more like a WinMain function and will make the compiler think you don’t have a main function anymore, therefore causing an error. So in order to prevent that, I did a “#define SDL_MAIN_HANDLED” before the SDL include. Looking at the SDL_main.h file, doing this prevents the #define’s of the SDL_MAIN_NEEDED and SDL_MAIN_AVAILABLE macros and therefore prevents that main redefinition.
Here’s an S.O. post about what I was talking about earlier. In this one, the accepted answer is to do an #undef main after the SDL include, but it’s for the same purpose.
So with that, the other thing I changed is I redefined “main()” as “main(int argc, char * argv[])”. This has no effect in a console application, when talking about this SDL stuff, but looking at the SDL wiki FAQ, I think this would be good practice to do, because it has significance when you’re developing a VS windows application (I mention it more below).
For the WinTest application I made, it’s the same idea with GLEW and SDL, dll-wise. You’ll see in display.h here that I didn’t “#define SDL_MAIN_HANDLED”. This is because this time, since this is a Windows application, you want SDL to overwrite your main function into an SDL_main, so that (at least I think) it can do some special handling with the WinMain function that a Windows application wants.
This is also where the importance of that specific main definition I mentioned earlier comes in. When the main becomes redefined, you want it’s format to match that described in “SDL_main.h” like below, so that SDL can then reference the right function as needed in the dll files.
extern C_LINKAGE DECLSPEC int SDL_main(int argc, char *argv[]);
If you don’t match that format, you’ll get an error. Since headers usually are for literally pasting/replacing code during the compilation process in C/C++, you can think of that error like this:
With the main redefiniton, in your main.cpp file (with just “main()”), your main function would be changed like so:
int main()
–
int SDL_main()
Since this doesn’t match the SDL_main prototype SDL defined, the compiler won’t make any special connections involving main functions, so you get an error.
The last thing is that, unlike the console application project, in this windows application project, you need to link SDL2main.lib as well. That’s what the SDL wiki FAQ says. This is probably because since SDL_main is significant here, you need that library to access the actual SDL_main source.
Anyways, other than that, I think that’s it. What I got was a blue window with “hello world” in its title bar, both on the ConsoleTest and WinTest projects. Hopefully that’s what you were looking for from your tutorial.