The Ur-Quan Masters Discussion Forum

The Ur-Quan Masters Re-Release => Technical Issues => Topic started by: Senor Quack on December 22, 2007, 11:33:34 pm



Title: Planet rotation task causes lander slowdown in my port to GP2X
Post by: Senor Quack on December 22, 2007, 11:33:34 pm
Hello, I have taken over the port of UQM to the GP2X 200mhz ARM handheld (http://wiki.gp2x.org/wiki/The_Ur-Quan_Masters).  I have gone a long way towards making this port better than ever on this device, and the users are very happy.

My problem is that we still have to overclock a little bit to make the planetary lander perfectly smooth on planets with heavy activity.  I have gone to pretty long lengths to improve performance, including custom writing a fullscreen blitter in ARM ASM, changing the internal mixing code entirely over to integer, integrating ARM ASM memory handling routines, integrating an ARM ASM ivorbisdec library etc etc.

Anyways, by what is probably a bit of good luck, I have discovered that because the PROFILE_ROTATION flag has accidently been left on in my compile, I was seeing the following output on stdout:

Code:
Rotation frames/sec: 242/3460(msec)=61.111111

Big deal, you say?  Well, I get this profiling output every few seconds even when I'm guiding the lander around the planet collecting minerals.  Doing a search through the source code, I have discovered that this output is from code in  the function RenderLevelMasks in plangen.c, called from within the rotate_planet_task function.  This appears to be all the code related to drawing the rotated planet in the orbit display, which sucks up a LOT of valuable ARM CPU cycles.

The ARM seems to be struggling with handling all that math, which I would guess should be suspended while you're just down on the surface.  Please correct me if I am wrong.   Should I submit a bug report to request this be the case?  Any suggestions on how to go about disabling the rotate_planet_task code while on the surface?  I am not familiar with coding multithreaded programs, unfortunately. 

Thanks


Title: Re: Planet rotation task causes lander slowdown in my port to GP2X
Post by: Senor Quack on December 23, 2007, 02:13:01 am
I have discovered what I need to add to the code to get planet rotation code to correctly pause when the lander is on the surface.  I now have the rotation code completely paused when collecting minerals.  I will be sumitting a bug report to explain how in the next few days..

(A check is being made in one place to see if rotation is paused, but not in another, in plangen.c)


Title: Re: Planet rotation task causes lander slowdown in my port to GP2X
Post by: meep-eep on December 23, 2007, 02:29:22 am
Yes, I consider this to be a bug. And we also accept enhancement request in our bug database (http://bugs.uqm.stack.nl/).

We would also be interested in any other changes that you have made which may make sense in the main branch. (But submitted as one patch per issue.)
Even platform-specific code like the ARM blitters would be welcomed, if handled cleanly.

As for how to approach this particular bug, there are other who are better known with this part of the code than I. I guess you could use a condition variable to pause the thread. Or, you could stop the thread altogether, and restart it afterwards. That should help with memory usage too.


Title: Re: Planet rotation task causes lander slowdown in my port to GP2X
Post by: Novus on December 23, 2007, 02:32:24 am
As far as I can tell from a quick test, there are no ill effects from extending the check on PauseRotate in rotate_planet_task to encompass the calls to RenderLevelMasks and SetShieldThrobEffect, although I'm not convinced that it's impossible for one old frame (wrong planet angle) to be displayed after unpausing rotation. More careful thought is required than I can handle right now (at 3:30 AM), but I think I have a pretty good idea what to check in a patch.