Are you able to use any debugger or other software to determine just what part of your screensaver program maps to address 0x00406805? If so, expect that part to need more attention.
Are you able to use any debugger or other software to determine just what part of your screensaver program maps to address 0x00406805? If so, expect that part to need more attention.
Absolutely. I was going to ask if anyone knows of a good Windows debugger, attaching Visual Studio to the process say?
Cheers, Mike.
( edit ) Wow, I've just fallen over at the latest VS version price ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Nope. BOINC is fine - that's just the route to the invoked debugger. BTW PEBrowse Professional Interactive from Smidgeonsoft is quite a neat low level debugger for Windows.
Same old problem, a call to the OpenGL v3.2+ API falls over for lack of legacy or backwards compatibility. That means the new framework doesn't solve the issue, even though the GLEW/GLFW is a nice interface.
OK. I'll go and write a Windows workaround myself .... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I'll be darned! Now here's a thing : take any given video card driver on some machine and use a utility like glewinfo or visualinfo to define what's actually on offer per some stated/reported OpenGL version ( as the driver itself reports ). What do you find ?
(a) some, most I've tested actually, precisely fit the declared OpenGL version spec. You get all up to and including that version, and nil that exceeds that. Plus or minus some vendor specific extensions ( ie. without the ARB tag ), which is of course perfectly allowed.
(b) some, like (a) above, give all that it should up to some version but gives a bit more eg. features of v1.5 plus a few from v2.1 say. Plus or minus some vendor specific extensions ....
(c) a few ( and this is my main worry ) give most of what is defined as standard up to and including some OpenGL version. But they miss a couple.
For instance I have an old SiS VGA card that reports as v1.4 but doesn't actually have three of four v1.2 components :
[pre]glCopyTexSubImage3D MISSING
glDrawRangeElements OK
glTexImage3D MISSING
glTexSubImage3D MISSING[/pre]
and two v1.4 facilities :
[pre]glPointParameteri: MISSING
glPointParameteriv: MISSING[/pre]
... thus in this instance you miss out on 3D textures and some state query aspects. This would probably come to light at runtime following a call to a NULL pointer producing an exception. Sounds familiar ?
Lessons :
- if it matters ( and when wouldn't it ? ) you need to have and utilise a runtime check mechanism to establish said facilities that you intend to use. Failing that your app could fall over without obvious reason, and in that regard I have very much been there, done that, but yet have no T-shirt! :-)
- if one can't assume the presence of supposed functions for a given declared OpenGL version, then what else may be problematic ? In particular I've found some variance in the behaviour of implementations of a function called glMapBuffer ( first introduced in v1.5 ). I have made heavy use of this, hence my interest. Believe or not, this would be an ARB compliant instance :
[pre]void* glMapBuffer(GLenum target, GLenum access){
return NULL;
}[/pre]
... that is, it fails every time and yet emits no error recoverable via glGetError(). Now in this matter I have found discussions based upon the alignment of structures to be placed in the server side memory. Mal-alignment is not a reportable fault for this function, yet there remains this intriguing comment in the description of a related function glBufferData() :
Quote:
Clients must align data elements consistent with the requirements of the client platform, with an additional base-level requirement that an offset within a buffer to a datum comprising N bytes be a multiple of N.
... which I understand, but leaves the question of how to achieve that, in a framework looking to run on many types of clients. I am going to investigate the prospects of forcing alignment ( by compile time techniques ) to some suitable catch-all case. A 64 bit ( 8 byte ) boundary seems to be mentioned alot. My hypothesis is that glMapBuffer may fail without specific report due to alignment issues on one machine vs another. Whether it's general memory alignment ( so the CPU ) or card memory ( hence the GPU ) or some mutual mismatch, I don't know.
In any event, these revelations go quite a long way to explaining the difficulties on Windows platform builds.
Thank you kindly Robert for your nudge in a most fruitful direction. :-)
Might I emphasise that none of this appears to arise/apply to Linux builds what-so-ever, and thus I hope by extension to Mac's when I get to them.
Cheers, Mike.
( edit ) I forgot to say : the glMapBuffer()/etc documents depend on the OpenGL version, and those referring to later versions have additional mentions of alignment requirements. This, in my mind, leaves the possibility that a backwards compatible context ( obtained from a v3.2+ instance ) - say giving the interface a v2.1 flavour - may impose said alignment requirements even though the prior context definition didn't ever include that. If so, would that not be rather 'unfair' ? :-) :-)
( edit ) The GLEW library allows an easy runtime check of OpenGL facilities. I will enact this in the screensaver code for the particular group of post v1.1 functions that I rely upon ....
( edit ) I believe SSE for instance likes/requires 16 byte alignments, thus also fits as an 8 byte too ( said to be a common NVIDIA/Linux choice ). But my smallest data structure to go to the video card buffer is 24 bytes ( six floats for a single vertex, comprising 3 colors making RGB plus 3 position co-ordinates ), thus any offset should go as multiples of 24 - again fine as an 8 byte boundary also, but not a 16 byte one. The magic question here would be whether the driver covers the relevant notable cases re. transfer to the card vs. access once on it. Hmmmmm ...... I do not know enough.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Here's a quite valuable quote from an OpenGL message board guru, made ~2005 :
Quote:
Re: glMapBuffer() returns NULL
Check for errors. Implementations return NULL from MapBuffer to indicate failure to map. The spec does not mandate that any mappings succeed, so it would be legal for an implementation to always fail a map. In this case Buffer(Sub)Data must be used to fill in the object data.
then follows with excerpts of the then standards specification :
Quote:
What should the error behavior of BufferDataARB and MapBufferARB be?
RESOLVED: BufferDataARB returns no value and sets OUT_OF_MEMORY
if the buffer could not be created, whereas MapBufferARB returns
NULL and also sets OUT_OF_MEMORY if the buffer could not be
mapped.
and
Quote:
The entire data store of a buffer object can be mapped into the
client's address space by calling
void *MapBufferARB(enum target, enum access);
with set to ARRAY_BUFFER_ARB. If the GL is able to map the
buffer object's data store into the client's address space,
MapBufferARB returns the pointer value to the data store. Otherwise
MapBufferARB returns NULL, and the error OUT_OF_MEMORY is generated.
is specified as one of READ_ONLY_ARB, WRITE_ONLY_ARB, or
READ_WRITE_ARB, indicating the operations that the client may perform
on the data store through the pointer while the data store is mapped.
... with two associated subtleties
(1) - if a given driver is compliant at all, and
(2) - even so, the OUT_OF_MEMORY error report might only occur if an attempt was made to map. Meaning that : no attempt -> no failure of attempt -> no error reported.
So I think the way to go is :
- glBufferData() to allocate, but not yet initialise, the memory with mandatory report of failure via glGetError()
- then glBufferSubData() to load the data to the video card, without any need to know a pointer, and that has a range check with report :
[pre]GL_INVALID_VALUE is generated if offset or size is negative, or if together they define a region of memory that extends beyond the buffer object's allocated data store.[/pre]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Here's another interesting case :
[pre]---------------------------
GLEW Extension Info
---------------------------
GLEW version 1.7.0
Reporting capabilities of pixelformat 3
Running on a Intel Bear Lake B from Intel
OpenGL version 1.4.0 - Build 7.14.10.4935 is supported
GL_VERSION_1_1: OK
---------------
GL_VERSION_1_2: OK
---------------
glCopyTexSubImage3D: OK
glDrawRangeElements: OK
glTexImage3D: OK
glTexSubImage3D: OK
GL_VERSION_1_2_1: OK
-----------------
GL_VERSION_1_3: OK
---------------
glActiveTexture: OK
glClientActiveTexture: OK
glCompressedTexImage1D: OK
glCompressedTexImage2D: OK
glCompressedTexImage3D: OK
glCompressedTexSubImage1D: OK
glCompressedTexSubImage2D: OK
glCompressedTexSubImage3D: OK
glGetCompressedTexImage: OK
glLoadTransposeMatrixd: OK
glLoadTransposeMatrixf: OK
glMultTransposeMatrixd: OK
glMultTransposeMatrixf: OK
glMultiTexCoord1d: OK
glMultiTexCoord1dv: OK
glMultiTexCoord1f: OK
glMultiTexCoord1fv: OK
glMultiTexCoord1i: OK
glMultiTexCoord1iv: OK
glMultiTexCoord1s: OK
glMultiTexCoord1sv: OK
glMultiTexCoord2d: OK
glMultiTexCoord2dv: OK
glMultiTexCoord2f: OK
glMultiTexCoord2fv: OK
glMultiTexCoord2i: OK
glMultiTexCoord2iv: OK
glMultiTexCoord2s: OK
glMultiTexCoord2sv: OK
glMultiTexCoord3d: OK
glMultiTexCoord3dv: OK
glMultiTexCoord3f: OK
glMultiTexCoord3fv: OK
glMultiTexCoord3i: OK
glMultiTexCoord3iv: OK
glMultiTexCoord3s: OK
glMultiTexCoord3sv: OK
glMultiTexCoord4d: OK
glMultiTexCoord4dv: OK
glMultiTexCoord4f: OK
glMultiTexCoord4fv: OK
glMultiTexCoord4i: OK
glMultiTexCoord4iv: OK
glMultiTexCoord4s: OK
glMultiTexCoord4sv: OK
glSampleCoverage: OK
GL_VERSION_1_4: MISSING
---------------
glBlendColor: OK
glBlendEquation: OK
glBlendFuncSeparate: OK
glFogCoordPointer: OK
glFogCoordd: OK
glFogCoorddv: OK
glFogCoordf: OK
glFogCoordfv: OK
glMultiDrawArrays: OK
glMultiDrawElements: OK
glPointParameterf: OK
glPointParameterfv: OK
glPointParameteri: MISSING
glPointParameteriv: MISSING
glSecondaryColor3b: OK
glSecondaryColor3bv: OK
glSecondaryColor3d: OK
glSecondaryColor3dv: OK
glSecondaryColor3f: OK
glSecondaryColor3fv: OK
glSecondaryColor3i: OK
glSecondaryColor3iv: OK
glSecondaryColor3s: OK
glSecondaryColor3sv: OK
glSecondaryColor3ub: OK
glSecondaryColor3ubv: OK
glSecondaryColor3ui: OK
glSecondaryColor3uiv: OK
glSecondaryColor3us: OK
glSecondaryColor3usv: OK
glSecondaryColorPointer: OK
glWindowPos2d: OK
glWindowPos2dv: OK
glWindowPos2f: OK
glWindowPos2fv: OK
glWindowPos2i: OK
glWindowPos2iv: OK
glWindowPos2s: OK
glWindowPos2sv: OK
glWindowPos3d: OK
glWindowPos3dv: OK
glWindowPos3f: OK
glWindowPos3fv: OK
glWindowPos3i: OK
glWindowPos3iv: OK
glWindowPos3s: OK
glWindowPos3sv: OK
GL_VERSION_1_5: MISSING
---------------
glBeginQuery: MISSING
glBindBuffer: OK
glBufferData: OK
glBufferSubData: OK
glDeleteBuffers: OK
glDeleteQueries: MISSING
glEndQuery: MISSING
glGenBuffers: OK
glGenQueries: MISSING
glGetBufferParameteriv: OK
glGetBufferPointerv: OK
glGetBufferSubData: OK
glGetQueryObjectiv: MISSING
glGetQueryObjectuiv: MISSING
glGetQueryiv: MISSING
glIsBuffer: OK
glIsQuery: MISSING
glMapBuffer: OK
glUnmapBuffer: OK
GL_VERSION_2_0: MISSING
---------------[/pre]
... all v2.0+ functionality not supported. So here we have an instance where the disclosed version ( v1.4 ) is misleading, in that glPointParameteri() and glPointParameteriv() are absent. But none-the-less does support v1.5 features that would suit me ie, all the ones with 'Buffer' within their name !
{ Here's a great analysis of this very device. It's a circa 2007 product, so not really 'ancient'. }
So this suggests the strategy of determining - at runtime, case by case - whether my exact desired functionality is offered rather than relying upon the grosser selection mechanism of the driver's self-declaration of OpenGL version. That would assume that the driver writers have at least honoured dependencies amongst the functions ( eg. you can see above that all buffer-ish functions are exposed but nothing query-ish ). That's probably true. I'm just declaring that an assumption ..... :-)
For information, this is it's extension support :
[pre]OpenGL vendor string: Intel
OpenGL renderer string: Intel Bear Lake B
OpenGL version string: 1.4.0 - Build 7.14.10.4935
OpenGL extensions (GL_):
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_multitexture,
GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_texture_env_crossbar, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_cull_vertex,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_lod_bias,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture3D,
GL_3DFX_texture_compression_FXT1, GL_IBM_texture_mirrored_repeat,
GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_WIN_swap_hint.
GLU version string: 1.2.2.0 Microsoft Corporation
GLU extensions (GLU_):
GL_EXT_bgra.
WGL extensions (WGL_):
WGL_ARB_buffer_region, WGL_ARB_extensions_string, WGL_ARB_make_current_read,
WGL_ARB_pixel_format, WGL_ARB_pbuffer, WGL_EXT_extensions_string,
WGL_EXT_swap_control.
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| 1 | wp fu . i . . . . | 32 8 8 8 8 | . . . | . . . . . | . . . |
| 3 | wp fu . i . . . . | 32 8 8 8 8 | . 16 . | . . . . . | . . . |
| 5 | wp fu . i . . . . | 32 8 8 8 8 | . 24 8 | . . . . . | . . . |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+[/pre]
That is, alot of fancy stuff not contemplated in v1.4 days, and in particular quite a mix of non-ARB extension sources : IBM, 3DFX, NV, SGIS, WIN. This is quite legal of course, but one wonders why that mix was chosen. In any case, it is all curiouser and curiouser.
Now the good news is that I have satisfactorily achieved many more Windows apps running - provided these OpenGL preconditions being discussed are satisfied - especially getting backwards compatible profiles on v3.2+ machines. I feel I have cut the Gordian Knot of the problem, but I'll claim victory when I iron everything out properly and get it working on all platforms that it should and failing that have accurate reporting for the breach. The basic idea is to have the screen saver work on as many platforms as possible. Honestly I didn't expect that going from v1.1 functionality ( ie. Starsphere ) to v1.5 was going to be such a big deal, c'est la vie ....
If anyone has absolutely nothing better to do this weekend I'd be delighted if you would run, on Windows machines only, the following utilities ( glewinfo and visualinfo ) and email me ( hewsmikeATiinet.net.au putting '@' where AT is. Bot defense ) while attaching the resultant report files : glewinfo.txt and visualinfo.txt which are emitted by their respective utilities. I reckon I might be able to confirm my thinking, perhaps see something new.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ok, great success by not using glMapBuffer at all. Using a combination of glBufferData to allocate and then glBufferSubData to populate the server side from a heap based array works fine. While you could combine those two into one glBufferData call, it's easier to distinguish failure modes during testing this way. My research suggests others have the least trouble with that approach, and you don't deal with any pointers outside of your own code this way.
Now for low-end version compliance : I've decided to test the driver to see if it says that it supports v1.5+, but then I test the variable GLEW_VERSION_1_5 ( which is either true or false, set by glewInit ) to see if the driver is 'telling the truth' about it's v1.5 interface. If it fails then the program doesn't proceed, exiting with an appropriate error. I think that's the safest route ( fewest surprises ) and I can't do any more except by writing the driver myself! :-)
We obviously never throw anything out at my workplace : I found a card that can offer 300 x 200 with 16 bit "color" depth and only the Microsoft driver available at v1.1, whereupon a driver upgrade yielded v1.2 ! So at least I have a forest of peri-fencepost cases to test with ... :-)
Texturing is working fine using TGA file format via glfwLoadTexture2D(), but I am now working on embedding all such images within the executable, using ResourceFactory and glfwLoadMemoryTexture2D(). Thus the app will be self contained. If that works I'll publish Linux and Windows executables containing all this progress next week, for comment and testing ....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
We still have the font problem with our normal screensaver graphics, i.e. all text looks unreadable unter Win Vista or Win 7 when using the standard M$ graphics driver (not e.g. some from NVidia or ATI). I bet this has somehting to do with the OpenGL implementation / emulation in the M$ driver, too. As you are fighting with this anyway, could you have a look at that problem, too, if you find the time?
Are you able to use any debugger or other software to determine just what part of your screensaver program maps to address 0x00406805? If so, expect that part to need more attention.
Starpshere uses OGLFT::TranslucentTexture for fonts, and examining the source code for OGLFT I don't find any OpenGL dependency beyond v1.1, thus the MS driver ought faithfully provide there. [ To my knowledge Freetype2, while producing bitmaps from font files etc, doesn't render and so isn't relevant to this problem ]
That I reckon leaves the issue as being that of the Win7/Vista 'aero' feature which may be active in either ( a user can turn that on or off ). Here an app writes to the client area of the window - this is not memory on the video card - which is then blended, via another driver, with a like client area of any overlapping windows/desktops to then give an output onto the card. The methodology of this is opaque to me, especially whether it honors OpenGL and/or whether that would still occur with fullscreen vs windowed modes. My guess is ... well ... it wasn't on their list of concerns. :-)
Alas I don't have a Win7/Vista machine with only an MS driver on it to test my suspicions by switching the aero setting.
Cheers, Mike.
( edit ) Thus my advice would be for those with Win7/Vista and only the MS driver on board is : get a better driver. For a good laugh here is the introduction from this MS web page :
Quote:
The Microsoft implementation of OpenGL for the Windows operating system is industry-standard graphics software ....
quite forgetting to mention that v1.1 is in it's 16th year, and the latest is v4.something ... :-)
( edit ) side note : I have a Ubuntu 11 host which has aero like features, window transparencies etc ... which I am trying to turn off for testing! My background of 'black' to the star field alas is the contents of the window beneath. All other aspects, fonts included, are fine with the Linux drivers. So the clearing color and blending settings only affect that which is under control of a given OpenGL context, but cannot affect what is subsequently done by the OS to process that client area on it's way to display ..... unfortunately most I've read discusses turning transparency on, not off.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Are you able to use any
)
Are you able to use any debugger or other software to determine just what part of your screensaver program maps to address 0x00406805? If so, expect that part to need more attention.
RE: Are you able to use any
)
Absolutely. I was going to ask if anyone knows of a good Windows debugger, attaching Visual Studio to the process say?
Cheers, Mike.
( edit ) Wow, I've just fallen over at the latest VS version price ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Nope. BOINC is fine - that's
)
Nope. BOINC is fine - that's just the route to the invoked debugger. BTW PEBrowse Professional Interactive from Smidgeonsoft is quite a neat low level debugger for Windows.
Same old problem, a call to the OpenGL v3.2+ API falls over for lack of legacy or backwards compatibility. That means the new framework doesn't solve the issue, even though the GLEW/GLFW is a nice interface.
OK. I'll go and write a Windows workaround myself .... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I'll be darned! Now here's a
)
I'll be darned! Now here's a thing : take any given video card driver on some machine and use a utility like glewinfo or visualinfo to define what's actually on offer per some stated/reported OpenGL version ( as the driver itself reports ). What do you find ?
(a) some, most I've tested actually, precisely fit the declared OpenGL version spec. You get all up to and including that version, and nil that exceeds that. Plus or minus some vendor specific extensions ( ie. without the ARB tag ), which is of course perfectly allowed.
(b) some, like (a) above, give all that it should up to some version but gives a bit more eg. features of v1.5 plus a few from v2.1 say. Plus or minus some vendor specific extensions ....
(c) a few ( and this is my main worry ) give most of what is defined as standard up to and including some OpenGL version. But they miss a couple.
For instance I have an old SiS VGA card that reports as v1.4 but doesn't actually have three of four v1.2 components :
[pre]glCopyTexSubImage3D MISSING
glDrawRangeElements OK
glTexImage3D MISSING
glTexSubImage3D MISSING[/pre]
and two v1.4 facilities :
[pre]glPointParameteri: MISSING
glPointParameteriv: MISSING[/pre]
... thus in this instance you miss out on 3D textures and some state query aspects. This would probably come to light at runtime following a call to a NULL pointer producing an exception. Sounds familiar ?
Lessons :
- if it matters ( and when wouldn't it ? ) you need to have and utilise a runtime check mechanism to establish said facilities that you intend to use. Failing that your app could fall over without obvious reason, and in that regard I have very much been there, done that, but yet have no T-shirt! :-)
- if one can't assume the presence of supposed functions for a given declared OpenGL version, then what else may be problematic ? In particular I've found some variance in the behaviour of implementations of a function called glMapBuffer ( first introduced in v1.5 ). I have made heavy use of this, hence my interest. Believe or not, this would be an ARB compliant instance :
[pre]void* glMapBuffer(GLenum target, GLenum access){
return NULL;
}[/pre]
... that is, it fails every time and yet emits no error recoverable via glGetError(). Now in this matter I have found discussions based upon the alignment of structures to be placed in the server side memory. Mal-alignment is not a reportable fault for this function, yet there remains this intriguing comment in the description of a related function glBufferData() :
... which I understand, but leaves the question of how to achieve that, in a framework looking to run on many types of clients. I am going to investigate the prospects of forcing alignment ( by compile time techniques ) to some suitable catch-all case. A 64 bit ( 8 byte ) boundary seems to be mentioned alot. My hypothesis is that glMapBuffer may fail without specific report due to alignment issues on one machine vs another. Whether it's general memory alignment ( so the CPU ) or card memory ( hence the GPU ) or some mutual mismatch, I don't know.
In any event, these revelations go quite a long way to explaining the difficulties on Windows platform builds.
Thank you kindly Robert for your nudge in a most fruitful direction. :-)
Might I emphasise that none of this appears to arise/apply to Linux builds what-so-ever, and thus I hope by extension to Mac's when I get to them.
Cheers, Mike.
( edit ) I forgot to say : the glMapBuffer()/etc documents depend on the OpenGL version, and those referring to later versions have additional mentions of alignment requirements. This, in my mind, leaves the possibility that a backwards compatible context ( obtained from a v3.2+ instance ) - say giving the interface a v2.1 flavour - may impose said alignment requirements even though the prior context definition didn't ever include that. If so, would that not be rather 'unfair' ? :-) :-)
( edit ) The GLEW library allows an easy runtime check of OpenGL facilities. I will enact this in the screensaver code for the particular group of post v1.1 functions that I rely upon ....
( edit ) I believe SSE for instance likes/requires 16 byte alignments, thus also fits as an 8 byte too ( said to be a common NVIDIA/Linux choice ). But my smallest data structure to go to the video card buffer is 24 bytes ( six floats for a single vertex, comprising 3 colors making RGB plus 3 position co-ordinates ), thus any offset should go as multiples of 24 - again fine as an 8 byte boundary also, but not a 16 byte one. The magic question here would be whether the driver covers the relevant notable cases re. transfer to the card vs. access once on it. Hmmmmm ...... I do not know enough.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Here's a quite valuable quote
)
Here's a quite valuable quote from an OpenGL message board guru, made ~2005 :
then follows with excerpts of the then standards specification :
and
... with two associated subtleties
(1) - if a given driver is compliant at all, and
(2) - even so, the OUT_OF_MEMORY error report might only occur if an attempt was made to map. Meaning that : no attempt -> no failure of attempt -> no error reported.
So I think the way to go is :
- glBufferData() to allocate, but not yet initialise, the memory with mandatory report of failure via glGetError()
- then glBufferSubData() to load the data to the video card, without any need to know a pointer, and that has a range check with report :
[pre]GL_INVALID_VALUE is generated if offset or size is negative, or if together they define a region of memory that extends beyond the buffer object's allocated data store.[/pre]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Here's another interesting
)
Here's another interesting case :
[pre]---------------------------
GLEW Extension Info
---------------------------
GLEW version 1.7.0
Reporting capabilities of pixelformat 3
Running on a Intel Bear Lake B from Intel
OpenGL version 1.4.0 - Build 7.14.10.4935 is supported
GL_VERSION_1_1: OK
---------------
GL_VERSION_1_2: OK
---------------
glCopyTexSubImage3D: OK
glDrawRangeElements: OK
glTexImage3D: OK
glTexSubImage3D: OK
GL_VERSION_1_2_1: OK
-----------------
GL_VERSION_1_3: OK
---------------
glActiveTexture: OK
glClientActiveTexture: OK
glCompressedTexImage1D: OK
glCompressedTexImage2D: OK
glCompressedTexImage3D: OK
glCompressedTexSubImage1D: OK
glCompressedTexSubImage2D: OK
glCompressedTexSubImage3D: OK
glGetCompressedTexImage: OK
glLoadTransposeMatrixd: OK
glLoadTransposeMatrixf: OK
glMultTransposeMatrixd: OK
glMultTransposeMatrixf: OK
glMultiTexCoord1d: OK
glMultiTexCoord1dv: OK
glMultiTexCoord1f: OK
glMultiTexCoord1fv: OK
glMultiTexCoord1i: OK
glMultiTexCoord1iv: OK
glMultiTexCoord1s: OK
glMultiTexCoord1sv: OK
glMultiTexCoord2d: OK
glMultiTexCoord2dv: OK
glMultiTexCoord2f: OK
glMultiTexCoord2fv: OK
glMultiTexCoord2i: OK
glMultiTexCoord2iv: OK
glMultiTexCoord2s: OK
glMultiTexCoord2sv: OK
glMultiTexCoord3d: OK
glMultiTexCoord3dv: OK
glMultiTexCoord3f: OK
glMultiTexCoord3fv: OK
glMultiTexCoord3i: OK
glMultiTexCoord3iv: OK
glMultiTexCoord3s: OK
glMultiTexCoord3sv: OK
glMultiTexCoord4d: OK
glMultiTexCoord4dv: OK
glMultiTexCoord4f: OK
glMultiTexCoord4fv: OK
glMultiTexCoord4i: OK
glMultiTexCoord4iv: OK
glMultiTexCoord4s: OK
glMultiTexCoord4sv: OK
glSampleCoverage: OK
GL_VERSION_1_4: MISSING
---------------
glBlendColor: OK
glBlendEquation: OK
glBlendFuncSeparate: OK
glFogCoordPointer: OK
glFogCoordd: OK
glFogCoorddv: OK
glFogCoordf: OK
glFogCoordfv: OK
glMultiDrawArrays: OK
glMultiDrawElements: OK
glPointParameterf: OK
glPointParameterfv: OK
glPointParameteri: MISSING
glPointParameteriv: MISSING
glSecondaryColor3b: OK
glSecondaryColor3bv: OK
glSecondaryColor3d: OK
glSecondaryColor3dv: OK
glSecondaryColor3f: OK
glSecondaryColor3fv: OK
glSecondaryColor3i: OK
glSecondaryColor3iv: OK
glSecondaryColor3s: OK
glSecondaryColor3sv: OK
glSecondaryColor3ub: OK
glSecondaryColor3ubv: OK
glSecondaryColor3ui: OK
glSecondaryColor3uiv: OK
glSecondaryColor3us: OK
glSecondaryColor3usv: OK
glSecondaryColorPointer: OK
glWindowPos2d: OK
glWindowPos2dv: OK
glWindowPos2f: OK
glWindowPos2fv: OK
glWindowPos2i: OK
glWindowPos2iv: OK
glWindowPos2s: OK
glWindowPos2sv: OK
glWindowPos3d: OK
glWindowPos3dv: OK
glWindowPos3f: OK
glWindowPos3fv: OK
glWindowPos3i: OK
glWindowPos3iv: OK
glWindowPos3s: OK
glWindowPos3sv: OK
GL_VERSION_1_5: MISSING
---------------
glBeginQuery: MISSING
glBindBuffer: OK
glBufferData: OK
glBufferSubData: OK
glDeleteBuffers: OK
glDeleteQueries: MISSING
glEndQuery: MISSING
glGenBuffers: OK
glGenQueries: MISSING
glGetBufferParameteriv: OK
glGetBufferPointerv: OK
glGetBufferSubData: OK
glGetQueryObjectiv: MISSING
glGetQueryObjectuiv: MISSING
glGetQueryiv: MISSING
glIsBuffer: OK
glIsQuery: MISSING
glMapBuffer: OK
glUnmapBuffer: OK
GL_VERSION_2_0: MISSING
---------------[/pre]
... all v2.0+ functionality not supported. So here we have an instance where the disclosed version ( v1.4 ) is misleading, in that glPointParameteri() and glPointParameteriv() are absent. But none-the-less does support v1.5 features that would suit me ie, all the ones with 'Buffer' within their name !
{ Here's a great analysis of this very device. It's a circa 2007 product, so not really 'ancient'. }
So this suggests the strategy of determining - at runtime, case by case - whether my exact desired functionality is offered rather than relying upon the grosser selection mechanism of the driver's self-declaration of OpenGL version. That would assume that the driver writers have at least honoured dependencies amongst the functions ( eg. you can see above that all buffer-ish functions are exposed but nothing query-ish ). That's probably true. I'm just declaring that an assumption ..... :-)
For information, this is it's extension support :
[pre]OpenGL vendor string: Intel
OpenGL renderer string: Intel Bear Lake B
OpenGL version string: 1.4.0 - Build 7.14.10.4935
OpenGL extensions (GL_):
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_multitexture,
GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_texture_env_crossbar, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_cull_vertex,
GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_stencil_two_side, GL_EXT_stencil_wrap,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_lod_bias,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture3D,
GL_3DFX_texture_compression_FXT1, GL_IBM_texture_mirrored_repeat,
GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_WIN_swap_hint.
GLU version string: 1.2.2.0 Microsoft Corporation
GLU extensions (GLU_):
GL_EXT_bgra.
WGL extensions (WGL_):
WGL_ARB_buffer_region, WGL_ARB_extensions_string, WGL_ARB_make_current_read,
WGL_ARB_pixel_format, WGL_ARB_pbuffer, WGL_EXT_extensions_string,
WGL_EXT_swap_control.
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| 1 | wp fu . i . . . . | 32 8 8 8 8 | . . . | . . . . . | . . . |
| 3 | wp fu . i . . . . | 32 8 8 8 8 | . 16 . | . . . . . | . . . |
| 5 | wp fu . i . . . . | 32 8 8 8 8 | . 24 8 | . . . . . | . . . |
+-----+-------------------------+-----------------+----------+-----------------+----------+
| | visual | color | ax dp st | accum | layer |
| id | tp ac gd fm db sw st ms | sz r g b a | bf th cl | sz r g b a | ov un sw |
+-----+-------------------------+-----------------+----------+-----------------+----------+[/pre]
That is, alot of fancy stuff not contemplated in v1.4 days, and in particular quite a mix of non-ARB extension sources : IBM, 3DFX, NV, SGIS, WIN. This is quite legal of course, but one wonders why that mix was chosen. In any case, it is all curiouser and curiouser.
Now the good news is that I have satisfactorily achieved many more Windows apps running - provided these OpenGL preconditions being discussed are satisfied - especially getting backwards compatible profiles on v3.2+ machines. I feel I have cut the Gordian Knot of the problem, but I'll claim victory when I iron everything out properly and get it working on all platforms that it should and failing that have accurate reporting for the breach. The basic idea is to have the screen saver work on as many platforms as possible. Honestly I didn't expect that going from v1.1 functionality ( ie. Starsphere ) to v1.5 was going to be such a big deal, c'est la vie ....
If anyone has absolutely nothing better to do this weekend I'd be delighted if you would run, on Windows machines only, the following utilities ( glewinfo and visualinfo ) and email me ( hewsmikeATiinet.net.au putting '@' where AT is. Bot defense ) while attaching the resultant report files : glewinfo.txt and visualinfo.txt which are emitted by their respective utilities. I reckon I might be able to confirm my thinking, perhaps see something new.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ok, great success by not
)
Ok, great success by not using glMapBuffer at all. Using a combination of glBufferData to allocate and then glBufferSubData to populate the server side from a heap based array works fine. While you could combine those two into one glBufferData call, it's easier to distinguish failure modes during testing this way. My research suggests others have the least trouble with that approach, and you don't deal with any pointers outside of your own code this way.
Now for low-end version compliance : I've decided to test the driver to see if it says that it supports v1.5+, but then I test the variable GLEW_VERSION_1_5 ( which is either true or false, set by glewInit ) to see if the driver is 'telling the truth' about it's v1.5 interface. If it fails then the program doesn't proceed, exiting with an appropriate error. I think that's the safest route ( fewest surprises ) and I can't do any more except by writing the driver myself! :-)
We obviously never throw anything out at my workplace : I found a card that can offer 300 x 200 with 16 bit "color" depth and only the Microsoft driver available at v1.1, whereupon a driver upgrade yielded v1.2 ! So at least I have a forest of peri-fencepost cases to test with ... :-)
Texturing is working fine using TGA file format via glfwLoadTexture2D(), but I am now working on embedding all such images within the executable, using ResourceFactory and glfwLoadMemoryTexture2D(). Thus the app will be self contained. If that works I'll publish Linux and Windows executables containing all this progress next week, for comment and testing ....
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Hi Mike! We still have the
)
Hi Mike!
We still have the font problem with our normal screensaver graphics, i.e. all text looks unreadable unter Win Vista or Win 7 when using the standard M$ graphics driver (not e.g. some from NVidia or ATI). I bet this has somehting to do with the OpenGL implementation / emulation in the M$ driver, too. As you are fighting with this anyway, could you have a look at that problem, too, if you find the time?
BM
BM
RE: Are you able to use any
)
Sure, use addr2line
Oliver
Einstein@Home Project
Hi Bernd ! Hi Oliver !
)
Hi Bernd ! Hi Oliver ! :-)
Starpshere uses OGLFT::TranslucentTexture for fonts, and examining the source code for OGLFT I don't find any OpenGL dependency beyond v1.1, thus the MS driver ought faithfully provide there. [ To my knowledge Freetype2, while producing bitmaps from font files etc, doesn't render and so isn't relevant to this problem ]
That I reckon leaves the issue as being that of the Win7/Vista 'aero' feature which may be active in either ( a user can turn that on or off ). Here an app writes to the client area of the window - this is not memory on the video card - which is then blended, via another driver, with a like client area of any overlapping windows/desktops to then give an output onto the card. The methodology of this is opaque to me, especially whether it honors OpenGL and/or whether that would still occur with fullscreen vs windowed modes. My guess is ... well ... it wasn't on their list of concerns. :-)
Alas I don't have a Win7/Vista machine with only an MS driver on it to test my suspicions by switching the aero setting.
Cheers, Mike.
( edit ) Thus my advice would be for those with Win7/Vista and only the MS driver on board is : get a better driver. For a good laugh here is the introduction from this MS web page :
quite forgetting to mention that v1.1 is in it's 16th year, and the latest is v4.something ... :-)
( edit ) side note : I have a Ubuntu 11 host which has aero like features, window transparencies etc ... which I am trying to turn off for testing! My background of 'black' to the star field alas is the contents of the window beneath. All other aspects, fonts included, are fine with the Linux drivers. So the clearing color and blending settings only affect that which is under control of a given OpenGL context, but cannot affect what is subsequently done by the OS to process that client area on it's way to display ..... unfortunately most I've read discusses turning transparency on, not off.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal