stwf
-
Posts
178 -
Joined
-
Last visited
-
Days Won
2
Posts posted by stwf
-
-
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
-
I gave this a spin. It seems to work fine, though I weren't able to trigger any combat on either of the combat demo maps. (I believe those maps were bugged a few months back, which is probably when you branched off.)
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...
-
1
-
-
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.
-
Now that sounds like some incentive
I doubt they'd give one to just anybody, it would probably have to be one person associated with 0 A.D. who was trusted to actually produce something. That said, I think it's a much better deal for them than it would be for us.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...
-
1
-
-
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!
-
1
-
-
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.
-
I can reduce my cpu power from 6*2,8GHz to 1*800Mhz. You can feel the effect immediately
with 1*800MHz, the rendering in 0ad(latest dev ppa build) completely freezes (but hey, music continues nicely!)
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!
-
No I don't think more than once per second makes sense. I was just talking about intervals of 0.1 seconds to make clear what I mean.
If it's not significantly more than 100 µs it shouldn't be a problem. I think we can remove the code to calculate the play-time entirely and set the interval to 1 sec.
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.
-
@stwf
How should we proceed now?
This implementation is obviously not ready to commit yet and there's some more work required to get it to that point. If you have a lot of changes too, it probably doesn't even make sense to make it ready to commit, because you'd have to change it again to match your changes.
How much do your changes overlap/conflict with my changes and when do you think you'll have the new version ready to commit? I have a lot of time this week and next week but then my vacation is over.
If our changes affect too much of the same code, one needs to take the lead and merge it. It's fine for me either way.
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.
Another thing I noticed today. Did you know that there's only one piece of music looped over and over again even if more than one is specified in the [civ].json file? Also as far as I can tell there's just one ambient sound used (day_temperate_gen_03.ogg).
A callback function that allows scripts to set the next piece to be played would be a good solution IMO.
It would trigger when the end of the first peice is detected and will come soon (ogg->atFileEOF()), but not instantly (there's still some data queued in the buffers).
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 could be triggering race conditions elsewhere, I suspect #1729 was one of them.
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 it certainly varies how much play-time you get each time you load data into a CStreamItem, but since the speed of playing sound effects and musfic is fixed, it should be possible to know how much additional play-time you got after loading a new chunk of data.
Probably we should make the thread's sleep-time variable and calculate it each time after reading additional data. However certain events like fading and playing sounds instantly should ignore this sleep time and wake the thread up immediately.
That seems to be the cleanest solution for me.
I'll try to make a proof of concept implementation to see if it works in practice.
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.
What's more safe if this is in the main thread? That's the first time I'm working with threads, so I might miss something.
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.
I've now written a test-function that checks the amount of playtime that was added. It's possible to get the data but I still have to check if it is useful for what I hope.
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.
I've moved the call to CSoundManager::IdleTask() from the main thread to the worker thread because apparently it can block the main thread for quite a while under some circumstances. I guess the blocking got worse because m_WorkerMutex is blocked much longer inside Run() when it isn't called that often anymore.
I've also added some profiling macros, especially at places where time could be lost while waiting for the mutex. I did not add information about how long the thread is sleeping because IMO the profiler should only show load and not idling that has no impact on performance.
The 10 seconds are currently hardcoded. In theory this time depends on how much play-time is left in the buffers that are queued in OpenAL.
I tend to say that it's not worth the effort to calculate this sleep-time on the fly and a hardcoded value should be fine.
However these 10 seconds are quite random and I didn't do any analysis to get to that value. What do you think?
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.
if (m_CurrentTune)
m_CurrentTune->EnsurePlay();
if (m_CurrentEnvirons)
m_CurrentEnvirons->EnsurePlay();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.
-
@stwf
Is it ok for you if I continue my work and ask you for review as soon as it's more stable?
If you like to fix it yourself it's fine for me, in this case I'd start checking wraitii's new AI for performance issues. I have some ideas there too.
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.
-
stwf, I've implemented a prototype for the battle detection logic:
https://github.com/z...le-detection-x1
When a player's damage rate exceeds a certain threshold for a long enough time, it emits a "MT_BattleStateChanged" message. How would you recommend that I make the sound manager change the music track being played accordingly?
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.
Foundations under attack (discussion)
in Game Development & Technical Discussion
Posted
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.