DeathBasket

The max tempo is 255 in Zelda but hardly anything will be that fast. Errors in tempo that I have seen before were because of the MIDI file setting a different amount of 'ticks per quarter note' but that was fixed a long time ago. My guess would be that the MIDI file you used is setting the time intervals using frames per second before setting the tempo, which InstEd will not understand and just set to some default value. The other case is that the tempo was not set at all and was assumed to be 120 (I think, that is the default for MIDI files anyway iirc). For now you could try changing the tempo in the files that were output yourself, I need to go back over the code at some point and see if I can improve the way this is being done because if you find problems with it, it is inevitable that someone else will sooner or later.

I'm wondering if you've made any progress on this? I understand you're probably busy, what with school/college and things starting and whatever, I'm just curious because I haven't got everything set up to test things out myself.

Track 0 in the MIDI file contained no usable data since it is usually used only for tempo and text messages. The track 0 mentioned here is referring to the first 'note layer' found in each channel. If you could upload the files I will take a look and see if I can find any errors.

I just hope it isn't too difficult to use, seems that you know what you're doing with it though, which is good. By the way, if you're recording audio from the game, you should use Nemu since the sound is much smoother due to it not clipping every time the framerate drops.

It seems the jpeg image 'settings' folllow a format something like this then: 0082xx00 <- x is image number? yyyyyyyy <- image pointer 00000000 <- constants from here? 00000000 014000F0 <- image dimensions? 320x240 is the size of all jpeg backgrounds in OoT 00020000 <- scale? is OoT run in 640x480 resolution? 00000000 Other maps will need to be checked out before this can be confirmed though. Numbers after the image's pointer could well be where it is to be drawn on the screen (top left at 0,0 and bottom right at 320,240) but I don't have any way of testing anything at the moment.

Well I would guess that the word at 0xA8 gives the number of jpeg images, the word at 0xAC is where their entries are. Each entry looks to be 0x1C bytes long, they point to the images and maybe determine when each one should be loaded. Could you check this out for the back alley maps?

That might be a good feature, actually. I'll think about how best to implement it.

Do you mean doing everything in one go? That would be possible but I don't see any advantage in doing it because the current method allows you to keep track of which samples you've imported so you don't end up importing the same ones multiple times.

http://wiki.spinout182.com/w/Maps_and_Scenes#Mesh_Header It would look something like 01nn0000 xxxxxxxx yyyyyyyy ... nn would be the number of display lists to load and xxxxxxxx is the location of the display lists in the map file. yyyyyyyy is the location of the jpeg image in the map's file, I can't remember what the data following this does though, but according to the wiki it is 0x14 bytes long. I can't remember if I have notes on it somewhere...

Sure. The easiest way is to use the instrument ripper to get the instrument you want from one of the supported games (see readme). That'll output a folder with a name like 'set03inst01' for example. You can rename this if you want, but you must also rename the instrument data file in that folder to the same name as the folder, the program relies on the names being the same. To import the instrument, you need to create a folder in the program's directory named 'user', and copy your instrument's folder there, so you'd have something like '...insteduserset03inst01'. Now when you use the program, following this example you would type 'set03inst01' in the user defined instrument edit box and that would add your instrument's data to the set. For instruments that do not come from Ocarina of Time, you will also need to import the sample files that the instrument ripper would have spat out. You can do this using the sample inserter option, which will tell you what the sample's new pointer will be after adding it to Audiotable. Make sure you write it down because you will need it. Open up the instrument's data file ex. 'set03inst01.i' in a hex editor and search for the lower three bytes of the sample's original address, which is in the sample file's name ex. if it was 'sample00123450', you would search 0x123450 in the hex editor. The reason you only search the lower three bytes is because some samples have the uppermost byte set to some unknown value, you can just change that to zero and then the rest to your new pointer. Once you have inserted the sample and fixed its pointer you can add the instrument to your set the same way as I described above. Note: you need to fix the CRC after using the sample inserter. The method for percussion sets (instrument 127) is basically the same, but you must type the name in the 'user defined percussion set' edit box instead. As far as I know only one percussion type instrument can be used at a time. If you want me to provide a tutorial video or more information, let me know and I will. If you want to import samples from games that the instrument ripper doesn't support, that is a bit more complicated and I don't really want to do an in-depth explanation unless anyone really needs it.

mml2m64 is beyond irrelevant. As long as you can produce a MIDI file suitable for Zelda* (see below) then this tool has everything you need to be able to convert and import it into the game. * To make MIDI files that will work well in Zelda, follow these guidelines: monophonic channels no notes shorter than a hemidemisemiquaver except semihemidemisemiquaver triplets since those are the shortest length available (length of 1) write your MIDI files with instruments available in Ocarina of Time don't increase pitch bend range beyond 12 semitones, that is the highest range supported in Zelda as far as I know. make sure continuous control changes (ex. increasing/decreasing volume) do not happen on time intervals smaller than Zelda can use (see second point) The reason semihemidemisemiquavers cannot be used when their triplet form can (you might have noticed) is because they would have a length of 1.5, but length must be an integer, so after rounding the sequence would end up being inaccurate with things going slightly out of time.

Tool has been updated again (now r5). This time I added most (all?) of the remaining instruments from OoT, including percussion sets. I don't really plan to add anything else to this so you can take this to be the first complete release in terms of features, unless anybody has any suggestions for things they want to see added that are doable. There's bound to be some bugs here and there so if you find any be sure to post them and I'll see what I can do to get them fixed. By the way, if anybody knows what that instrument is that I've labelled 'What' (it's used in the Goron City music), let me know and I'll give it a proper name.

Yes, that seems to be repeating too much, which you notice when standing far away or viewing the faces from an angle. I will probably double the width of the texture so it doesn't repeat too much, mirroring could also help so I will try that too and see which is the better option. I haven't pinpointed that yet, may be an error with the graphics plugin as the shadows are drawn on Link's feet but not the surfaces. I know that they are sometimes affected by the environment lighting though.

I don't ask for assistance with this because my own work on it is very inconsistent; I would not think it fair to have people helping out when I as the project's leader would go months and months without doing anything at all. The past versions have all failed because of a lack of proper planning and documentation which lead to me having no idea what was what inside the ROM and ultimately not liking having to work with it. This time around everything is much more organised and with all the tools available that were not before I don't even need to keep (many) files that are in Zelda's formats, which makes everything a lot more bearable and less confusing. If this ever gets cancelled I would of course release all the files since I plan to do that when the whole thing is finished anyway. This will take a very long time to complete but this time around I do not see any reason why it won't happen. Anyway, I loaded up my map in the game to get a proper idea of the size and how it'll look. I really love SharpOcarina... There's still some texturing and UV error fixing to be done before I can start adding proper collision data, actors and such but this is actually coming on pretty well.

Thanks. I'm using SketchUp, yes; I finally seem to be getting along with it or at least I've learned to live with it, which is more than can be said for other modelling programs I've tried out. The only drawback with it is texturing (as I'm sure you know), but once you get to grips with the different options available it's simple enough (though very time consuming) to get everything looking nice.

Just so you know this project hasn't died, here are some shots of the new Hyrule Field map I'm working on. I'm moving again very soon so I don't know if I'll be posting many more updates for a while, especially after my lectures start.

I'd be willing to chip in but since I have a really limited knowledge of C, C#, etc. and not much time or motivation to put in to learning these (not really languages I need to know for my studies), I never feel like I'd be a great help.

Any other problems with normals would probably be from the obj exporter (which are you using by the way?) since they are being read from the obj file. It's possible we could come up with a way of calculating them based on reading the triangles the display list draws but if the exporter is getting them right then that's really unnecessary.

Yes, just download the source, change those lines and compile. Normals simply define the direction a plane (in 3d space) is facing. In this case they are used to update the shading; if the normal points towards the Sun's (light source) position then the triangle is highlighted, if it points away then it is darkened, etc.

Could be the normals. I get this a lot too and my maps don't have 'broken' polygons. What version of SharpOcarina are you using? From what I can tell by looking at the source here they do not seem to be correct. I am not sure about that though; I don't know if the normals have been changed since being read from the object file but since they are signed numbers should they not be multiplied by 127? EDIT: Yep, that seems to make my map look a lot nicer. For comparison: Note: the first screenshot was from an old version where textures were still darkened, sorry... Still, these were both near enough the same time of day so you should be able to notice the difference in shading; the second image looks a lot more natural.

Thanks, I didn't realise the link had not updated. Anyway, I've put a new version up now with a few more features - you can now rip instrument/sample data from OoT, MM and SM64 and I also added a sample inserter. This makes adding instruments so much quicker and easier. Percussion sets (instrument number 127) are not currently supported but I will add that at some point in the future. Edit: New version, I found and fixed two bugs with the sequence builder aspect.

Nice, though there's something strange going on with the item amounts... If you can, you should fix this, the spawn position and string position before releasing this.

The new version is now up (link in first post updated), the sequence converter and inserter are included in the program now. There shouldn't be too many problems (none that I know of yet); pitch bend may still be a little out though, I don't remember what OoT's range is so I just guessed. I made this using this tool to create the instrument set and the sequence: I plan to add some more instruments to the tool now when I can be bothered, and maybe add the sample inserter if I decide it really has a use.

Sequence converter is mostly finished now, I need to change a few things though. Here's a look at some of the output so far:

Progress: The program is now outputting files that are basically a text version of the format Zelda uses. Now I just need to write the part that will convert those to the actual data, which shouldn't be too difficult so I'm hoping to have it done and be testing it out at some point tomorrow. Seems to be working well so far, I tried a few random MIDI files I found and the only problems seem to arise from files that are using chords, which shouldn't be a problem in files designed for use with the game anyway. I will post some examples of how the sequences are sounding in-game once I've finished the converter, the next release will include it and will come shortly after once I have the sequence inserter finished.