When I was trying to understand the number of new tiles loaded, i found
this piece of code in RMFractalTileProjection
- (RMTileRect) projectRect: (RMXYRect)aRect atZoom:(float)zoom
{
int normalised_zoom = [self normaliseZoom:zoom];
float limit = [self limitFromNormalisedZoom:normalised_zoom];
First of all normaliseZoom returns a float and limitFromNormalisedZoom
accepts a float. And also, the method project:atZoom (just above this
method) does this properly. Casting to a int causes truncation. So, how
does this affect the rest of the code ? This affects the number of tiles
loaded. At this point, i don't know whether it is serious bug or not. I am
not able to beleive that this is intentional.
The way I tracked down is a little long story. The method computes the
tileRect width and height like this:
tileRect.size.width = aRect.size.width / bounds.size.width * limit;
tileRect.size.height = aRect.size.height / bounds.size.height * limit;
aRect.size.width is computed by multiplying screenBounds.width with scale.
If you substitute the equation for scale which is computed from this function
-(float) calculateScaleFromZoom: (float) zoom
{
return bounds.size.width / tileSideLength / exp2(zoom);
}
NOTE: This is the only place where exp2 is used and everywhere else it is
exp2f. FWIW, this should be fixed.
By substituting, you will figure out that
tileRect.size.width = screenBounds.size.width/tileSideLength;
This should result in the same number of tiles loaded irrespective of the
zoom. I don't know whether addTiles has other checks or not. The bug above
resulted in a different value for tileRect.size. Even after fixing this, it
is not same because exp2(zoom) and limit are not same because of the
roundf() in normalizeZoom.
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What subversion release are you using? Does the behavior occur on the
simulator, a real iPhone/iPod Touch, or both?
If you can reproduce your bug, please provide the source code for a
reproducing case. The best place to start is with the SampleMap project.
Please don't send patches/diffs. Post source code directly to the issue
tracker, noting your suggested revisions. If they are extensive, use a
branch in subversion with the same name as your issue number (e.g.
branches/issue59).
Please provide any additional information below.
Original issue reported on code.google.com by surut...@gmail.com on 10 Apr 2009 at 7:32
Original issue reported on code.google.com by
surut...@gmail.comon 10 Apr 2009 at 7:32