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

polymer/eduke32/build/src/engine.c

@@ -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();
 }
 
 

polymer/eduke32/build/src/polymost.c

@@ -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

polymer/eduke32/source/game.c

@@ -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)
     {