I have written before about the issues with the texture failing to reload when I update the terrainscene node many times before rendering. Another bug I have encountered is probably closely related with this issue. While loading the texture, my custom window gets automaticly repositioned a bit and then repositioned again to its original position. As a result the textures might fail and what more, the top 30 pixels of the viewport gets clipped. So the window's top rows will never get refreshed again, never. What makes this exotic disease worse : the window refresh problem never happens in debug nor in release mode. Guess what, it happens only when I run it from the exe file.
Since the opengl dll-s are the same, I have no idea how to fix it. I tried to message-box the viewport settings, they are correct, no access violations, nothing to go on with.
Has anybody heard of such an issue?
Texture load problem and window update problem.
The code is too long, besides there should be nothing wrong?! The problem is also not with the texturing, what my first guess was. The problem appears only when the window GETS a WM_SIZE message. (Somehow even setting the window to not resizeable it might get a WM_SIZE message when working with long data and no window rendering happens for seconds.)
Despite setting the viewports top left corner to 0,0 after resizing the window, it gets clipped.
I also tried to render in a fixed button style childwindow. In that case no clipping appears, but the fixed childwindow gets shifted down by ~10-30 pixels . So it looks like the window's absolute coordinatesystem gets shifted.
The actual 0,0 coordinates are not the real 0,0 coordinates of the window, if OpenGl renders to (0,0) ; (1,0) ; ... (screenwidth,0), etc they might get negative coordinates in the aspect of the window's origin, so they are clipped.
Shall I send a picture to show it?
Despite setting the viewports top left corner to 0,0 after resizing the window, it gets clipped.
I also tried to render in a fixed button style childwindow. In that case no clipping appears, but the fixed childwindow gets shifted down by ~10-30 pixels . So it looks like the window's absolute coordinatesystem gets shifted.
The actual 0,0 coordinates are not the real 0,0 coordinates of the window, if OpenGl renders to (0,0) ; (1,0) ; ... (screenwidth,0), etc they might get negative coordinates in the aspect of the window's origin, so they are clipped.
Shall I send a picture to show it?
Tomi
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
This looks like it's related to the client_size bug that had been in SVN for a few days recently. Maybe update your lib code and see if it's still there. Or it's vice versa a problem which needs the correct client_size/window_size to be set and which needs to be fixed still. Again: Do you use SVN, or the stable 1.7.1 code?
No, I have downloaded the 1.71 version a few month ago. I tried the win32 example for irrlicht, but with rendering into the main HWND. That was running ok. I have also a mouse stuck problem. If I resize the window the mouse stays pressed down...
Interestingly initialising the window as "BUTTON"
solves the resize problem, but then I have no message handler. Maybe its the windows fault, maybe its an issue with the message handler, maybe its opengl that messes up the whole thing...
Interestingly initialising the window as "BUTTON"
solves the resize problem, but then I have no message handler. Maybe its the windows fault, maybe its an issue with the message handler, maybe its opengl that messes up the whole thing...
Tomi