I have a work around for the lack of loop points in WAV files. I basically recreate them in FL Studio.
Here's the charge beam and spiderball sounds, correctly looped in WAV. https://www.mediafire.com/?hodzzhi43149byn
Archived M2K2 Forum
Here is a csmp2adpcm file I wrote real quick, keep in mind that i developed it completely in wine, so tell me if it's missing any dlls
https://dl.dropboxusercontent.com/u/21757902/csmp2adpcm.zip
It doesn't do batch convert, but you should be able to do that easily using a simple batch command:
https://dl.dropboxusercontent.com/u/21757902/csmp2adpcm.zip
It doesn't do batch convert, but you should be able to do that easily using a simple batch command:
Code:
@echo off for /r %%i in (*.csmp) do csmp2adpcm %%i @echo on
Quote from Antidote:
Here is a csmp2adpcm file I wrote real quick, keep in mind that i developed it completely in wine, so tell me if it's missing any dlls
https://dl.dropboxusercontent.com/u/21757902/csmp2adpcm.zip
https://dl.dropboxusercontent.com/u/21757902/csmp2adpcm.zip
lol, I just wrote one too. Guess it wasn't necessary but I guess here it is if anyone wants it.
Just specify a folder on mine and it'll automatically convert all CSMP files in the folder, plus stick dspadpcm and its required DLLs in the same folder and it'll also convert them to wav for you.
attachment:
And in my usual fashion here is the source:
http://pastebin.com/F8GBFQia
If you wish to compile it, just grab GCCommon.h from bmdview2 and it'll compile fine.
http://pastebin.com/F8GBFQia
If you wish to compile it, just grab GCCommon.h from bmdview2 and it'll compile fine.
decoding /media/Storage/MetroidPrimeAssets/MP3InGameAudio/0_36E954B2225A9CD1.CSMP
sample rate 32000 Hz
channels: 1
stream total samples: 56483 (1.7651 seconds)
encoding: Gamecube "DSP" 4-bit ADPCM
layout: flat (no layout)
metadata from: Retro Studios CSMP header
samples to play: 56483 (1.7651 seconds)
Guess what guys :3
sample rate 32000 Hz
channels: 1
stream total samples: 56483 (1.7651 seconds)
encoding: Gamecube "DSP" 4-bit ADPCM
layout: flat (no layout)
metadata from: Retro Studios CSMP header
samples to play: 56483 (1.7651 seconds)
Guess what guys :3
It's technically not even an editor yet :P Need to add an interface for viewing/editing object properties and some move gizmos, among other things...
I ended up rewriting it since the version I was showing before because the backend was terrible. I think with the way it's structured now though, hopefully I can get this stuff implemented fairly easily.
I ended up rewriting it since the version I was showing before because the backend was terrible. I think with the way it's structured now though, hopefully I can get this stuff implemented fairly easily.
https://sourceforge.net/p/vgmstream/feature-requests/5/
^ Let's cross our fingers and hope :3
^ Let's cross our fingers and hope :3
If you have 3DS Max you can use the CMDL import script linked in the first post. Aside from that, no.
hmm, I could probably use some input on the editor + interface though. There's obviously going to be a need to edit a lot of different formats, aside from just rooms - models, sounds, textures, fonts, strings, whatever. I kind of like the idea of having all this stuff in one package. So say you're editing a HUD Memo and there's a field to select what STRG displays onscreen... you could click a button that automatically switches to a STRG-editing interface with the selected STRG loaded, or create a new one from scratch. Or you could click just about any object, and quickly switch into a CMDL editor to tweak materials. Stuff like that. It doesn't really seem that hard to do this stuff from a technical perspective - I'm going to end up making all these tools anyway, not that much harder to put them all in one application - but I can't really wrap my head around how it should work with the UI. Has anyone got any ideas, or am I being too ambitious/is this a bad idea/this stuff should be handled by other external tools or what?
Opening an MLVL file to open up an entire world and then accessing individual rooms from there is also definitely gonna be a necessity at some point instead of loading MREAs directly, because the MLVL contains a lot of stuff that's extremely relevant to an individual room, like layer names, file lists, connected rooms, and aether box coordinates. So basically there's a good chance the MLVL will need to be updated whenever a room file is saved, and if the program has easy access to the MLVL then it can handle all this stuff automatically so the developer doesn't need to think about it. It would also make it simple to automatically generate file dependency lists and repack.
I'm also wondering if we might end up needing our own formats for maintaining project files. I'm not sure if anyone wants to work with "384fb1ed.CMDL" or "12a811ee.TXTR" or "2328wlglkgageheahle;lhe;r.STRG". Hashing the names would make converting actual filenames to file IDs and saving game-compatible formats easy, but the reverse process - looking the files back up based on the IDs - would probably be rather difficult. Custom formats could keep track of the filepaths, though, and then they could simply be converted to the game's formats when you repack.
Also trying to think of what would be the best way to lay out the object-editing interface. An instance list like Retro World Editor had is pretty much necessary, because a lot of objects don't even have position coordinates, and can't be displayed in the viewport; so there's not really any way to access them other than from a list. It'll also make it easy to add lots of options to toggle visibility on layers/objects/individual object instances, which are pretty necessary because otherwise you get scenes that look like this.
Anyhow, I'm probably thinking too far ahead, but all the same, any input on any of this stuff appreciated.
hmm, I could probably use some input on the editor + interface though. There's obviously going to be a need to edit a lot of different formats, aside from just rooms - models, sounds, textures, fonts, strings, whatever. I kind of like the idea of having all this stuff in one package. So say you're editing a HUD Memo and there's a field to select what STRG displays onscreen... you could click a button that automatically switches to a STRG-editing interface with the selected STRG loaded, or create a new one from scratch. Or you could click just about any object, and quickly switch into a CMDL editor to tweak materials. Stuff like that. It doesn't really seem that hard to do this stuff from a technical perspective - I'm going to end up making all these tools anyway, not that much harder to put them all in one application - but I can't really wrap my head around how it should work with the UI. Has anyone got any ideas, or am I being too ambitious/is this a bad idea/this stuff should be handled by other external tools or what?
Opening an MLVL file to open up an entire world and then accessing individual rooms from there is also definitely gonna be a necessity at some point instead of loading MREAs directly, because the MLVL contains a lot of stuff that's extremely relevant to an individual room, like layer names, file lists, connected rooms, and aether box coordinates. So basically there's a good chance the MLVL will need to be updated whenever a room file is saved, and if the program has easy access to the MLVL then it can handle all this stuff automatically so the developer doesn't need to think about it. It would also make it simple to automatically generate file dependency lists and repack.
I'm also wondering if we might end up needing our own formats for maintaining project files. I'm not sure if anyone wants to work with "384fb1ed.CMDL" or "12a811ee.TXTR" or "2328wlglkgageheahle;lhe;r.STRG". Hashing the names would make converting actual filenames to file IDs and saving game-compatible formats easy, but the reverse process - looking the files back up based on the IDs - would probably be rather difficult. Custom formats could keep track of the filepaths, though, and then they could simply be converted to the game's formats when you repack.
Also trying to think of what would be the best way to lay out the object-editing interface. An instance list like Retro World Editor had is pretty much necessary, because a lot of objects don't even have position coordinates, and can't be displayed in the viewport; so there's not really any way to access them other than from a list. It'll also make it easy to add lots of options to toggle visibility on layers/objects/individual object instances, which are pretty necessary because otherwise you get scenes that look like this.
Anyhow, I'm probably thinking too far ahead, but all the same, any input on any of this stuff appreciated.
Here is a modified version of vgmstream that supports CSMP (uncompressed)
https://dl.dropboxusercontent.com/u/21757902/vgmstream.zip - Source only
For linux, just open a terminal in test and type make, as long as you have vorbis and mpeg123 installed it should compile fine.
https://dl.dropboxusercontent.com/u/21757902/vgmstream.zip - Source only
For linux, just open a terminal in test and type make, as long as you have vorbis and mpeg123 installed it should compile fine.