0000037: Harvested asteroids shrink to a minimum size

Notes
(0000051) lmop (developer) 2007-03-18 18:19	Scaling is linear: src/Game/ResCollect.c: HandleAsteroidScaling() asteroid->scaling = (real32)asteroid->resourcevalue / (real32)asteroidstatic->resourcevalue;

(0000054) lmop (developer) 2007-03-21 14:30	There's a secondary issue which is that resource collectors' harvesting is tied to specific frames. I think this is for two reasons: 1) reduce the number of calculations required when lots of harvesters are in play (regardless of whether they are on screen or not) 2) allow non-integer multiples of frame rate to be collected (resources collected = n resources every t frames) since the internal storage variables are of type int. Turning off the frame sync'ing produces very smooth scaling (as you might expect). The non-integer multiples of resource collection is a little dodgier since the type would have to be changed to a real32 (which will fit in the current sdword allocation) to allow sub-resource unit interpolation and that would require another save game version bump. Changing the scaling to use cube root definitely looks more realistic but with frame sync'ing it effectively recreates the minimum size problem again. For example, when harvesting the fairly common asteroid3, the penultimate resource ratio is 5/100. That translates to an asteroid over a third of the original linear size which is substantial. Again, fractional resource unit harvesting counteracts this.

Issue History
Date Modified	Username	Field	Change
2007-03-09 16:26	lmop	New Issue
2007-03-09 16:26	lmop	Affected: Linux	=> Unknown
2007-03-09 16:26	lmop	Affected: Mac	=> Yes
2007-03-09 16:26	lmop	Affected: Windows	=> Unknown
2007-03-09 16:26	lmop	gcc version used	=> 4.0.1
2007-03-09 16:26	lmop	In Original Game	=> Unknown
2007-03-09 16:26	lmop	revision or version first notice	=> n/a
2007-03-09 16:26	lmop	system type: 64 bit or 32 bit	=> 32 bit
2007-03-18 18:19	lmop	Note Added: 0000051
2007-03-21 14:30	lmop	Note Added: 0000054

Relationships