pouët.net

Starting with OpenGL

category: code [glöplog]
Sagacity: Using Qt? Then this is for you: Have Fun!

See main.cpp for usage.
added on the 2015-08-13 14:26:55 by EvilOne EvilOne
EvilOne: Awesome, I will definitely steal(*) this when I get around to doing the GLSL editor :)

(*) Properly credit
added on the 2015-08-13 15:31:16 by sagacity sagacity
EvilOne: There is this XML for GLSL that supports a lot of stuff. I'd love to use that in my own stuff when I find time... Especially switching keywords etc. based on the #version is really neat!
added on the 2015-08-13 16:32:58 by raer raer
Quote:
I use afullscreen triangle. Clipping is free, and setting up a single triangle to cover the whole screen isn't very hard.

Wtf. Very obivious, but I never thought about it... :D
added on the 2015-08-13 16:43:53 by raer raer
Fun fact one: This should be easy.
Fun fact two: I am not able to fix it because the Qt install insists on puking a fucking Qt Creator onto my system, and the Qt-Plugin for VS was just a pile of crap and compile times were like a party in 1699.

TL;TR Wouldn't install Qt on my fresh Windows 10 (Visual Studio + Diablo 3)

P.S. It's a good idea to rename the tokens from the SyntaxToken enum, as they infer with some windows headers... easy copy and paste.
added on the 2015-08-13 17:22:57 by EvilOne EvilOne
Someone on HN recommended http://learnopengl.com/ a few weeks/months ago as a resource to learn "modern" OpenGL.

IIRC they go with v3.3 and the core profile.
added on the 2015-08-14 01:44:21 by Y0Gi Y0Gi
Hmmm... here is your prosaic oneliner for prototyping GLSL stuff...

Code: #define GLSL(source) "#version 400 core\n" #source const char* vs = GLSL( void main() { // Put your elite shader here... } );
added on the 2015-08-14 08:23:11 by EvilOne EvilOne
I recommend to implement auto shader reload/recompile on file change as a first exercise - you will start loving it once you notice the significantly reduced turn around times.
added on the 2015-08-14 11:00:55 by las las
I'm currently moving away from D3D9 too... because of "that-one-feature" you can't fake with a gazillion render-to-texture hacks and to make my life easier.

Fun fact of the day: I can't decide whether to use GL or D3D11. Sigh.

Official State of D3D9. Damn, that was a local maxima in the field of graphics.
added on the 2015-08-14 11:56:58 by EvilOne EvilOne
Quote:
Fun fact of the day: I can't decide whether to use GL or D3D11. Sigh.


You mean Vulkan or D3D12? :)
added on the 2015-08-14 13:13:33 by Scali Scali
EvilOne: I just created a thread on the internet site www.pouet.net to ask some tips about OpenGL, maybe it is relevant for you, too!
added on the 2015-08-14 13:25:28 by sagacity sagacity
ok, just started tinkering around with using GLFW and GLEW - and directly hit annoying linker warnings in VS Express 2010, complaining about incompatible runtime libs. I'm using the prebuilt binaries of GLFW and GLEW and I want to link them statically - Anybody knows the magic trick to link them together under VS Express?
Already tried all the runtime lib options in the linker settings..
added on the 2015-08-14 13:45:07 by arm1n arm1n
Spike: Perhaps you can share the linker output with us.
added on the 2015-08-14 13:52:45 by sagacity sagacity
Quote:
You mean Vulkan or D3D12? :)

Vulkan or D3D12 really don't add anything. It's like writing the driver itself. Not interested in that. Performance yada yada. I'm fine with 30fps ;-)

Sigh, as much as I hate anything Apple, from what I read in the docs, they have made some very good design choices regarding Metal... not to low level, maybe not as fast as the other contenders. But I would prefer the implicit bind model like in MTLRenderCommandEncoder.
added on the 2015-08-14 13:53:01 by EvilOne EvilOne
Runtime Lib is Multithreaded-Debug.
Code: 1> main.cpp 1>MSVCRT.lib(MSVCR100.dll) : error LNK2005: _free ist bereits in LIBCMTD.lib(dbgfree.obj) definiert. 1>MSVCRT.lib(MSVCR100.dll) : error LNK2005: _strncmp ist bereits in LIBCMTD.lib(strncmp.obj) definiert. 1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) ist bereits in LIBCMTD.lib(typinfo.obj) definiert. 1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) ist bereits in LIBCMTD.lib(typinfo.obj) definiert. 1>LINK : warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden. 1>LINK : warning LNK4098: Standardbibliothek "MSVCRT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden. 1>C:\Projekte\2015\fw3d\Debug\fw3d.exe : fatal error LNK1169: Mindestens ein mehrfach definiertes Symbol gefunden.


But after some quick googling now i have the impression that it's not possible out of the box. Seems recompiling all those libs is the only option. Yeah great, like i have nothing else to do..
added on the 2015-08-14 14:00:59 by arm1n arm1n
Quote:
Quote:
You mean Vulkan or D3D12? :)

Vulkan or D3D12 really don't add anything. It's like writing the driver itself. Not interested in that. Performance yada yada. I'm fine with 30fps ;-)


Well, going forward it is likely that new features will be added to these APIs as new GPUs come out.
So it would be a good future-proof decision.
D3D11 is probably going to be supported for quite some time yet, as it seems that MS believes both APIs should co-exist, with D3D12 for the 'experts' and D3D11 for everyone else with graphics acceleration needs.

OpenGL/Vulkan is always a gamble. The fact that the whole API needs to be implemented in the graphics drivers means you are directly dependent on the vendors for supporting it. So if some vendor decides that they aren't going to waste resources on OpenGL anymore now that Vulkan has arrived, that's the end of that. Or, the other way around... vendors may not want to invest in developing drivers for Vulkan since existing software only targets OpenGL anyway.

Early Vulkan drivers will probably be quite 'eventful' to develop for... as new versions of OpenGL/extension have always been. You generally want a 'pipe cleaner' game release for that first, to get all implementations somewhat in check.
added on the 2015-08-14 14:03:48 by Scali Scali
I think D3D12 and Vulkan will be a pain in the ass to use for rapid (demoscene style) prototyping.
D3D11.x does a pretty good job handling your data flow, while it seems that you have to do a large part of that yourself in D3D12 (and Vulkan - and OpenGL btw.).

EvilOne: I would recommend D3D11.x. I'm quite happy with it - once you start liking the (codewise) super ugly buffer setups etc. it's really convenient to use.
Especially if you are trying to do some more complex stuff - the debug layer is really neat for debugging with Visual Studio.
added on the 2015-08-14 14:31:18 by las las
sagacity: got it to work after recompiling GLEW and GLFW.

here's a short how-to in case someone needs to do the same:

Code: 1.) Building GLEW download and extract GLEW source code package from http://glew.sourceforge.net/ goto <glew-dir>/build/vc10 (or vc12) open glew.sln select desired build configuration (debug or release) select glew_static project set C/C++ Code Generation options for glew_static project: Select correct runtime library Build project Result: glew32s(d).lib 2.) Building GLFW download and extract GLFW source code package from http://www.glfw.org/download.html download and extract CMake win .zip from http://www.cmake.org/download/ run CMake GUI (i.e. bin/cmake-gui.exe) select GLFW source root directory choose output directory ("Where to build the binaries"), can be same as above click "Configure" select compiler deselect "USE_MSVC_RUNTIME_LIBRARY_DLL" option make sure "BUILD_SHARED_LIBS" is also disabled click "Configure" again click "Generate" open generated GLFW.sln (located in output directory as specified above) select desired build configuration (debug or release) set C/C++ Code Generation options for glfw project: Select correct runtime library Build project Result: glfw3.lib
added on the 2015-08-14 14:59:52 by arm1n arm1n
Glad to see more people picking up OpenGL! I'll be back on myself again very soon Summer holidays nearly over, my g/f will be back to work (teacher) meaning when she's marking, i'm coding or playing guitar!. Right now I don't get enough free time!

If you do want to ditch GLFW, the window set up code from IQs 4k templates or even NeHe is enough to get you going.

Regarding GLEW.. I don't use the static library, I #define GLEW_STATIC and include the glew files in my projects directly. not sure if it has a impact on size or anything apart from impacting compile time if I do a 'rebuild all' - but i like it that way.
added on the 2015-08-14 19:40:02 by Canopy Canopy
I didn't really like GLEW, so I rolled my own shit. Not that hard...
added on the 2015-08-17 11:07:34 by raer raer
GLEW is indeed a pile of crap.
added on the 2015-08-17 12:01:56 by EvilOne EvilOne
What problems did you have specifically with GLEW? I didn't encounter any issues myself, using it on linux, FreeBSD, OS X and Windows.
I was going to roll my own though, but never got round to it yet. Would be good to side-step the GLEW issues if I get to that.
Or, if someone knows another alternative that's a better building-block, I'm open to that as well.
added on the 2015-08-17 12:23:36 by Scali Scali
We have been using a custom GLEW replacement for a while now.
You just add the function names to a simple textfile and execute a little tool which generates a .h/.cpp with what you need. It's win only but good enougn and allows for some nice debugging "addons".

I'm not certain since I never tried this, but it could be similar.
added on the 2015-08-17 12:57:45 by las las
Again, try epoxy. :-) Switched from GLEW to it and not looking back.

Maybe not the thing for 4kB, though.
added on the 2015-08-17 13:11:13 by Sesse Sesse

login