tnx the GLFW got me going.
i hoped that i did not need it but it seems that i otherwise have to use to manny OS pecific commands. GLFW now takes care of that.
the modern c++ (17) has some different syntax. most of the commands are similar. works like a charm (yes i use the new books to make the program)
i only hope that the gpu of a frend (tester) support the opengl (ati HD 7950).
should word on paper.
I don't mean to be harsh or unkind, but I'll say it straight anyway, you are a guy with a butcher knife that feels if it comes to it, you'll do a heart transplant if needed.
From all the code you've shown so far, I can tell that you need to learn C to a basic minimal level way before tackling OpenGL.
Forget OpenGL, forget C++, get a simple text game running with plain old, reliable C.
On 10/27/2018 at 9:11 AM, fleabay said:Find a tutorial/book that was created in the last 5 years and don't try to figure this stuff out with trial and error. Put more effort into learning your chosen language over OpenGL for a few weeks.
I'm repeating what Fleabay is saying, but that is the honest truth, learn C first and only C, that will give you a much bigger return on invested time than trying to learn it all at once.
Cheers
On 10/28/2018 at 4:38 AM, Zakwayda said:To echo others, I wouldn't worry about cross-platform development right now.
I'm going to have to disagree with that.
The easiest way to get started on OpenGL is to use one of the many libraries (such as SDL) that hide all of the hairy platform-specific code. I would use SDL (or one of its many alternatives) even if I were targeting only a single platform, but it also provides platform independence basically for free.
Writing platform-dependent code is a bad habit that can be difficult to quit. If you're just getting started, it's best not to pick up that habit in the first place. Plus, using SDL is actually easier than using the Windows API.
25 minutes ago, a light breeze said:I'm going to have to disagree with that.
The easiest way to get started on OpenGL is to use one of the many libraries (such as SDL) that hide all of the hairy platform-specific code. I would use SDL (or one of its many alternatives) even if I were targeting only a single platform, but it also provides platform independence basically for free.
Writing platform-dependent code is a bad habit that can be difficult to quit. If you're just getting started, it's best not to pick up that habit in the first place. Plus, using SDL is actually easier than using the Windows API.
I think you may not have read my post fully, or misunderstood it, or maybe missed the overall context of the thread. (Also, I wasn't the first in the thread to suggest that the OP might not be ready for multi-platform development.)
The OP appeared to be attempting to write cross-platform code from scratch while perhaps not yet having a solid grasp on the fundamentals of C/C++ development. It was this approach that I was advising against. Using SDL or something similar would be perfectly reasonable and entirely in line with my suggestions. In fact, in the very post you quoted I suggested the possibility of using a higher-level framework.
Also, I'd disagree that writing platform-dependent code is a bad habit. I agree it's probably not the way to go for the OP (the point of my original reply), and it's probably something most developers can avoid. But if no one wrote platform-dependent code, we wouldn't have high-level frameworks to begin with.
In summary, I don't think we actually disagree on anything of importance. I think you just misinterpreted my post.
5 hours ago, Zakwayda said:In summary, I don't think we actually disagree on anything of importance. I think you just misinterpreted my post.
It's a question of priorities. You're saying (if I understand you correctly), "either write platform-specific code or use a framework". I am saying, "out of these two options, using a third-party library (not necessarily the same as a "framework") is the better choice." We both agree that these two are the only options, because it is flat-out impossible to write platform-independent OpenGL code without using a third-party library of some sort.
Note that SDL doesn't abstract away OpenGL unless you use the 2D rendering API (which I would not recommend). It just creates the window and OpenGL context for you and feeds you input events. So using SDL isn't an alternative to using OpenGL with C++, but a tool for using OpenGL in C++ more effectively.
42 minutes ago, a light breeze said:It's a question of priorities. You're saying (if I understand you correctly), "either write platform-specific code or use a framework". I am saying, "out of these two options, using a third-party library (not necessarily the same as a "framework") is the better choice." We both agree that these two are the only options, because it is flat-out impossible to write platform-independent OpenGL code without using a third-party library of some sort.
Note that SDL doesn't abstract away OpenGL unless you use the 2D rendering API (which I would not recommend). It just creates the window and OpenGL context for you and feeds you input events. So using SDL isn't an alternative to using OpenGL with C++, but a tool for using OpenGL in C++ more effectively.
I get the sense you have an objection, but I'm not entirely clear what it is. I'm also not clear why you put 'framework' in scare quotes, or if your comments about SDL are directed at me (they don't seem to relate to anything I said specifically).
In any case, I stand by my original suggestion. The OP seemed to be attempting low-level cross-platform development without having a good grasp on some important fundamentals. I and others suggested that might not be the best strategy. This seems fairly uncontroversial to me.
If there's some particular statement or suggestion you disagree with, maybe you could quote just that part and say why you disagree.
Anyway, not trying to be difficult 
I'm just a little confused by the conversation, that's all.
@ a light breeze
Most of the GLFW tuturials comes with SDL.
@ Zakwayda
For windows i got a window that can be with and without border. a few resolutions(hard code) that can change by a button (object linked to class).
Some text that change when klicking on a button (screen flash becose the window get destroyed and recreated).
None are persistand.
buttons tend to overlap
Using the wrong tools is just a pain and that is what i learned. Also i did had a text based game before going to opengl (perhaps a bit to soon)
writers most of the time asume you continue writing code with previous example.
i asume that in the example shows the code that makes the example work.
i don't have other ppl to ask becose the ppl i know don't do code.
i've learned that c++ for linux often opens with void() or main()
for windows c++ often opens with int main ()
both are correct and can be used on different senario. int main () works for both and void works a bit more specific for windows therefore is int main() sometimes beter to be used.
(i might be wrong but that is how i got some code working)
