 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| DJ Bouche Posts: 102/111 |
The data is the raw interpreted music data, not compressed in any way as already stated above. Zelda 3's music is in fact in 3 banks (being an older game, similar games using N-SPC at the time also practiced this), newer games tended to use only a few songs that would stay in the same location in the SPC-RAM, and one other song that would be uploaded to the SPC only just prior to playing when needed (for example, the main level type music), SMW2: Yoshi's Island uses this practice. In order to utilise more of the SPC-RAM you'll have to rewrite the music changing code on the S-CPU side of things to dynamically upload single songs, as well as re-organise your music data. This requires assembly hacking knowledge and SCPU-SPC700 communications knowledge, and was originally a key part of a new music changing engine I was trying to implement years ago in the newer N-SPC hack for SMW.
But yes, the addressing in the Z3 music editor itself refers to the SPC-RAM. While on the topic of N-SPC, how goes the disassembly, Math?  |
| Yoronosuku Posts: 683/1239 |
There's no compression -.- game uses N-SPC and all the data is present as-is, raw hex. If you mean the samples are compressed, I wouldnt so much call BRR a compression so much as an encoding (or maybe it is a compression, but we're talking about the data itself right?) Theres no funny compression going on. As to answer the question, you can repoint the data anywhere in the ROM as long as the game still knows to upload from the new area in to SPC memory. If you go over the SPC memory limit, stuff will break. |
| MathOnNapkins Posts: 663/1106 |
In moving it from the S-CPU to the SPC there is no decompression. There might be some bit shifting and expansion on the SPC side, I could check on that. But I would hardly call that compression. |
| Euclid Posts: 46/83 |
gee read the dates, it's 2 year old info
When i first looked at the data it doesn't seem to fit the hex values in HM (like change a note changes more than one hex value), which is the reason why i think it's compressed. |
| d4s Posts: 77/98 |
Originally posted by richyawyingtmv Originally posted by richyawyingtmvOriginally posted by MathOnNapkins :> |
| richyawyingtmv Posts: 228/294 |
Originally posted by MathOnNapkins Aha, ok. Thought so. Orochimaru said he had heard it was, and I went with that. Guess he was wrong though. |
| MathOnNapkins Posts: 662/1106 |
Uh... no. It's not compressed. |
| richyawyingtmv Posts: 227/294 |
Originally posted by Euclid Apparently, the music data is compressed. Correct me if im wrong, but HM decompresses it so it can be edited, then it recompresses the data before saving to the rom. |
| Euclid Posts: 45/83 |
z3 has 3 "banks" of music data, one bank is loaded into the game at specific times, you can tell what songs are in which "bank" in the HM music editor.
but What i find strange is all the song data is stored in less than 64kb of space in the rom, I'm guessing there's some compression going on there but who knows. |
| d4s Posts: 76/98 |
Originally posted by richyawyingtmv yes, but read on. Originally posted by richyawyingtmv the limit here isnt rom space, but the spc work ram. it only has 64kb of ram, so youre probably restricted to that for one song with the z3 music engine (and basically 99% of all snes music engines aswell, for that matter). I have never looked at how z3 does the music, but it may be entirely possible that it even has ALL songs loaded into spc-ram all the time, which would limit your available space even more. if thats the case, you'd have to write your own loader that uploads individual songs during gameplay, which would be pretty hardcore for someone without assembler programming knowledge. better ask mathonnapkins, i think he's the most intelligible person around when it comes to z3. if z3 loads songs individually, you'd have to find the songs in the rom. there'd be a pointertable pointing to each of them. you'll then have to move the songs somewhere else and update the pointers accordingly. these are just some wild guesses of mine, havent had a look at z3 for over 2 years. |
| richyawyingtmv Posts: 226/294 |
Over the past month or so, I've been messing around with the music editor in Hyrule Magic - basically replacing the music in the game with other music - for example, I recently replaced the dungeon theme with the Zelda 2 palace theme.
The thing is, there is a bit of a space issue. If I expanded the rom, would I be able to re-point the music data to be written at the end of the rom? I've already tried doing this using Lunar Expand and the CallLoop function in the HM music editor (which basically repoints the music data), but I cant input an address larger than 4 bytes to repoint the music to - eg. $FFFF is the limit. The free space at the end of the rom after being expanded starts at $100210. I may be doing something completely wrong here though - I havent worked with a hex editor for years. Another thing I've been trying out is replacing the instrument samples used in the music with samples from other sources (eg. taken from other games, recorded myself from live instruments). This works, but I am restricted by the limitations - most samples have to be very short in length as there is a space issue. I'm wondering, is there any way to, just like what I want to do with the music data, repoint the samples to be stored at and accessed from the free space at the end of the rom after being expanded? Or is this impossible with the music engine used in Z3? If possible at all, this would greatly improve the music I can achieve with the editor. Thanks in advance to anyone who can help me. |
