Im trying to make a game using C++ and GLFW. Im currently trying to use SOIL source code (I did include the files in my project) and for some reason there is a linking error. Can anyone tell me why this is?
C++ Help Needed
Other urls found in this thread:
vulkan-tutorial.com
learnopengl.com
twitter.com
Cause C++ sucks ass.
Are you using windows? I am and my libsoil is called libSOIL.lib. Also make sure you use the right version depending on if you are targeting 64 or 32 bit.
also
>GetHieght();
Its defined in the cpp file
Im using windows. I auto completes and everything. Im not sure where this error is coming from.
C++ to male games in 2017
OP make sure you have the libraries linked for both static and dynamic.
Go into the project settings and make sure they're linked. Right click on the project and go to its settings and show us the linker.
hieght
Where did you grab your libsoil? Did you compile it yourself?
recheck:
properties >linker>additional library directories
should have path to libsoild directory there
and
properties >linker>input>additional dependencies
should have libSOIL.lib there
Which thing do you need to see?
This. I can't remember Winblows Visual Shitter, but aren't you supposed to link the static and dynamic libraries for debug and build options separately as well?
don't use SOIL, there isn't any point
just use stb_image (which is what SOIL uses in the first place) and load the images yourself, it isn't hard at all
it's a header only library so it's easy to setup
Something like:
// opengl texture id
GLuint texture;
// get texture data from stbi
int w, h;
uint8_t* data = stbi_load("path goes here", &w, &h, nullptr, STBI_rgb_alpha);
// generate and bind opengl texture id
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_ID, texture);
// set the filter (use GL_NEAREST for pixel shit, GL_LINEAR for smooth shit)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
// set the wrap mode
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
// send data to opengl
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, w, h, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
// unbind (bind again for later use)
glBindTexture(GL_TEXTURE_2D, 0);
also avoid `using namespace std` because it'll pollute the global namespace
consider passing by const reference too
also before including it be sure to define STB_IMAGE_IMPLEMENTATION at least once somewhere in your code
Yeah kind of pointless to use SOIL when you can just setup its primary functions in about 30 minutes.
Under Additional Library Directories you'll want to type in the directory for the SOIL dependencies (and I think you'll have to do that for gflw as well).
Then you'll need to go to Linker > Input > Additional Dependencies and link crap like libSOIL.lib as this gentleman said.
Alright So this is what The lib file i was given looks like in the file viewer. It appears to be a .a rather than .lib file and im not sure if that effects it.
If it is better to use something other that soil where can I go to learn how to setup the primary functions. Im new to opengl, alright at c++ and am pretty shit with visual studio so I was using SOIL because i dont know how to do what it does myself.
Pretty sure .a libraries are for linux and mac. Your file should be libSOIL.lib.
Just read the SOIL source code if you really want. It's a really dead simple library. I mean, it's whatever. You can use it, nobody cares. However, I think if you really want to learn OpenGL, you should be able to set up your own texture import library.
Look at what this guy posted:
He creates a texture ID, loads the texture file, and then does the basic texture buffer creation, binding, and coordinate mapping. You ideally would want to know this if you're serious about OpenGL. If you're not, just use some 3D graphics library. Also, Vulkan is the future fag. Get on the hype train or get left behind. :>)
>.a libraries are for linux/mac
Dude, I knew something was fucking weird. I saw the .a outputs and yet I saw him using Visual Studio. I was going to post:
>.a
>winblows
Lel
But I thought I was retarded.
I can already tell you suck at C++.
Please stop and use Java/Unity
Thanks.
And OP, I know you're using open.gl as your reference. That guy actually has a Vulkan tutorial too and guess what:
vulkan-tutorial.com
stbi_uc* pixels = stbi_load(TEXTURE_PATH.c_str(), &texWidth, &texHeight, &texChannels, STBI_rgb_alpha);
He doesn't use the libSOIL(MYSELF).
Quite honestly I started out like OP just 5 years ago. I recommend he continues down this path. At least then he'll come to appreciate how fucking hard graphics programming is. Hell, I used to think library linking was the devil. Spent like 3 hours trying to get that shit to work back in the day.
...Yep that is where im at right now. But its interesting atleast. Is there a lot of documentation on vulkan that I could use to learn it?
There's the official Superbible for Vulkan:
>can't fucking link it so just go to libgen and look up "Vulkan Guide" and you'll see the link
I highly recommend the Vulkan Programming Guide book in that libgen link. It's pretty up to date so you won't be running into archaic dependency issues or trying to work their project files into your new IDE.
>Hell, I used to think library linking was the devil. Spent like 3 hours trying to get that shit to work back in the day.
word
So many noob traps in just getting the libraries right alone. Outdated guides. Websites distributing random.libs .dlls that have god knows what in them. Then where to put the binaries. Oh wait actually you need to compile your own, install windows version of cmake, choosing the right architecture. Then there is the linking itself. Oh looks like you need a dll in the folder with your executable as well.
you can find STBI and STBI_write on sjwhub
if you're new to opengl, you shouldn't need anything more than this for now. stick to the basics and work on the fancy APIs later
dude people gotta learn somehow lol get your ass back to plebbit
i guess this depends on what your goals are
if OPs goal is to make a game, he's wasting his time (unless he's smart and doesn't fall for the whole "make engine, not game" thing)
if OPs goal is to learn the basics of graphics programming, i'd say he's fine but still has a long way to go
on the subject of learning though...
honestly, you'd be better off doing this in c for now. c++ isn't as bad as everybody says it is, but really you want to focus more on learning the API itself and not how you can wrap everything up in it
instead of a texture class you'd just stick with something simple like
struct tex {
GLuint id;
GLint w, h;
} tex_t;
for the sake of minimalism
best of luck op. btw if you want my 2c i think vulkan is a little bit too new to start diving deep in but if you wanna go for it then by all means do so
Linker and cmake issues are cancer. I'm surprised they don't have some kind of automated project solution that takes care of these problems. It really disincentives new programmers from learning. And I know what people will say:
>if you can't figure a fucking linker, how are you supposed to figure shader compilation?
My response is as follows: dumb ass IDE problems are a completely different ball game from the programming itself. Still, it's part of the ritual. You have to appease the linker and library gods before you're allowed to draw the satanic triangle.
You know you the error you get is a linker error, yet you show some of your code as if that would help anyone find the error.
The error is most likely in your build system, so read your cmake or whatever you use and find the error there.
>>if you can't figure a fucking linker, how are you supposed to figure shader compilation?
shader compilation takes only a few lines of code which can be easily understood with a bit of reading
figuring out linking is more a process of memorization and knowing your IDE
>focus on C to wrap around the API
Not a bad idea honestly. C++ STD libraries are pretty decent (even with the flack they get), but you'll want to understand the API and not get lost on templates and RAII. However, there will simply be more documentation when programming in the C++ environment. This can either be a blessing or a curse depending on whether or not your solution to not understanding something is to copy paste.
>btw if you want my 2c i think vulkan is a little bit too new to start diving deep in but if you wanna go for it then by all means do so
Actually, Addison-Wesley released their OFFISHUL Vulkan Programming Guide and it's pretty fucking good. I have no idea if these are the Khronos approved methods for Vulkan development but it's not completely hopeless. I expect within a year that the Vulkan documentation will be on par with the OpenGL side. And I say this because there's a lot of deprecated and horse shit OpenGL guides out there that are as good as trash.
>figuring out linking is more a process of memorization and knowing your IDE
Oh yeah I know that. I'm just playing devil's advocate. I actually do think that not knowing your IDE is perfectly acceptable even if you're planning on doing some low level programming. Though you should get used to the fact that you will have to google solutions that won't make sense. It's more of an exercise in patience and trial and error than anything else.
>shader compilation takes only a few lines of code which can be easily understood with a bit of reading
I should be more specific. Shader program creation, shader program linking, the shader code itself, passing it to the appropriate OpenGL objects, et cetera. I should have said "the shader pipeline" instead.
meanwhile, in linux:
> apt install freeglut-dev
> ok now i can link against glut
windows: 0
linux: 9999
(This is op on a different computer)
I want to make games. Not game engines unless necessary (Which it seems to be).
That is why I want to learn this.
Relevant and non-shit online GL tutorials:
>Learning modern 3D graphics programming by Jason McKesson
What else?