]> git.mxchange.org Git - flightgear.git/commit
I just nailed an especially annoying tile cache scheduling bug.
authorcurt <curt>
Mon, 12 Nov 2001 22:05:47 +0000 (22:05 +0000)
committercurt <curt>
Mon, 12 Nov 2001 22:05:47 +0000 (22:05 +0000)
commit36de63366b1b7de5581d477f65a41ec414e5c33e
treedf888851eb63c46ed456a79aa9934396137a4dad
parenta3bce2f219e0b629e5086c12d24459ad754e4312
I just nailed an especially annoying tile cache scheduling bug.

What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo.  This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load.  The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.

These negative tile id's up the logic used to remove tiles from the
cache.  When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id.  Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove.  However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal.  This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.

I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
src/GUI/apt_dlg.cxx
src/Scenery/newcache.cxx
src/Scenery/tilemgr.cxx
src/Sound/fg_fx.cxx