replying directly to complement a little
the hosting system I mentionned is called dedibox (http://www.dedibox.fr/=
the RAM usage measured
in everycase we replayed a 9 turn replay with the following options
no sound, no music, english, turbo*4 color cursor, windowed, native
resolution (1024x768, 400x300 for tiny)
we did two runs each time
normal build : 101024 99640
tiny : 55060 55012
low mem: 94260 91160
low mem, no anim: 87340 85348
low mem, no anim, no facing 86877 84288
tiny low mem: 55408 53000
tiny, LM, NA 53972 51808
tiny, LM, NA, NS 53792 51504
conclusions
* the second run is always a bit lower, no idea why
* tiny-gui has half sized imge (quarter of the surface and mem use) and the
gain from that is bigger than the gain from low mem
* the animation image cache does indeed use most ram
* when removing switching, we loose 1M without tiny and 250k with it.
Theoretically, removing switching removes half of the cache. We can thus
assume that the remaining image cache for anim is about 1M/250k
* most of the remaining cache is probably terrain, we havn't tried disabling
terrain borders, but that would be an interesting experiment
* the unit image cache is huge, but probably can't optimized much more.
cheers
Boucman
On Mon, Feb 25, 2008 at 6:41 PM, Nils Kneuper <[EMAIL PROTECTED]>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everybody!
> Last weekend we had a small Wesconf at FOSDEM 2008 in Brussels.
> This mail is meant as some kind of short compressive version of what we
> have
> done at FOSDEM.The following Wesnoth Developers and Packagers were at
> FOSDEM in
> the hackers room that we used for our discussions and work:
> boucman
> cycholka (aka Mist)
> ettin
> grzywacz
> Ivanovic
> Mordante (aka SkelletonCrew)
> Noyga
> Pietro_S
> Rhonda
> Dave (aka Sirp)
> YogiHH
>
> At FOSDEM itself and in the evenings we basically talked about what
> Wesnoth
> already has achieved, what we think which direction Wesnoth will/should
> take in
> the future and what we plan to work on in the foreseeable future, plus
> things in
> our policy that might/should be changed. I will separate the list of
> topics into
> the various areas of the game that we do have, it is not sorted by who
> took part
> in the discussion and when it took place. Keep in mind that many of the
> plans
> listed here are more of "long time plans", that is they might not be
> completed
> for the next stable series to follow 1.4.x, but might take by far more
> time.
>
>
> * Translations:
>
> - - How to handle translation and grammar fixes to reduce the amount of
> work for
> translators?
> In the current version of Wesnoth many translatable strings are included.
> We do
> often find spelling mistakes and such strings often get invalidated. To
> reduce
> the workload of translators by setting up some automatic system to remove
> unneeded fuzzy markers, boucman had the idea to introduce a pseudo
> translation
> ('Wesnothian') where we just collect all the spelling and grammar fixes.
> Those
> will eventually be applied and the translation file will be the source of
> strings with false fuzzy markers. I already said that I can easily add
> this
> pseudo translation and already talked to Rhonda so that he can have a look
> at
> what Debian already has in regards of tools to do most of the work
> automatically. He agreed to have a look at it.
>
> - - Scalability of the translation community
> Currently it looks like we basically reached a maximum of work/size for
> our
> translation community. There is currently no translation that is 100%
> complete
> and it is unlikely that one will be complete in the initial 1.4 release.
> We
> discussed what we can do to help the translation teams and to reduce their
> workload. This is also related to the addition of new content, since
> really much
> was added post 1.2. Part of the result of this discussion is, that new
> content
> should have been possible to translate for some time already in the form
> that it
> goes into the game (cf the huge refactoring in NR, leading to hundreds of
> fuzzy
> strings in the first month after addition to mainline, some translations
> already
> had it almost complete in wescamp), that is the content should be
> available in
> wescamp for some time already (this should by now be nothing more than
> setting
> the correct marker when uploading content to the add-on server), it should
> have
> been checked, that all strings are already marked translatable (wmllint
> can do a
> lot of it by now) and that the texts are already fine and do not need
> bigger
> changes beside spelling and grammar fixes that can be included in the
> "Wesnothian" translation and can be applied.
>
>
> * Multiplayer
>
> - - simple password/nickname in MP, like in IRC?
> We talked about adding some simple nickname registration like it is done
> in IRC
> with the tool named "nickserv". That means that you can basically register
> a
> nickname/password combination for the MP server. This nickname
> registration is
> *only* about the nickname itself, no stats are meant to be saved. This
> feature
> is meant to allow players to be more confident in knowing who they play
> with,
> that is the user named "abcdefghij" will, if he is registered, be the same
> today
> like he is tomorrow, where without such a feature everybody can say that
> he/she
> would be "abcdefghij".
>
> - - simple rooms in MP, like in IRC
> We talked about the possible addition of some room system for multiplayer,
> so
> that players could define rooms for multiplayer campaigns, tournament
> games,
> 1vs1 only, LANGUAGE only and so on. This is also meant in conjunction with
> a
> possible ability of some kind of "server rotation" to allow a better
> scalability
> if we need serverpower for more users.An example of how such a rotation
> could be
> done can be seen in IRC where many servers do form the network named
> "freenode.net". This way the server could scale better even when we have
> many
> more users simply by adding one extra server.
>
> - - change "package format" for network traffic
> Currently the mp-server has to decompress all packages, take the
> information it
> needs for itself, and then send the stuff to the other players. By
> introducing
> some fixed header package which includes all information the server itself
> really needs, all the rest could be left compressed and thus reduce the
> amount
> of CPU power the server needs.
>
> - - Should we support more "experimental" multiplayer content?
> We talked about adding more multiplayer content that does not focus on
> competitive tournament like multiplayer, like for example the rumble
> add-ons and
> other things like more RPG like content. In general we came to the
> conclusion
> that this might be a good idea, even knowing that balancing for this
> content
> will not be perfect. We also talked about the addition of other factions.
> Those
> would not be added in the default era, since it would basically be
> impossible to
> balance *everything* with all of them. The discussion was very
> controversial and
> we had no clear decision if we should allow addition of new factions like
> the
> Kalifa or not. There will have to be some further discussions, but the
> main
> direction was that *if* we add some faction, it should play differently
> compared
> to what we currently have and be an interesting alternative (yes, we know
> that
> this is not much and our normal standard...).
>
> - - Work on Multiplayer campaign support, improving it, adding features
> needed to
> enhance experience with it and eventually including some in mainline
> Mordante volunteered to further support the work on multiplayer campaigns
> by
> having a look at the existing bugs (and the ones that will eventually pop
> up).
> We came to the conclusion that there are some problems left that won't be
> fixed
> before 1.4, like for example that start of scenario saves for multiplayer
> content are broken. But basically it should be working good enough so that
> we
> can now get some real mp campaign work done and maybe integrate some into
> mainline with the next development version series.
>
> - - Multiplayer server on Windows
> Since there were some reports on the multiplayer being unstable under
> Windows,
> we tried to stresstest a server compiled and run by cycholka in the local
> lan.
> We managed to crash the server several times. We have no sure way to
> definitely
> crash the server. But there might be problems with heavy WML scenarios and
> observers joining them. This problem requires further investigation.
>
>
> * Memory consumption
>
> - - Reducing memory consumption when using the configure option
> --enable-lowmem
> On Saturday we worked on further reducing memory consumption when
> compiling with
> the option --enable-lowmem. Boucman changed the animation engine, so that
> when
> this option is set, no unit animations are used at all. So when using this
> option, we can now even strip all unit images beside the unit base image
> from
> make install. This is not done so far, but could be implemented to save
> diskspace on small devices. This change saves several MB (boucman should
> have
> the results from our test written down). Beside removing animations, the
> facing
> of units was changed. Units now do only face in exactly one direction when
> lowmem is specified at compile time.
>
> - - config revamp with respect to memory consumption
> Some configuration objects (like for example units) should be changed to
> allow
> redcution of memory usage. Boucman, Mordante, YogiHH and Dave were
> talking
> about what could and should be done. This will be a bigger refactoring and
> a lot
> of work.
>
> - - unit WML cache loaded on demand
> Currently all WML of the units is loaded when the unit is required. Not
> all of
> it will be needed always. YogiHH wants to have a look at what can be
> changed to
> improve the behavior of the cache.
>
>
> * Bigger refactoring
>
> - - new GUI system
> Mordante plans to refactor the gui system to make it easier themeable and
> to
> reduce the maintance load. Currently the GUI section seems to be a mess
> which
> makes adding new features like tabbed view and changes to dialogs very
> difficult. Beside this the dialogs do mainly scale badly with sizes
> different
> much from the "normal" size 1024x768. For example could the attack dialog
> show
> all the stats about ctk, cth, ... without having to click an extra button
> when
> the screen resolution is big enough. Something like this is not possible
> with
> the current engine.
>
> - - odd-on server revamp
> Mordante wants to takle some changes for the add-on server to introduce
> the long
> wanted things like "content type" and to allow running tools like wmllint
> on
> severside or on clientside right before uploading to reduce the amount of
> problems with add-ons. Many of those changes will require changes to the
> GUI
> system so that they can be displayed in a usable way.
>
> - - new build system
> Post 1.4 esr and I will work on switching the build system from autotools
> to
> something "better". At the moment it is not sure which build system will
> be
> used, the basic two alternatives are scons and cmake. There was a talk at
> FOSDEM
> about each of them, videos of these talks will be available at fosdem.orgin
> the
> foreseeable future. grzywacz and I attended the talks and our impression
> was
> that the syntax of cmake looks a little uglier than the syntax of scons.
> But on
> the other hand the featureset of cmake seems to be really superior. For
> example
> it directly offers many tests and might make life for packagers easier. It
> could
> be used to easily allow creation of lite packages without much extra work.
> We
> will have to evaluate and testimplement so that we see which of those is
> better
> for Wesnoth.
>
> - - formula AI integration
> Dave has been working on allowing some formulas for AIs to be coded in
> WML. This
> is some kind of functional programming inside WML to better control the
> behavior
> of the AI. For example it would be possible to hardcode mapspecific
> behavior of
> the AI in the first turns for some maps. Dave also demonstrated how the
> current
> branch already does work to the developers that were still around when
> FOSDEM
> was almost over. So far it seems to already work nicely and can probably
> be
> merged into trunk after 1.4 is tagged. This AI also requires some
> additional
> dependencies from boost. This is mentioned further below.
>
> - - savegame format revamp
> Currently the savegames seem to be a rather big mess. Mordante plans to
> have a
> look at it and reimplement some of the logics. The benefit of this would
> be that
> savegames should look more uniform. At the moment for example start of
> scenario
> saves in MP look different than Turn1 saves. This revamp will also be
> needed to
> cleanly fix some replay and mp-campaign savegame problems.
>
> - - getting stats.wesnoth.org to scale better
> Currently stats.wesnoth.org is basically unusable since the svg graphics
> want to
> display every single entry. With several hundred values rendering the
> images
> takes too long so that a timeout on the pages is the result. The data from
> stats.wesnoth.org is very valuable for balancing content so we should try
> to
> find a way to create better graphs that maybe not try to show every value
> but do
> some calculations for how we show things. Maybe there are already some
> nice
> libraries available which can do the work for us.
>
>
> * Smaller Refactoring
>
> - - layering in display code
> Mordante wants to work on allowing layering in display code. This should
> allow
> missiles in animations to be drawed on top and items to be drawed below.
>
> - - fire and forget for animations
> Boucman wants to implement a way to really have "fure and forget"
> animations.
>
> - - addition of boost foreach and boost smart_ptr
> Dave needs those two dependencies for formula ai and they do make sense to
> support c++ coders in their work. The plain header files should be enough
> to
> have it work, so it is not much of a new dependency.
>
> - - prevent UMC namespace collision
> Currently it is possible that namespaces of UMC collide. This should be
> prevented since it can lead to strange bugs. A nice and good way to do so
> has to
> be found.
>
> - - testing if binary wml is faster than text wml and compare speed with
> gzip wml
> We talked about the speed benefits binary WML might have compared to
> normal text
> WML and to gzipped WML. At the end of FOSDEM Dave started to implement
> some
> testcases to somehow benchmark the various kinds of ways we can use WML.
> He
> suspects that binary WML might be a whole lot faster for processing and
> thud
> should be used more often.
>
> - - release of 1.3.19 aka 1.4-rc2
> On Sunday afternoon I released as planned before.
>
>
> * Policy and standards
> - - updates to coding standards (in the wiki)
> The wikipage about coding standards was updated at FOSDEM. Have a look at
> it to
> see the changes. A new coding standard still has to be introduced: remove
> implicit conversions of t_strings.
>
> - --- important ---
> - - more content in, more content out
> We discussed what we can do in regards of content additions. We came to
> the
> conclusion that we should keep with making it rather easy to add content,
> but
> that we should also add a general policy to easily allow removal of
> content.
> Currently we in theory do have this already, but with a better defined
> policy it
> might be easier to handle. Here is what conclusion we had at the end:
> * Before content is added it has to meet some requirements to make life
> easier
> for translators (cf "- Scalability of the translation community"). This
> means
> that the content should be available for translators for at least one or
> two
> months via wescamp, so that they can already work on the stuff if they
> have the
> time to do so.
> * Content that is added should be evaluated after some time (that is after
> two
> or three releases with the add-on in it, we should decide if we want to
> keep
> it). The reason for this is that translators should know as early as
> possible if
> they should spend their time on it or not (removal)
> * If content is in after this time, it is enough if a developer says "I
> don't
> think this content works nicely and should stay in" to have a new
> evaluation
> among us devs.
>
> - - money/ads/hosting discussions
> We talked about the possibility of adding ads to wesnoth.org. A
> possibility
> would be to only show the ads to windows users, like we have done for a
> short
> time with the "get firefox"-banner. The reason to have those ads would be
> to
> found a dedicated root server that we do have full access to. Boucman said
> that
> there was some offer in France for rather string 2GHz machines with many
> GB
> harddrive and unlimited bandwidth usage. On such a server we could host
> the
> website including forum and wiki, a mailserver to allow @wesnoth.org email
> addys/aliases for devs, the multiplayer and content-servers. Currently
> there
> seem to be some problems with the confirmation mails at the forum
> registration.
> In the last year every now and then we had some problems with the servers,
> so it
> might be a valid idea to change to a server we have full control about.
> Beside
> this the money can be used to eventually found a real Wesconf, where every
> developer could get some support for their expends to get there. We
> could/should
> also ask more prominently for donations to be able to found a Wesconf.
> To really allow this we should have a look at what is needed in the
> various
> countries to start a non-profit foundation. This would probably allow us
> not to
> be forced to pay too many taxes, as we would normally have to do with ads.
>
>
>
> Overall FOSDEM was really great to discuss things. We were able to talk
> about
> many topics, though we have not implemented too much, since it was better
> to use
> this chance for discussing concepts and ideas. If I have forgotten
> anything in
> this list, please post it. If I made any big errors, please correct me.
> Of course this is also meant as a base for further discussions, especially
> with
> those who were not able to attend FOSDEM. So feel free to start discussing
> about
> single of the items. Probably it will be better if you discussed the stuff
> with
> new topics for each, since otherwise it will be really difficult to follow
> what
> was the "we had this at FOSDEM" and "following in depth discussions".
> What still is to be done, is putting our decisions into the Wiki.
>
> Cheers,
> Nils Kneuper aka Ivanovic
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHwv3KfFda9thizwURAso6AJwLap3lFdu2XMFi1CVbQyYJfHZE0gCfeNxl
> Iy2t70iegXqJf1iP8s+2sF8=
> =cDqg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Wesnoth-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/wesnoth-dev
>
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
