Don't call setaspect_new() at end of rotatesprite.

This fixes 2nd and following rotatesprite calls drawing differently from
the first in a context with custom set-up aspect, as reported by Lezing here:
http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__143090

Also, back up and restore the aspect state across EVENT_DISPLAYREST.

git-svn-id: https://svn.eduke32.com/eduke32@3265 1a8010ca-5511-0410-912e-c29ae57300e0
This commit is contained in:
helixhorned 2012-12-10 18:17:53 +00:00
parent 4caab915ec
commit 99f56fd295
3 changed files with 4 additions and 4 deletions

View file

@ -7479,8 +7479,6 @@ static void dorotatesprite(int32_t sx, int32_t sy, int32_t z, int16_t a, int16_t
buffermode = obuffermode;
setactivepage(activepage);
}*/
setaspect_new();
}

View file

@ -5780,8 +5780,6 @@ void polymost_dorotatesprite(int32_t sx, int32_t sy, int32_t z, int16_t a, int16
gshang = ogshang;
gctang = ogctang;
gstang = ogstang;
setaspect_new();
}
#ifdef USE_OPENGL

View file

@ -2875,7 +2875,11 @@ void G_DisplayRest(int32_t smoothratio)
// TODO: get rid of the other outer apScriptGameEvent checks, too
if (apScriptGameEvent[EVENT_DISPLAYREST])
#endif
{
int32_t vr=viewingrange, asp=yxaspect;
VM_OnEvent(EVENT_DISPLAYREST, g_player[screenpeek].ps->i, screenpeek, -1, 0);
setaspect(vr, asp);
}
if (g_player[myconnectindex].ps->newowner == -1 && ud.overhead_on == 0 && ud.crosshair && ud.camerasprite == -1)
{