g-truc / ogl-samples Goto Github PK
View Code? Open in Web Editor NEWThis project forked from groovounet/ogl-samples
The OpenGL Samples Pack
Home Page: http://www.g-truc.net/project-0026.html#menu
License: MIT License
This project forked from groovounet/ogl-samples
The OpenGL Samples Pack
Home Page: http://www.g-truc.net/project-0026.html#menu
License: MIT License
glGetString(GL_EXTENSIONS) shouldn't be called from a core profile.
This is at least called when running ./build/Release/gl-320-primitive-sprite possibly elsewhere too.
See Mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=77582
After generating VS2010 project files with CMake I get these errors when building ALL_BUILD
:
Error 8 error C2758: 'test::Success' : must be initialized in constructor base/member initializer list C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 9 error C2758: 'test::Profile' : must be initialized in constructor base/member initializer list C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 10 error C2758: 'test::Major' : must be initialized in constructor base/member initializer list C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 11 error C2758: 'test::Minor' : must be initialized in constructor base/member initializer list C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 12 error C2758: 'test::FrameCount' : must be initialized in constructor base/member initializer list C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 13 error C2614: 'test' : illegal member initialization: 'test' is not a base or member C:\dev\projects\ogl-samples\framework\test.cpp 101
Error 23 error C2552: 'Color' : non-aggregates cannot be initialized with initializer list C:\dev\projects\ogl-samples\tests\gl-440-fbo.cpp 324
Error 24 error C2552: 'Color' : non-aggregates cannot be initialized with initializer list C:\dev\projects\ogl-samples\tests\gl-440-fbo.cpp 325
Error 25 error LNK1104: cannot open file '..\framework\Debug\framework.lib' C:\dev\projects\ogl-samples\build\tests\LINK
Error 26 error LNK1104: cannot open file '..\framework\Debug\framework.lib' C:\dev\projects\ogl-samples\build\tests\LINK
...
Tested with both git-head and ogl-samples-4.4.1.3.7z
.
I can't run gl-400-fbo-multisample and all the others who uses the interpolateAtSample
in vert
{
vec2 Texcoord;
//sample vec2 Texcoord;
} Vert;
layout(location = FRAG_COLOR, index = 0) out vec4 Color;
void main()
{
Color = texture(Diffuse, interpolateAtSample(Vert.Texcoord, gl_SampleID));
//Color = texture(Diffuse, Vert.Texcoord);
}
Asking on the irc opengl, a guy suggested me to use the commented out lines instead, and that works. He also said it is probabily a glsl compiler bug... what do you think?
Edit: https://devtalk.nvidia.com/default/topic/914874/opengl/glsl-compiler-bug-on-interpolateatsample-/
gl-430-multi-draw-indirect sample crashes because glMultiDrawElementsIndirect function pointer is NULL.
I can't find any reference of GL_ARB_query_statistics_arb
probably it's GL_ARB_pipeline_statistics_query
instead, isn't?
Due to the recent commits I can now get Linux builds to compile (thanks for that!), but running ANY sample results in (via gdb):
Program received signal SIGSEGV, Segmentation fault.
__memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1704
1704 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory.
I am using glibc version 2.17 on Ubuntu 13.04 x64 with latest updates. I have no problem compiling or running any other OpenGL related apps, including those using SSE3 optimizations. I have never encountered this error before in any other context.
ldd output:
linux-vdso.so.1 => (0x00007fff233fe000)
libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0x00007f03dda75000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f03dd70f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f03dd4f2000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f03dd2e8000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f03dd0d8000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f03dced1000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f03dccc9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f03dc9c6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f03dc6c0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f03dc4aa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f03dc0e1000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f03dbece000)
libatiuki.so.1 => /usr/lib/fglrx/libatiuki.so.1 (0x00007f03dbdb1000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f03dbb93000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f03db98e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f03ddc56000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f03db784000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f03db57f000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f03db379000)
This samples show three things:
*imageLoad even not allowed on multisampled images on AMD cards.. (even on latest HD7xxx series)
*Unique ability of NV GPUs to use even imageStore with image2DMS (this is unique in all APIs (as d3d provides RWTexture2D and Texture2DMS but not RWTexture2DMS (feature for DX 12? :-) )
*Inability in GLSL of getting # of samples of attached tex (though some of your samples also suffer from lack of this having hardcoded values of 4)
Shader:
uniform layout(rgba8) image2DMS ColorImage;
in ivec2 gl_FragCoord;
void main(void)
{
ivec2 coords = ivec2(gl_FragCoord.xy);
vec4 color=vec4(0,0,0,0);
for(int i=0; i<4; i++)
{
color += imageLoad(ColorImage, coords, i);
}
ivec2 temp=imageSize(ColorImage);
imageStore(ColorImage, coords+ivec2(1,2), gl_SampleID+1,temp.xyxy+color);
}
Image is bound with GL_RGBA8 format, like this (line 313):
glBindImageTexture(…, GL_RGBA8);
But should be:
glBindImageTexture(…, GL_32UI);
(because in the shader image is declared with layout(r32ui)).
In the shader “unsigned int” is used instead of “uint”.
Ok, let me get this thing right 😕
In your initBuffer
I saw you were initializing all the buffers passing a size twice as needed..
positionSize * 2
I tried first to set it back to 1 and then I got an exception at the first glTexBufferRange
, because
"error(high) 1281: GL_INVALID_VALUE. + is greater than the value of BUFFER_SIZE for ."
This means that in our initBuffer
we should do the same trick that we do for the transform buffur, that is getting the GL_TEXTURE_BUFFER_OFFSET_ALIGNMENT
and creating our input and output buffers with the max(textureBufferOffset, bufferSize)
, where bufferSize
is essentially in sequence:
positionSize
texCoordSize
colorData
Am I right?
Hi,
You are creating window like this:
glfwOpenWindow(Size.x, Size.y, 0, 0, 0, 0, 0, 0, GLFW_WINDOW);
It seems that on Intel OGL pixel format without depth buffer is selected and rendered output for some samples (gl-320-draw-base-vertex) is incorrect.
If above call is changed to:
glfwOpenWindow(Size.x, Size.y, 0, 0, 0, 0, 24, 0, GLFW_WINDOW);
Rendered output is correct.
Thanks.
In the gl-430-caps project I noticed some differences between the code's minimum values and the spec's minimum values. This is the document I was using for comparison, which I assume is the most recent for OpenGL 4.3 (http://www.opengl.org/registry/doc/glspec43.core.20130214.pdf).
First, page 564 says that MAX_GEOMETRY_UNIFORM_COMPONENTS has a minimum value of 512.
Next, page 566 says that MAX_COMPUTE_UNIFORM_COMPONENTS has a minimum value of 512.
Finally, page 566 also says that MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS does not have a defined minimum value (all other MAX_COMBINED_[stage]_UNIFORM_COMPONENTS follow the formula from Table 23.66 on page 570 except for MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS).
It tries to write the binaries to ogl-samples/gl-410/*
instead of ogl-samples/data/gl-410/*
:
$ strace build/Debug/gl-410-program-binary |& grep 'binary\.\w\+\.bin' | github-quote
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.vert.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.geom.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.frag.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.vert.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.geom.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.frag.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.vert.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.geom.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.frag.bin", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.vert.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.geom.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
open("/home/jfonseca/work/vmware/tests/ogl-samples/gl-410/binary.frag.bin", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
And as consequence, glProgramBinary
call never gets exercised. I noticed this because I wanted to test out apitrace with it.
This used to work in the past, as I can still find some old shader binaries from Feb 26 2014.
So it might be worth adding some additional checks when writing the binary programs to ensure this doesn't silently fail in the future too.
On cleanup you test if UniformPointer is not valid and if so you unmap the pointer.
The negation should probably be removed.
https://github.com/g-truc/ogl-samples/blob/master/tests/gl-440-buffer-storage.cpp#L225-L230
Oï! Dans ogl-samples-4.5.0.0 il faut enlever le fichier external/glfw-3.0.3/src/config.h pour faire une build mac/linux
Are not handled by debugOutput routine. This causes gl-430-debug sample to output corrupted text.
On a Linux system the CMakeLists.txt as written will not look for a GLEW library already installed on the system. If it's already installed, this results in "cannot find -lglew" errors. The offending lines are:
if(APPLE)
find_library(GLEW_LIBRARY GLEW)
else()
it should be:
if(APPLE OR UNIX)
find_library(GLEW_LIBRARY GLEW)
else()
Also your listings of changes in readme.txt say you got rid of GLEW in version 4.3.2.0. You should put an entry that you added GLEW back.
Also you should be checking the version number of GLEW as a number of your 4.2 .. 4.4 samples will not build with older GLEW 1.9 libraries.
If you don't want to do it that way, and always want to use your own GLEW on Linux, then you need to explicitly set the GLEW library in your /external directory that you're using. You can't just rely on the linker to pick it up. I'm not installing your GLEW on my system. It's hell trying to keep GLEW working with most open source projects, and nowadays I'll only use what comes from the Ubuntu repositories. Custom builds tend to explode because they get installed in the wrong directory like /lib64, or else big projects only like the older, more stable, packaged versions of GLEW.
G-Truc v4.3.2.2: gl-430-multi-draw-indirect should be querying GL_UNIFORM_ARRAY_STRIDE to get the stride used for uniform blocks and build the buffer to the required stride.
I get the follow errors:
jarrett@jarrett-laptop:~/projects/ogl_samples$ make
Scanning dependencies of target DATA_COPY
In source build
[ 0%] Built target DATA_COPY
Scanning dependencies of target es-200-draw-elements
[ 0%] Building CXX object samples/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o
In file included from /home/jarrett/projects/ogl_samples/external/glf/compiler.hpp:96:0,
from /home/jarrett/projects/ogl_samples/external/glf/glf.hpp:30,
from /home/jarrett/projects/ogl_samples/samples/es-200-draw-elements.cpp:12:
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl: In member function ‘std::string glf::compiler::loadFile(const string&)’:
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl:305:32: error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(const string&)’
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl:305:32: note: candidates are:
In file included from /home/jarrett/projects/ogl_samples/external/gli-0.3.1.0/gli/gtx/../gtx/loader_dds9.hpp:14:0,
from /home/jarrett/projects/ogl_samples/external/gli-0.3.1.0/gli/gtx/loader.hpp:14,
from /home/jarrett/projects/ogl_samples/external/glf/common.hpp:16,
from /home/jarrett/projects/ogl_samples/external/glf/glf.hpp:28,
from /home/jarrett/projects/ogl_samples/samples/es-200-draw-elements.cpp:12:
/usr/include/c++/4.7/fstream:460:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode = std::_Ios_Openmode]
/usr/include/c++/4.7/fstream:460:7: note: no known conversion for argument 1 from ‘const string {aka const std::basic_string<char>}’ to ‘const char*’
/usr/include/c++/4.7/fstream:446:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT = char; _Traits = std::char_traits<char>]
/usr/include/c++/4.7/fstream:446:7: note: candidate expects 0 arguments, 1 provided
/usr/include/c++/4.7/fstream:420:11: note: std::basic_ifstream<char>::basic_ifstream(const std::basic_ifstream<char>&)
/usr/include/c++/4.7/fstream:420:11: note: no known conversion for argument 1 from ‘const string {aka const std::basic_string<char>}’ to ‘const std::basic_ifstream<char>&’
In file included from /home/jarrett/projects/ogl_samples/external/glf/compiler.hpp:96:0,
from /home/jarrett/projects/ogl_samples/external/glf/glf.hpp:30,
from /home/jarrett/projects/ogl_samples/samples/es-200-draw-elements.cpp:12:
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl: In function ‘std::string glf::format(const char*, ...)’:
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl:329:21: error: ‘va_start’ was not declared in this scope
/home/jarrett/projects/ogl_samples/external/glf/compiler.inl:331:14: error: ‘va_end’ was not declared in this scope
In file included from /home/jarrett/projects/ogl_samples/external/glf/glf.hpp:177:0,
from /home/jarrett/projects/ogl_samples/samples/es-200-draw-elements.cpp:12:
/home/jarrett/projects/ogl_samples/external/glf/glf.inl: In function ‘std::string glf::loadFile(const string&)’:
/home/jarrett/projects/ogl_samples/external/glf/glf.inl:165:32: error: no matching function for call to ‘std::basic_ifstream<char>::basic_ifstream(const string&)’
/home/jarrett/projects/ogl_samples/external/glf/glf.inl:165:32: note: candidates are:
In file included from /home/jarrett/projects/ogl_samples/external/gli-0.3.1.0/gli/gtx/../gtx/loader_dds9.hpp:14:0,
from /home/jarrett/projects/ogl_samples/external/gli-0.3.1.0/gli/gtx/loader.hpp:14,
from /home/jarrett/projects/ogl_samples/external/glf/common.hpp:16,
from /home/jarrett/projects/ogl_samples/external/glf/glf.hpp:28,
from /home/jarrett/projects/ogl_samples/samples/es-200-draw-elements.cpp:12:
/usr/include/c++/4.7/fstream:460:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream(const char*, std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits<char>; std::ios_base::openmode = std::_Ios_Openmode]
/usr/include/c++/4.7/fstream:460:7: note: no known conversion for argument 1 from ‘const string {aka const std::basic_string<char>}’ to ‘const char*’
/usr/include/c++/4.7/fstream:446:7: note: std::basic_ifstream<_CharT, _Traits>::basic_ifstream() [with _CharT = char; _Traits = std::char_traits<char>]
/usr/include/c++/4.7/fstream:446:7: note: candidate expects 0 arguments, 1 provided
/usr/include/c++/4.7/fstream:420:11: note: std::basic_ifstream<char>::basic_ifstream(const std::basic_ifstream<char>&)
/usr/include/c++/4.7/fstream:420:11: note: no known conversion for argument 1 from ‘const string {aka const std::basic_string<char>}’ to ‘const std::basic_ifstream<char>&’
make[2]: *** [samples/CMakeFiles/es-200-draw-elements.dir/es-200-draw-elements.cpp.o] Error 1
make[1]: *** [samples/CMakeFiles/es-200-draw-elements.dir/all] Error 2
make: *** [all] Error 2
The following test have frame buffer incomplete by specification:
"Each draw buffers must either specify color attachment points that have images attached or must be GL_NONE. (GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER when false)"
gl-320-fbo-depth
gl-320-fbo-depth-multisample
gl-320-fbo-multisample-integer
gl-320-fbo-shadow
The fix is the following:
After
glBindFramebuffer(.....);
Add
glDrawBuffer(GL_NONE);
This happens when CMAKE_BUILD_TYPE=Debug
, for all compressed textures.
The assertion seems bogus to me.
This patch fixes it:
diff --git a/external/gli/gli/core/load_dds.inl b/external/gli/gli/core/load_dds.inl
index 6d4270e..770c66e 100644
--- a/external/gli/gli/core/load_dds.inl
+++ b/external/gli/gli/core/load_dds.inl
@@ -407,8 +407,11 @@ inline storage load_dds(std::istream& FileIn)
break;
}
}
- else
+
+ if (Format == gli::FORMAT_INVALID)
+ {
assert(0);
+ }
std::streamoff Curr = FileIn.tellg();
FileIn.seekg(0, std::ios_base::end);
Salut Christophe,
I see in the caps::initVersion()
you check also about the KHR_debug
extension
if(this->check(4, 3) || Extensions.KHR_debug)
but this extension will be checked only in the caps::initExtensions()
which is being called after the caps::initVersion()
in the caps constructor
Am I wrong?
I'm not being able to compile the samples in Mint 64-bits.
[ 10%] Building CXX object samples/CMakeFiles/gl-320-fbo-depth-multisample.dir/gl-320-fbo-depth-multisample.cpp.o
Linking CXX executable ../build/release/gl-320-fbo-depth-multisample
CMakeFiles/gl-320-fbo-depth-multisample.dir/gl-320-fbo-depth-multisample.cpp.o: In function initTexture()': gl-320-fbo-depth-multisample.cpp:(.text+0x14d7): undefined reference to
glTexImage2DMultisample'
collect2: error: ld returned 1 exit status
make[2]: *** [build/release/gl-320-fbo-depth-multisample] Error 1
make[1]: *** [samples/CMakeFiles/gl-320-fbo-depth-multisample.dir/all] Error 2
make: *** [all] Error 2
having
gcc: 4.7.2
OpenGL version string: 4.3.0 NVIDIA 313.09
OpenGL shading language version string: 4.30 NVIDIA via Cg compiler
Based on the docs
void glMinSampleShading(GLfloat value);
value can be only [0, 1], then 2 should be wrong..
The CMake script installs the sample binaries to the /usr/local directory on Linux, not /usr/local/bin as would be expected. Also there is no uninstall provided, so this has the effect of crapping on /usr/local and leaving a mess for the user to clean up manually. Fortunately not a huge mess as everything begins with gl-*. The offending line is probably
install (DIRECTORY data DESTINATION .)
which probably replaces the sane Unix defaults with . the directory itself. This is probably a Windows-ism and probably isn't correct behavior even on Windows, as C:\Program Files\projectname is the typical default CMake installation directory.
It's been awhile since I've done CMake, but probably installation and uninstallation targets are a bit more verbose to specify, with specific targets for binaries, libraries, shared libraries, etc. I doubt there's any one stop shop where you give it a '.' and uninstallation is definitely not automatically generated either.
https://github.com/g-truc/ogl-samples/blob/master/tests/gl-320-buffer-uniform.cpp#L190
should be glUniformBlockBinding(ProgramName, this->UniformPerScene, uniform::PER_SCENE);
Quite tiny and direct.
Shrek
GLO_BUFFER_OFFSET
is defined as this:
#define GLO_BUFFER_OFFSET(i) ((char *)NULL + (i))
This is undefined behavior in C++. While the integer literal 0 is implicitly convertible to a pointer, that doesn't mean that the null pointer must have the numerical pointer value of 0. Or, to put another way, C++ does not require the following:
void *pNull = 0;
int iNull = reinterpret_cast<int>(pNull);
iNull == 0
Now to be fair, there is no way to define a buffer offset macro that is protected C++, as conversions from integers to pointers is undefined behavior. However, the definition of NULL
is not defined except that it is some value which is implicitly convertible to the null-pointer constant.
C++11 makes it possible for standard libraries to define NULL
as nullptr
instead of 0. nullptr
is an object of type std::nullptr_t
, and the entire reason it exists is because nullptr
cannot be implicitly converted to an integer (unlike the integer literal 0). It fixes an overload resolution bug. If a standard library defined NULL
this way, your code would break.
Though to be fair, I heard that a programmer working on a standard library implementation tried to do this to see what would happen, and attempting to build a large program failed due to people assuming that NULL
was 0. So it's unlikely for them to do so, but it's still possible.
I would suggest the following. Since you're invoking undefined behavior anyway, just be explicit about it:
#define GLO_BUFFER_OFFSET(i) reinterpret_cast<void*>(i)
At least then your code won't break if someone redefines NULL
on you...
Getting a lot of "error LNK2019: unresolved external symbol" errors when building samples in VS2013 (see below). Can be solved by building FreeImage manually and replacing included FreeImage .dll & .lib
3>C:\ogl-samples-4.4.1.2\build\Debug\gl-320-fbo.exe : fatal error LNK1120: 10 unresolved externals
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_Initialise referenced in function "void __cdecl glf::FreeImageInit(void)" (?
FreeImageInit@glf@@yaxxz)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_DeInitialise referenced in function "void __cdecl glf::FreeImageFree(void)" (?FreeImageFree@glf@@yaxxz)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_Unload referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_Load referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_Save referenced in function "void __cdecl glf::save_png(class gli::texture2D const &,char const *)" (?save_png@glf@@YAXABVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_GetBits referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_GetBPP referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_GetWidth referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_GetHeight referenced in function "class gli::texture2D __cdecl glf::load_png(char const *)" (?load_png@glf@@ya?AVtexture2D@gli@@pbd@Z)
9>png.obj : error LNK2019: unresolved external symbol _FreeImage_ConvertFromRawBits referenced in function "void __cdecl glf::save_png(class gli::texture2D const &,char const *)" (?save_png@glf@@YAXABVtexture2D@gli@@pbd@Z)
hi,
I think there should add texture memory initialization in gl-320-fbo-blit and gl-420-fbo-srgb-decode-ext. In test case gl-320-fbo-blit and gl-420-fbo-srgb-decode –ext, they both use glTexImage2D with null data to allocate a texture memory, but without initialization, then are used to be bound fbo to render with less size texture. Hence they both cause corruption.
I add the following two lines after glFramebufferTexture() function to initialize. And in my modified code testing, they are run successfully without corruption.
GLuint clearColor[4] = {0, 0, 0, 0};
glClearBufferuiv(GL_COLOR, 0, clearColor);
Thanks!
Crystal
There is a bug in the code.
TransformUniformMVP = glGetUniformLocation(...);
// ...
glGetActiveUniform(TransformProgramName, TransformUniformMVP, ...);
Above code isn't correct because glGetActiveUniform command takes 'index' as a second parameter not 'location'.
This works on NV and AMD but not on Intel because locations in Intel driver are some large numbers and don't start from 0.
Thanks.
Errors while compiling in VS 2013:
56>framework.lib(png.obj) : error LNK2019: unresolved external symbol _FreeImage_DeInitialise referenced in function "void __cdecl `anonymous namespace'::FreeImageFree(void)" (?FreeImageFree@?A0x88dbf2a9@@yaxxz)
Hi,
It seems that there is a bug in gl-430-caps sample:
Sample is not aware of GL_COMPRESSED_RGB_FXT1_3DFX and GL_COMPRESSED_RGBA_FXT1_3DFX formats and fails on Intel HW.
Thanks,
Michal
It should be
else if(Version == std::string("300 es")) VersionData.GLSL300ES = true;
Sample is using feature from 4.3:
Add VERTEX_ATTRIB_ARRAY_LONG query for whether a vertex attribute is
stored as an unconverted double (Bug 8272).
Hi,
the change in the subject breaks running the samples in interactive mode (when AUTOMATED_TESTS is undefined), since the loop condition for closing the window is always true.
Line421 should be: glActiveTexture(GL_TEXTURE0 + sampling::SAMPLER_DIFFUSE);
I tried:
sudo make x11-dist-install
from the ..../ogl-samples/external/glfw-3.1.1 and the ..../ogl-samples directory and also greped through the various makefiles and the is not rule for x11-dist-install.
Could it be your readme.md is outdated? Or is something missing?
Thanks
I guess this:
glClearBufferfv(GL_UNIFORM_BUFFER, 0, &glm::vec4(0.0f, 0.5f, 1.0f, 1.0f)[0]);
should be:
glClearBufferfv(GL_COLOR, 0, &glm::vec4(0.0f, 0.5f, 1.0f, 1.0f)[0]);
it looks like although make install is executed and binaries are copied to the installation directory, when running tests, they will still try to load data like texture files from the location where the binaries are complied, i notices that the function getDataDirectory() get value from OGL_SAMPLES_SOURCE_DIR which is set as the absolute path of the source code when configuring make files , i didn't find a way to make it as relative path when configuring make files, so, am i missing something or is it expected this way?
There is this bug in Mesa referring to ogl-samples test gl-320-fbo-layered:
https://bugs.freedesktop.org/show_bug.cgi?id=76397
The linked reference image with the expected test result [1] is
wrong. Borders should be white, not black.
[1] https://github.com/g-truc/ogl-samples/blob/master/data/templates/reference/gl-320-fbo-layered.png
So a straight "sudo make x11-dist-install" as given in readme.txt won't work.
gl-320-fbo-shadow.cpp line 281 should be checking the shadow frame buffer completeness.
Double
else if(!strcmp("GL_ARB_robustness_isolation", Extension)) ExtensionData.ARB_robustness_isolation = true; else if(!strcmp("GL_ARB_robustness_isolation", Extension)) ExtensionData.ARB_robustness_isolation = true;
Ps: sorry but I can't push at the moment
In
gl4.glDrawArraysInstanced(GL_TRIANGLES, 0, vertexCount, 5);
there should be 2 instance rather than 5..
I know my GPU is old. The compilation stops at some gl-410-* file; I assume that it is because I only have OpenGL 3.3
$ glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce G 103M/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 319.32
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL extensions:
I thought that I can get 300, 320, 330 things work at least. However, it is not the case and many programs ends with "(0) : error C5145: must write to gl_Position".
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.