Wesnoth 1.1.5

[Yogibear]

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.

[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_]

Ebuilds for Gentoo are ready !

Thank you !

[palloco]

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]

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]

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.

[Polaris]

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?

[flava_clown]

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..

...

[Yogibear]

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.

[turin]

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.

[Xan]

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.

[flava_clown]

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

[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.

[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...

[scott]

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.