xdaniel

KeyWaitB (ＬＲＺ 上下 上下 左左 右右 B A START) L + R + Z Up + C-Down C-Up + Down Left + C-Left C-Right + Right B + A + Start KeyWaitB'(ＬＲ左右 +START) L + R + Left + C-Right + Start ...is what I gather from the video.

If you mean ex. the 0000FC06 FFFFFFFF at 0x03FFFEF8 in your screenshot, why would that be odd? That's part of the vertex data, the texture coordinates and colors for one vertex, to be exact; the display list proper begins at 0x03FFFF10. If you'd use the start address of the vertex data as your display list address - meaning that the system would try and interpret vertex data as commands -, that would very likely cause crashes or other problems on hardware and might be ignored by emulators (ex. via sanity checks like "if pointer is invalid, ignore command"). If you're certain that the start address you're using is correct, I'll have a closer look at the display list in the screenshot later.

Uhm, nope? Completely unfixed, 120 crashes, and a whole lot of Yay0 blocks.

Rewritten much of the dialog box control; it still prints text letter-by-letter, and still does automatic linebreaks after words if a line would overflow. What's new: can now be set to fade in each letter as it appears, now has a nicer framework for tags, supports per-letter color and print delays, and supports a simple drop shadow by drawing each letter twice (black and offset). Edit, oh yeah: DialogBox.Message = "Alright, here we go <d=22>yet again<d>. Now rewriting the <d=22><c=255,128,64>bloody dialog box<c>!<d> Here's hoping it <c=128,255,128>will actually work<c> now... I mean, this whole project is shoddy, but it should be a '<c=64,128,255>good shoddy<c>', right?"Edit 2: Manual (tag <w>) and automatic (if dialog box overflows) "wait for keypress" implemented, also fixed a few other things here and there, and added a rudimentary background image to the box:

Uh, no? You do realize that The GCN is not just about projects, mods or whatever?

Heavy, you've brought my favorite Zelda game into my second-favorite Zelda game!

Not sure what to say... I'm not a religious person, but if there's any sort of higher being or something out there, please watch over JSA and his recovery. Whenever you appeared, JSA, you've been helpful to anyone asking, you figured out new things and so on, and whenever you disappeared, you've had us wishing you well and wishing for you to return soon. This time is no different - take care, get better, and come back soon. You'll surely return someday... they all return someday! Seriously tho, I'm wishing you all the best and hope that you can be treated properly as soon as possible.

The game's been funded today and has hit the one million USD mark earlier - with 29 days still left to go. Those PS3, 360 and Wii U versions don't seem very farfetched, now do they? Also, as an aside, regarding that planned poll about Call's design... A Roll expy would be fine and fitting the inspiration, but Aero deserves a chance to live.

Heh, looks like the dump of my own cartridge is a good one, as the bps patch worked fine on it Anyway, he's done a great job with this, looks pretty awesome - in my opinion better than what I've seen of the VC version -, a lot like I imagine an official release back in the day would've looked.

Well, yes? As I was saying, at 0x15780 is a Mtx command. Matrices are what position stuff - everything, from the camera itself to tiny dust particles - in a three-dimensional space in games. I bet that command loads the matrix that transforms the following display list's / model's vertices so that the model faces the screen.It would be interesting to know what the DL call right after the Mtx command is responsible for, tho, like if that's still needed with, for example, the Heart Piece, or if that's specific to Navi's original model.

Over 10000 backers, over $603000 pledged, two-thirds of the main goal. In less than one day. Holy shit. And damn, this is the 4th Kickstarter I'd love to back, but until KS somehow manages to add Paypal support, I won't be able to... Edit, also, game design by one of the level designers and music by the composer of the original NES Mega Man, art direction by, among other things, a character and mecha designer for Misadventures of Tron Bonne (and the winning Aero design for MML3! <3), (co-)developed by Inti Creates of Mega Man Zero and ZX series fame, etc., etc.

For one, 0x15780 appears to be the correct start address, as the last command right before that at 0x15778 is EndDL/0xDF. 0x15790 is likely yet another UoT bug; I vaguely seem to remember something regarding display list addresses being off by a bit... Secondly, the command at 0x15780 is Mtx/0xDA, which, in this case, loads a matrix from RAM segment 0x01 - the segment, and the matrix contained, very likely being set up at runtime by the game, and very likely what transforms the model to always face the screen. The next command after that is a DL/0xDE display list call to segment 0x08, which is also set up at runtime, so I have no idea what it contains; might be animation-related, might be something else, I don't know. A wild guess and not guaranteed to work, to make a different/custom model that replaces Navi's sphere also face the screen, would be to 1) leave the pointer to 0x15780 intact, 2) leave the Mtx command there intact, 3) overwrite the DL call at 0x15788 with one to the replacement model, and 4) overwrite the RDPPipeSync/0xE7 at 0x15790 with an EndDL. Again, a wild (but educated) guess, and probably not something I'm gonna try out myself (honestly too lazy).

The "regular DS", i.e. not the DS Lite or DSi, has hinges that don't break that easily, even in the hands of a child, unless you forcefully try to snap it into two. I do agree that the old DS' shouldn't even factor into this discussion, tho, because it's the DS' that first came out almost 9 years ago (I feel old), the - in my opinion - last really important games for which came out a year ago, meaning Pokemon Black/White 2.

Started writing a dialog box control; still pretty rudimentary: It prints the text letter by letter, and automatically inserts linebreaks if a word overflows the box to the right (in this case, between "Novel" and "Engine"). Still thinking about how to format and implement control codes for ex. text color, wait-for-keypress & next dialog box, inserting variables such as names, etc. (And I lied; it's not awesome. Yet.)

I'm starting to think that hard-coding stuff isn't the worst option... or, maybe not "hard-coding" in the sense of putting a bunch of ex. offsets into the actual code, but having external files that contain all of those offsets, file numbers, what have you. Not unlike SayakaGL and its ZeldaVer.xml, with the scene, object and actor table offsets, etc... That would mean manually looking for ex. our newly found scripting commands in every level file, but all that seems more feasible (for me) than tearing apart the game's code, or interpreting it in the editor. Hell, it might be possible to find some of this stuff automatically by making the program recognize patterns in the data, which would be not unlike SceneNavi...

I love Amazon, got it a day before release <3 F.O.E... F.O.E...

And this thing is just gonna exacerbate this. Nintendo's already got a problem with effectively communicating with customers who aren't already fans - look at the issues they've had, trying to clarify that the Wii U is a separate console and not just a Wii add-on. Now they're introducing a so-called "2DS" next to the "3DS" systems. I can already see people going "Is this 2DS a new thing? I can't seem to find any game for it in stores, only ones for 3DS."

Dumping some notes here while messing around... Training stage (virtual start 0x00DD7620), at 0x9748 is the ground-based turret thingy (ID 0x0410 I think). Begins with "D00A0008"; 08 might be index into another table, probably 0xCB1FC in code?, that actually determines what model is used, as changing to 03 (from next entry at 0x977C, ID 0x0411 then?) changes the model to that of the rotating, round, floating enemies. Changing to 09 gives it the model of those winged enemies, complete with flapping animation. EDIT: 66 are the moving doors from the training stage; while not moving, they have their usual collision model, etc. meaning you can fly right into them & get damaged, can't shoot nor target them, etc. EDIT 2: Something else in there, besides the D00A00xx "command", determines ex. if the enemy shoots at you. Nulling the remaining data until FE000000 makes them not shoot at you (still targetable, destroyable). EDIT 3: There's C0050087 00000064, where the 64 seems to be the amount of time from spawning until they shoot. Setting that to 00 makes them shoot right when they come into view. EDIT 4: E00000xx 000000yy seem to be shot properties or something; changing xx appears to change the angle of the shot, yy appears to be another delay. This enemy has this command twice, E0000002 00000006, E0000002 00000001. Changing 06 in the first to 01 reduces the delay between the two considerably. (EDIT 7; 06, not 0A) EDIT 5: Oh man, wtf? Changed the second E0###### shot thingy to "185A0384 02140008" from the moving doors; enemy shot at me once, then turned and ran off to my left! EDIT 6: "16B40384 FC040014", bwahaha, they shoot, then turn around like "Hmpf!", as if they're mad they missed XD

In case anyone else is working on SF64, here's pretty much all I know... and I really wouldn't mind some help:

This is horrible... ...and yes, it really is, because this is almost as hacky as the old SF64 Toolkit's level viewer was... or, it's hacky in different ways. It does use the enigmatic table 0xC5BFC to populate the RAM segments (which might actually start several entries before that), but the address of Corneria's entry in said table, which is 0xC5BFC, is currently and temporarily hard-coded in and the program throws an exception if you try to load any non-Corneria entry... I think I remember why I had stopped hacking this game. I didn't get anywhere without hard-coding all kinds of stuff and I couldn't even find half the data you'll need for an editor (or even a good viewer) -.-

Haha, this is nostalgic, reminds me of when I first messed around with the game: Meteo's boss in all its untextured (code copy-pasted, hacked up and partially commented out from SceneNavi) glory. Got a very dumb Ucode interpreter and renderer going, just so that I can try and render stuff. Next I'll try to figure out more about the enigmatic table at 0xCE158 0xC5BFC in the code file, which should help figuring out level to file linkage... and speaking of which, here's what I currently know about that, in (messy...) copy-pasta form from my local wiki setup:

Trying to get reacquainted with SF64 by reading my old notes, the SF64Toolkit source and writing documentation... Also gonna dig up Izuna again and maybe use that as a base for an editor or something...

Not much time right now, but I did work on SF64 a few years ago. See... my YT channel, z64 and OZMAV SVN, I think.

Sachika Misawa - Links (Toaru Kagaku no Railgun S ED2) Haven't heard her in a voice acting role yet, but I think she's got a beautiful singing voice!

Rinku: I've honestly not worked with fog very much, but I believe the "near" distance is where fog starts in relation to the camera, while the "far" distance is where the fog ends. They can also influence the draw distance of room and actor models, cutting them off beyond a certain point, but I'm not sure if that's just a side effect or not. That said, there's a way to mess around with the current environment settings easily in-game - in the Majora's Mask Debug ROM: http://tcrf.net/Proto:The_Legend_of_Zelda:_Majora's_Mask/Debug_Version#Environmental_Control - The menu in the third screenshot there is what you want, just press Start three times on controller 4 to get there. It allows you to change, in order, the ambient light, the first diffuse light, the second diffuse light, and the fog using the D-pad and A/B buttons on the controller. EDIT: IP.Board doesn't like apostrophes in URLs -.-