I'm unable to use GLTools stock shaders in an OpenGL context that was not created by glut.
I'm learning OpenGL from the Superbible 5th edition. The provided GLShaderManager and gltMakeCube (from GLTools) allow me to render some cubes (GLBatch::Draw()) in a window created by glut, using the following code from the Superbible:
gltSetWorkingDirectory(values[0]);
glutInit(&count, values);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutInitWindowSize(1200, 400);
glutCreateWindow("Test");
I'm trying to remove the glut code from this program, following the example here http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_Programming_Animations_with_GLX_and_Xlib to create a window and attach a context to it. (I'm running Ubuntu)
I've managed to create a window and a context, and to call glClearColor successfully to change the window's background color. However, my cubes are no longer being drawn. The example program linked above works properly, but it doesn't seem to use a shader, instead relying on calls to glColor3f and glVertex3f to build a cube.
Why doesn't my technique of rendering with GLTools' stock shaders work in a window/context that's not created by glut?
Related
I'm currently upgrading three.js from a 2015 version, to the latest! However it seems that the GLSL shaders work in a slightly different manner. As a result, when trying to add an extension with #extension GL_OES_standard_derivatives : enable it seems to error and prevent the shader from being used. See below for the stack trace and the code pen for an example of the shader i'm using.
THREE.WebGLShader: gl.getShaderInfoLog() fragment
ERROR: 0:89: '
' : extension directive must occur before any non-preprocessor tokens in ESSL31: #version 300 es
https://codepen.io/redrubia/pen/ZEezjVw
It's not necessary to manually add #extension GL_OES_standard_derivatives : enable to your shader code. Instead, extensions can be managed over the material object. Please use this approach:
material.extensions.derivatives = true;
I am using Python 3 and GTK 3, running Debian Buster. I need to find the mouse pointer location on the screen globally, not just within the application's own windows.
I used to use gtk.gdk.get_default_root_window().get_pointer() and it works, but this was marked as deprecated in an error message. I searched all over the place and found references in GTK 3 documentation to "devices" but got lost pretty fast. Experimenting, I was not able to find out how to do this. I might have succeeded if I had understood how to get a "device," - not a specific device, but just the "device" representing the mouse pointer as it appears on the screen. I do not care what device is putting the pointer there. For now, I did what I needed to do using XWindows calls, but this seems too specific to the OS and I would like to stick with GTK for this.
Absolutely obvious:
GdkDisplay * gdk_display_get_default (void);
// then pass it to
GdkSeat * gdk_display_get_default_seat (GdkDisplay *display);
// then pass it to
GdkDevice * gdk_seat_get_pointer (GdkSeat *seat);
// and finally, pass it to
void gdk_device_get_position (GdkDevice *device, ... );
Honestly, IDK what I'm doing and GDK documentation doesn't have a single place to describe all those Screens, Displays, Monitors etc, but try this.
On OSX (with 2560 x 1600 native resolution), Gloss displays everything at zoom-factor 2x.
Giving a window size of 300 x 300 to the display function creates a window of 600 x 600. All content in that window is also twice as big (in each dimension), regardless of whether drawn with Gloss or loaded as a sprite (I'm using Juicy for that). Scaling the content down does not give the same clean result as when displayed in the actual native resolution.
Is there a way to make Gloss render in full native resolution?
I'm still new to Gloss and hope I haven't missed anything obvious.
Here is the code...
module Main where
import Graphics.Gloss
import Graphics.Gloss.Juicy
import Codec.Picture
main :: IO ()
main = loadJuicy "someimg.png" >>= maybe ( print "Nope" ) displayImg
displayImg :: Picture -> IO ()
displayImg p = display ( InWindow "Image" ( 300, 300 ) ( 100, 100 ) ) white ( pictures [ p, translate 32 32 $ circleSolid 4 ] )
... and the corresponding render:
Update:
This seems to be a general issue with OpenGL and retina displays (actually the way OSX pixels are calculated internally). Since, as I understand, Gloss doesn't really allow low-level access my guess is that this is not fixable.
Update 2:
This seems to be a particular issue with GLUT as the underlying backend for Gloss. Rebuilding Gloss enabling GLFW and disabling GLUT should fix the issue.
Gloss can be used with native resolution under OSX with hdpi-display when the default window management backend GLUT is exchanged for GLFW. To do this rebuild Gloss with the appropriate flags:
cabal install -f -GLUT -f GLFW
(Note: With GLFW I could not use some modules in Gloss anymore, e.g. Gloss.Data.Picture or maybe more importantly Graphics.Gloss.Juicy. Using only Graphics.Gloss.Rendering works though. Related to the resolution: make sure to draw your pictures in the size of the framebuffer, not the window size as those may differ.)
this is somenthing I was trying to solve for HOURS, but I don't get why this is not working.
First of all, I'm trying to do a release for neko or windows in Flash Develop. My project is a OpenFl one, and the language is Haxe 3.
What I have installed:
actuate: [1.8.6]
flixel-addons: [2.3.0]
flixel: [4.2.1]
hxcpp: [3.4.64]
lime: [2.9.1]
nape: [2.0.20]
openfl: [3.6.1]
And yes; I'm using haxeFlixel.
When I try to do a release in windows or neko, these errors appear:
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : Module openfl.display.Shader does not define type Shader
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : For function argument 'ax'
-src/skill/SkillLogicProjectil.hx:13: lines 13-54 : Defined in this class
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/shaders2/Shader.hx:11: characters 7-28 : Module openfl.display.Shader does not define type Shader
The most funny thing is: I'm not even using Shader in SkillLogicProjectil. That class only creates a sprite that follows a Player and has a var with the sprite that represents the skill.
If I comment this class, the error is in another class, and finally ends in my GameState.
This error doesn't appear when I do a release in html5. In html5 there are no problems with the release, but I can´t make the game load without Flash Develop running the process in http://localhost:2000/. I need to make a release that can be opened with a computer, without using Flash Develop to open it.
What can I do?.
The new version of Flixel supports Haxe 3.4.3 and OpenFL 8, have you given these versions a try?
I'm trying to get the PCL Visualizer demo examples to work (all code here: http://pointclouds.org/documentation/tutorials/pcl_visualizer.php) for Windows, PCL 1.6, 32 bits version.
It works fine except for the Interaction Customization part, which is ironically the one i'm most interested on. An unhandled exception occurs at the spinOnce(100) line on the main method. From the long search I've done, it looks like it is deeply connected to VTK not being thread safe and keyboard/mouse callbacks interfering with the VTK window. However, I don't think I've completely understood this and could be mistaken. I have found a very similar question here in stackoverflow (using "pcl::visualization" in different threads from different instance of a class) and I tried using scoped_locks around the spinonce, as he suggests, but I think I'm not doing it right.
Has anyone managed to fully use this example on win32? For reference, here is my poor attempt at locking the spinonce:
while (!viewer->wasStopped ())
{
boost::mutex vis_mutex; //storage for static lock
boost::mutex::scoped_lock lock(vis_mutex);
viewer->spinOnce ();
boost::this_thread::sleep (boost::posix_time::microseconds (100000));
}
Thanks in advance!
I am afraid that it may be related to the version of PCL.
Tutorials are made to match latest versions of PCL and since 1.6 things might have changed.
I recommend you to update to the latest PCL from github. (actually I use code from this tutorial on win64 right out of the box, no issues)