windows application programming / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

windows application programming

previous 1 2

Move Thread

LAN_403

Linas

Mon Mar 11 2013, 11:44AM

Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721

Daedronus wrote ...

// here, enjoy

Wow, that was fast, and it works the way i want, many many many thanks

Steve Conner

Mon Mar 11 2013, 01:27PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

That's the most ghetto piece of Win32 programming I've ever seen.

You inserted the paint code right into the main message loop, so it gets called when the application receives any message at all. That includes WM_TIMER messages, so it gets called every time the timer fires and actually works fine for Linas' purposes.

I prefer to put my paint code in the WM_PAINT handler, and trigger it by calling InvalidateRect() from the timer handler.

Daedronus

Mon Mar 11 2013, 01:54PM

Registered Member #2329 Joined: Tue Sept 01 2009, 08:25AM
Location:
Posts: 370

First, It's the standard message loop any windows game or application that displays animations uses.

Second, you are misreading it, there is no timer, and it doesn't get fired any time a message is received, instead, it paints the window any time there is no windows message to process.

This is also the DirectX skd / NVidia recommended message loop.

WM_TIMER is the ghetto way to make real time applications.

Steve Conner

Mon Mar 11 2013, 02:01PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

OK, I misread the main message loop, the paint code only gets called once PeekMessage() has emptied the message queue.

However, I get 50fps all day long with the WM_TIMER method. I think Windows itself is the ghetto way to make real-time applications.

Let me get something straight: You're updating the screen by copying the new data to it with BitBlt, right? Whenever I did this in Win32, the new stuff wouldn't appear unless I had previously marked the area as dirty with InvalidateRect. This is why Linas' attempt didn't work. So how come the NVidia/DirectX way works?

Edit: I guess there are two issues:
1) If the paint code is in WM_PAINT, it won't even get called unless someone calls InvalidateRect, or the window gets resized etc.
2) If you put the paint code outside of WM_PAINT, so it can get called without a corresponding InvalidateRect, does the output ever get displayed? I thought that if a region wasn't marked as dirty, GDI simply wouldn't bother to redraw it.

Daedronus

Mon Mar 11 2013, 02:15PM

Registered Member #2329 Joined: Tue Sept 01 2009, 08:25AM
Location:
Posts: 370

If you can draw at 60fps but the timer is set for 50fps, you waste cycles doing nothing but if you set the timer for 60fps but get to a point where you can only sustain 30fps, you swamp the message queue with timer message.

I had a application that misbehaved horribly, tabs refused to dock, etc.., because it happened sometimes to get swamped with timer messages, cursed the original programmers, removed all timers and moved to update/draw functions called from the main loop like here, and everything was fine.

This is why I claim WM_TIMER was the ghetto method, it works....most of the time.

If you think windows is ghetto, wait until you are forced to code something for iPhone. Obscure development IDE, 1 million obscure options...that happen to matter and break stuff, slow as hell compile time.

Steve Conner

Mon Mar 11 2013, 02:24PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Daedronus wrote ...

If you think windows is ghetto, wait until you are forced to code something for iPhone. Obscure development IDE, 1 million obscure options...that happen to matter and break stuff, slow as hell compile time.

I've been developing for WinCE 6 for the past 5 years, it's like Win32 stuck in a 10 year time warp. Might still be better than IPhone though.

What are your thoughts on my issue 2 above? Do other GDI commands like SetPixel and Polyline work when they're dropped right in the message loop? I never played that much with executing them outside of BeginPaint/EndPaint.

Also, if I want some memDCs to use as buffers, I like to create them once at the beginning of the program, reuse them over and over, and destroy them before quitting. Not sure what the overhead is of creating a new one for every frame. I guess if your window size is changing, you have to create new ones.

Daedronus

Mon Mar 11 2013, 03:01PM

Registered Member #2329 Joined: Tue Sept 01 2009, 08:25AM
Location:
Posts: 370

There is nothing special about the WM_PAINT, with one exception, BeginPaint, it only works inside WM_PAINT. All other GDI commands will work outside.
This is why Linas code didn't work outside WM_PAINT, instead use
HDC hdc = GetWindowDC(hwnd);
outside WM_PAINT;

Ideally WM_PAINT should validate without painting anything, and the client background color set to transparent, so the only painting is done from the message loop/the application paint function. Without this you will get some artifacts when the window is resided and the background is repainted, overdrawing what you paint.
Same for WM_ERASEBKGND.

The invalidated region is ignored by all GDI commands, unless you specifically write code to take it into account or using BeginPaint. BeginPaint WILL return a DC that uses the invalidated region for clipping.

DC's indeed should be created at application start, bitmaps, when resided. For one or two the overhead shouldn't be too big.

Steve Conner

Mon Mar 11 2013, 03:49PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

OK, I got it

Hopefully this discussion might be of interest to Linas too.

Linas

Mon Mar 11 2013, 04:13PM

Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721

Steve Conner wrote ...

OK, I got it

Hopefully this discussion might be of interest to Linas too.

yea it is, it show that i know not that much, and have to start working

anyway, just with few hours of work, multithreaded version is ready. only problem i only can get around 80% of processor time because i use only single buffer for all threads and i have to mute them if some one know iteration number for Z point
]posix.zip[/file]

previous 1 2

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob