DeathBasket

Testing some stuff with SharpOcarina: Textures are off, I know, that was an error with Sketchup while triangulating and I didn't bother to fix it.

Yes, it turns out SketchUp is adding a prefix to each group name, I didn't realise. Also, the waterbox room data I promised. Instead of: 0000qqqq It seems to be something like: 00rrrrrr where r would be pppp00 || 00qqqq and p would then be room_number << 5 so a waterbox in room 0xD would look something like 0001A000 Edit: The saving error is fixed in that one, thanks.

I get errors when trying to save binary or inject into the ROM: In a later version would it be possible to have group names displayed instead of Mesh1, Mesh2, etc.? It's not important but it'd just be quicker for selecting the right part of the map to edit. Selecting the right rooms for waterboxes is definitely a must for the next build, so I'll probably take a look at that at some point.

haddockd, if you're using the ruby plugin then unfortunately it ignores groups and SharpOcarina doesn't seem to display anything if no groups are present. You can fix it by opening your .obj file and writing "g (something)" at the top but since everything is in one group you won't be able to assign different collision types or other things to specific parts of the map. I don't think there's anything you can do without making your own version of the plugin or just using a different program.

The XML is generated by SharpOcarina. You'd create a new scene then load your obj file as the collision and room models and to generate an XML you would go to File > Save Scene. It is not actually needed, just a way of saving your setup so that you could continue working on it at another time.

Collision fiasco definitely seems like the right choice of words here. All the errors are tiny things that it's difficult for anybody to notice really... I think I've got a proper fix this time, no guarantees though. ... nf[0] = (float)(dy[0] * dz[1]) - (dz[0] * dy[1]); nf[1] = (float)(dz[0] * dx[1]) - (dx[0] * dz[1]); nf[2] = (float)(dx[0] * dy[1]) - (dy[0] * dx[1]); /*calculate length of normal vector*/ nd = Math.Sqrt((nf[0]*nf[0]) + (nf[1]*nf[1]) + (nf[2]*nf[2])); for (i = 0; i < 3; i++) { if (nd != 0) uv[i] = nf[i] / nd; /*uv being the unit normal vector*/ nf[i] = uv[i]*0x7FFF; /*nf being the way OoT uses it*/ } /*distance from origin...*/ dn = (int)Math.Round(((uv[0] * p1[0]) + (uv[1] * p1[1]) + (uv[2] * p1[2])) * -1); if (dn < 0) dn += 0x10000; Helpers.Overwrite16(ref Data, pos + 0xE, (ushort)(dn & 0xFFFF)); for (i = 0; i < 3; i++) { ni[i] = (int)Math.Round(nf[i]); if (ni[i] < 0) ni[i] += 0x10000; Helpers.Overwrite16(ref Data, (pos + 8 + (i << 1)), (ushort)(ni[i] & 0xFFFF)); } Obviously you'll need to define uv as new float[3]. This should produce correct results without having to rewrite the function completely unless I've made a mistake somewhere...

xdaniel, this is part of my collision fixing code (written in Delphi because I'm more familiar with it): //get two vectors in the plane, head to tail d[0].x := v[0].x - v[1].x; d[0].y := v[0].y - v[1].y; d[0].z := v[0].z - v[1].z; d[1].x := v[1].x - v[2].x; d[1].y := v[1].y - v[2].y; d[1].z := v[1].z - v[2].z; //use the cross product to find the normal vector normal.x:=(d[0].y * d[1].z) - (d[0].z * d[1].y); normal.y:=(d[0].z * d[1].x) - (d[0].x * d[1].z); normal.z:=(d[0].x * d[1].y) - (d[0].y * d[1].x); //find its length length:=sqr(normal.x) + sqr(normal.y) + sqr(normal.z); length:=sqrt(length); //now find the unit vector if length <> 0 then begin unitnormal.x := normal.x / length; unitnormal.y := normal.y / length; unitnormal.z := normal.z / length; end; //Zelda uses 0x7FFF as 1.0 so... normaldir.x := round(unitnormal.x * 32767); normaldir.y := round(unitnormal.y * 32767); normaldir.z := round(unitnormal.z * 32767); //now find the perpendicular distance from plane to origin distance := round(((v[0].x * unitnormal.x) + (v[0].y * unitnormal.y) + (v[0].z * unitnormal.z)) * -1); //we have everything calculated now, time to write it I tested it with Hyrule Field's collision and its output was exactly the same as an unedited version, which is a good sign. Source code and executable here if anybody wants it. Usage: collisionfix (scene file) The problem with your code seems to be this: for (i = 0; i < 3; i++) { if (nd != 0) nf[i] /= nd; nf[i] *= 0x3FFF0001; nf[i] = (float)Math.Sqrt((double)nf[i]); if (ni[i] < 0) nf[i] *= -1; } Which should just be: for (i = 0; i < 3; i++) { if (nd != 0) nf[i] /= nd; nf[i] *= 0x7FFF } Or at least that's what my algorithm does differently. It may still be down to a rounding error somewhere else though so I'd advise you to check over the code a bit more. Edit: more good news, I ran this with a map created with SM642Z64 and the map now seems to be crash-free.

Ah, those could be the scrolling images from maps with static backgrounds and more than one camera angle then. I noticed that before if I changed, say, the Kokiri shop's background, the second background that appears when buying something would still appear despite not seeming to be in the map file at all.

I'm not entirely sure about samples but pointers to sequences and instrument banks are all relative to the start of their files and therefore wouldn't need changing. The files themselves though (Audiobank, Audioseq, Audiotable) have their offsets hardcoded in the machine code around 0xB5A4C0, which is a pain. Also, iirc, the JFIF images' pointers are relative to the start of the map they're stored in and they do not appear in the DMA table.

True, I'm just more used to writing stuff like this by hand where the order doesn't matter too much. We would need to add some extra brackets so that it executes correctly though: dn = (int)( ((nf[0] / 0x7FFF) * p1[0]) + ((nf[1] / 0x7FFF) * p1[1]) + ((nf[2] / 0x7FFF) * p1[2]) ) * -1; This way we can avoid having C# see it as nf/(0x7FFF*p1). I think I'll try rewriting the whole algorithm from scratch so I can pinpoint any errors that are still there.

Have you tried with no actors/objects present? There shouldn't still be a problem with the collision since normals and distance are calculated correctly. If there is, it could be to do with using (int); I don't know if that rounds or truncates (I know nothing of C#) but you may need to try using math.round or math.ceiling. If there's still a problem then it could be anything but we'll probably find it eventually.

So I only have the free version of SketchUp and apparently it ignores all groups when exporting to .obj (this plugin). Does anybody know of a way to preserve all of the groups while exporting so that I can use SharpOcarina properly, or do I have to go and get some other program?

I can't spot anything wrong with the algorithm; the normal vector is calculated correctly (I do find it odd that 0x8001 is -1.0 instead of 0x8000 but that's just me). fffffffffuuuuuuu I keep reading stuff wrong so I'll go and test this again I should stop going to sleep at 3AM Okay so everything in the algorithm is correct except this part: ...(nf[2] / 0x7FFF) * p1[2]) The yellow bracket should come just before the red one, so that it looks like: ...(nf[2] / 0x7FFF * p1[2])) If it were me, I'd rewrite that line as: dn = (int)( (nf[0] * p1[0] / 0x7FFF) + (nf[1] * p1[1] / 0x7FFF) + (nf[2] * p1[2] / 0x7FFF) ) * -1; I think C# does multiplication first; if that's the case then the original line would have produced terrible results anyway because it was written to be executed in the order it appears (ex. nf[0]/0x7FFF, then result*p1[0]).

Looks like we'll be getting this in Europe too. I might actually pre-order this game after all...

I'm not sure what's causing it but sometimes the camera speed will randomly increase. Also files (at least for the demo) seem to be loaded from the program's directory rather than the XML's. Criticisms aside, I can't wait to try this tool out properly.

lolwat that's even weirder than the time Diglett got stuck up a mountain in Pokémon Mystery Dungeon

From what I can tell the 'bb' you mention in the flags entry of the scene table is used as an index for a list of addresses at 0x8012A3A4 in RAM. The addresses are then loaded and jumped to and the code there decides which textures to load. I haven't looked at it in much detail but the Deku Tree's entry (0x13) will check whether it's day or night (word at 8015E670) and then use that information to load the right texture for the entrance. The lava in Dodongo's Cavern changes texture every two frames (I think), based on a counter at 80223E04. We could make use of this by changing the texture pointers but it doesn't look like we can do much else at the moment without having to write an assembly hack for it.

8111FB40 0005 The value at that address is loaded as a halfword so the gameshark code needs to be 16-bit, otherwise it's loading 0x0500 which is why time was speeding up for you.

Just disable any jumps to the actor spawn function in the bosses' actors that are used to spawn hearts. You'll know which ones they are because a2 will be set to 95 (0x5F) a few lines before the jump.

Here it is: http://www.mediafire...v9j71lhjt0iwia4 Resources are included in the download for those who want them. I have only found one bug so far. Holding down A when the main menu/results/game over screen is supposed to appear will cause them to be skipped, you'll go straight to the Deku Tree boss and it won't reset any of the data. It could easily be fixed by just changing a bit of the code around but I'm not bothered about it right now. Anyway, have fun and maybe post some of your results. My attempt:

Thanks for the support guys, I appreciate it. Update time: I've got all the information together now for when I'll trigger the timer on/off and tomorrow I'll work on actually implementing that. I've also decided to try and make a proper results screen instead of just displaying the final results like the screenshot I posted. Hopefully I'll do a similar thing for a game over screen too. We'll see how it goes. I'll tidy it up (and comment) a bit and then probably put it in a folder with the patch/other resources for when you download it. Thanks. I wouldn't be doing stuff like this if you didn't get me started on assembly hacking. http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif I'm not really bothered about minibosses since the line between miniboss and normal enemy is rather ambiguous. Timed enemy or puzzle rooms might be something to think about though. Maybe something like the Gerudo Training Grounds but with a different reward depending on how long you take to finish.

Since when did Nintendo care, especially about a Nintendo 64 game? There are loads of major hacks going on for other games too and I've never heard of Nintendo shutting any of those down. Regardless, my opinion is that we should be able to make all the fan material we like as long as we're not making money from it.

Zeth you made me do this:

Something I started working on yesterday. You will fight each boss in a row and the times you take to defeat them will be recorded so you can view them when (if) you finish. I currently have the settings screen working (replaces the map select) and the timer and difficulty levels are working too. The next thing I need to do is find a good place to trigger the timer (maybe when the boss music starts?) and I'll need to make a few modifications to the warp actor and then I'm basically done. Screenshots: Here's a video preview: DOWNLOAD