Pure win32 / opengl example

[n00bmind]

This version uses just Win32 to process all input and output, and binds only the necessary OpenGL functions using the function types defined in glext.h (included), so it has no dependencies whatsoever.
Take a look at how the code is distributed because it is taken quite directly from my own engine, so you may prefer things arranged in a different way.

[ocornut]

Thank you!
It would be good if the coding style matched closely the one used by imgui and it's example. I feel that caring for details is generally a good indicator of a PR. Either way this looks like a good base to work from and a good de-facto reference code, if you want to polish it we can probably make it into master.

Linking to #281.

[n00bmind]

Ok, I'll see if I can put a bit more time into it these next days..

[ocornut]

Don't sweat it too much too, because I'll be reworking the example structure in the next month-ish so I expect to take over this example anyway (and it'd be easy for me to tweak it). This is already a very good base for me to start from.

Features like #1542 requires a bit of a reorganization of the input handling and window management. I have it working in a private branches but I'm currently evaluating how feasible it is to use in various engines and I don't know what's the right level of abstraction yet.

[n00bmind]

Wow!
I was not aware of any of that, looks impressive!
Ok, I'll try just renaming/moving things to more generally resemble the other examples..
Which one example would you say is best to use as a reference?

[ocornut]

They should all follow the same structure. In your case the GLFW+GL3 example for the GL part, and the DirectX11 example for the Win32 part.

[ocornut]

@n00bmind Note that the examples/ have been refactored very recently. It would be easier today to recreate something like your PR by combining imgui_impl_win32.cpp and e.g. imgui_impl_opengl2.cpp and the missing glue in main.cpp. Such example would be nice, if you are interested in starting from here and recreating one.
Thanks!

[n00bmind]

Hi Omar,
Sounds good. I've been really busy irl these last few months (moved to another country and all) so kind of forgot a bit about this, but I'd love to finish it up. I'll be having more time now, so I'll look into it soon, I promise :)

[n00bmind]

Ok I just 'restarted' my fork following the new structure etc. (github wanted to close this for some reason).
It still needs a couple things. I just need to set aside a couple hours and I think it'll be good to go.

[n00bmind]

Oh, I just noticed a "small" annoyance, which makes me doubt how to proceed.. imgui_impl_opengl3.cpp already includes gl3w.h for bindings.
The whole point of this example I think was about how to do those yourself on windows and get rid of any dependencies beyond opengl32.lib itself, so.. what do you think should be done here?

[ocornut]

Thanks!
(yeah it's a common git pitfall when making PR, git associate 1 PR to 1 branch, so further commits are added to the PR.)

I initially choose gl3w for the examples because it was smaller than other solutions. I would say for now using gl3w instead of glext.h may be preferable as a first step, if only because it is already on the repo (so your commit would have to be squashed). Is glext.h more standard? I'm not against transitioning to something else e.g. glext.h later if it simplify the portability of examples. But glext looks like a dependency similar to gl3w that we have to bundle? If we used it we could move it to examples/libs/.

imgui_impl_opengl3.cpp already includes gl3w.h for bindings.

This is a recurrent issue for many users, which forces them to copy and edit that file to change the include. It's unfortunately tricky to handle that with OpenGL.. :(

I was considering adding a set of #define that imgui_impl_opengl3.cpp would use and support gl3w/glad/glew/glext etc. One advantage being that the #ifdef/#include pairs would be explicit so people would understand the issue better and understand the imgui_impl_opengl3 is "compatible" with their existing loading. And ideally can add the define to their build system (or imconfig.h). Worse case they still edit things out.

The addition of a GL3+ example for apple system faces the same need (#1873).

Could you format all the code in main.cpp to use the same format as other examples? e.g. if (value) instead of if( value ) etc. for consistency. Thanks!

[n00bmind]

I've never used gl3w before, I'll take a look and compare against using glext directly and get back to you..
I agree that maybe a #define/#include set would make the issue more explicit, even if a bit ugly. It could be put together as an "opengl resolve" step. I'll think about it a bit and see if there's anything cleaner that could be done there.
Yes, sorry about formatting. I was planning on doing a formatting pass when everything's there, for now I was just hacking together something I could work with..

[n00bmind]

Ok, I've switched to using gl3w for now.. I don't see any major problems and switching was pretty easy, so if you want me to proceed with this route, I'm ok with that.
My reasons for using glext directly are mainly:

• Almost no setup. You just need to include the publicly available glext.h somehow. No need to link against anything, or do a generation step or whatever.
• Faster to load. I just bind against the functions I know my app will use, nothing more.

On the other hand, it's a bit more code on the client side, but it's also code that very seldom will change.. Yes, like you mentioned, glext.h would have to be included in the libs dir for convenience (wglext.h also, and possibly its equivalent for other platforms..)
About supporting several binding methods.. still didn't look into it much but I don't really see an alternative to having a bunch of #ifdefs/defines/includes..

One other thing, I created a VS project, but the earliest version I have is 2015, so I don't know how compatible it would be with older versions..

[ocornut]

Thanks. We can tackle the glext vs gl3w later, we can go this route first. For now make sure to squash the commits to remove the big files from history.

No need to link against anything, or do a generation step or whatever.
On the other hand, it's a bit more code on the client side,

Seems equivalent to gl3w except the functions are explicitly initialized in main.cpp.

You'll also want to update examples/README.md.

You can copy one of the existing 2010 project as a base, change the filename manually and/or request 2015 to not upgrade them and keep them 2010. It's a good test as by default it means we'll stay with older C++11 compliance and older Windows SDK as well.

[n00bmind]

I don't really know how to squash commits, but I'll look it up.

Seems equivalent to gl3w except the functions are explicitly initialized in main.cpp.

Well, not really, gl3w makes you link against gl3w.c.

I'll try an take care of the readme, project, formatting etc. when I get home today.

[n00bmind]

Ok, I think this is mostly there..
Regarding squashing glext.h.. did you mean I should use something like 'filter-branch' and remove it from every commit? i.e: if I do:
git filter-branch --tree-filter 'rm -f glext.h' HEAD

would that work?
There's also the remaining question of what to do with wglext.h. It is necessary even when using gl3w if I'm not mistaken.. should I add that in its own folder under libs? If so, what do I call that folder?

[ocornut]

Normally if you rebase and merge your multiple commit into 1 commit when the file will be gone.
I don't know about filter-branch but that's another possibility.

For wglext.hYou can call the folder libs/glext/
Which functions are needed?

[n00bmind]

I actually don't think I use it for any functions.. I only use it for a few symbols like WGL_CONTEXT_MAJOR_VERSION_ARB and the like.. it would be perfectly possible to define those by hand too I guess.

[n00bmind]

Hope I did everything right there with the squashing.. (I'm not too proficient in git).
Let me know if you see anything weird.
Other than that, I don't think there's much more to do here.

[ice1000]

Minor suggestions:

• Rename window to hwnd as other windows impl
• Rename windowClass to wc as other windows impl does
• Use CreateWindow with ShowWindow + UpdateWindow as other windows impl does

(I'm just telling that this pr is slightly different from other windows impls. I really appreciate your changes, it's awesome!)

[ocornut]

Closed/solved, see #3218 (comment)