在GLFW应用程序中,std :: cin表现得很奇怪

时间:2017-05-16 16:25:44

标签: python c++ opengl glfw

我正在滥用OpenGL,让它以各种角度呈现对象的单个屏幕截图。我不需要GUI来交互;我只需要能够从控制台启动它并通过stdin输入态度信息。我需要它以这种方式工作,因为它将从Python应用程序通过popen调用。

不幸的是,当我使用std::cin来完成此操作时,给它\n字符似乎并不会导致它注册输入。相反,我必须按Ctrl + D关注\n,这样我就可以继续按预期提供额外的输入。

请注意,如果我在第一个输入(qw)上执行Ctrl + D,它会按照您的预期退出(由于cin.eof()即将出现true)。

这种行为是可以接受的,除了it appears Python won't allow me to send a Ctrl+D to the OpenGL app without closing the stream entirely(不是我想要的)。我也尝试发送curses.ascii.EOT(传输结束字符,0x04)代替(per this forum question),但这似乎也不起作用。

以下是相关代码:

  glfwSwapBuffers(window);

  std::cerr << "Waiting for input ? " << std::flush;

  // priming read
  std::cin >> qw;

  /*
   * Main event loop
   */
  while (!std::cin.eof()) {

    //glfwPollEvents(); // Seems to make no difference

    std::cin >> qx;  
    std::cin >> qy;
    std::cin >> qz;

    object = glm::normalize(glm::dquat(qw, qx, qy, qz));
    std::cerr << "Quaternion: " << object.w << ',' << object.x << ',' << object.y << ',' << object.z << std::endl;

    scene.render(&shader_program, object, translation, sensor);
    pixels = scene.projected_area(width, height);
    projected_area = pixels * box_width * box_width / (double)(width * height);
    std::cout << std::setprecision(17) << projected_area << std::endl;

    glfwSwapBuffers(window);

    // next priming read
    std::cin >> qw;
  }

  glfwTerminate();

似乎这个特定用例不在人们通常使用OpenGL的范围内。任何人都可以解释发生了什么/告诉我如何让它像我没有使用GLFW那样表现吗?

更新:我想知道是否会发生这种情况,因为glfw opens multiple threads。甚至在我调用任何 glfw方法之前,我会看到我的进程有五个线程:

$ ls -l /proc/16051/task
total 0
dr-xr-xr-x 7 mohawkjohn mohawkjohn 0 May 16 19:18 16051
dr-xr-xr-x 7 mohawkjohn mohawkjohn 0 May 16 19:18 16052
dr-xr-xr-x 7 mohawkjohn mohawkjohn 0 May 16 19:18 16053
dr-xr-xr-x 7 mohawkjohn mohawkjohn 0 May 16 19:18 16054
dr-xr-xr-x 7 mohawkjohn mohawkjohn 0 May 16 19:18 16055

更新2:我已经确认当我打开文件并从ifstream而不是从标准中读取时,会发生正常行为。我也注意到当我按下Enter键时在OpenGL应用程序的控制台中,我得到的反馈是^M而不是换行,即使我在Linux中。

1 个答案:

答案 0 :(得分:0)

GLFW issue tracker上的那些人已经为这种行为提供了解释 - 看起来 - 实际上并不是由GLFW引起的。

不知何故,我的stty设置被搞砸了(我还不清楚这是怎么发生的)。决议是运行

stty sane

在运行我的应用程序之前。请注意,可以使用

检查stty的当前设置
stty -a

在这种情况下,问题似乎是icrnl设置已关闭;它通常会将键盘上的回车转换为换行符。