Chengband Win32 interface slow under Win7

[Therem Harth]

Much, much slower than the Vanilla SDL interface anyway. It lags visibly when I force it to center the screen on the character... Are there any tricks for speeding it up on Windows 7?

[chris]

Originally Posted by Therem Harth

Much, much slower than the Vanilla SDL interface anyway. It lags visibly when I force it to center the screen on the character... Are there any tricks for speeding it up on Windows 7?

How about Vanilla using the main-win code?

At first glance the WM_PAINT handling seems very poorly designed as each tile character calls back to either term_pict_win or term_text_win. Each of these routines is designed to be self sufficient and runs a lot of code to set up and restore the DC over and over again. However, profiling on my machine shows that paints are being processed in debug mode in anywhere from 30ms to 70ms, so I'm not sure this is too bad after all (for drawing 3000 or so tiles).

For me, the main issue is the lack of double buffering. I can't use the center on screen option as all the flickering makes me sick (literally). I personally don't have a problem with the speed though the slowdown is noticeable.

I've been meaning to fix the double buffering issue for some time, but don't like wandering inside main-win.c

[Therem Harth]

Ah, alright... For now I've just turned off centering (and turned on highlighting so that I can always see where my @ is). Been breathed on from offscreen a few times, but nothing lethal so far.

[chris]

I'm working on a fix ... I confess to never looking at terminal code before.

I've learned so far that main-win draws directly to the window resulting in a very choppy update when centering the player. A better approach would be for the term_pict and term_text routines to draw to a memory buffer and then for TERM_XTRA_FRESH to blit the buffer to the window. This buffer could be stored in the extra terminal data.


Also, I've learned most drawing is done outside of the normal WM_PAINT processing and results in garbage if you drag another window on top of Chengband while playing. I can live with this since we have the Ctl+R redraw command.

EDIT: Actually, the problem here was in WM_PAINT processing which did a BeginPaint() EndPaint() and then an (erroneous) call to ValidateRect(). If WM_PAINT messages had queued up in the interim, this ValidateRect() call would cause them to be skipped.

Its a big job so no promises ...

[Therem Harth]

'Tis alright. I wasn't looking to open up a can of worms, actually.

[chris]

Originally Posted by Therem Harth

'Tis alright. I wasn't looking to open up a can of worms, actually.

No big deal ... I meant to go in there at some point anyway.

I really can't tell if my changes have made a noticeable improvement! I tried downloading vanilla to compare, but it seems the same as Heng/Cheng when center player is turned on (3.3.0 which is the latest on oook). I'm not surprised since the main-win.c on github looks very similar to what I started with. Is it possible to download an SDL Angband for Windows?

EDIT: OK, I think the code is actually now noticeably faster. Its hard to tell in the dungeon, but when running in town or in the wilderness, I can definitely tell.

I no longer get a slight flicker, but having the whole world move is very hard for me to get used to. I don't think I can handle the center player option without getting nauseous, actually!

*Goes to bathroom to puke*

[Therem Harth]

Yeah, forget about it then. BTW I'd offer to help but I know zilch about Win32 programming.

[Derakon]

Originally Posted by Therem Harth

Yeah, forget about it then. BTW I'd offer to help but I know zilch about Win32 programming.

Only one way to learn...

[AnonymousHero]

Originally Posted by Derakon

Only one way to learn...

If main-win is actually using the Win32 API then I don't think we should encourage people to actually go in there without really good reasons .

The Win32 API is certainly not for the faint of heart.