On Fri, 9 Dec 2016 10:35:11 +0100 "Enrico Weigelt, metux IT consult" <enrico.weig...@gr13.net> wrote: > > Actually I did not think the map display was calling canSee(), but it > > does, albeit only per Unit, not per Tile. > > hmm, what is that flag actually used for ? all the tiles a player can > see (IOW: has been explored) or just changes in these tiles (eg. moving > enemies, etc) ?
If by "that flag" you mean the contents of canSeeTiles[][], it is not concerned with exploration, but with visibility. They are not the same thing, although visible => explored. I am not sure I understand what you are asking here. > my implementation only holds the lock while the visibility map is > recomputed, Odd. Why is that an improvement? The current code only holds the lock when actually switching the map over to the new version, which is *much* smaller window than the duration of a map recomputation. > BitSets are kinda case that calls for a heavy machine specific > optimization, so I'd be surprised if they didn't invest more resources > into that. > > Do we have some realistic workload example for a measurement ? My standard regression test is 10 rounds of a 7-AI game played to 1700 on two different maps, followed by a single round per map but with a complete save-reload at each turn. This is not "realistic" in that there are no human players, but it approaches repeatability. I accumulate averages of several game parameters. One of these is turn speed. If you have self-contained patches (i.e. just the bitset cutover, or just the lock removal) then I can run an A-B test. It is however more customary for the proponent of a change to produce the evidence that it is merited:-). > > I think it is memory consumption that the Android folks are (rightly) much > > more worried about. More worried than us anyway (for now). > > Isn't there an android port ? Not by us. Someone apparently hacked something together but never contributed any code back again. It would be nice to do a proper Android port, but as usual, major bugfixes are more important. Also, my eyesight is bad enough already, so I am in no rush to play FreeCol on a phone! > Do we really need an extra hashtable for each individual tile ? > Wouldn't it be even more logical to have one per player ? > (by the way would make killing a bit less complex) Perhaps, in hindsight. However keeping it all in Tile keeps all the complex code in one place rather than spreading it out into Player. Maintainability is important. Note also that Tile caches are created on demand, so they only exist for tiles that have been explored by a European player. At least in the beginning this is much less storage than outright allocating a Map per European Player. You know I am going to say this, but, I will need convincing that there is a problem here. > where does the ID come from and what it is exactly used for ? > isnt the coordinates just enough ? All FreeColObjects have an id. It is fundamental. See Game.java. Cheers, Mike Pope
pgpTTsaMwCcUy.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
