GL_EXT_packed_pixels vs GL_APPLE_packed_pixels - macos
My application checks for GL_EXT_packed_pixels extension before using packed pixel formats such as UNSIGNED_INT_8_8_8_8_EXT. On my MacBook, my code can't find this extension, despite that using packed pixel formats still appears to work.
OpenGL Extension Viewer seems to suggest that it has a special name on OS X:
What's the difference? Should I just check for either GL_EXT_packed_pixels or GL_APPLE_packed_pixels when assessing if UNSIGNED_INT_8_8_8_8_EXT is supported?
EXT_packed_pixels has these definitions:
UNSIGNED_BYTE_3_3_2_EXT 0x8032
UNSIGNED_SHORT_4_4_4_4_EXT 0x8033
UNSIGNED_SHORT_5_5_5_1_EXT 0x8034
UNSIGNED_INT_8_8_8_8_EXT 0x8035
UNSIGNED_INT_10_10_10_2_EXT 0x8036
While APPLE_packed_pixels has these:
UNSIGNED_BYTE_3_3_2 0x8032
UNSIGNED_BYTE_2_3_3_REV 0x8362
UNSIGNED_SHORT_5_6_5 0x8363
UNSIGNED_SHORT_5_6_5_REV 0x8364
UNSIGNED_SHORT_4_4_4_4 0x8033
UNSIGNED_SHORT_4_4_4_4_REV 0x8365
UNSIGNED_SHORT_5_5_5_1 0x8034
UNSIGNED_SHORT_1_5_5_5_REV 0x8366
UNSIGNED_INT_8_8_8_8 0x8035
UNSIGNED_INT_8_8_8_8_REV 0x8367
UNSIGNED_INT_10_10_10_2 0x8036
UNSIGNED_INT_2_10_10_10_REV 0x8368
Comparing the two, EXT_packed_pixels is a subset of APPLE_packed_pixels, and the shared values are the same. Therefore, if APPLE_packed_pixels is supported, you can safely use all definitions from EXT_packed_pixels.
As your screen shot of the extension viewer already suggests, GL_EXT_packed_pixels has been core functionality since OpenGL 1.2. So in most cases, you should not have to test for any of these in the extension string. If you check the version first, and it's at least 1.2, you already know that the functionality is available. The test logic could look like this:
if (strcmp(glGetString(GL_VERSION), "1.2") >= 0 ||
strstr(glGetString(GL_EXTENSIONS), "_packed_pixels") != NULL)
{
// supported
}
Related
OpenGL ES / Vulkan: Per fragment stencil write/test (on Qualcomm Snapdragon XR2)
I would like to render two meshes, the first one writing into the stencil buffer and the second one testing against it. I want to do that on a per fragment level though (the fragment shader of the first object should define which value to write into the stencil buffer and the fragment shader of the second object should define whether and against which stencil value the fragments of the second object should be clipped). My Target Platform is the Oculus Quest 2, which has a Qualcomm Snapdragon XR. If the platform would support GL_ARM_shader_framebuffer_fetch_depth_stencil, I could use that, but that's only supported on some Mali GPUs. The reason I want to use stencils is that I want to render everything in a single forward rendering pass for performance reasons and since I'm already forced to use fragment discard in my shaders, early z-rejection is off the table anyway so that's not a concern. How can I achieve per fragment stencil writing/testing on Qualcomm Snapdragon XR2 in either OpenGL ES 3.0 or Vulkan? any pointers are appreciated.
I had to print out all available extensions on the Quest 2 recently for a project and can confirm that GL_ARM_shader_framebuffer_fetch_depth_stencil is supported. To be clear though, this extension only enables reading the stencil value, not writing to it. If it helps, these are the supported extensions: GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_half_float GL_OES_framebuffer_object GL_OES_rgb8_rgba8 GL_OES_compressed_ETC1_RGB8_texture GL_AMD_compressed_ATC_texture GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_hdr GL_OES_texture_compression_astc GL_OES_texture_npot GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_OES_texture_3D GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_QCOM_alpha_test GL_OES_depth24 GL_OES_packed_depth_stencil GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_EXT_sRGB GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_EXT_texture_type_2_10_10_10_REV GL_EXT_texture_sRGB_decode GL_EXT_texture_format_sRGB_override GL_OES_element_index_uint GL_EXT_copy_image GL_EXT_geometry_shader GL_EXT_tessellation_shader GL_OES_texture_stencil8 GL_EXT_shader_io_blocks GL_OES_shader_image_atomic GL_OES_sample_variables GL_EXT_texture_border_clamp GL_EXT_EGL_image_external_wrap_modes GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_OES_shader_multisample_interpolation GL_EXT_texture_cube_map_array GL_EXT_draw_buffers_indexed GL_EXT_gpu_shader5 GL_EXT_robustness GL_EXT_texture_buffer GL_EXT_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_OES_texture_storage_multisample_2d_array GL_OES_sample_shading GL_OES_get_program_binary GL_EXT_debug_label GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_QCOM_tiled_rendering GL_ANDROID_extension_pack_es31a GL_EXT_primitive_bounding_box GL_OES_standard_derivatives GL_OES_vertex_array_object GL_EXT_disjoint_timer_query GL_KHR_debug GL_EXT_YUV_target GL_EXT_sRGB_write_control GL_EXT_texture_norm16 GL_EXT_discard_framebuffer GL_OES_surfaceless_context GL_OVR_multiview GL_OVR_multiview2 GL_EXT_texture_sRGB_R8 GL_KHR_no_error GL_EXT_debug_marker GL_OES_EGL_image_external_essl3 GL_OVR_multiview_multisampled_render_to_texture GL_EXT_buffer_storage GL_EXT_external_buffer GL_EXT_blit_framebuffer_params GL_EXT_clip_cull_distance GL_EXT_protected_textures GL_EXT_shader_non_constant_global_initializers GL_QCOM_texture_foveated GL_QCOM_texture_foveated2 GL_QCOM_texture_foveated_subsampled_layout GL_QCOM_shader_framebuffer_fetch_noncoherent GL_QCOM_shader_framebuffer_fetch_rate GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_EGL_image_array GL_NV_shader_noperspective_interpolation GL_KHR_robust_buffer_access_behavior GL_EXT_EGL_image_storage GL_EXT_blend_func_extended GL_EXT_clip_control GL_OES_texture_view GL_EXT_fragment_invocation_density GL_QCOM_motion_estimation GL_QCOM_validate_shader_binary GL_QCOM_YUV_texture_gather GL_IMG_texture_filter_cubic```
You can have per-invocation stencil reference values with VK_EXT_shader_stencil_export. Nevertheless that extension is not widely supported. I am not sure what you are trying to do, but it seems you will need to find another way.
freeimage 3.17 library build failing on Mac OS X: fails with C++11 narrowing error... any ideas?
With not having any understanding of C++ (I'm teaching myself Swift), I'm struggling a bit to get around this one - but ideally would love to be able to expose some of the functionality in the FreeImage library in my project. It appears that only one module is generating any errors: dcraw_common.cpp - and the lines in error are those from the following entry list where there is a value of 0x80 or above. From the investigations I've done, it would appear that these values are too large for a signed char (max 128?), yet the list also includes negative numbers, and so it can't use an unsigned char. Any help would be most gratefully received. Here's an example of the error message generated by the make process: Source/LibRawLite/./internal/dcraw_common.cpp:4543:19: error: constant expression evaluates to 136 which cannot be narrowed to type 'signed char' [-Wc++11-narrowing] +1,-1,+1,+1,0,0x88, +1,+0,+1,+2,0,0x08, +1,+0,+2,-1,0,0x40, ^~~~ And here's the code: void CLASS vng_interpolate() { static const signed char *cp, terms[] = { -2,-2,+0,-1,0,0x01, -2,-2,+0,+0,1,0x01, -2,-1,-1,+0,0,0x01, -2,-1,+0,-1,0,0x02, -2,-1,+0,+0,0,0x03, -2,-1,+0,+1,1,0x01, -2,+0,+0,-1,0,0x06, -2,+0,+0,+0,1,0x02, -2,+0,+0,+1,0,0x03, -2,+1,-1,+0,0,0x04, -2,+1,+0,-1,1,0x04, -2,+1,+0,+0,0,0x06, -2,+1,+0,+1,0,0x02, -2,+2,+0,+0,1,0x04, -2,+2,+0,+1,0,0x04, -1,-2,-1,+0,0,0x80, -1,-2,+0,-1,0,0x01, -1,-2,+1,-1,0,0x01, -1,-2,+1,+0,1,0x01, -1,-1,-1,+1,0,0x88, -1,-1,+1,-2,0,0x40, -1,-1,+1,-1,0,0x22, -1,-1,+1,+0,0,0x33, -1,-1,+1,+1,1,0x11, -1,+0,-1,+2,0,0x08, -1,+0,+0,-1,0,0x44, -1,+0,+0,+1,0,0x11, -1,+0,+1,-2,1,0x40, -1,+0,+1,-1,0,0x66, -1,+0,+1,+0,1,0x22, -1,+0,+1,+1,0,0x33, -1,+0,+1,+2,1,0x10, -1,+1,+1,-1,1,0x44, -1,+1,+1,+0,0,0x66, -1,+1,+1,+1,0,0x22, -1,+1,+1,+2,0,0x10, -1,+2,+0,+1,0,0x04, -1,+2,+1,+0,1,0x04, -1,+2,+1,+1,0,0x04, +0,-2,+0,+0,1,0x80, +0,-1,+0,+1,1,0x88, +0,-1,+1,-2,0,0x40, +0,-1,+1,+0,0,0x11, +0,-1,+2,-2,0,0x40, +0,-1,+2,-1,0,0x20, +0,-1,+2,+0,0,0x30, +0,-1,+2,+1,1,0x10, +0,+0,+0,+2,1,0x08, +0,+0,+2,-2,1,0x40, +0,+0,+2,-1,0,0x60, +0,+0,+2,+0,1,0x20, +0,+0,+2,+1,0,0x30, +0,+0,+2,+2,1,0x10, +0,+1,+1,+0,0,0x44, +0,+1,+1,+2,0,0x10, +0,+1,+2,-1,1,0x40, +0,+1,+2,+0,0,0x60, +0,+1,+2,+1,0,0x20, +0,+1,+2,+2,0,0x10, +1,-2,+1,+0,0,0x80, +1,-1,+1,+1,0,0x88, +1,+0,+1,+2,0,0x08, +1,+0,+2,-1,0,0x40, +1,+0,+2,+1,0,0x10 }, chood[] = { -1,-1, -1,0, -1,+1, 0,+1, +1,+1, +1,0, +1,-1, 0,-1 }; ...
C++11 prevents 'narrowing conversions' like that. Early versions of C++ would accept them. I think this patch to the source of dcraw_common.cpp should fix it. https://gist.github.com/conchurnavid/ac19c8e882f1835f0310 There's a duplicate question here. Building FreeImage 3.16.0 for Android
The most usable solution I found to this issue was the following GitHub posting: https://github.com/danoli3/FreeImage. Here some kind soul appears to have successfully built the 3.17.0 library and uploaded it. I've found that works just fine. Please bear in mind however that it's been built with a hard-coded path of /opt/local/lib - which may be an issue when you come to implementation, since your app will be looking for it there, not bundled with the app. I did find this LiveCode post aided my understanding in that regard a lot. Hope this helps.
Predefined Windows icons: Unicode
I am assigning to the lpszIcon member of the MSGBOXPARAMSW structure(notice the W). I want to use one of the predefined icons like IDI_APPLICATION or IDI_WARNING but they are all ASCII (defined as MAKEINTRESOURCE). I tried doing this: MSGBOXPARAMSW mbp = { 0 }; mbp.lpszIcon = (LPCWSTR) IDI_ERROR; but then no icon displayed at all. So how can I use the unicode versions of the IDI_ icons?
There is no ANSI or Unicode variant of a numeric resource ID. The code that you use to set lpszIcon is correct. It is idiomatic to use the MAKEINTRESOURCE macro rather than a cast, but the cast has identical meaning. Your problem lies in the other code, the code that we cannot see. Reading between the lines, I think that you are targeting ANSI or MBCS. You tried to use MAKEINTRESOURCE but that expands to MAKEINTRESOURCEA. That's what led you to cast. You should have used MAKEINTRESOURCEW to match MSGBOXPARAMSW. That would have resolved the compilation error you encountered. You could equally have changed the project to target UNICODE. But none of that explains why the icon does not appear in the dialog. There has to be a problem elsewhere. If the dialog appears then the most likely explanation is that you have set hInstance to a value other than NULL. But the code to set lpszIcon is correct, albeit not idiomatic.
Reflection Swift 2.0 XCode 7 beta 5
Apple has changed the Swift reflection in XCode 7 beta 5. The global reflect() function is gone, and you'll have to do this: let mirror = Mirror(reflecting: object) It gives more or less the same information in a nicer way (no more .1 og .2 for propertyname and value). But I can't find a way to explore if the mirrored item is an instance of a class. The older implementation you could check the following: reflectedProperty.1.objectIdentifier != nil || reflectedProperty.1.count > 0 But objectIdentifier seems to be gone and the count is always 2 regardless of type. Help anyone?
Ok so I found a workaround. I was iterating over mirror.children.enumerate() which seemed to make all the properties of type String. Instead I dug into Apple preliminary documentation, and read that it could be a good idea to "upgrade" children to e.g. AnyRandomAccessCollection. Which made it possible to rely on the count of an objects children to determine if it's an object (after testing whether it's an array) Currently I have a functioning Swift class to JSON Serializer working here on this gist if you are interested in the code: https://gist.github.com/peheje/cc3618253d4f38ea4885
I am not sure if you are looking for this, but the output for the following is "Class" mirror.displayStyle
boost object_pool construct method
I'm keen on using boost's object_pool class for memory re-use for a set of video frames. boost::object_pool< VideoFrame > FramePool; Now, the VideoFrame class has two constructors. The first version of the constructor takes 4 arguments while the second version takes 6 arguments/parameters. For every "new" video frame that is allocated, I would like to call the constructor on the object either using the 4 or 6 parameter version. For example: //VideoFrame *F = new VideoFrame(IdeckLinkOutput, &R, PixelFormat, FrameFlags); VideoFrame *F = FramePool.construct(IdeckLinkOutput, &R, PixelFormat, FrameFlags); Building this on MSVS 2005, I receive the error: error C2660: 'boost::object_pool<T>::construct' : function does not take 4 arguments According to the documentation on the 'construct' method of object_pool, "ElementType must have a constructor matching ???; the number of parameters given must not exceed what is supported through pool_construct" I've seen boost's page for the pool_construct, but I'm not too sure the direction I need to take. The build of boost that I have on my machine has both a pool_construct.m4, pool_construct.sh, pool_construct.bat, pool_construct.inc. It's a question of what do I do with these example files within my own project? Would I create my own variation of pool_construct.inc and include that in my own project? How would I add the file? Any tips/recommendations would be much appreciated. Please note that I have installed gnu's m4. zerodefect.
If I look at /usr/include/boost/pool/detail/pool_construct.inc on my Debian machine (sorry don't have access to MSVC currently), I see it only supports up to 3 constructor arguments. Messing with m4 as per the documentation to support more than the supported 3 sounds like a pain compared with simply creating a new constructor which bundles enough of the arguments in a single struct or boost::tuple to bring the total passed down to the number supported.