I have drawn a picture with openGL on my windows. Now whenever I hold the mouse button on the windows and move it, my picture always got distorted. I don't know what function in openGL that can help me redraw the picture while the windows is moved. Anybody could help?
I tried this but seems not work:
void myDisplay()
{
.....
}
void reshape(int x, int y)
{
glutPostRedisplay();
}
int main()
{
.....
glutDisplayFunc(myDisplay);
glutReshapeFunc(reshape);
}
The first (and usually only) necessary step is to to quit using glut. glut is oriented primarily toward producing a static display, so it attempts to accumulate changes and then redraw only when the state has "stabilized" again, such as when you're done resizing the window. That made sense at one time, but mostly doesn't anymore.
Given that it's been around 10 years since glut was last updated, out of date design goals are hardly a surprise. That doesn't change the fact that it's carefully written to prevent what you want from happening. If you wanted to, you could probably rewrite it to fit your expectations better, but it'll almost certainly be quite a bit simpler to use something else that's designed to do what you want (or at least something closer to what you want).
Add glutIdleFunc function
int main()
{
.....
glutDisplayFunc(myDisplay);
glutIdleFunc(myDisplay);
glutReshapeFunc(reshape);
}
Solution that worked for me was to skip the execution of InvalidateRect/RedrawWindow functions after calling MoveWindow on WM_MOUSEMOVE (I'm not using glut). Because usually it makes sense to execute InvalidateRect(wnd,0,0) after all mouse/keyboard events, but apprently calling it after MoveWindow causes the window contents to "stay behind" dragging.
Related
I'm asking this question ahead of time, since I haven't gotten around to attempting an actual, real implementation yet. Win32 (C++) is turning out to be a colossal pain to program. But, my question is this:
I want to make my application's window become fully transparent with a dotted perimeter when resizing the window. How would I accomplish this? Think of what happens in Windows 3/3.1 (I believe it was this version) when resizing a window. Everything goes transparent, with a dotted-outline where the mouse is moving, then it repaints the entire contents. That's what I'm trying to achieve.
A while ago, I tried handling the WM_(ENTER/EXIT)SIZEMOVE messages and make use of SetWindowLong() to set the WS_EX_TRANSPARENT extended style, but my window became (indefinitely) pass-through, and when the window's focus was killed, it could never again regain focus.
Do I need to handle other messages like WM_NCLBUTTON(DOWN/UP)? I have a boolean flag to tell me when to halt drawing during resizing, and the logic for determining when I'm resizing works perfectly, but I cannot get the visuals to work. I'm not sure which parts of the Win32 API to actually use. I've done some research, and uxtheme.lib/.h seems promising, but I'm not sure how that would work with WM_NCPAINT, which I have been using with (some) luck.
EDIT
I need to clarify something, in case anyone was confused or unsure of what I meant. What I meant by the Windows 3.1/3 resizing scenario is that once WM_ENTERSIZEMOVE has occurred, the window (controls, caption, frame) should be made entirely invisible, and the window's nonclient-region's perimeter should display a dotted-outline of sorts. Then, only until the resize has been finished, when WM_EXITSIZEMOVE has occurred should the entire window (controls, caption, frame) be fully redrawn, updated, and returned to its normal, functional state. Sorry for any miscommunication!
I found the answer... After so long, finally found it. Here's where I found it! http://www.catch22.net/tuts/win32/docking-toolbars-part-2# - Hope it helps anyone else possibly in my shoes!
And it turns out that the solution was rather simple. In fact, the core concept of what is explained is near-completely what I was thinking, yet I just had no idea how to implement it. The solution involves overriding the default WM_NCLBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP (specifically when initiating a window movement) messages, and drawing a patterned rectangle which follows the position of the cursor. Then, afterwards, calling SetWindowPos or some other similar function to relocate the window.
Basically, block Windows from attempting to display anything graphics related until the resizing has been finished. Then, and only then, make Windows move the entire window in one huge, foul swoop.
Based on Remy's comment, there is a global option and corresponding registry setting for this, so perhaps try setting the registry setting when the move starts and restoring it when the move finishes.
Unfortunately this doesn't work as Windows appears only to pick up the setting on restart, broadcasting WM_SETTINGCHANGE also doesn't trigger it, which is a pity as doing something yourself that the OS already has an implementation of do is rather a poor state of affairs.
i'm continue my dialog with openGL and c++ and for a now i want to make "scenes", that will change each other. for example screen with button "go next", i push button and then begin game.
What is the best approach with openGL in c++ for this ? The main question is what make with glut initialization commands like :
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE|GLUT_RGB);
glutInitWindowSize(screenWidth, screenHeight);
glutInitWindowPosition(0,0);
glutCreateWindow("Puzzle quest!");
// Registration
glutDisplayFunc(Draw);
glutIdleFunc(Draw);
Is i need to implement this method in both classes, or only in one, and then only "show start button/ hide game functionality, hide start button/ show game functionality+start timer" ?
I do not mess with screen settings during scene/mode changes. Screen setings is changed on resize of the OpenGL window not on some button event...
You have to write your visualization and UI logic stuff dependent on some variables for example:
enum _game_screens_enum
{
_game_screen_main_menu=0,
_game_screen_game,
_game_screen_game_over,
_game_screen_help,
_game_screen_intro,
_game_screen_redefine_keys,
_game_screen_high_score,
_game_screen_exit,
};
int screen=_game_screen_main_menu;
Now in draw,update and UI handling functions just add appropriate ifs for example:
void draw()
{
if (screen==_game_screen_main_menu)
{
// draw main menu ...
}
else if (screen==_game_screen_game)
{
// draw in game screen stuff...
}
else ...
}
And that is it ...
Are you looking for a fade effect or some sort of transition where they are blended? Fade effect should be easy if using alpha channel... enable blend... draw black quad in front of everything as its alpha value increases from 0 to 1 over whatever time frame you want the fade to occur. The fade in would be the opposite. Not sure about the blending scenes effect... maybe accum buffer, or read pixels and then draw pixels if you can change alpha values.
Otherwise, glutDisplayFunc is the correct way to switch between scenes/drawing functions.
Try just fading effect, it could be of great help.
You should only initialize glut once.
Normally, the display and idle callbacks would do different things depending on what state you're in.
On a high level:
void idle()
{
if (showingMenu)
menu.idle();
else
currentScene.idle();
}
You could do it by switching functions, but I think that makes debugging more difficult.
(You should probably not use the same function for drawing and idling, though.)
I'm hoping someone can help me out, I'm using SFML 2.1 and when I draw my renderWindow it just keeps flickering, now I know SFML uses two buffers so i'm sure one is not getting drawn at all but I can't understand why.
Here is my loop
while(!quit)
{
rs.Canvas.pollEvent(gameEvent);
colour += 1;
rs.Update(colour);
if(gameEvent.type == sf::Event::Closed)
quit = true;
rs.Canvas.clear( sf::Color(colour,0,0) );
rs.Canvas.draw( sprite );
rs.Canvas.display();
if(colour >= 300)
quit = true;
}
the rs.Canvas has these set
Canvas.setVerticalSyncEnabled(true);
Canvas.setFramerateLimit(60);
Can anyone see why my renderWindow would flicker?
From the SFML 2.0 tutorial, under the section Controlling the framerate:
Never use both setVerticalSyncEnabled and setFramerateLimit at the same time! They would badly mix and make things worse.
http://www.sfml-dev.org/tutorials/2.0/window-window.php#controlling-the-framerate
In the comments of your post, you state that you were calling clear twice on the window. This would effectively treat your window as if it were single buffered. I understand that the effect of this could create some screen tearing, but on my end I am not getting a glaring flicker effect. Make sure to remove your a call to either setting the framerate or to using the vertical sync, just to be sure.
Basically I was calling
rs.Canvas.clear
twice. I removed the second call and everything then worked fine
So I've created this program to render to a window using DirectX. It has an init() method which requires a HWND object so that it can initialize DirectX to the window, and then a render() method which is called inside of an infinite-loop, and then finally a cleanup() method to release DirectX-objects and devices. However, DirectX will render a couple of frames of a rotating cube (maybe enough for a half-rotation), and then the screen will go black. Then the cube will come back on, but it is still rotating during the black period. This continues in an on...off...on...off sort of pattern. Is DirectX maybe not rendering correctly to the window? What's wrong?
From my experience I think there is a good chance you need to explicitly implement the handling of the background erase event for your window (see this page), otherwise, the default implementation will kick in and get in your way (sometime erasing what DirectX just rendered as others suggested).
But well, as everybody mentioned already: this is only a little theory, and we would need some code to check this further :-).
I have a main window which has both a glut UI in the top 10% of the screen, and the openGL world in the bottom 90% of the screen. Every time my cursor starts hovering over the GLUT portion, openGL rendering will freeze. It resumes only when the cursor exits the GLUT area.
This is because as long as the cursor is hovering over the GLUT area, presumably glutIdleFunc is never called because glut is not "idle", so openGL stuff is not rendered.
I already tried making a new unrelated thread that just calls the display code and/or glutPostRedisplay but I got a framerate of whopping 20 fps as opposed to the 100+ fps the normal way. I don't know exactly why. (In this test I also disabled glutIdleFunc so there is no idle func, just the separate thread calling the display)
Ways to get around this (other than "stop using glut" which I might do in the future but for now I would like a temporary solution)?
I know this is an old question, but I was having a similar issue and wanted to share how I solved it.
Basically, in your idle function, you should manually set the window to your normal window ID. Thanks to Joel Davis' HexPlanet code ( https://github.com/joeld42/hexplanet/ ) for demonstrating this:
void glut_Idle( void )
{
// According to the GLUT specification, the current window is
// undefined during an idle callback. So we need to explicitly change
// it if necessary
if ( glutGetWindow() != g_glutMainWin )
{
glutSetWindow(g_glutMainWin);
}
...
}
Create a callback for passive motion func:
void passiveMouseFunc(int,int){
glutPostRedisplay();
}
And register it using:
glutPassiveMotionFunc(passiveMouseFunc);