Progress bar

Post by **Kvasir** » March 5th, 2006, 10:17 pm

When browsing the forum I saw there was a thread on showing something earlier during startup and since I was curious about how Wesnoth worked I looked a bit deeper on it. The following patch when applied shows a simple big progress bar during startup. I also think applying something like this during campaign loading would be desireable since slow machines like mine take ages to do that (actually about slightly less than minute).

edit: Removed the patch as it is now outdated

Post by **Boucman** » March 6th, 2006, 7:36 am

nice....

could you post it on patches.wesnoth.org after reading the sticky on posting patch in this same forum ? I'll look at it ASAP

thx

Post by **Boucman** » March 8th, 2006, 10:13 am

Ok, I just looked at your patch on patches. wesnoth.org and yes, it's a step in the right directions.... here are a couple of steps to help

1) better granularity would be nice
2) a line telling what the game is doing would be nice
3) display.cpp seems a good place to put your stuff so it's ok

I didn't commit it because you said in your p.w.o comment that you wanted to work on it some more... so just tell me when you're ready here and it will go in.

thx
Boucman

Post by **Kvasir** » March 15th, 2006, 10:54 pm

When reading or verifying the cache it recursively calls an _internal function with as far as I could see no easy way to find out how many times the function will be called. For now I just use a magic number that has been set after logging the amount of function calls and it works fine but that number obviously requires updating after each data set update. So my question is if there is a way to find out how many times the code is going to call this function inside the code?

Post by **Boucman** » March 18th, 2006, 9:17 am

probably not...

you usually use recursivity specifically for that reason...

glad to see this patch is still alive

Post by **Yogibear** » March 19th, 2006, 12:40 am

Kvasir wrote:When reading or verifying the cache it recursively calls an _internal function with as far as I could see no easy way to find out how many times the function will be called. For now I just use a magic number that has been set after logging the amount of function calls and it works fine but that number obviously requires updating after each data set update. So my question is if there is a way to find out how many times the code is going to call this function inside the code?

Hmm, shouldn't a static variable inside of that function do this job?

Post by **Boucman** » March 19th, 2006, 10:44 am

no...

the point is to know a priori the number of calls, a static variable would tell you that a posteriori (which can be done recursively in a more elegant way by each level returning the recursion level)

Post by **Darth Fool** » March 19th, 2006, 11:30 am

You could store store the value in the highest level of the cache. Than when you are loading the cache, you could use that information. But, as far as determining how deep the rabbit hole goes the first time, you got have to take the red pill.

Post by **Kvasir** » March 19th, 2006, 6:21 pm

The current version which is on patches.wesnoth.org introduces better granularity during startup. The total percentage to game config loading is fixed which means progress is too slow when there is no cache. It doesn't bother me but if people find it important I can change it.
I also didn't include a logo and the strings are hardcoded in the executable. If there are good ideas about on stuff to add here feel free to propose it.
I also changed the structure, everything is now in two seperate files, I did this mainly to speed up rebuilding (display.hpp is used in many files) but I guess it may also make it easier for others to adapt the code.

The recursive thing was already counted by static variables, the final count is written out on stderr and I manually copied these over as the magic number constants in the code.

Post by **Boucman** » March 19th, 2006, 7:22 pm

hmm

apparently you uploaded three time the same patch... could you post a corrected one to patches.wesnoth.org please ?

Post by **Kvasir** » March 19th, 2006, 8:15 pm

Sorry for all the reposts, I had made a spelling error in the new patch and always uploaded the old one. I also noticed the patch didn't include the new files so I uploaded them as well..

Post by **Boucman** » April 2nd, 2006, 8:15 am

ok, your patch has been commited

thanks a lot for the work you've done, that's great

and sorry for the time it took me to commit it

Post by **Yogibear** » April 7th, 2006, 4:40 pm

Unless i am not mistaken, there is a problem with the patch. binary_wml now has a dependency to loadscreen and this one directly or indirectly needs all the other stuff within wesnoth.

On the other hand, wesnothd (the server app) builds with binary_wml and therefore also "inherits" all those dependencies. This should be fixed or it will become a pain to build wesnothd.

Post by **Darth Fool** » April 7th, 2006, 4:53 pm

Yogi Bear wrote:Unless i am not mistaken, there is a problem with the patch. binary_wml now has a dependency to loadscreen and this one directly or indirectly needs all the other stuff within wesnoth.

On the other hand, wesnothd (the server app) builds with binary_wml and therefore also "inherits" all those dependencies. This should be fixed or it will become a pain to build wesnothd.

agreed.

Post by **Kvasir** » April 7th, 2006, 8:02 pm

Can someone tell me if there is already a preprocessor macro/define I can use to test what is being built? I will gladly add an updated patch with it as soon as either someone can tell me it or after I have found the time to look into it myself.