I would say don't be too much of a platform stickler. If you have windows available, then just use that. I prefer linux at home too, but I've had three programming jobs now, and I can say that all three used windows. So consider this practice for potentially having to settle with windows when you get out in the field.
Also, I would be worried about burning too much unnecessary energy on dev environment setup. You'll most likely find yourself eyeballs deep in course work in short time, so while dev environment shenanigans don't seem like too big of a deal now, they could easily turn your life into hell when you start having deadlines to meet. If I were you, I would get the windows dev environment all setup with however the teacher recommends, and then start mentally preparing for the course work.
Former weird CS undergraduate here — seconding the proposal to just use whatever the course suggests.
However! Most of the interesting stuff I’ve learned — the bits which let me contribute outside my “area of expertise” — came from being stubborn about problems like yours and teaching myself a tonne from scratch. Here are some thoughts that past-kacey probably would have pursued:
write a bunch of makefiles to invoke a wine-msvc tool chain to do the build, then use winedbg as my debugger.
decompile the pre compiled binary, port it, then recompile. The NSA released a cool free tool called ghidra which should help.
port my tool chain over to windows on msys2.
Zooming out: most of my coworkers are the punch in/punch out type, and they absolutely would have broken down and done whatever the prof asked. They are paid embarassing amounts of money, and lead rich and interesting lives outside of work. If the goal is to get a degree, get a job, and crank out code, being stubborn hasn’t seemed useful — in my experience and section of the industry. Could be different for you.
That said, if you enjoy this stuff, imo there’s nothing quite like setting up your own challenges and accomplishing something people have told you is impossible or foolhardy.
They have us using glut, which is not bad in it self.
It's awful. That library was antiquated when I was in school over a decade ago. Why are professors still using that now 25 yo library when GLFW is more functional, more actively developed, and an arguably easier API? That library stopped being updated nearly a decade before OpenGL 3.
From the looks of graph1.h, it looks like you are using OpenGL2 to draw stuff, so that may unfortunately answer some questions... I know this isn't explicitly an OpenGL course, but "Computer Science 2", so I'll withhold my rant there.
So far, I have asked our computer science club about it. The main thing I was told was that the professor just wants us to use windows. That I can understand, but I still want to see how far I can go
I'd normally applaud this. However, we are talking OpenGL, and the answer to "how far I can go" tends to be "to the very abyss of the GPU". My answer to this would be to simply ask the professor about looking at and/or compiling an implementation for Linux, but you seem to have already done that to TBD results.
While I agree, at the same time "Just use windows" is a horrible, dismissive explanation, especially for a university student. So let me explain a bit about the tools you are using and why you may end up spending more time trying to make this work (assuming you never get the source code for this wrapper) than you would on the entire course work proper:
understand the goals of your tools. To make this verrrrrrry short, OpenGL's goal is to provide an interface for drawing to the screen using your GPU. And nothing else. Every and anything else has to to be made around it; your window (especially because windowing systems aren't cross compatible, as you may see here), how you load textures, manually requesting every single OpenGL command your program needs and graphics card supports, etc.
1.1 With that above mentality in mind, this is where GLUT comes in. Among a few other functions, the goal of GLUT to provide some (hopefully) cross-platform boilerplate and actually draw a window. Which is important to help learn concepts (or in industry, make many products), but the actual work of creating such a windowing system is not fairly productive. You will simply be making separately implementing code for each platform based on X11/Windows/Mac interfaces which leads to a blank window. This takes a lot of time with not much to show for it if you wanted to make this yourself, a common theme of graphics programming APIs (I assure you, if you want to do this on modern APIs like Vulkan/Metal/X12, it gets worse)
1.2 Same with BMPLoader, and then your professor's wrapper. I can't even find BMPLoader, but the name implies that the goal is to read an ancient image format into an array (buffer) of colors, and then the wrapper can use that information to store those color buffers into a texture for OpenGL. Again, very boilerplate stuff that doesn't necessarily teach you how to draw on screen. It should be noted that the BMP format was made for windows, so that may be more friction to encounter if you wanted to diverge into Linux. learning the BMP format and how to read it may not be the best of your time. Nor would solving those bugs even if everything compiled.
Now that you understand the tools, you should understand the value of these tools and investing in them. And the unfortunate answer is "not that much". Even if you were in a more advanced graphics programmer class and you wanted to go above and beyond (with the professor's permission of course), you'd probably end up replacing all the above with modern OpenGL implementation (or maybe even Vulkan if you dare), GLFW for windows, and stbImage to load images. The work to render a texture or draw 2D shapes would be a lot more involved (OpenGL 3/4 has a LOT more boilerplate since it was made for 3D rendering), but it would still be very doable. Not much work for someone who's worked in OpenGL, but it would be quite an endeavor for a newcomer. One I feel every graphics programmer should try themselves at some point, but that of course leads to the last question
Answer this question: "What is the problem I'm trying to solve?". And while I spent all this time talking about the mindset of a graphics programmer... you don't sound like you're in a graphics programming course right now (for the love of God I hope not, not with those tools and implied tools...). Not only will diving off into the deep end of this rabbit hole be unproductive to the goals of your course, it may also be a bit out of your element. That presents situations to grow as a programmer/engineer, but is this the way you want to grow? fixing ancient frameworks made in a bygone era? There are certainly careers for that, but it may not be something to aim for early in your career.
Anyways, all that was a very blow-hardy way to say "use Windows", but if you went so far as to ask on Tildes about this, I may as well give a similar mind dump on the why's behind those words.
While I agree with the rest of the responses here that the practical move would be to use Windows... I hecking love rabbit holes like this. It may not be useful to go down this rabbit hole for career purposes or whatever, but like... It's fun!!! It's really fun. It's a hobby in and of itself, imo.
I started poking around by doing a Google search for "graph1.h" "glut". Doing so returns this post, but also a few other results (GitHub repos, StackOverflow questions). They seem to be from people who took your class years ago, given the repeated mentions of CSI and CSII.
Curiously, there's a copy of graph1.h in one of those GitHub repos, added in 2015. For kicks, I tried diffing it with the copy you shared, and it looks like 5 lines have been added between 2015 and now. I think this supports your theory that this is an in-house hackjob?
I also tried looking a little more deeply into BMPLoader itself, since I was curious what the original library looked like (and therefore which parts were hacked on):
Searching bmploader chris backhouse yields this StackOverflow answer with a link to a now-dead university page. Thankfully, there's the Wayback Machine, and luckily the site has been preserved! (Snapshots: 2007, 2011 -- no difference.) What a lovely little retro site. :3
The page has a download link for BMPLoader, but sadly this wasn't preserved. Still, we now know that bmploader.zip existed at one point. Searching for this filename leads to a Japanese blog post with a download link for bmploader.zip... but drat, it's on Google Drive, and sharing is restricted.
There is also a link to this Japanese page cataloging links from fireemblem.net of all things! This page contains a download link to BMPLoader.zip, but of course it's down. However, if we plug this link into Wayback Machine, we get an archived download from 2006 that works! Yet, the only file contained inside is EBOOT.PBP, which seems to be a firmware file for the PSP. Google Translate says "Image/Textbook Reader BMP Loader 0.2 English BMP document reading device for PSP", so it's dubious if this is even related. I almost went down the rabbit hole of unpacking the EBOOT.PBP file, but I didn't get very far before stopping. Still, Playstation Portable modding... neat!
I wanted to dig a little more into the Wayback Machine, but while I was looking into this, the site seems to have gone down. Yeesh!
If I get bored again, I may try poking around some more. Good luck, though! :3
I would say don't be too much of a platform stickler. If you have windows available, then just use that. I prefer linux at home too, but I've had three programming jobs now, and I can say that all three used windows. So consider this practice for potentially having to settle with windows when you get out in the field.
Also, I would be worried about burning too much unnecessary energy on dev environment setup. You'll most likely find yourself eyeballs deep in course work in short time, so while dev environment shenanigans don't seem like too big of a deal now, they could easily turn your life into hell when you start having deadlines to meet. If I were you, I would get the windows dev environment all setup with however the teacher recommends, and then start mentally preparing for the course work.
Can you use it on Linux via Wine?
Former weird CS undergraduate here — seconding the proposal to just use whatever the course suggests.
However! Most of the interesting stuff I’ve learned — the bits which let me contribute outside my “area of expertise” — came from being stubborn about problems like yours and teaching myself a tonne from scratch. Here are some thoughts that past-kacey probably would have pursued:
Zooming out: most of my coworkers are the punch in/punch out type, and they absolutely would have broken down and done whatever the prof asked. They are paid embarassing amounts of money, and lead rich and interesting lives outside of work. If the goal is to get a degree, get a job, and crank out code, being stubborn hasn’t seemed useful — in my experience and section of the industry. Could be different for you.
That said, if you enjoy this stuff, imo there’s nothing quite like setting up your own challenges and accomplishing something people have told you is impossible or foolhardy.
It's awful. That library was antiquated when I was in school over a decade ago. Why are professors still using that now 25 yo library when GLFW is more functional, more actively developed, and an arguably easier API? That library stopped being updated nearly a decade before OpenGL 3.
From the looks of graph1.h, it looks like you are using OpenGL2 to draw stuff, so that may unfortunately answer some questions... I know this isn't explicitly an OpenGL course, but "Computer Science 2", so I'll withhold my rant there.
I'd normally applaud this. However, we are talking OpenGL, and the answer to "how far I can go" tends to be "to the very abyss of the GPU". My answer to this would be to simply ask the professor about looking at and/or compiling an implementation for Linux, but you seem to have already done that to TBD results.
While I agree, at the same time "Just use windows" is a horrible, dismissive explanation, especially for a university student. So let me explain a bit about the tools you are using and why you may end up spending more time trying to make this work (assuming you never get the source code for this wrapper) than you would on the entire course work proper:
1.1 With that above mentality in mind, this is where GLUT comes in. Among a few other functions, the goal of GLUT to provide some (hopefully) cross-platform boilerplate and actually draw a window. Which is important to help learn concepts (or in industry, make many products), but the actual work of creating such a windowing system is not fairly productive. You will simply be making separately implementing code for each platform based on X11/Windows/Mac interfaces which leads to a blank window. This takes a lot of time with not much to show for it if you wanted to make this yourself, a common theme of graphics programming APIs (I assure you, if you want to do this on modern APIs like Vulkan/Metal/X12, it gets worse)
1.2 Same with BMPLoader, and then your professor's wrapper. I can't even find BMPLoader, but the name implies that the goal is to read a
n ancientimage format into an array (buffer) of colors, and then the wrapper can use that information to store those color buffers into a texture for OpenGL. Again, very boilerplate stuff that doesn't necessarily teach you how to draw on screen. It should be noted that the BMP format was made for windows, so that may be more friction to encounter if you wanted to diverge into Linux. learning the BMP format and how to read it may not be the best of your time. Nor would solving those bugs even if everything compiled.Anyways, all that was a very blow-hardy way to say "use Windows", but if you went so far as to ask on Tildes about this, I may as well give a similar mind dump on the why's behind those words.
While I agree with the rest of the responses here that the practical move would be to use Windows... I hecking love rabbit holes like this. It may not be useful to go down this rabbit hole for career purposes or whatever, but like... It's fun!!! It's really fun. It's a hobby in and of itself, imo.
I started poking around by doing a Google search for
"graph1.h" "glut"
. Doing so returns this post, but also a few other results (GitHub repos, StackOverflow questions). They seem to be from people who took your class years ago, given the repeated mentions of CSI and CSII.Curiously, there's a copy of
graph1.h
in one of those GitHub repos, added in 2015. For kicks, I tried diffing it with the copy you shared, and it looks like 5 lines have been added between 2015 and now. I think this supports your theory that this is an in-house hackjob?I also tried looking a little more deeply into BMPLoader itself, since I was curious what the original library looked like (and therefore which parts were hacked on):
bmploader chris backhouse
yields this StackOverflow answer with a link to a now-dead university page. Thankfully, there's the Wayback Machine, and luckily the site has been preserved! (Snapshots: 2007, 2011 -- no difference.) What a lovely little retro site. :3bmploader.zip
existed at one point. Searching for this filename leads to a Japanese blog post with a download link for bmploader.zip... but drat, it's on Google Drive, and sharing is restricted.BMPLoader.zip
, but of course it's down. However, if we plug this link into Wayback Machine, we get an archived download from 2006 that works! Yet, the only file contained inside isEBOOT.PBP
, which seems to be a firmware file for the PSP. Google Translate says "Image/Textbook Reader BMP Loader 0.2 English BMP document reading device for PSP", so it's dubious if this is even related. I almost went down the rabbit hole of unpacking theEBOOT.PBP
file, but I didn't get very far before stopping. Still, Playstation Portable modding... neat!If I get bored again, I may try poking around some more. Good luck, though! :3