[**SOLVED**]How to redraw viewport during Window move?

[irrlicht_ist_toll]

Hello everyone, I'm new to the forum, let me start by thanking the Irrlicht team for such a great engine,
I've been experimenting for a few days and it's just fantastic!!!!

I'm using the engine with a Win32 window I've created. The first question I have is how to redraw the irrlicht viewport while dragging the Window,
since I've noticed such things kind of stop the thread, likewise for when you throw a message box pop up for example.
The worst part is that if you move the window past the edge of the screen and come back the viewport gets dirty and it looks real bad.

I tried calling my render routine from within wndproc in a couple of spots, but the program crashes

Code: Select all

    case WM_WINDOWPOSCHANGING:
        //irrlicht_update();
        break;
 
    case WM_PAINT:
        hdc = BeginPaint(hWnd, &ps);
        // TODO: Add any drawing code here...
        irrlicht_update();
        EndPaint(hWnd, &ps);                 
        break;

Have any of you found a way around this? sorry if it's too much of a newbie question

Thanks!

[CuteAlien]

The idea in 3D rendering is that you render constantly. So it's not like in Windows application thats part of the screen becomes invalid and then that rectangle is updated. Instead you render the whole scene maybe 60 times per second.

[irrlicht_ist_toll]

Thanks CuteAlien, you're right, I already have a main loop and rendering going on, that's running fine.
The problem lies with certain Windows things, like moving the window with your mouse, as it holds the thread somehow and you don't come back to the main loop (to render) until you let go the window on its new position. So your animation is frozen during this.

Somehow there should be a way to still render while Windows handles these events, as I've seen other programs do it.

Thanks again

[CuteAlien]

Ah - this is complicated. The problem is that Windows enters a modal loop in this situation. There have been 2 discussions about that before, but no real solution yet:
http://irrlicht.sourceforge.net/forum/v ... =1&t=45402
http://irrlicht.sourceforge.net/forum/v ... =2&t=38729

[chronologicaldot]

Notably, some gamer might expect the game pauses if he has to relocate or resize the window for whatever reason. Seen it. Not that irrlicht does it on purpose. If the problem were "fixed", it'd still be nice to have solutions for pausing rendering and animation.

[irrlicht_ist_toll]

Thanks guys, oh well that's a bummer
It's not so much the freezing of the animation that concerns me, but the thing with getting garbage on the viewport if you drag the window outside the screen and come back, it looks really unprofessional

How do other guys do it? there's plenty of applications you see they're using either OpenGL or DX and they don't have the issue, for example Blender, etc. I'ts interesting...

How about this (well, apart form multithreading): saving a snapshot of the last frame when the user clicks down, and then using windows GDI to paint that last frame on the panel on wndproc? It'd still be frozen but you wouldn't get garbage.

My other question, hopefully is not too stupid, but why does the application crash if you try to irrlicht-render from within wndproc? isn't that "context" at that point "yours"??

[hendu]

That would require readback from the GPU, which is really slow, every frame. I doubt you can detect when a drag-by-titlebar starts in time to take the shot.

[irrlicht_ist_toll]

Oh, Ok, thanks everyone, I'm still delighted to work with Irrlicht, what a great engine.
I'll post if I work out a solution.

[irrlicht_ist_toll]

I've got it guys!!!!

Thanks to this guy:
http://www.gamedev.net/topic/555313-how ... i-move-it/

It's rather simple, just render under WM_MOVE in wndproc

Code: Select all

    
case WM_MOVE:
application.update();
application.draw_graphics();
DefWindowProc(hWnd, message, wParam, lParam);
break;
 

With this above, not only does the viewport redraw but the application also updates!!

Note that for the application update you still need to figure out the timelapse, since at that point it's not determined on the main loop but by the windows redraw time.
But you can probably do that easily with a separate timer, or perhaps just assuming a reasonable average lapse.

The only thing left is for when a child Window hovers over the viewport, but I think that's just a matter of finding the proper child-window-move-event case name.