RIP Konami 1969-2015
- User Lists
Showing Visitor Messages 31 to 45 of 59
November 29th, 2012 02:04 PMJambo51OK, implemented those changes and I'm getting sensible sounding noises out. If I could just understand and parse the actual noise behaviour (ie, how it chooses what sound it makes), I'd be done.
Oh well, in any case, I'm about to move on to assembly into the Gen 1 and 2 ROMs.
Got any preferred formats for that? I was thinking something that looked a bit like XSE in terms of the music commands (since the music is technically a script, when you think about it).
So an example music command would be:
Note C 4 12 7 1
Where the parameters stand for:
C = Note to play
4 = Octave
12 = Length
7 = Velocity
1 = Fade
The reason for so many parameters is that asking a user to understand the Frame Delay command is asking a bit much, IMO, so if I have it in each note command and parse it correctly, I can add it in on the fly when necessary.
Also, incidentally, brilliant Profile Image! :D
November 25th, 2012 10:24 PMJambo51I can tell you that E3 determines the noise pattern on Gen 2, although I'm unsure as to how it actually defines anything, as it points to a bunch of numbers which carry no obvious meaning. As for the rest, I'll see about implementing the changes at least, so that the notes exported make sense.
November 25th, 2012 01:32 AMJambo51Well, that pretty much covers the full gauntlet of questions for Gen 1, as (distortion and noise notwithstanding) I seem to have very accurate reproductions of the music coming out now. There are some issues with the rising notes, but I'll look into them more accurately at a later date.
November 24th, 2012 08:34 AMJambo51Fair enough, I worked off that assumption, and it seems to be working. Now another question, do you know where the headers for the songs in this region (22330-23F51) are? They're missing from any known list, and they would appear to include the battle themes (given that those are absent from what my tool can export currently).
I have tried to find them, with no luck, so I'm a bit bemused.
November 24th, 2012 07:21 AMJambo51Don't suppose you know the "max" value of it? I assume it can't be 0, for obvious reasons, so does it just operate from D1 - DF?
November 24th, 2012 07:01 AMJambo51Frame delay defines how long each "tick" of the music actually takes. It's normally set to 0xC, but can be changed to lengthen/shorten a note's duration. With a note length of 0 and a frame delay of 0xC, the note lasts 12 (0xC) frames on a GBC, or W06 on GBA (due to the halving effect).
In GSC, there's a command which directly modifies this frame delay to allow for longer/shorter notes, and I was wondering if there was an analogous command on RBY, since some notes don't play at the correct rate on export with my tool, and I assume that with the systems being so similar, there will be a command which modifies this value somewhere.
November 24th, 2012 02:59 AMJambo51I don't suppose you know what the "Frame Delay" command is on Gen 1? It's command 0xD8 on GSC and has a format of D8 [Frame Delay] [Note Volume].
The other question has to be what does command E8 in RB and presumably Y do? It doesn't appear to actually take any parameters, so it's somewhat confusing. It's just there...
November 23rd, 2012 03:57 PMJambo51Ah, it turns out the off notes are caused by incorrect note alignment in the definitions.ini.
November 23rd, 2012 03:51 PMJambo51VG = VoiceGroup
It's already heavily reliant on an ini which comes with it to define what each command does, in terms of the Pokémon music engine.
The thing is, even if the Pokemon engine is unusual, most other engines out there have to have the same end effect in terms of what commands do, so it should be entirely possible to modify the code to suit other games.
In other related news, I rewrote the code to support the RB style (direct references) as well as the GSC song table approach. Using this, I was able to get a recognisable Pallet Town out of the ROM, though it's pitched too low (Probably something to do with the different note structure, given that the code's written around note C being in one specific place, which it no longer is). Other than that, it runs reasonably well!
November 23rd, 2012 01:38 PMJambo51OK, a bit of a development on the Gen 1 music front. It turns out they (Red and Blue, at least) don't use music tables (as in a list of pointers to song headers), and in fact they have collections of song headers grouped together in at least 2, if not 3, sets of locations in the ROM. (Quite how these songs are referenced in game, I don't know, but I digress).
I say 3 as some songs are missing from these headers AND there is a 3rd set of the triangle waves, the other sets of which follow directly on from the headers in question.
Now, the problem is, detecting which style any given games uses will be awkward, and it will be even more awkward if the game uses a different style altogether.
This is, quite frankly, a disheartening discovery (for obvious reasons). I can probably get around it by "creating" a song table in my tool's memory which it could use to navigate the songs, however. This could be complex, especially since I'll have to make it work for an unknown (at compile time) number of "table fragments". I would also need to take into consideration the lack of any obvious boundaries to the table fragments.
However, shy of writing a brand new tool for them, I can't see what else I can do.
Other than this, I have added code to my tool which generates a VG for the ROM you have open, and "rips" the relevant triangle waves along with it. In this way, I can ensure that (if the triangle wave location is known, then they can be ported to gen 3 easily).
November 22nd, 2012 11:02 AMJambo51Yeah, I would appreciate knowing how you used those commands to do the pitch bending, since it looks very much like I am going to need them for some of the songs in GSC and RBY.
Other than that, and the ever annoying Noise tracks, the songs are sounding very, very accurate now.
November 21st, 2012 03:04 PMJambo51Well, 96 / 0 would be undefined, so I made it act like z = 1 under that circumstance IF ANF ONLY IF there is still modulation to be run. (Hence my reference to XX and Y not being 0 as well).
I haven't yet investigated this distortion command beyond looking at the basic structure. It doesn't help that I'm unsure of the effect that the command will have, which can't be said of any other command I have investigated so far (except from the "Tone" command, I still don't know what that does).
Based purely on what I can hear from the evolution jingle, it appears that distortion is somewhat analogous to pitch bending on Gen 3, but don't quote me on that.
November 21st, 2012 06:37 AMJambo51An addition to that, what I have discovered is that if z = 0 (with respect to that modulation document you sent me earlier), AND xx != 0 AND y != 0, then LFOS = 96, otherwise, LFOS = 0.
It turns out that this was why the modulation in the rocket hideout was incorrect, as the LFOS wasn't correctly set because I hadn't implemented this rule.
Now, this weird distortion you reference, I already know of one song in GSC which would appear to use it (the Evolution jingle) and the command for this distortion (in GSC at least) is E0.
E0 XX YY (NL) - Unsure if NL is part of the command. (Where N = Note, L = Length as defined elsewhere)
distortion x, y(,nl) (in that format you previously mentioned)
However, I currently have no understanding of how this works, beyond the fact that it takes 2 (obvious) parameters, though something I remember seeing once indicated that it actually took 3 parameters, which may mean that the distortion command also includes the note which has to be distorted as well.
November 20th, 2012 04:58 PMJambo51This is just note velocity (v???). I treated the overall volume (VOL) as a constant 119, since there was nothing else to define it in the triangle tracks. I'm talking specifically about music exported by my tool. If it's using the max volume, it sounds fine, but both of the other 2 sound far too quiet.
The modulation is fairly constant, yes, in the Rocket Hideout. I have discovered it's due to a misinterpreted LFOS. The LFOS isn't set, for whatever reason, I set it manually and it was far more accurate.
I have also found that the modulation depth needs to be approximately halved for it to sound even vaguely correct, based on some experimentation. I will put this down to the GBA's system of having 96 ticks in a measure, instead of the "normal" 192.
This isn't entirely surprising to me, since I already know that you need to similarly half any DS music's Modulations when importing into a Gen 3 ROM. I will assume it's a quirk of the Sappy Engine.
November 20th, 2012 11:44 AMJambo51Well, with the modulation, I applied what you said, and for most songs, it comes out very accurate, but with the Rocket Hideout (very high modulation rate and depth), it just sounds all wrong.
As to the triangle volume, I'm still using the 127, 127/2, 127/4 model (albeit with different numbers, since I keep raising the volume to try to find an accurate point).
I think I currently have it as 1 = 127 * 0.8, 2 = 127 / 1.1, 3 = 127 / 1.2, and yet, it STILL sounds FAR too quiet in most songs. I can't understand the lack of accuracy with it, tbh, it's bizarre.
Do remember, it was a whole new music engine. That necessitates the loss (or changing) of some of the previous features. The reason that the emulation of actual GB carts works so well is that it actually uses the original music engine which is built into the carts themselves. Don't misunderstand, the GBA is physically capable of emulating the music perfectly, it's the sound engine which isn't.
A music table is (in Gen 2, at least) a simple list of pointers to the music headers. In Gen 3, it has extra data which tells the sappy engine what type of song it is. Used to put sounds/fanfares into a different memory location, I believe, so they don't interfere with the "main" songs.
If there is no table in the Gen 1 ROMs, we'll have no choice but to put all the pointers in the ini, sadly. I can't find one, but I'm assuming it follows the same format as Gen 2's. Problem is, I tried "pointerifying" one of the header offsets, and found no reference to it anywhere in the ROM, so I'm bemused.
Thing is, GBC pointers look nothing like a GBA pointer, and they can be confusing to get to grips with.
I'll give you an example: Say we want the pointer to 0xE906E (which happens to be the music table location in GSC (USA))
First, you divide it by 0x4000 and take the INTEGER DIVISION (so ignore anything after the point) result. This number is known as the ROM Bank.
In this case, it's 0x3A.
Now, subtract (0x4000 * 0x3A) from 0xE906E -> you get 0x106E.
Now ADD 0x4000 to that number and then reverse it: 0x106E + 0x4000 = 0x506E
Reverse: 6E 50
Finally, append the ROM Bank to the front of it and voila, one GBC ROM Pointer: 3A 6E 50
Confusing, huh? It makes sense in terms of the GBC hardware though. They had to make use of extremely limited memory, and as such, loaded chunks of 0x4000 bytes of the ROM into memory as and when it was needed. The memory location this started at was 0x4000, explaining why there's an additional 0x4000 added to the pointer.
It actually references memory location 0x506E in memory when ROM bank 3A is loaded. Make sense?
The last 30 visitor(s) to this page were:
This page has had 1,509 visits
All times are UTC -8. The time now is 06:41 PM.