natt
Junior Member
Posts: 248
Registered: 05-11 |
Quasar said:
Well I was wrong, so I deleted my thread.
Turns out the tweaked Mode 13h that DOOM uses *is* in fact unchained and therefore planar, and this can be seen in the I_UpdateBox function which actually pushes out the pixels - it does the same kind of planar write pattern of every 4th byte followed by changing the page # by writing to VGA register on port 3C5 - dunno how I missed this before.
Anyway, this still leaves me without a really good explanation of what's going on here. :(
Well, I'll tell you what I concluded. Perhaps you already know all this though.
In d_main.c:D_Display, we have the following sequence of calls if we're wiping case (lots of other stuff has been omitted):
code:
wipe_StartScreen()
<draw lots of shit for the next tic>
M_Drawer()
NetUpdate()
wipe_EndScreen()
<wipe loop>
The <wipe loop> morphs from the screen captured by wipe_StartScreen() to the screen captured by wipe_EndScreen() while continually calling M_Drawer() along the way. It does this by alpha blending and modifying the current screen, which is also the screen that M_Drawer() draws to.
So in order for the loop to finish successfully, what M_Drawer() puts on the screen during the loop must be the SAME as what it put on to the screen right before wipe_EndScreen(). But here's the problem: if you look at the ways the stuff drawn by M_Drawer() can change, you'll find that NetUpdate() does in fact change it:
code:
NetUpdate() -> D_ProcessEvents() -> M_Responder()
and M_Responder() can change the position of the sigil (which menu item it's pointing to).
So the M_Drawer() call inside the wipe loop draws the sigil in a different place than the "target" screen, stored by wipe_EndScreen(), so the wipe never finishes.
Swapping lines 359 and 360 of d_main.c, NetUpdate() and M_Drawer(), seems to work, as expected.
|
06-29-11 16:24 
