stwf

lol I guess! But if the damage is being done faster than he can fix things even he would engage the enemy, then finish the construction.

It may be too late to interject here but I'd like to vote for 100% health also. It just makes real world sense, a Barracks can't be functional until its done, until then its just an empty building. Finish it, they move the equipment in. The it can keep producing until the health goes to zero. As far as gameplay goes also, if you can't keep a building site secure then how can you expect to finish the building? Would a carpenter be able/willing to hang doors while arrows were flying around? And if an attack did damage to a building that damage would have to be repaired before construction could finish. I like the rising and falling to indicate completeness, I also think it is good to only have one thing the player has to worry about, attacks are like negative construction, easy to visualize. As already pointed out an attack should be able to reduce a building site to nothing if so desired. It would be crazy to finish a building that could then be taken down with a single arrow!

Stevens-MacBook-Pro:s0ad steve$ ./libraries/osx/wxwidgets/bin/wx-config --libs -L/Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_xrc-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_webview-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_qa-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu_net-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_html-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_adv-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_osx_cocoau_core-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu_xml-2.9.a /Users/steve/Projects/s0ad/libraries/osx/wxwidgets/lib/libwx_baseu-2.9.a -framework WebKit -lexpat -lwxregexu-2.9 -lwxtiff-2.9 -lwxjpeg-2.9 -lwxpng-2.9 -lz -lpthread -liconv

Hi After applying the changes to the build scripts you sent me. I get a different link error. Linking AtlasUI Undefined symbols for architecture x86_64: "_iconv", referenced from: wxMBConv_iconv::GetMBNulLen() const in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) constin libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) constin libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_baseu-2.9.a(baselib_strconv.o) (maybe you meant: wxMBConv_iconv::FromWChar(char*, unsigned long, wchar_t const*, unsigned long) const, new_wxMBConv_iconv(char const*), vtable for wxMBConv_iconv, wxMBConv_iconv::Clone() const , wxMBConv_iconv::GetMBNulLen() const , wxMBConv_iconv::ms_wcNeedsSwap , typeinfo for wxMBConv_iconv, wxMBConv_iconv::wxMBConv_iconv(char const*), wxMBConv_iconv::wxMBConv_iconv(char const*), wxMBConv_iconv::ms_wcCharsetName , wxMBConv_iconv::ToWChar(wchar_t*, unsigned long, char const*, unsigned long) const, typeinfo name for wxMBConv_iconv, wxMBConv_iconv::~wxMBConv_iconv(), wxMBConv_iconv::~wxMBConv_iconv(), wxMBConv_iconv::~wxMBConv_iconv()) "_iconv_close", referenced from: wxMBConv_iconv::~wxMBConv_iconv()in libwx_baseu-2.9.a(baselib_strconv.o) wxMBConv_iconv::~wxMBConv_iconv()in libwx_baseu-2.9.a(baselib_strconv.o) "_iconv_open", referenced from: wxMBConv_iconv::wxMBConv_iconv(char const*)in libwx_baseu-2.9.a(baselib_strconv.o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status

yes, its broken, but you can still declare war after the game ends and let them fight away. I do need to merge my branch up...

Hi If anyone wants to take a look at the sound manager rewrite, its in my git repository https://github.com/s...ree/fix_sources It goes into a distress mode when sources run out, in which it recycles them faster. A possible improvement would be to set priorities int these situations, but I could only bring them up in huge combat demo. Still needs some double checking and cleaning up before I patch svn. Also the battles should sound much better I think.

I reread the deal more closely, and they are also giving 100% of the revenue for the firs 3 months on purchases if you enter the program, also which doesn't do us much good ;-). I figured this wouldn't get someone to jump in and start developing (the unit only costs $75-$100 anyway) just a nice incentive to someone already working on it. But they do want you to commit to a ship date so it may not be appropriate for us after all...

Another note, the Gamestick people are offering free GameSticks and dev kits to anyone who has a game to port. So anyone willing to try to port 0ad could at least get some free hardware for the effort...

I'm certainly not volunteering to do the work that might be needed to bring up a functioning Android port. But I am about to receive the following two devices from KickStarter backing and they both seem like winners. http://www.kickstarter.com/projects/872297630/gamestick-the-most-portable-tv-games-console-ever http://www.kickstarter.com/projects/ouya/ouya-a-new-kind-of-video-game-console It could be a brave new world for console games and it would be great to have 0AD there. Lets remember Android really isn't just about mobile gaming anymore...

I hadn't really looked into it THAT much, but judging by the fact that the error came from inside CSoundBase::InitOpenAL, I'm pretty sure allocating a new source is the only memory type thing going on in there. My new code allocates all sources at startup time and manages them thereafter, so this isn't really an issue anymore.

yes, issues like this (running out of OpenAL sources) are the target of the rewrite I'm doing now. I think its mostly a sound card issue as I can usually get thousands of sources but some machines top out at 200-300. I'm on my third rewrite of the rewrite, so I must be geting close!

Thanks for the research! To me thats sounds pretty good. In the worst case the music stalls but comes back. Which is probably what you would want in a sense, since game play should get the nod over music if necessary and possible.

Are you using the latest svn trunk? I was hoping the fixes in there made the music less obtrusive. If you are we can adjust the sleep parameters to tone it down even more.

Cool, thanks for testing... If you want to experiment with values you can add more sleep time to the equation by changing line 157 of SoundManager.cpp. I have set this as high as 7000 without seeing any gaps in music, but I think trying it on a single core machine may be necessary to see if that is too long a timeout since we have to be prepared to wait longer than 7000 ms on a constrained machine.

OK, I checked in a simplified version of the work done by Yves. This uses a second mutex for items that are marked for deletion. It also uses SDL_Delay to sleep the thread. The delay is 1 second usually but falls to 0.1 if some music fading is going on. Also in this case if the music stops it should be restarted again. Please let me know if this still causes problems on the single core machines. We could probably bump up the non-fade sleep time to 2 seconds with little issue if it is still getting in the way. Thanks for all of the help on this!

Yes, I agree for two reasons, thread switching SHOULD be extremely fast I mean what would be the point otherwise lol, and even 1 second is an eternity in processor time... Also the thread will be doing more than that in my new update, it needs to check to see if non repeating sources are done playing, and if so return them to the pool of sources, so calling it infrequently could cause issues with action sound playback...

Thanks for all of the good work on this. These are the reasons threading can be so tough, especially on low resource machines. By sleeping a thread for 15 seconds you aren't guaranteed of a call in 15 seconds, especially when the main thread is waiting on something time consuming like a large file read. In fact the system may mistake such a large sleep value for licence to give this thread a very low priority. Also possibly a solution is to use a smaller sleep value and load fewer buffers. That being said I don't think that music stoppage during startup is the end of the world as long as the code to resume them is put back. I'm not even sure you would want the sound manager to get time in the case where resources were so tight that somebody has to be kept waiting... My rewrite stuff is taking longer than I thought, I still can't get through the huge combat demo without errors, so if this gets settled down then maybe we should commit it. Especially if you want to make an interim release. I can always put my changes on top of it when the time comes.

Awesome work, thanks! I do have extensive changes, so I don't think it makes sense to put any more work into the cleanup. I can do that on top of my changes. When is a good question, but this weekend is a good bet. I want to make sure its behaving right even in low resource environments. But I do think these changes will go into the code very cleanly. The areas you hit aren't very much changed in the new code. Did you mention you wanted to look into some other areas? That might be a good idea to do for the next few days if you wanted. The music is handled from the simulation (javascript), so I just implemented the system as it was in the code previously. The javascript takes the first song and plays it looping. There has been a lot of talk about taking over that responsibility from the js code but its been hard to pin down a consensus. Hopefully its something the Design Committee can clear up.

It seems that bug was fixed with no actual sound manager involvement, so I'm not sure why you say that. Also I didn't say there was a race condition just that the main thread might occasionally wait for the lock to delete items when it should just move on and do it some other time.

Hi and Merry Christmas if you celebrate! Merry times anyway if you don't! Yes also you never really know the quality of the audio you'll be loading so memory size is not going to be easily translated into an amount of time, I think. it's better to have something that could react to conditions. lol I've worked with threads in the past and gotten only pain! But the truth is they are fine as long as you are careful. My usual fear is things getting deleted out from under you, so while OpenAL is fine with deleting sources at any time, we're deleting the associated ISoundItem too. This could happen before the main thread even returns from the alSourcePlay command, so if you use the SoundItem to play the sound it could return into an object that was already gone. That sort of thing. Plus as you noted I doubt its the deleting thats slowing anything down, its the file loading. THAT can probably be moved into the thread with little problem, its a good idea. To some degree the streaming should already be going on in the background. But that first seek and read maybe not. Anyway now I'm thinking if there may be some unnecessary contention with the deleting and the threads run action, I will look into that. You're right that one shouldn't have to wait for the other. But my experience in this project tells me there isn't a whole lot of deleting going on, the sounds played are a select few over and over and they are usually cached and played by OpenAL directly. In practice I believe the thread is mostly just handling the music and ambient sounds. ok sounds good, although We probably could come up with a decent enough number on our own and then ut something in so that if it detected a buffer outage it would be smart enough to shorten the sleep pattern.

Thanks so much Yves, I'm actually in the middle of restructuring the SoundManager stuff to fix a few problems we've run into, and also due to a deeper understanding of OpenAL than I had when this started! But I'll incorporate the ideas in this fix at least as well as any further input you can give. The thread is also not only working during fades it is required to keep the music and ambient music queues fed. The timeout value you'll need will probably also vary widely with sound cards and/or various driver implementations. It also depends on how much memory you choose to use for your buffers. To me 10 seconds sounds like too long but I don't have any data on this. I would mind an algorithm that could start shortening if it detected issues where it wasn't getting called quickly enough. I'm trying to be careful about what get moved in to thread. I definitely think the call to CleanupItems (where finished sounds actually get deleted) needs to happen in the main thread for safetys sake. As you noted if the music or ambient sound buffers run out the sound will stop and not restart whn you re-supply the buffers. I put that code in a while ago, I don't think it is needed often but it doesn't seem to cause too much trouble, so I left it in.

Absolutely, its ok with me! I appreciate the help! I am in the middle of a large rewrite of the SoundManager code (going to be a huge improvement!) but the threading code isn't part of that. So I'm sure your changes will still be an improvement. Whenever you wat to move on send me your changes and I'll incorporate them as soon as the rewrite is done. Thanks!

I know its too late fot his release, but you can put my full name in there - "Steven Fuchs"

oh, ok. I am not familiar with how that works, does the simulation code have access to the same components? I asked the Design Committee to rule on that, whether or not to take music control out of the simulations hands and put it under SoundManager. I thought they should decide it once and for all. In the meantime this could be a good starting point for the battle detection issues.

Sounds neat... As for changing to war music I believe this will work... (Javascript, right?) global.music.setState(global.music.states.BATTLE); and then to go back, global.music.setState(global.music.states.PEACE); Let me know if that doesn't work.