When I use to draw in c++, the frame comes out fine for 2-3 seconds and then crashes saying:
[xcb] Unknown sequence number while processing queue.
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
I have called the XInitThreads() befor initgraph()
I use Ubuntu 17.10 and g++ 7.2
There seems to be a problem with Ubuntu while using XInitThreads() from what I saw online.
Is there an alternative drawing method? Or can I fix this problem?
A part of my code:
int main()
{
int gd = DETECT, gm;
XInitThreads();
initgraph(&gd, &gm, NULL);
line(100,100,200,200);
delay(10000);
getch();
}
See: xcb.freedesktop.org/tutorial
It seems as if you could use this tutorial. My understanding was that graphics.h was a header for functions included a long time ago, with Borland Turbo-C? If the functionality of that library was directly reproduced, it wouldn't be compatible with xcb or Xlib since it took over the framebuffer entirely.
I found the Basic Windows and Drawing tutorial, which you'll find at the link I provided, to be very helpful. After you create a window and map it to the screen, you can draw in it using the primitives, pixel by pixel if you like.
Related
I making a port of my 3d program to macOS.
I'm using c++ and FreeGlut at windows. So at macOS, I've started to use it with GLUT. I don't use cocoa and create an OpenGL window context via GLUT.
There is a problem with the support of hidpi retina.
Glut reshapefunc is detecting two times the smaller resolution (I mean it detects logical points, not actual retina pixels) That's why the image looks pixelated.
How to turn on retina support in GLUT (or freeglut)?
I've tried the solution from this article http://iihm.imag.fr/blanch/software/glut-macosx/ (add line "hidpi" to glutInitDisplayString
and GLUT_3_2_CORE_PROFILE to glutInitDisplayMode). But it doesn't help.
Is it possible to make it without big changes in the program? Because it's quite a big program (3d software).
Thank you
You should only use one of glutInitDisplayString and glutInitDisplayMode.
glutInitDisplayMode overides glutInitDisplayString if it comes after.
try:
glutInitDisplayString("hidpi core rgba double")
I've got a weird problem that's suddenly appeared across all projects I'm working on. I'm using C++, SDL2 and OpenGL, and one of the first things that happens in my int main is to create an SDL window with an OpenGL flag like below:
int main( int argc, char* args[] )
{
//Minor stuff here e.g. initialising SDL
mainwindow = SDL_CreateWindow("...", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_OPENGL);
}
For some reason this has started to cause a segmentation fault. If I change the flag from SDL_WINDOW_OPENGL to anything else, it does create a window but obviously fails shortly afterwards given the lack of an OpenGL context to do anything with. I've gone as far as to strip out all code except for the SDL and OpenGL initialisation stuff, and it still fails with a segfault error.
This issue has started as of today across two projects that share the same basic int main structure. This leads me to believe it's not a code issue (largely because the code hasn't actually changed), but that something with my setup / environment has gone wrong. So far I've tried the following to no avail:
Redownloaded latest SDL library
Redownloaded latest GLEW library
Reinstalled Codeblocks
Any ideas for a) what might be causing this and b) where I should start looking to fix it?
Thanks
Nathan
And like so many other problems in life, the answer turned out to be drivers. A system-wide update of some kind interfered with the graphics' ability to render any kind of OpenGL. A direct download and install of the latest graphic drivers fixed it.
I'm trying to use gDEBugger to debug my OpenGL application, but the problem is that when I use normal GLFW libraries, gDEBugger runs the program and stops at specified breakpoints, but when I use Qt's QOpenGLWidget, although I'm calling native OpenGL API calls, when I try to step through the program, it seems that gDEBugger runs the program and the program exits, without any stop on breakpoints.
Does anybody know how to use gDEBugger to step through OpenGL code in Qt? Are there other debugger tools available I can use?
Thank you in advance
I've had similar problems using Nvidia Nsight and QOpenGLWidget. In nsight I'd only see the draw calls of QOpenGLWidget and not my own.
The problem for me was that I was setting the default QSurfaceFormat explicitly myself to the desired OpenGL version.
When I commented it out and not longer set that, it worked fine. And I could now see both contexts, mine and the one used by the qopenglwidget.
Not sure why this happens. Probably worth looking into the source to see how the widget renders to texture and then calls your rendering functions.
Let me know if it works for u?
I have, thanks to some help, managed to get the program below to compile and run but although it keeps on chugging away I cannot see anything drawn on the Pi's screen.
I don't think that it is a problem unique to the use of openvg and ajstarks code as, during the problem I had compiling the test progam, I tried a different way of writing images (sorry, all I remember was that it was low level and didn't need the includes for openvg). It took a bit of searching and re-writing to get it to compile and when it did the same thing happened.
I persevered for a while, but got no where. There were some references to some sort of limitation with Raspberry Pi and X Windows leading to the same problem. You draw something but it doesn't display. Given that there were several comments suggesting that openvg worked, I went back to that and (thanks to a guy called Ross) eventually worked out why I couldn't compile the code.
So now I am at a point where I can compile code that others have got to run successfully, but it doesn't draw anything on the screen. I know that the code runs - it chews CPU cycles (well the official demo does, mine less so although it's still definitly going) and the code can be quit with
Another method of working with graphics has come across the same no-output-display problem, so I think the problem is somewhere on my Pi but I have drawn a blank on how to address the X Windows (or it might have been X11, wish I had kept the tabs open!) not wanting to draw issue.
Any help greatly appreciated, thanks in advance!
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
extern "C" {
#include "VG/openvg.h"
#include "VG/vgu.h"
#include "fontinfo.h"
#include "shapes.h"
}
using namespace std;
int main (void) {
int width, height;
VGfloat w2, h2, w;
char s[3];
init(&width, &height); // Graphics initialization
w2 = (VGfloat)(width/2);
h2 = (VGfloat)(height/2);
w = (VGfloat)w;
Start(width, height); // Start the picture
Background(0, 0, 0); // Black background
Fill(44, 77, 232, 1); // Big blue marble
Circle(w2, 0, w); // The "world"
Fill(255, 255, 255, 1); // White text
TextMid(w2, h2, "hello, world", SerifTypeface, width/10); // Greetings
End(); // End the picture
fgets(s, 2, stdin); // Pause until RETURN]
finish(); // Graphics cleanup
exit(0);
}
Ok...
Thanks to a stroke of luck I have found the answer and it's odd. To me anyway...
In case anyone else encouters the problem, here is the (partial) solution which leads to another question to be posted shortly.
I am trying to run a programming club in my school and it's not practical to physically connect the Pi's to kb, mouse and monitor so they all auto-run VNC and we connect to the machines using Ultra-VNC. The programs are written in a shared directory and Eclipse C++ runs on the host; therefore all program output is viewed via VNC.
I had been continuing to try to solve the problem and at one point connected a keyboard and mouse and noticed that they seemed to be recognised (laser came on, Caps Lock toggled, etc.) but they didn't do anything when moved/typed on.
Eventually the penny began to teater on the edge as I got increasingly confused as to why no one else was having this problem. Is seemed odd that no one else had the issue and then I began to wonder more about the kb/mouse issue.
I tried plugging the HDMI output into a monitor at home (shool ones are still analogue d-sub!) and lo and behold, the physical kb and mouse worked. Then it got really strange!
Somehow I have 2 desktops running at the same time. The physical keyboard and mouse control one and VNC controls the other. Interestingly, VNC has the title Pi's X Desktop suggesting that the graphics problem might be something to do with X, but I am not sure for the reason below.
If I start a terminal window on 'Physical' desktop, it doesn't show up on 'VNC' desktop and vice versa - they seem to be independent, although that's not quite true.
When I run the test file on 'Physical' desktop, it works fine and can be controlled only using the physical kb. When I run it on 'VNC' desktop, it can be controlled only with the VNC kb but the output displays on the physical screen.
I really don't get this!
So, this answers the original question as the program does run on the Pi.
Off to post (hopefully a final) question on how to either get VNC to show the 'Physical' desktop or how to target the graphics output to the 'correct' desktop.
I am currently making an OpenCV project in C++ where I look for motion with a kinect and use that to cue a slideshow (sans recognition). Currently, I am displaying the slideshow using OpenCV (as I've only had about a week to whip this up). It looks good and its quick. The only problem is that this is going to be on display for a big production and I can't really afford to have the window showing (I'm talking window decorations like the title bar and such).
I need to get rid of the title bar. I've done a lot of research, and I have found out that you can magically grab the window handle by calling cvGetWindowHandle("SlideShow"), but that is a void function, so I don't really know how I am supposed to get a handle from that to manipulate.
I'm developing this for both windows AND ubuntu, since it will end up on a windows machine, but I can only demo on a laptop running ubuntu.
If anyone can tell me how to take the window and render it fullscreen with a resized image to fill most if not the entire screen in either Windows or Ubuntu, I will be forever grateful.
I am using OpenCV 2.1 on Ubuntu 11.04. On my system CV_WINDOW_FULLSCREEN and CV_WINDOW_AUTOSIZE flags both map to 1
And both flags behave exactly the same. They give you a fixed size window, which would be expected for AUTOSIZE flag but not the FULLSCREEN. I think these two flags are meant for different functions although their simillar appearance is very confusing. The flag CV_WINDOW_NORMAL maps to value 0 which is what you have used. It gives you a resizable window that you could maximize, but it is not a fullscreen window.
Edit: I just found the solution in another stachoverflow post. Here is the solution from that post which worked great on my system:
cvNamedWindow("Name", CV_WINDOW_NORMAL);
cvSetWindowProperty("Name", CV_WND_PROP_FULLSCREEN, CV_WINDOW_FULLSCREEN);
cvShowImage("Name", your_image);
I get a real fullscreen with no title bar etc.
you can use the cv::setWindowProperty function for your purpose, just set it to CV_WINDOW_FULLSCREEN.
Full documentation in the openCV-WIKI
In opencv/4.5.1, this is how it is done:
namedWindow("Name", WINDOW_NORMAL);
setWindowProperty ("Name", WND_PROP_FULLSCREEN, WINDOW_FULLSCREEN);
Assuming you have added using namespace cv;