DeathBasket

I loved the levels in Sunshine and it would be great to see some more like those, but Galaxy is still my favourite Mario game. It would be really nice to see another game like Galaxy but just with more open levels.

It's been about 10 - 15 C around here lately but that's probably going to drop below zero by mid December. It's pretty cold inside too because nobody wants to turn the heating on (it costs money).

It would definitely be nice to see a sequel. I would help out whenever I have some spare time but that's becoming increasingly less often at the moment...

Oh my, I am laughing so hard! 6 trololos at once... that has to be some kind of record.

Wow, SayakaGL, SharpOcarina, a DS game, an N64 demo, a NES emulator, a GB emulator... is there anything you can't do?(!)

Happy birthday, spinout. Have a nice day.

I thought beta quest was just cutscene maps with the cutscenes themselves disabled... I got the same thing to happen when messing with exits and cutscenes a while back.

Well if it was cancelled I'd just be £50 up (that's food for a month!). I'm not really that fussed about the game and I only pre-ordered it because I was bored; I won't even have access to a Wii until December anyway.

Y R Y X- Y Y- R L-- ? An ocarina song I came up with ages ago. I'm not sure if those are the right notes because I'm still more used to the N64 version. Anyway, it should be played in a 3/4 time signature and a - means hold the note for an extra beat.

I'm moving into my new house tomorrow so I'm going to be away for a while (internet is not set up). If anybody needs me for anything, leave me a PM and I'll reply when/if I get the chance.

I find that SketchUp does everything needed for modelling OoT maps except the texture mapping, which is almost always terrible on any geometry that isn't a box or flat surface. I like some of the features 3DS Max has but it takes a lot longer to create maps and is much more difficult to use. I think I'll be sticking with SketchUp, at least for now.

I was suggesting using Nemu just to find the right places to start writing the code but of course the final version of the hack would be a modified Link actor which you'd do in a text editor. If you're serious about this hack then you should start reading up on MIPS assembly code so that you can understand exactly what spinout's hack does and how to implement something similar in MM.

Those are the RAM addresses, use Nemu's debugging tools to view and edit the code. I don't have the ROM addresses right now but they wouldn't be of much use at the moment anyway.

80763754 is the address of the code that handles the controls. around 80753130 is the code that spawns Tatl. I couldn't get it to spawn Link properly though (wrong variables?), it'll either crash or he just doesn't show up. I might look at it properly tomorrow.

http://spinout182.com/4player/ I might not help directly with the hack (depends on what time I get) but I'll see if I can find some of the information you'll need. What version of Majora's Mask are you using?

I know, crazy isn't it? I'm just used to writing things more accurately and I end up trying to apply that in programming too, but with integers this small it's pretty insignificant how you do it I suppose. Anyway, at least we know why some textures were getting darkened now and how to fix that.

True, but if something had a value of 7 then a bit shift would make it zero when it should actually be closer to one (0.8...). That probably shouldn't bother me as much as it does... You'd also not be able to get a pure white if converting back this way since you'd get 248,248,248.Rounding errors don't matter too much here since the conversion is only one-way. I don't see why somebody'd want to create a texture, convert to this format, convert back and then convert again. Regardless, removing the right shift in the code as I said earlier will output textures that look fine and is simpler than my way of doing it so is probably the one that should be implemented. It is, I just have a background in maths and not programming so... that's just the way I do things I suppose. Can't really be bothered right now. I probably wouldn't be able to tell the difference between that and the way I'd do it but... maths OCD I guess. SanguinettiMods: you probably don't notice the darkened textures on a map because of the lighting. I can show you some screenshots for a comparison if you like.

I've rewritten it as this: private ushort ToRGBA5551(byte R, byte G, byte B, byte A) { float X, Y, Z; int U, V, W; X = ((float)R / 255) * 31; Y = ((float)G / 255) * 31; Z = ((float)B / 255) * 31; U = (int)Math.Round(X); V = (int)Math.Round(Y); W = (int)Math.Round(Z); return (ushort)((U<<11)|(V<<6)|(W<<1)|(A>>7)); } Which seems to give the correct results, at least on the textures I've used.Simply doing bit shifts isn't always correct in this situation because it will not get the ratio correct. ex. in your situation (5-bit to 8-bit) 11111 should become 11111111, but a bit shift would give you 11111000 instead.

Nice to see you around, as always.

@some stuff I saw in the shoutbox: afaik there shouldn't be an issue with darkened RGBA5551 textures, but looking at xdaniel's code: private ushort ToRGBA5551(byte R, byte G, byte B, byte A) { return (ushort)((((R >> 1) & 0xF8) << 8) | (((G >> 1) & 0xF8) << 3) | (((B >> 1) & 0xF8) >> 2) | (A >> 7)); } I don't think that's the correct way to convert the colours... I haven't noticed the problem myself (or I might just not have used any textures that get converted to that format yet) but I'll try playing round with the source a little. Edit: a quick fix is just to remove the "x >> 1", but it's still not totally accurate.

Happy birthday, though I'm sure the forum's been telling me it's your birthday for two days in a row (?), probably the difference in timezones. Anyway, have a good day.

If you're working in metres then the scale should be 1 metre = 1 unit, but that seems to depend on the exporter (SketchUp's vs ruby plugins). I don't know what it is for imperial since I don't use that system. The notes I have on door sizes are: Boss door: 120 wide 160 high 40 deep Normal door: 60 wide 100 high 40 deep Dodongo's Cavern doors: 160 wide 160 high 40 deep Push block (small): 60x60x60 Arcaith probably has a few more notes on object sizes. As for the actual modelling, there's not too much I can say to help other than just to make good use of the length display in the bottom right corner to get all your lines and shapes the right size. I'd recommend scaling and triangulating your map before you texture it too as that will sometimes mess with texture mapping.

this

You need a separate waterbox for each room but at the moment SharpOcarina will only assign them to room 0. You could change that manually or just wait until the feature is included in the program.I don't know what the problem with your actors is, but it might help to read this page.

I updated the information I posted on the previous page about which rooms waterboxes are active in, any chance it could be implemented before the next release?