News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Black screen flicker in Windows GDI

Started by Markohs, September 04, 2013, 05:14:46 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Markohs

Today I was playing and under heavy CPU pressure, the screen flickered black some times when in fast forward, I don't know exacly what causes this, but it might be related to threading. Or not.

Sometimes the screen turned black and it was slowly redrawn correctly **on dirty tiles only**, the rest of screen remained black.

I use Win32, Built with VS2012, GDI. MULTI_THREAD=4

@6670

I'm the only one that noticed this?

TurfIt

I've noticed lately something changing the zoom level when the CPU gets too busy. ie. try to raise a huge mountain, the program goes unresponsive, then when it comes back it auto zooms in, but doesn't mark the whole screen dirty. Hence moving objects get drawn in the new zoom on top of the old size terrain. Whereever this auto zoom has come from, it has gotta go...

I've not seen a flickering black screen, but I usually use SDL.

Markohs

I compiled the single thread version and the problem disapeared. Might be a race condition, somehow the screen in flushed black (in simview.cc, line 153), and written entirely to screen before it's redrawn.

EDIT: No, it can't be because the screen whould be GRAY, not black. Maybe Win32 losed the framebuffer and hinted us to refill screen completely and we ignored the event. Or maybe it's a bug in my video card driver. Only showed in high CPU usage, the sound was even pausing, si it might have been just my system.

But if someone has similar problems, report them, please. :)

TurfIt

Try multithreaded, but with the multithreading in simsys_w.cc disabled. ( I just search/replace in _w.cc for MULTI_THREAD -> mMULTI_THREAD) That would isolate the threaded simview from the OS stuff.

Dwachs

Quote from: TurfIt on September 04, 2013, 05:23:39 PM
I've noticed lately something changing the zoom level when the CPU gets too busy. ie. try to raise a huge mountain, the program goes unresponsive, then when it comes back it auto zooms in, but doesn't mark the whole screen dirty. Hence moving objects get drawn in the new zoom on top of the old size terrain. Whereever this auto zoom has come from, it has gotta go...
Could reproduce this, the call is in karte_t::update_frame_sleep_time... it should set everything dirty..

Edit: try r6680.
Parsley, sage, rosemary, and maggikraut.

TurfIt

That fixes the dirty, but doesn't fix the fact it should never have changed the zoom in the first place. I assume the intent is to maintain some responsiveness if the user zooms out too far for their computer to handle. But if the hiccup is due to a user initiated command that takes a while, zooming in is annoying and accomplishes nothing.

prissi

Which command should this be (apart from raising a 14+ hill)? You need to be without response for a long time.

95% of the errors of getting inresponsitive is zooming out too much. And then you cannot even save your game anymore. Hence this emergency measure which is better than loosing the game.

TurfIt

I thought I'd seen it on repeatedly rotating a huge map, but I can't replicate it now. Doing that does kill the framerate for ~30 secs until it recovers, but that's an entirely separate problem.