I am reading a tutorial about openGL 3.3 (where naturally GLSL 330 is in use). Unfortunately my hardware is limited to openGL 3.0 (where GLSL 130 is the newest format). In GLSL 130 the syntax
layout (location = 1) in vec4 position;
produces an error. Most importantly a code where several instances of "layout" are applied to different variables does not work. I even tried
#extension ARB_explicit_attrib_location : require
which is also not supported. Is there a way to rewrite these statements from 330 in 130 equivalently?
If your implementation does not support ARB_explicit_attrib_location (either as an extension or as version 330 or later), then you cannot use explicit attribute locations. You must specify them before the linking phase with glBindAttribLocation.
And technically, your "hardware" could do this just fine. NVIDIA and ATI support this extension in all hardware that they still support in drivers. This is an API convenience. I'm guessing you're on some from of Intel hardware. If so, you have my sympathy.
BTW, is that my code, by chance?
Related
I'm trying to draw a triangle according to LINK
The problem is that my GPU is AMD Radeon (TM) R5 M330 // Discrete/Hybrid.
It supports Vulkan™ API Version 1.2.170.
Vulkan Sdk version is 1.3.216.0.
I get
'FeatureRestrictionNotMet(FeatureRestrictionError { feature: "dynamic_rendering", restriction: NotSupported })'
due to Vulkan supported API version with GPU
Is there any way to draw the triangle without the need of dynamic_rendering or is it possible to draw that using another way?
I am new to graphics programming and this will be my first experience with Vulkano-rust-AMD stuff.
It appears to me that gl_FragCoord is not sufficiently defined in the ES shading language specification: here
What is missing in my opinion is a specification of where pixel centers are supposed to lie: at integer coordinates or right between them. In contrast the regular Shading Language Specification of gl_FragCoord has this nailed down: here
Worse even I get mixed results on different platforms: An ARM Mali T604 seems to follow the .5 convention whereas an Adreno 330 seems to put the pixel centers at full integers (both tested on Android 4.4.2).
Can someone enlighten me on what's best practice here?
Going through the actual specification document, I found this:
1.1.4 Changes from OpenGL GLSL 3.3:
Removed:
* Layout qualifiers: index, origin_upper_left and pixel_center_integer
I don't know these qualifiers were omitted from OpenGL ES, and I couldn't find a clear mention which convention is the correct one (or if it's left for implementations to decide), although I think the traditional way is at half-integer coordinates. In any case, looks like you'll have to add some code to e.g. round the values down to get consistent behaviour.
By the way, the man pages are not to be trusted - they tend to omit a lot of stuff and contain errors. Specification is always the authority.
#aptitude search fltk|grep dev
p libfltk1.1-dev - Fast Light Toolkit - development files
p libfltk1.3-dev - Fast Light Toolkit - development files
Why to choose one over another?
From version history:
This is basically FLTK-1.1.10 with extra features, but with an incompatible ABI. The new features include: full UTF-8 Unicode support, which allows left-to-right non-Latin text such as Greek and Cyrillic; new Fl_Tree, Fl_Table and Fl_Native_Filechooser widgets; printing support; a device abstraction layer; and a new progamming manual generated from the code using Doxygen.
As you see, you have now:
A new ABI that is incompatible with the old
UTF-8/Unicode
New tree, table, and filechooser widgets
Printing
Device abstraction(new implementation)
Programming manual from Doxygen
The OP also describes memory usage differences:
I also noticed 1.1 used 3 MB and 1.3 46 MB
I have a small problem that disturbs me after compiling with Emscripten an OpenGL / GLUT code.
I can compile with gcc and emcc.
I just have a warning about-nostdinc + + Maios under different codes (this has never been a problem for me)
Code compiled with gcc works fine.
But the generated html page displays only a black square.
The code is generated but nothing appears
Do you have any idea why?
According to https://github.com/kripken/emscripten/wiki/OpenGL-support the support is stable for features that are directly available in WebGL and OpenGL-ES-2. Legacy, fixed function pipeline OpenGL code is not yet fully supported.
I suggest you rewrite your program to follow modern OpenGL principles, i.e. don't use built in matrices, use generic vertex attributes, vertex buffer objects, use shaders (vertex and fragment); within the featureset providede OpenGL-ES-2.
I am writing an OpenGL game which will hopefuflly be for both linux and iphoneOS, I basically want to be able to build using the OpenGL ES 1.5 headers and run it on my linux desktop. Can I do this? IE, I want to only use the subset of API calls common between OpenGL and OpenGL-ES.
Doing the above and linking with normal libGL.a from my system gets me my screen but I seem to be able to do nothing but change the scene background colour.
I've done exactly that, and it worked well for me.
There are a bunch OpenGL|ES extensions that aren't available on standard OpenGL but very nice to have on a low spec platform. glDrawTexImage is such an extension. Emulating these extensions using a hand full of desktop OpenGL-calls is not a big deal though.
Also OpenGL|ES supports the fixed-point data-format for most entrypoints. Take glClearColorx for example. These aren't available for the desktop OpenGL, so you have to write a wrapper if you want to use them. It's a bit more work if you also store your vertex data in this format.
Oh - and note that OpenGL|ES does not come with the glu-library. You can use it on the desktop, but if you do you'll have to reimplement them later (see the 100 questions about gluLookAt and gluUnproject).
There is no such thing as OpenGL ES 1.5. Did you mean 1.1 ?
Also, how do you get a window ? This is platform specific.
In any case, you still should compile against the header that corresponds to the lib you will link against. You don't know for sure what the header sets up (e.g. on windows, which you don't care about but still, calling conventions are specified in there).
There are also some calls that don't map well between the 2. E.g. APIs that are only using doubles in GL are float in GLES (from the ES spec):
The double-precision only commands
DepthRange, Frustum, and Ortho are
replaced with single-precision or
fixed-point variants
So in short, there is a bit more work than just using the same code, although the work in question is still minimal if you stick to GL ES subset.