sound vs music
Monkey Targets Forums/XNA/sound vs music
| ||
| Hi, Ok, to prevent music files from being converted to massive 'wav' files, it looks like we need a way to differentiate between sound and music files for XNA. So, given, a WAV or MP3 or WMA file, we need a way to tell monkey whether that file is to be used for sound or music. Some possibilites include: * Treat WAV files as sounds, MP3 and WMA files as music. * Kludge sound and/or music file names, eg: level1_music.mp3. * Put sounds in a 'sounds' dir and music in a 'music' dir. * Add some kind of 'control' file to '.data'. I personally prefer the first - easiest to do and is consistent with how file types already control what a file is used for. The only downside is not being able to store sounds as 'compressed' files - but sound files are uncompressed again anyway when target is built so it's not much of a loss. But what would the people actually using XNA prefer? |
| ||
| it seems perfect to me. If the MP3 and WMA files get converted to wav files for sound by the compiler(or whatever)before executing, than to me, it makes sense to do the first : >* Treat WAV files as sounds, MP3 and WMA files as music. Are short wave files faster to load and process? I am assuming they are as they don't have to be decompressed and translated. Also, it doesn't affect me either way, at this time, as I haven't gotten in to XNA for obvious reasons but in my ignorant opinion I will assume it to be the correct solution. I will keep an eye on these to see what others have to say about it but for now I am fixed on this solution. |
| ||
| I replied to the bug post but upon seeing your additional post here.. I quite like the *.music.wma/mp3 approach. |
| ||
| Option 1 sounds fine - and stays consistant. |
| ||
| I prefer folders or a configuration file. Driving it directly from the file type just adds more "magic" to the build process and makes life more difficult down the road when trying to manage builds across multiple platforms. |
| ||
| The first option is fine for me, since sounds are converted to wav anyway and I will be building for XNA only for xbox. (anyway, if it's fine for indie games on xbox, it will be fine for windows builds via internet without changes, don't you think?) |
| ||
| I might be missing something here, but for XNA do you not build sounds,music,images, well any resource BEFORE you compile - or you'll have like a 5 min+++ compile time for even a smaller game right? Or maybe monkey projects tend to be so small content building works fine anyway? With that said, option 1 sounds good to me. |
| ||
| Strongly disagree with option 1. I reckon a project file should be added to define things such as data and any future specifics that are unknown at the moment. It would be good to be able to specify which data is included instead of being forced to use all data in the data folder. Maybe it could be an option on the compiler so then different versions of data can be compiled for different builds? That would be useful for all targets not just XNA... |
| ||
| Hi, > I reckon a project file should be added to define things such as data and any future specifics that are unknown at the moment. Ok, what does this project file look like exactly? What format does it have? What can it do? Is it recursive? etc, etc... I'm not exactly opposed to the idea (in fact, I'm sure it'll happen eventually) but I do think it's probably overkill for the sake of this one feature that affects one target. Sure, option 1) is kind of a hack - but it'll work and it's easily reversible if/when a better solution comes along. Adding a project system feels like a much bigger step to be taking, and one that should probably be done with a bit more planning IMO. |
| ||
| It's not "easily reversible". It would mean that the users have set up their dev processes to spit out wav and mp3 files just to match the implicit definition of music/sound effects and those processes would have to be changed again in the future. If you go with folders or a config file at least what's going on is explicit and common across all targets and we know where future change will be centred. What would such a file look like? Who cares? JSON, yaml, XML, a properties file, whatever. What can it do? Well for now it only needs to list the sound and music assets, right? Is it recursive? Does it need to be for your current problem? |
| ||
| Hi, Well, solution 1 is already in so that will be out soon. I do plan on adding data config files to deal with both this and related issues such as what data to copy/update on what targets etc, but that'll take a bit longer. |
| ||
| mark, Have you had any experience with .htaccess files? Could it not be some kind of file similar to that so that unless specified, monkey behaves in a default manner. When an .htaccess file is discovered at a path then defaults for that path and within are overridden. I would say recursive (just cos its straight forward enough to do) .. but aim for the project file to be used once per project. That's assuming its for data only... The other better option (in my opinion, can't speak for anyone else) is to have a build file that sits in the root directly and has some xml/text/ini/whatever entries to specify data to be included. Part of your re-build project option in the compiler could be to re-curse the data folder and automatically add all data as entries into the build file.. eg to replicate the same behaviour as now. Apologies if it sounded against the grain/off-topic, option 1 is definitely a good solution for monkey. It will add ease of use and be sensibly logic. I was more thinking of dealing with the issue of download sizes and adding a pinch more flexibility ( http://monkeycoder.co.nz/Community/posts.php?topic=1755 ) |
| ||
| Hi, Ok, option 1 fix for this is in experimental update V47! If your project doesn't work with V47, please post a bug. |
| ||
| Cool! Thank you! |
   |