Texture load problem and window update problem.

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
bonsalty
Posts: 120
Joined: Thu Dec 10, 2009 1:30 pm
Location: Budapest,Hungary

Texture load problem and window update problem.

Post by bonsalty »

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?
Tomi
bonsalty
Posts: 120
Joined: Thu Dec 10, 2009 1:30 pm
Location: Budapest,Hungary

Post by bonsalty »

I tried a few things like rendering in a childwindow as shown in the irrlicht tutorial. It looks like resizing the win32 window is the main problem. It causes to shift everything down by few pixels...
Tomi
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

We need much more info about this, probably some code, screenshots, etc. Moreover, if you're using SVN versions of Irrlicht, make sure that you update often enough.
bonsalty
Posts: 120
Joined: Thu Dec 10, 2009 1:30 pm
Location: Budapest,Hungary

Post by bonsalty »

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?
Tomi
bonsalty
Posts: 120
Joined: Thu Dec 10, 2009 1:30 pm
Location: Budapest,Hungary

Post by bonsalty »

This is what you can see after resizing the window ...
Image
Tomi
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

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?
bonsalty
Posts: 120
Joined: Thu Dec 10, 2009 1:30 pm
Location: Budapest,Hungary

Post by bonsalty »

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...
:(
Tomi
Post Reply