stwf
WFG Retired-
Posts
178 -
Joined
-
Last visited
-
Days Won
2
Everything posted by stwf
-
Build environment and deployment on the Mac
stwf replied to Yves's topic in Game Development & Technical Discussion
The best tool ever for automating DMG packaging is choctop http://drnic.github.com/choctop/ although you need to set up a small ruby environment its easy and so worth it. -
Yes to all questions... Works on Mac (I'm developing it on a mac), and can play the music continually. Here is a new diff file that fixes the build on Windows... All it needed was to add 'precompiled.h' to all of the files and I got it to build in VC++10. Try it out if you like. No directional code yet. So if you'd rather wait a few more days for that it's fine... new_sound_manager_3.diff
-
This is actually the correct answer OpenAL is pretty flexible, so things like custom volume rolloff, doppler effect, and applying reverb to single sources is straightforward. So getting these details right can be an iterative process. The current system only provides a flag, eOmnipresent that is defined as playing a sound at the listeners location. It does make sense to add one for a sounds with direction that should be played even when off screen. All of the sounds are specified in xml files. So a custom rolloff for each could be added to that pretty easily. I do wonder how much you want to hear things that are offscreen. Of course you want to be notified of attacks as they start, but actually hearing all of the sounds of battle while you are trying to do something on the other side of the screen could be distracting.
-
Hello Gang, I have a new version of the sound code. Mostly just adds the 0AD boilerplate at the top of each file and some minor code cleanup. I've started working on the code for locating sounds and should have that soon... BTW the new forum wouldn't let me upload a .diff file. I had to add a .txt suffix to get it to go... new_sound_manager_2.diff.txt
-
Thanks... After much thought I think i have an idea, but any feedback is appreciated. Time spent discussing now can save a lot of coding time later! I was thinking that the real 3d is very tricky and probably not of much help to the player. Since the only representation they have is the 2D screen. My idea was to map the location of the sounds to the location of the image on the screen. Just ignore everything about the location except for its right<-> left positioning (screenwise), assume the left side of the screen is 45 degrees left of center, the right side of the screen 45 degrees to the right, and place the various sounds along that range. Then put offscreen sounds that are set to play anyway a bit further out than that than that. This would put everything at the same distance from the listener. It could be a nice touch to have far distant sounds be quieter (in a low shot), but in most game situations the distances aren't different enough to convey useful information to the player. Even if someone has a full surround sound system I don't think that playing a sound behind them would prompt them to scroll to the bottom of the screen. But a sound full in the left ear might get them to look to the left hand side of the screen. Feel free to tell me if this is totally off-base. Between learning the system and writing the code I've actually played very few games :-(...
-
Hello all, Thanks for the help, I got Ubuntu running in VMWare, not too bad! Why is Copy/Paste different in different apps? lol I posted a diff file to trac: http://trac.wildfiregames.com/ticket/1223 This version builds on mac and linux Fully supports the SoundGroup.xml as well as allowing for control of the Sound item from Javascript. The missing feature is for position. It seems like the implementation of this merits some discussions here. Bugs carried over from the previous code include the playing of sounds that aren't on the screen and special intensity levels which also probably needs some discussion. I think the code is pretty solid, but probably wouldn't recommend Alpha 10 unless you plan on holding it off a bit. Of course its up to you either way.
-
Thanks! You are right about this commit, my mistake SoundGroups have their own volume, so once that is supported(soon) ths won't be used.but I. Didn't mean to leave it out of this build... My mistake... I will fix that tomorrow... I don't have a windows build nvironmentnalthough i can run win and Linux under VMware. Is it easy to set one up? Anyone have a good link explaining it?
-
No problem, its been fun! I do have a new release should be pushed to github, the url is: https://github.com/stwf/0ad/tree/new-sound-manager Also there are these svn patches that git created. I attached them here. I'm interested to see if they now work. This version cleans up the logs, fixes the crash on exit, and a few minor tweaks. Also the parameters for sound buffer size, and the number of buffers to keep in memory per item can now be set through the config file. So we can start to tweak these things if the values I'm using don't work out in the wild... Enjoy. 4_28_12_sndCode.zip
-
Hello, I have attached patches that were generated from by git branch. Sorry there are 5 (the command I used treats each commit separately). They should work with svn although you may need to apply them with the command 'patch -p1 -i 0001-new-soundmanager-code-release-1.patch', etc. Let me know if they don't work...... As mentioned in this blog post: http://codeprairie.n...s-with-git.aspx So while the underlying code has been completely rewritten, the only changes to the javascript side were the additions of the classes MusicSound, and AmbientSound to the previous Sound. MusicSound and AmbientSound each play in their own tracks, at their own volumes, and only one can play at a time. When you set a new one it will automatically fade out and release the old one. Regular Sounds, as well as the SoundGroups support for the SoundGroup xml remain the same. So it seems like a good place to do some testing and firm up the new underlying SoundManager code. There are alot of numbers for things like buffer sizes that can be tweaked for better performance if need be. I can say it works perfectly on my blazingly fast iMac with lots of RAM and an SSD..... I've tried to keep to the projects coding conventions where I could, any hints to improve the code more than welcome! Good Luck! PS, still missing a lot of functionality. Position isn't set for the action sounds, many of the parameters in the SoundGroup files are currently ignored, fading throuigh the javascript side is currently ignored as well as setting many of the parameters from javascript (gain is supported however) but in my examples most of these aren't used yet. Anyway there are other things too I'm sure. Enjoy, NewSoundManager.zip
-
Architecture for new sound system
stwf replied to k776's topic in Game Development & Technical Discussion
Hi THere has already been some work done on a SoundManager, but I'll take a look at your code. See what can be used. But in the meantime I am sure the developers would welcome your help in many areas. Maybe you should go on IRC in the #0ad-dev chatroom on Quakenet.org and see what they might have in mind. -
Architecture for new sound system
stwf replied to k776's topic in Game Development & Technical Discussion
Hello All, I just figure I'd kick this thread ahead a little. I know this stuff isn't the most interesting to think about hence the situation! Anyway it seems like there are two schools of thought here, and I don't think theres much point in pressing on until a direction is chosen. I really don't know enough about the game to give much advice here. I also have no real preference personally, whichever would work better. 1) is to let the Javascript control everything, in which case the sound manager will just be a generic javascript interface to OpenAL suited to our means. In that case we need to just start designing the interface language. I believe that was the idea with the stacks implementation that started this thread. 2) Is to put the SoundManager pretty much in charge of things. The C code could play background music depending on the current game condition, and also keep track of the objects in the screen area and play sounds for what ever activity they were currently taking part in. Access to set these items could be extended to javascript on an as needed basis. The third class of sounds I see as distance-proof. Like an alert for aggression or something that you want to hear no matter how far away it is, but it does have a location. This could of course be called from javascript, and maybe monitored by the Sound manager too, where ever it's feasible. Is there a need for a set of sounds with no general location, which should be heard no matter where the screen is? Also I think the model for 3 dimensional sound is not with the listener floating in a hot air balloon, but as it would be heard on the ground in the center of the screen. Since you're usually looking at the center those things would be the loudest, and stuff happening on the right of the screen would be on the right and a bit softer. You could combine this with a sharp rolloff for things that are off the screen. Only something huge and barely off screen would be audible. OK, discuss! Or tell me how off base my analysis is... -
Architecture for new sound system
stwf replied to k776's topic in Game Development & Technical Discussion
Hello All, As discussed in IRC I've been doing some research into OpenAL etc. To those means I've whipped up a sample app for playing sounds. The main classes I think could be a starting point to developing a new sound manager for 0AD. Right now it consists fo a SoundManager that can create SoundItems (wav files loaded into one buffer) and MusicItems (ogg files streamed in pieces) Sounds can be looped, played once and held, or played once and deleted. Music can loop or not. Plans are to add: 1) caching and reference counting for the sound data so there is only one copy of duplicated sounds. 2) crossfade both slow and fast for the music 3) load music files in a separate thread. 4) Smarts to eliminate crossfading to the same song. So please excuse my rusty cross platform C++, I know the code needs some work to be brought up to speed as well as fit in with 0AD conventions. But I think its a good starting point and can be worked on while coming up with a next-gen API that will let the game support all of the features listed here. Its an XCode project and the code can be grabbed or browsed at: git@github.com:stwf/SoundTest.git I'll hang around in IRC when I can if anyone wants to discuss this. steve -
Build environment and deployment on the Mac
stwf replied to Yves's topic in Game Development & Technical Discussion
missed that! I'm downloading it now and will try it out. So what work still needs to be done on the project to produce a stand alone app? My strategy was to make the pyrogenesis part a sub-project that builds a framework. So that might make the Premake part easier. Since Premake only needs to build the pyrogenesis subproject. Then you can keep the stuff thats nasty inside the hand made project, stuff that won't change very much. -
Build environment and deployment on the Mac
stwf replied to Yves's topic in Game Development & Technical Discussion
Hello All, I made it my goal to get you a double clickable app for 0AD on the Mac, and I am almost there. It all compiles into a framework in XCode, just need to finish getting the linking to work... .. It has been a pain. I am going the route of a hand built XCode project, so I'm not sure it fits in with your vision should how it works. Last I read you seemed to want to automate creation of the project? Anyway I could just maintain this myself in github and use it to provide you with an app that will run on a clean system, my goal! As for the storage issue, things that the app absolutely needs should go inside the app. Things it creates and manipulates itself should go in application support, and things the user can manipulate should go in docs. So a good app would have a basic maps, themes, scenarios bundled inside it. Space willing all maps should go in there. This way it can be drag copied to a new machine and still work. If that takes up too much space you'll need an installer to put large maps, music, etc inside Application Support. It would be nice to have an optional 0AD folder inside the Documents folder where I could add themes/mods. I'd like to see saved games there too, so I could manipulate, copy and archive them myself.