Starting with OpenGL
category: code [glöplog]
Forgot video: What we say about Vulkan three days after release...
EvilOne: Awesome, I will definitely steal(*) this when I get around to doing the GLSL editor :)
(*) Properly credit
(*) Properly credit
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!
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
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.
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.
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.
IIRC they go with v3.3 and the core profile.
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...
}
);
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.
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.
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.
Quote:
Fun fact of the day: I can't decide whether to use GL or D3D11. Sigh.
You mean Vulkan or D3D12? :)
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!
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..
Already tried all the runtime lib options in the linker settings..
Spike: Perhaps you can share the linker output with us.
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.
Runtime Lib is Multithreaded-Debug.
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..
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..
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.
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.
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.
sagacity: got it to work after recompiling GLEW and GLFW.
here's a short how-to in case someone needs to do the same:
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
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.
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.
I didn't really like GLEW, so I rolled my own shit. Not that hard...
GLEW is indeed a pile of crap.
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.
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.
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.
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.
Again, try epoxy. :-) Switched from GLEW to it and not looking back.
Maybe not the thing for 4kB, though.
Maybe not the thing for 4kB, though.
