Open GoogleCodeExporter opened 8 years ago
I suppose you could try to isolate what fixed it by doing a bi-section (r572
has the bug, r583 doesn't, try
updating to r577 and see if it's there, then go up or down until you find the
exact revision where it changed).
Thanks!
Original comment by pphaneuf
on 18 Jun 2008 at 1:59
Other errors with r612, see image.
On startup the first screen and after click to continue the main menu screen
doesn'T
get painted.
Moving the mouse over menu items brings them up and minimizing/maximizing the
window
corrects the drawing...
Original comment by tino.mie...@gmail.com
on 23 Jun 2008 at 6:58
Attachments:
Error still exists in r716 (trunk) and it is no Vista problem, running on XP
shows
the same symptoms.
Original comment by tino.mie...@gmail.com
on 5 Feb 2009 at 7:33
This bug does not seem to present itself on OS X or Linux as I have tested over
and
over to see if it will randomly occur. But I see it fairly often in Windows 7.
I am
casually working on a port for Xbox and Wii at the moment and on those systems
this
presents itself 100% of the time on menus and sometimes on level backgrounds. On
those systems the problem presents with a black screen as opposed to gray but
the
behavior is the same. When a menu option is selected the area sent to UpdateRect
becomes visible. It seems like the menu draw() is in some cases not triggering
the
screen to update. I haven't taken the time to trace everything out to see where
the
disconnect is. When you get in game or the demo starts the black screen goes
away and
everything looks good but sometimes the same issue will pop up later on a level
change on the background only. The play area always draws correctly as does
anything
that uses put_surface().
For now I simply commented out the targeted updates and called SDL_Flip() to
trigger
a complete redraw every end_frame(). Obviously it is not optimal but it allowed
me to
move on for the time being. I have a repository for my effort and you can see
where I
made this temporary "fix" and noted the issue here:
http://svn.huntsvegas.org/wsvn/quadra/trunk/skelton/svgalib/video.cpp?op=diff&re
v=3
Original comment by mwo...@gmail.com
on 27 May 2010 at 4:05
Well I put in some debug statements and a light bulb went off pretty quickly. I
could
see that when a menu option is selected SDL_UpdateRect() begins to be called
every
frame which means put_surface() is triggered to call every frame. For the parts
that
weren't drawing properly SDL_UpdateRect() was only triggered once. The reason
for
this is in Inter::draw_zone and it is documented:
"video->need_paint = 0; // RV: Only draw *once*: we are no longer running in
backbuffer mode"
I looked at the SDL port for Wii and Xbox (the latter I am currently picking up
to
maintain) and both use a backbuffer regardless of the flags set. So that code
won't
work with those ports for now. I enabled the framerate counter and tried leaving
need_paint true but that resulted in really bad framerates during gameplay.
They were
bad enough to affect movement at times. Using SDL_Flip() solves the issue while
maintaining a very respectable framerate so I am going to leave it that way for
now.
Why the issue pictured above happens sometimes in Windows 7 I still don't know.
Original comment by mwo...@gmail.com
on 30 May 2010 at 8:06
Original issue reported on code.google.com by
tino.mie...@gmail.com
on 18 Jun 2008 at 8:22Attachments: