GLFW basic sample won't run...

Monkey Targets Forums/Desktop/GLFW basic sample won't run...

SLotman

(Posted 2013) [#1]

I tried a simple test,on the computers at my university... couldn't run anything!

First, it just popped up the window, which was closed afterwards. This is a Win7-64 bits machine.

Then I opened mojo.glfw.cpp and changed the openal initialization from

if( alcDevice=alcOpenDevice( 0 ) ){

if( alcDevice=alcOpenDevice( "Generic Hardware" ) ){

Then the window stays opened, but apparently, it can't draw anything!
This is what happens:

Note that the window is never updated,but the console window receive the "Print" messages from the code. Input also works - but nothing gets displayed. If I minimize the window and then restore it, it is completely draw in gray.

From what I could gather, this computer has a Intel Q35 Express (?), running at 1280x1024x32 at 60hz. The sound card is just listed as "High Definition Audio Device".

This happens on every machine(all, same config) that I tested over there, so it's not a problem to a specific machine.

Unfortunately I can't try to install newer drivers on it, I don't have admin access to the machine.

Trying the same code (actually the same build, posted below) on another machine (this one also with Intel graphics, Intel 82945G on Windows XP), everything works.

If you guys want to test the program, here's the compiled version:
http://www.icongames.com.br/temp/debug-test.zip
(when I get home, I'll post the code here, but it's no big deal, just a 800x600 window, which writes text and draws rects on screen)

Have anyone encountered such problems?

SLotman

(Posted 2013) [#2]

Hmmm... what OpenGL API version does GLFW uses? I saw here this cards only supports opengl 1.3, maybe that's the problem?

I read this from GLFW website but I can't make heads or tails of it:(

AdamRedwoods

(Posted 2013) [#3]

according to this
http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units

it should support up to opengl2.0, so you should be able to use GLFW. but yeah, you may need to update those drivers first.

use GPUZ to get the specific details:
http://www.techpowerup.com/gpuz/

SLotman

(Posted 2013) [#4]

I can't install stuff, as I said, it's the university computer, and this GPUZ is an installer.

But I would believe Intel's website - if it says it's OGL 1.3, then it probably is :)

The question is: what version of OpenGL is used by GLFW?

AdamRedwoods

(Posted 2013) [#5]

what version of OpenGL is used by GLFW?

i believe mark mentioned it MUST be OpenGL ES 1.1 compatible, which is about opengl 1.4-1.5.... so yeah.

you may need to look into a DirectX7/9 Mojo port or see if Q35 can handle the XNA version.

SLotman

(Posted 2013) [#6]

Yikes! I entered some debugging into window.c... the driver reports OpenGL 1.0!

No wonder it won't work... :(

Edit: Even worst - the video driver *is* up to date! I ask myself how can dell sell computers with this piece of c### inside, and even worst, how Intel can pass this as a GPU :P

computercoder

(Posted 2013) [#7]

Edit: Even worst - the video driver *is* up to date! I ask myself how can dell sell computers with this piece of c### inside, and even worst, how Intel can pass this as a GPU :P

Thats how computers can be sold for so cheap these days. Most universities don't require high end graphics capabilities. Most of the time you just need to perform email, web searches, document editing (including any of the MS Office suite) and some light flash (or similar) video viewing. There's no need to have the better GPUs when all you need to do is that kind of simple stuff.

SLotman

(Posted 2013) [#8]

Dell here in Brazil is anything but cheap...

If I'd assemble a computer with 'cheap parts' I could make 2 or 3 by the same price they charge for their lower end machines!

(I have to admit their 'top of the line' machines are good - I've bought one Dell Inspiron 15r laptop this year to replace my old, broken, one and it's a really good machine... but it wasn't cheap, by all accounts.)

SLotman

(Posted 2013) [#9]

Just an update - I ran today GLInfo on the computer, and the report it generates seems to indicate the card should be able to run...

**************
* GLINFO LOG *
**************

  DRIVER INFO
---------------
Vendor    : Intel
Renderer  : Intel Bear Lake B
Version   : 1.4.0 - Build 8.14.10.1930


  OPENGL CAPABILITIES
-----------------------
Supported extensions: 
    GL_EXT_blend_minmax
    GL_EXT_blend_subtract
    GL_EXT_blend_color
    GL_EXT_abgr
    GL_EXT_texture3D
    GL_EXT_clip_volume_hint
    GL_EXT_compiled_vertex_array
    GL_EXT_cull_vertex
    GL_SGIS_texture_edge_clamp
    GL_SGIS_generate_mipmap
    GL_EXT_draw_range_elements
    GL_SGIS_texture_lod
    GL_EXT_rescale_normal
    GL_EXT_packed_pixels
    GL_EXT_separate_specular_color
    GL_ARB_multitexture
    GL_EXT_texture_env_combine
    GL_EXT_bgra
    GL_EXT_blend_func_separate
    GL_EXT_secondary_color
    GL_EXT_fog_coord
    GL_EXT_texture_env_add
    GL_ARB_texture_cube_map
    GL_ARB_transpose_matrix
    GL_ARB_texture_env_add
    GL_IBM_texture_mirrored_repeat
    GL_EXT_multi_draw_arrays
    GL_NV_blend_square
    GL_ARB_texture_compression
    GL_3DFX_texture_compression_FXT1
    GL_EXT_texture_filter_anisotropic
    GL_ARB_texture_border_clamp
    GL_ARB_point_parameters
    GL_ARB_texture_env_combine
    GL_ARB_texture_env_dot3
    GL_ARB_texture_env_crossbar
    GL_EXT_texture_compression_s3tc
    GL_ARB_shadow
    GL_ARB_window_pos
    GL_EXT_shadow_funcs
    GL_EXT_stencil_wrap
    GL_ARB_vertex_program
    GL_ARB_fragment_program
    GL_EXT_stencil_two_side
    GL_ARB_vertex_buffer_object
    GL_EXT_texture_lod_bias
    GL_NV_texgen_reflection
    GL_ARB_depth_texture
    GL_WIN_swap_hint

Max. viewport size          : 2048x2048
Max. texture size           : 2048x2048

Max. modelview stack depth  : 32
Max. projection stack depth : 4
Max. texture stack depth    : 10
Max. attribute stack depth  : 16
Max. name stack depth       : 128

Max. display list nesting   : 64
Max. evaluator order        : 32
Max. number of lights       : 16
Max. clipping planes        : 6
Max. pixel map size         : 65536

Point size range            : 0,500 to 10,000
Point size granularity      : 0,125
Line width range            : 0,500 to 7,500
Line width granularity      : 0,500

Number of auxiliary buffers : 0
Bits of sub-pixel precision : 4


  ACCELERATED PIXEL FORMATS
-----------------------------

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

Trying to make some sense out of this, I read somewhere that if the pixel format selected when creating the opengl window was not "hardware accelerated" then the returned opengl version is 1.0, just as I got when I tested it.

I'm going to try on monday to see what pixel format is being selected, and if it matches one of those listed above - if not, then there's the culprit; if it matches, than I have no idea how to fix this :(