Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Moderator: Forum Moderators
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Quick reply:xudojnik wrote:Tell me, please. Which version of Wesnoth do I need to play latest Wesband?
It is on 1.10.
I think an older version is also on 1.8.
-
- Posts: 54
- Joined: May 22nd, 2008, 2:45 am
Re: Wesband very slow
I've tried Wesband on 1.9.something and 10.2 now and it is unplayably slow. If I only have one character, it's not too bad, but if I have all four and I right click on one to do anything, there's a very long delay (I think 7-10 seconds). Then ending the turn takes about 20 seconds.
I'm running Gentoo AMD64 USE="dbus nls server -dedicated -doc"
Phenom 9850
8G DDR2 (800MHz in dual-channel)
NVidia 260 GT video card
3x 1.5TB SATA HDs in a raid 5 configuration
I know that AMD is slower per-thread than Intel, but this alone can't account for such a drastic slow-down. Perhaps this is simply a flaw in Wesnoth -- their scripting language just doesn't seem to scale well when you want to do very elaborate things.
Any ideas or info please?
I'm running Gentoo AMD64 USE="dbus nls server -dedicated -doc"
Phenom 9850
8G DDR2 (800MHz in dual-channel)
NVidia 260 GT video card
3x 1.5TB SATA HDs in a raid 5 configuration
I know that AMD is slower per-thread than Intel, but this alone can't account for such a drastic slow-down. Perhaps this is simply a flaw in Wesnoth -- their scripting language just doesn't seem to scale well when you want to do very elaborate things.
Any ideas or info please?
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Post your savegame so that it may be analyzed please.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
-
- Posts: 54
- Joined: May 22nd, 2008, 2:45 am
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
I would be glad to, but it's a new game.
If it helps at all, wesnoth was built with gcc 4.5.3 and -O3. I'm re-building it right now with gcc 4.7.1 using
Minor correction: The delay for right-clicking is aproximately 3 seconds. The same is true for movement. After my avatar moves, the mouse is frozen for 3 seconds and nothing is possible for that time. The time may have been slightly different before (sorry, not sure) as this is with wesnoth 10.3 buillt with gcc 4.7.1 and -O2. Ending the turn (when the AI moves) takes 37 seconds.
If it helps at all, wesnoth was built with gcc 4.5.3 and -O3. I'm re-building it right now with gcc 4.7.1 using
-O3 -fwhole-program
and if that's not better, I'll give -O2
a shot as well to try to rule out compiler issues.build options:
- Attachments
-
- Wesband_Dungeon_Turn_2-too-slow.gz
- Game I created yesterday.
- (448 KiB) Downloaded 415 times
Last edited by Sapient on June 23rd, 2012, 3:38 pm, edited 1 time in total.
Reason: Merged triple-post
Reason: Merged triple-post
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
I tried running it and got the same issue. However, I can guess why the right-click is probably taking so long to appear.
If you open the save file and search for "[menu_item]", you will see all the menu items. Within each one is a [show_if] and/or a [filter_location] that must be processed.
Some of these [show_if] are using [have_unit], which requires filtering upon every unit in the game. If there is an $x1,$y1 being used within the [show_if], then it probably should have been written using [filter_location] instead.
Take this for example:
Instead this could have been written much more efficiently as:
The improved version only needs to filter against adjacent units.
As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
If you open the save file and search for "[menu_item]", you will see all the menu items. Within each one is a [show_if] and/or a [filter_location] that must be processed.
Some of these [show_if] are using [have_unit], which requires filtering upon every unit in the game. If there is an $x1,$y1 being used within the [show_if], then it probably should have been written using [filter_location] instead.
Take this for example:
Code: Select all
[menu_item]
id="use_other_adj"
image="commands/cast.png"
description="Use/Cast on Unit"
needs_select=no
[show_if]
[have_unit]
canrecruit=yes
side="$side_number"
[filter_location]
radius=1
x="$x1"
y="$y1"
[/filter_location]
[/have_unit]
[/show_if]
Code: Select all
[menu_item]
id="use_other_adj"
image="commands/cast.png"
description="Use/Cast on Unit"
needs_select=no
[filter_location]
[filter]
canrecruit=yes
side="$side_number"
[/filter]
radius=1
[/filter_location]
As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Add information about it on the wiki, please.Sapient wrote: As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
... it's not a real tag. I just made the game ignore it...xudojnik wrote:Add information about it on the wiki, please.Sapient wrote: As an experiment, I tried replacing every [show_if] with [show_if_fail], and the right-click menu appeared quite speedily.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
-
- Posts: 54
- Joined: May 22nd, 2008, 2:45 am
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
ooh, would you pretty please post the patch so I can try it? I really used to enjoy this back in 1.8 when it was fast. In fact, if you can post a patch to both the add-on & the game, that would be great, but I would mostly need the patch to the game (since I don't know any of the wesnoth code).
Thankee!!
Thankee!!
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
No, that is a task for the add-on maintainer (Exasperation, I believe). However, if anyone needs help optimizing the [set_menu_item][show_if] conditions, feel free to post specific questions in the WML Workshop. As for the slowness at the end of turn, that is due to AI evaluation time. You may be able to fix that by setting enemies to be idle_ai (or stoned, or some other dumb ai) until they are within a certain range of the player.daniel.santos wrote:ooh, would you pretty please post the patch so I can try it? I really used to enjoy this back in 1.8 when it was fast. In fact, if you can post a patch to both the add-on & the game, that would be great, but I would mostly need the patch to the game (since I don't know any of the wesnoth code).
Thankee!!
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
-
- Posts: 54
- Joined: May 22nd, 2008, 2:45 am
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Perhaps there's a misunderstanding. I thought you meant that you added support for a tag calledSapient wrote:No, that is a task for the add-on maintainer (Exasperation, I believe).
[show_if_fail]
(in the wesnoth code). Perhaps you just meant that you changed the [show_if]
to [show_if_fail]
and let wesnoth ignore the tag it didn't recognize.I thought the Add-On author already did that.Sapient wrote:As for the slowness at the end of turn, that is due to AI evaluation time. You may be able to fix that by setting enemies to be idle_ai (or stoned, or some other dumb ai) until they are within a certain range of the player.
I may be a programmer, but sometimes, I just want to play a game.
-
- Posts: 54
- Joined: May 22nd, 2008, 2:45 am
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Thanks for your help Sapient, I made a small mod, but right-clicking is still slow (faster with only two characters however)
Any ideas on the huge delay after moving the avatar?
patch to speed up right-clicking:
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
In this addon used "continue movement" mechanic.daniel.santos wrote:Any ideas on the huge delay after moving the avatar?
In short, it means, that character gets additional movement points after movement, if no enemies nearby.
May be there is bad solution in moveto event handler.
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
This delay is caused mainly by the inefficient implementation of the function wml_actions.unpetrify(cfg) in file data\lua\wml-tags.luaxudojnik wrote:In this addon used "continue movement" mechanic.daniel.santos wrote:Any ideas on the huge delay after moving the avatar?
In short, it means, that character gets additional movement points after movement, if no enemies nearby.
May be there is bad solution in moveto event handler.
I suggest filing a bug report at bugs.wesnoth.org
To avoid the extra screen refreshes that are being triggered in that function, you can remove the [filter] and [/filter] lines inside the [unpetrify] tag so that the filtering works as intended.
However, the unit filtering is also running extremely slow, so that won't entirely alleviate the problem. For reasons that are currently unknown to me, this code was running very slow when I tried replacing unpetrify in the rousing event:
Spoiler:
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
I see nothing inefficient in there other than the redraw calls. I had put it there since the previous C++ code was apparently doing it like this. However, I didn't notice any obvious reason for it so we can just kill it I suppose.Sapient wrote:This delay is caused mainly by the inefficient implementation of the function wml_actions.unpetrify(cfg) in file data\lua\wml-tags.lua
radius= in SLFs is a known CPU sucker - well, known to me. And I think the only thing where I ever actually noticed such kind of performance impact upon coding wml. 14 is also rather high for it I think.
(silene computed its complexity (O(n^2*log(n))) - I think you remember it ?: http://forums.wesnoth.org/viewtopic.php ... 30#p387330)
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: Wesband, MP dungeon-crawler (now for Wesnoth 1.9.14+ !)
Anonymissimus - there is also the problem that it triggers screen refreshes when units matching the filter were not petrified in the first place. I don't think the screen refreshes should be there at all, though.
Regarding complexity... thanks for reminding me!
If we take n as radius in hexes then, much like the area of a circle is pi*n^2, this means that checking x and y for every hex in that circle would have a complexity O(n^2). Unfortunately, the implementation of get_tiles_radius is very suboptimal, so every time we need to get the set of tiles within a radius of (x,y), that has the added complexity of O(n^(2*log(n))), which is probably what silene was referring to in that thread. Combined this makes O(n^(2*log(n)+n^2)) for terrain_filter::match with a simple x, y,radius filter. I agree that's pretty bad, but considering the operations required are fast ones and there is a limit on radius due to fixed map size, it should still be pretty fast.
However, what I forgot was that since my location filter code is also inside a unit filter of store_unit, that greatly increases complexity to O(n^(2u*log(n)+n^(2u)) where u is the total number of units on the map. And that is going to be very bad when you have a large radius times a large number of units.
The solution as we discovered in the other thread (and as I had forgotten), is to put the unit filter inside a store_locations instead of putting the location filter inside a store_unit. Then, once you have the locations, you can set status.petrified=no in a loop (avoiding [unpetrify] due to all the screen refreshes that would trigger).
Regarding complexity... thanks for reminding me!
If we take n as radius in hexes then, much like the area of a circle is pi*n^2, this means that checking x and y for every hex in that circle would have a complexity O(n^2). Unfortunately, the implementation of get_tiles_radius is very suboptimal, so every time we need to get the set of tiles within a radius of (x,y), that has the added complexity of O(n^(2*log(n))), which is probably what silene was referring to in that thread. Combined this makes O(n^(2*log(n)+n^2)) for terrain_filter::match with a simple x, y,radius filter. I agree that's pretty bad, but considering the operations required are fast ones and there is a limit on radius due to fixed map size, it should still be pretty fast.
However, what I forgot was that since my location filter code is also inside a unit filter of store_unit, that greatly increases complexity to O(n^(2u*log(n)+n^(2u)) where u is the total number of units on the map. And that is going to be very bad when you have a large radius times a large number of units.
The solution as we discovered in the other thread (and as I had forgotten), is to put the unit filter inside a store_locations instead of putting the location filter inside a store_unit. Then, once you have the locations, you can set status.petrified=no in a loop (avoiding [unpetrify] due to all the screen refreshes that would trigger).
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."