Wesnoth 1.1.5

Get help with compiling or installing the game, and discuss announcements of new official releases.

Moderator: Forum Moderators

Yogibear
Retired Developer
Posts: 1086
Joined: September 16th, 2005, 5:44 am
Location: Hamburg, Germany

Post by Yogibear »

Yogi Bear wrote: Because of performance checking we tried to use two different compilers to see which one does the better job. Unfortunately one of them still seems to cause some "anomalies". I will update you if it is available.
And here it is:

http://prdownloads.sourceforge.net/wesn ... e?download

One note: This is solely to compare performance. There is some graphical glitches with minimizing and switching to other tasks and back. Just try to avoid doing that. If this build turns out to have a better performance, we most likely will take it and remove those things. But for now it is just to see if there is a significant effect.

I have tested it quickly and it feels indeed faster. Let's see what you think about it.
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
mjs-de
Posts: 13
Joined: March 31st, 2006, 12:07 pm

Gentoo ebuilds

Post by mjs-de »

Ebuilds for Gentoo are ready !

Location has changed, because of Problems with my hoster.

http://www.dorf.wh.uni-dortmund.de/priv ... th-dev.tbz
http://www.dorf.wh.uni-dortmund.de/priv ... th-svn.tbz
_Seth_
Posts: 1
Joined: June 14th, 2006, 8:28 am

Post by _Seth_ »

Ebuilds for Gentoo are ready !
Thank you !
palloco
Posts: 136
Joined: April 3rd, 2004, 9:28 pm

Post by palloco »

Yogi Bear wrote:windows binaries available:

http://prdownloads.sourceforge.net/wesn ... e?download

Because of performance checking we tried to use two different compilers to see which one does the better job. Unfortunately one of them still seems to cause some "anomalies". I will update you if it is available.
This version does not even work, it brings this error:
"WESNOTH ejecutó una instrucción no válida en el
módulo WESNOTH.EXE de 0187:008ff12c.
Registros:
EAX=0000000a CS=0187 EIP=008ff12c EFLGS=00010202
EBX=00000066 SS=018f ESP=00edfc90 EBP=00edfd68
ECX=00000000 DS=018f ESI=8187eeb4 FS=0f77
EDX=00000000 ES=018f EDI=00000000 GS=0000
Bytes en CS:EIP:
,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x
Volcado de pila:
,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x "

Did you compiled it with SSE option or some windows XP libraries?
Would it be possible to have a version compiled with 3dnow! enabled?

K6-III 400 Mhz, AOpen AX59Pro, 256MB RAM, Voodoo 3 3000, windows 98SE
Splroink
Posts: 1
Joined: June 15th, 2006, 3:13 pm

Post by Splroink »

Hi all, Wesnoth newbie here.

I think I've narrowed down the performance problem I've been having. Here's my theory based on looking at the 1.1.4 code. I haven't tried 1.1.5 yet but this probably applies to it too.

Loading and saving games takes time proportional to the total number of units. I'm not sure why it takes so long to do each unit, but the total time can be around 30 seconds on my computer. Also, I think it autosaves after every side finishes its turn.

Now, this wouldn't be so bad if there was an "autosaving..." indication, or better, a progress bar. Still, I think the time to save each unit's data is the main bottleneck so I bet that can be optimized better.

BTW, I like the quality of the code very much. It's nice and clean and uses proper constness, exceptions, the STL, call-by-reference, etc. Good job guys! Oh, and the game itself is totally addictive.
gabba
Inactive Developer
Posts: 129
Joined: January 24th, 2005, 5:08 pm
Location: Quebec

Post by gabba »

Yogi Bear wrote:
Yogi Bear wrote: Because of performance checking we tried to use two different compilers to see which one does the better job. Unfortunately one of them still seems to cause some "anomalies". I will update you if it is available.
And here it is:

http://prdownloads.sourceforge.net/wesn ... e?download

One note: This is solely to compare performance. There is some graphical glitches with minimizing and switching to other tasks and back. Just try to avoid doing that. If this build turns out to have a better performance, we most likely will take it and remove those things. But for now it is just to see if there is a significant effect.

I have tested it quickly and it feels indeed faster. Let's see what you think about it.
For me the first build performs fine; in this one there are graphical artifacts and the screen flashes.
User avatar
Polaris
Posts: 104
Joined: March 25th, 2004, 3:30 pm
Location: Invincible Cyclones Of FrostWinds
Contact:

Post by Polaris »

palloco wrote:
Yogi Bear wrote:windows binaries available:

http://prdownloads.sourceforge.net/wesn ... e?download

Because of performance checking we tried to use two different compilers to see which one does the better job. Unfortunately one of them still seems to cause some "anomalies". I will update you if it is available.
This version does not even work, it brings this error:
"WESNOTH ejecutó una instrucción no válida en el
módulo WESNOTH.EXE de 0187:008ff12c.
Registros:
EAX=0000000a CS=0187 EIP=008ff12c EFLGS=00010202
EBX=00000066 SS=018f ESP=00edfc90 EBP=00edfd68
ECX=00000000 DS=018f ESI=8187eeb4 FS=0f77
EDX=00000000 ES=018f EDI=00000000 GS=0000
Bytes en CS:EIP:
,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x ,02x
Volcado de pila:
,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x ,08x "

Did you compiled it with SSE option or some windows XP libraries?
Would it be possible to have a version compiled with 3dnow! enabled?

K6-III 400 Mhz, AOpen AX59Pro, 256MB RAM, Voodoo 3 3000, windows 98SE
From the dump you provide, it seems that both the code and the stack are corrupted... May be a stack overflow problem that leads the execution into the data segment. Have you tried debugging the program?
Standing With So Cold A Heart... Watching The Death Of The Sun...
flava_clown
Posts: 79
Joined: September 24th, 2005, 10:46 am
Location: Spain
Contact:

Post by flava_clown »

Yogi Bear wrote: http://prdownloads.sourceforge.net/wesn ... e?download

One note: This is solely to compare performance. There is some graphical glitches with minimizing and switching to other tasks and back. Just try to avoid doing that. If this build turns out to have a better performance, we most likely will take it and remove those things. But for now it is just to see if there is a significant effect.

I have tested it quickly and it feels indeed faster. Let's see what you think about it.
not for me, it was more a decrease than an increase of the performance. okay i could live with the flickering info texts from the menu, but the scrolling in the game doesn't deserve this name, it's a slideshow, around 1 frame per 3 seconds... in one word: unplayable!

i think one big problem with the saving is, that you save now much more informations than before. one unit have now every information you can think about. do we really need the movement costs for every single unit in a save game? or the residence? the max hp, max xp, alpha and what else? for what are the unit files then? and for what are the movement types? i mean in older save games there were only the necessary informations to a unit and things that aren't "normal" for this unit type.

anyway, since a lot of people don't want the autosave, what about to make it optional? what about an option that allows the player to disable the question if he/she want to save a replay (i have to click always no) and what about a quick save? which is quick, not like in the most games where quick means "quick to do" but not "quick with saving" ... i think a save game during the game like an autosave doesn't need the statistics from older scenarios nor other for the actual scenario unnecessary infos..

...
Imagine there's no countries
It isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
Yogibear
Retired Developer
Posts: 1086
Joined: September 16th, 2005, 5:44 am
Location: Hamburg, Germany

Post by Yogibear »

flava_clown wrote: i think one big problem with the saving is, that you save now much more informations than before. one unit have now every information you can think about. do we really need the movement costs for every single unit in a save game? or the residence? the max hp, max xp, alpha and what else? for what are the unit files then? and for what are the movement types? i mean in older save games there were only the necessary informations to a unit and things that aren't "normal" for this unit type.
The reason for this is replay compatibility. If unit stats like movement, resilience, hitpoints, xp etc change from one version to the other, all older replays containing that unit are almost for sure broken (that is they suffer from out of sync messages). Having that information in the savegame enables you to watch an older replay with a newer version of wesnoth.

Nevertheless it's a fact that savegames have grown a lot because of that and we have to think severely if we keep it this way or not.
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
User avatar
turin
Lord of the East
Posts: 11662
Joined: January 11th, 2004, 7:17 pm
Location: Texas
Contact:

Post by turin »

Yogi Bear wrote:Nevertheless it's a fact that savegames have grown a lot because of that and we have to think severely if we keep it this way or not.
This is my non-programming mind speaking... would it not be possible to only have the replays store all that data, and have normal saves as they used to be? That would require two different saving mechanisms, and it would make replays actually be different from other saves, but I don't see those as huge problems.

You would still get an OOS if you saved a scenario and loaded it under a different version, but that's not a huge problem, methinks.
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
Xan
Inactive Developer
Posts: 258
Joined: August 28th, 2005, 3:05 pm
Contact:

Post by Xan »

Yogi Bear wrote:Nevertheless it's a fact that savegames have grown a lot because of that and we have to think severely if we keep it this way or not.
Actually, I've never seen a replay where the unit data takes up more space than the replay data.
"It is time people learned about their failures and my successes."
flava_clown
Posts: 79
Joined: September 24th, 2005, 10:46 am
Location: Spain
Contact:

Post by flava_clown »

Yogi Bear wrote:
The reason for this is replay compatibility. If unit stats like movement, resilience, hitpoints, xp etc change from one version to the other, all older replays containing that unit are almost for sure broken (that is they suffer from out of sync messages). Having that information in the savegame enables you to watch an older replay with a newer version of wesnoth.

Nevertheless it's a fact that savegames have grown a lot because of that and we have to think severely if we keep it this way or not.
i said already, more or less, that i don't need/want a replay. the idea from turin seems to be really good for me. the unit data and all the necessary stuff to make a replay compatible with newer versions, should be saved only once, in the moment when wesnoth ask if you want a replay or not. if not, then you will go a lot faster to the next scenario and the saves between the turns are shorter, which is a fix for the problem! and to have the possibility to turn off the autosave feature completly would increase the performace a lot more, which brings back some of the old game fun. the way it is, removes the fun nearly complete! (at least for me)

and btw. thanks to some changes, some older campaigns won't work with newer versions, so we can drop the compatibility for the replays too, imho
Imagine there's no countries
It isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
torangan
Retired Developer
Posts: 1365
Joined: March 27th, 2004, 12:25 am
Location: Germany

Post by torangan »

You seem to miss the obvious part - if you load a save which doesn't contain a replay as well, tell me: Where do you get the data for the replay from when it's time to save it? Don't try the cheap exit of keeping it in memory, Wesnoth may have been restarted in the meantime.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp

Translators for all languages required: contact me. No geek skills required!
flava_clown
Posts: 79
Joined: September 24th, 2005, 10:46 am
Location: Spain
Contact:

Post by flava_clown »

okay that's a good point... but it seems that you missunderstand something. some of the infos in the autosave game are for the compatibility of a replay only, they can be easily stored in an extra file, that's more or less what turin want. the point is that we don't need infos like movement cost, resistence, max hp, mx xp,... and the like in every autosave file. you don't use the autosave for a replay!
btw. an option to turn the autosave feature off, would help alot! like this it's not necessary to talk about the stored informations...
Imagine there's no countries
It isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
scott
Posts: 5242
Joined: May 12th, 2004, 12:35 am
Location: Alexandria, VA

Post by scott »

flava_clown wrote: the point is that we don't need infos like movement cost, resistence, max hp, mx xp,... and the like in every autosave file. you don't use the autosave for a replay!
That information has another purpose which I consider far more important. It allows many of the new WML capabilities to function (although in that regard it should be possible to save only differences from the standard unit definitions rather than the whole unit every time).

I place exactly zero value in having replays from different development versions be compatible with each other. It might be nice for players but it doesn't help development to see what happened in an old version.
Hope springs eternal.
Wesnoth acronym guide.
Post Reply