SanguinettiMods Posted February 11, 2013 Share Posted February 11, 2013 I had another question; What are the chances of this having Animation Editing support if it's already going to be able to edit Hierarchies? Another thing as well, Would it be possible to port Matrix Data between characters? Say, Saria's Matrices over Link's, for example. Link to comment Share on other sites More sharing options...
xdaniel Posted February 11, 2013 Author Share Posted February 11, 2013 What exactly it'll be able to edit is still up in the air in general, so I'm open to suggestions. I'll try to implement editing for as many things as possible. As for matrix data porting, matrix data is generated on-the-fly according to the current animation frame, meaning the current position of the limbs - there simply is no matrix data to port. For specific vertices of a limb, the game uses the position of another limb instead of the one the currently rendered display list belongs to, then for the remaining vertices used by the display list, it uses the current limb's position. As far as I can tell - and someone with a deeper understanding of all this please correct me - everything is actually positioned using matrices "internally" (for my lack of a better word right now) and the game generates them as needed. Actors are positioned in a room like that, doing the N64's equivalents of glTranslate and glRotate, each actor's limb are positioned that way, the camera is positioned that way, and so on. There are base matrices in certain room files, used by some elements of the room in question, but even those are in turn modified by the game to ex. make Jabu-Jabu's walls wobble, and are only a part of a grand chain of matrices anyway - from the screen's projection matrix, to the skybox, to the rooms, to (for example) Link, to Link's limbs, to the dust Link kicks up when rolling. The only things that IIRC aren't done this way are TexRects, which are what make up most of the HUD, but even those are probably affected by the projection matrix, I'm not sure. Link to comment Share on other sites More sharing options...
SanguinettiMods Posted February 11, 2013 Share Posted February 11, 2013 Oh, I see. Well, the editing part will definitely be -awesome- I'm sure of that. I was just wondering because a long time ago I was going to make a Play As Saria, and because she has matrices connecting her limbs, they were broken. For the longest time I thought it was Hierarchy. Not necessarily porting matrix data, but at least fixing them if I were to use them for another character. I have no idea if this is just a re-wording of what I had just asked or not. Link to comment Share on other sites More sharing options...
xdaniel Posted February 11, 2013 Author Share Posted February 11, 2013 (edited) I'd guess the only additional thing you'd need to do is fix the addresses that the Mtx commands used for the joints point to... I don't have them in my head right now, but her and Link's hierarchies don't match up perfectly, I assume, in terms of which limb number is which limb... Like that ex. their left upper arms have different limb numbers, say ex. Saria's would be limb 5 while Link's would be limb 7, and their left shoulders would be limb 4 and limb 6 respectively. If you port Saria's left upper arm and shoulder over Link's, the arm that previously needed the matrix of limb 4 (shoulder) for the connecting vertices would now need those of limb 6, because that's where Link has his shoulder. Then you'll need to fix the Mtx command that loads the matrix for the vertices connecting the upper arm with the shoulder, so that it now loads the matrix from the address of limb 6's matrix, instead of limb 4's. I guess that those Mtx command fixes are all that need to be done for the connections to work properly. Hope that wasn't too confusing, it's kinda new to me as well, and it's 4:30 am here by now Edit: In fact, if you could make a Play as Saria patch where the connections are broken (or have that old one still lying around; I'm lazy I admit), I could try to fix it. Edited February 11, 2013 by xdaniel 1 Link to comment Share on other sites More sharing options...
SanguinettiMods Posted February 11, 2013 Share Posted February 11, 2013 Sure, maybe I'll try what you said tomorrow and if it doesn't work, because I might not get it completely, I'd forward a patch to you. Thanks for all the help! Link to comment Share on other sites More sharing options...
xdaniel Posted February 11, 2013 Author Share Posted February 11, 2013 DISCLAIMER: A big, bad hack where I check every instruction if the simulated registers contain enough data to form a valid gSPSegment command where the base address is inside the object RAM segment (0x06).. The good... or rather okay: The bad: The ugly: 2 Link to comment Share on other sites More sharing options...
Mallos31 Posted February 11, 2013 Share Posted February 11, 2013 what'd I say? Three days. XD Also, I'm sure this has a lot to do with the program being in early stages, but running this takes up more processing power than Skyrim. Just sayin'. I have a 6 core processor 4.1Ghz and it used 52% of it. Link to comment Share on other sites More sharing options...
Shadow Fire Posted February 12, 2013 Share Posted February 12, 2013 Saria has a moustache and beard... I KNEW she was really a dude! *scurries off to write a fanfiction about this* 4 Link to comment Share on other sites More sharing options...
xdaniel Posted February 12, 2013 Author Share Posted February 12, 2013 Saria has a moustache and beard... I KNEW she was really a dude! *scurries off to write a fanfiction about this* Oh god, did you have to remind me? I thought so too when the texturing came out like this... 1 Link to comment Share on other sites More sharing options...
Zue-Guy-Zen Posted February 12, 2013 Share Posted February 12, 2013 looks great, keep up the mighty fine work Xdan. I say, look at that beard on Saria. I wish I could grow one like that. I'm jealous 1 Link to comment Share on other sites More sharing options...
xdaniel Posted February 12, 2013 Author Share Posted February 12, 2013 Leaving actor rendering aside for a bit, not least because of Saria's beard (<.<), here's a new screenshot of Sorata's level viewing and editing side: The Return of the Actor Cubesâ„¢ - soon in cinemas near you! Well, no, in all seriousness: As wonderful as proper actor rendering in rooms would be, I have decided against doing it and there's two reasons for that. The first reason is simply how horribly incomplete actor rendering is, and how I can't see too many improvements to it short of writing a proper MIPS interpreter core, which would have to emulate each actor's code as well as any functions it might call elsewhere. There's actors whose hierarchies or animations cannot be found, there's actors whose display lists cannot be found or no distinction can be made on which of them are actually supposed to be rendered by the given actor with the given variable, there's actors whose scale for rendering cannot be found, etc., etc. All this would result in ex. actors that appear many times bigger than the room they're actually in, or actors, dungeon-specific ones in particular, who render each and every display list in their object file in one place. The result would simply not be up to the standard I'd like to have - either go all the way, which in this case isn't something I'd be able to do, or don't go at all. The second reason is far more simple, while at the same time probably even more important: performance. While everything is still rather unoptimized, I am not sure how far I can optimize ex. Nanami's display list parsing and rendering code, considering the design I've chosen for the whole thing. Of course I'll push for optimization when the time comes, but as it stands now, rendering ex. Ganon alone drops the FPS down to 38, with other actors not faring much better. Now imagine 20 or so demanding actors being rendered in addition to the room they're in. I can't see this working well enough to warrant implementing it. 3 Link to comment Share on other sites More sharing options...
SanguinettiMods Posted February 12, 2013 Share Posted February 12, 2013 That's definitely okay with me. Actor Cubes are nice enough! I mean, at least we can see what actor we have selected. Link to comment Share on other sites More sharing options...
Jason777 Posted February 12, 2013 Share Posted February 12, 2013 Actor cubes are a friendly and familiar face to everyone. Don't sweat the small stuff. Link to comment Share on other sites More sharing options...
Three_Pendants Posted February 12, 2013 Share Posted February 12, 2013 Actor cubes are as classic as wireframe in ZLE 1. Don't worry about it. At least we can see the representation well enough. I like the look of things and that actor menu looks so much cleaner than Sayakas's own. Link to comment Share on other sites More sharing options...
xdaniel Posted February 13, 2013 Author Share Posted February 13, 2013 (First things first, holy crap this post is yet another long one <.<) Heh, glad to hear you aren't disappointed about that, because I myself actually am a bit Kinda makes me wonder how Nintendo's own editing tools displayed actors in rooms, too. Anyway, something else feedback-wise, that might be a bit long-winded: Already before the last screenshot, I started overhauling the mouse controls. With actor editing starting to take shape, including picking them and eventually moving them via mouse, etc., I starting re-thinking how to approach the user's mouse-based interaction with the program, the 3D view in particular. Previously, the mouse was used only for camera control and selecting rooms by right-clicking, as mentioned before. Now I've started to implement "mouse modes" like UoT and Sayaka use, that control what the user can interact with and what not in the given mode. This is something else I'd like to get feedback on, as I'm not completely sure about the most intuitive way to do this. There's three modes currently: Camera only, room selection, and actor editing. Camera works like you'd imagine, looking around with the mouse while holding the left button, and moving around with WASD. Room selection is the same, but will additionally select any rooms that are under the mouse cursor when the user left-clicks. Meaning, you click on a room, the room is selected, and if you keep holding the button down, you can still look around. I can see this being a bit problematic if the user accidentally clicks outside of the room while trying to maneuver around. Actor editing is currently the same way, with actors being selected by left-clicking, in addition to camera movement. About moving and selecting actors: I feel like UoT has that down pretty well, so I'm thinking of emulating its mouse control behavior for the most part, including the camera locking onto the actor cube and the mouse cursor being locked in place while moving an actor. In addition to that, I wonder if I should add keyboard modifiers that change on which axis the actor is moved? Like that if you hold Shift, the actor will only move on the X axis, or if you hold Ctrl it'll only move on the Z axis or so. Thinking of keyboard-based modifiers in particular as you can just activate them by holding a key, as opposed to having to click somewhere on the GUI or somesuch. However, will that potentially "scare away" people, having to press keys for certain things? I'd rather not use the mouse wheel to select the axis, as I'm using it to switch between mouse modes (camera, rooms, actors), but I could switch to using that if you think keyboard modifiers are the worse idea. Not sure what else I could ask about regarding this, until after I've made a build that incorporates any suggestions you'd give me. One more thing to report: I cut down ROM loading time for the MQ Debug ROM by a bit over a second, by rewriting how the ROM loader fetches names from the filename table. That brings the time down from ~2.6 seconds by now (with ex. searching for scene, actor and object tables, and reading them) to ~1.4 seconds, which is about what it was before I added support for the actor and object tables. 1 Link to comment Share on other sites More sharing options...
Mallos31 Posted February 13, 2013 Share Posted February 13, 2013 This may seem a little ridiculous, but would it be possible to, say, make it to where you can right click an actor cube, and render it in a new tab like a browser or something, just in case you're not 100% sure what actor it is (Like, for so long, I have no idea what demo_geff was) If that's totally stupid, ignore it Link to comment Share on other sites More sharing options...
xdaniel Posted February 14, 2013 Author Share Posted February 14, 2013 (edited) First "mouse mode build": http://magicstone.de/dzd/random/SorataVSE_test2-14022013-0246.rar Switch modes with the mouse wheel or by clicking the label in the lower right corner; camera mode just moves the camera, room selection mode allows selecting rooms by left-clicking them, actor editing mode allows selecting actor cubes by clicking (all buttons right now) and moving them around by holding the left (left/right/up/down) or middle (left/right/into screen/out of screen) mouse button. All movement is sped up by holding Space and slowed down by holding Shift. Forgot what else has changed. Also, you will encounter instances of the GUI not updating, mainly when dragging actor cubes around, I know about that - there's a bunch of //TODO TODO TODO [...] in the code, some related to that. Feedback about mouse control & co. is welcome! Edit: Also didn't ignore you, Mallos Right-clicking an actor cube will eventually open a context menu, I'll add a "Render actor" menu entry or something that'll jump to the actor viewer. As for knowing what actor is what, that's what actor definitions are gonna be for, the things that build the actor editing interface (as seen for switches and treasure chests already) which also contain a short description. Edited February 14, 2013 by xdaniel Link to comment Share on other sites More sharing options...
sairugoth Posted February 14, 2013 Share Posted February 14, 2013 Man, I hate to be the one of the first persons to reply, well because, I feel bad about it when I get a error. I'm sorry Xdan , its just my bad luck. you see, I tryed my debug rom but I got a error (I even named it "THE LEGEND OF ZELDA"). But then I tryed the normal rom with the same name ("THE LEGEND OF ZELDA") and it worked. but when I clicked on a scene it error'ed this. Link to comment Share on other sites More sharing options...
Mallos31 Posted February 14, 2013 Share Posted February 14, 2013 I got that a few times. Opening the actor for the redead, Ganon, and NEVER try to open the "code" file or anything like it. Oooohhhh boy it gets buggy. Link to comment Share on other sites More sharing options...
xdaniel Posted February 14, 2013 Author Share Posted February 14, 2013 Man, I hate to be the one of the first persons to reply, well because, I feel bad about it when I get a error. I'm sorry Xdan , its just my bad luck. you see, I tryed my debug rom but I got a error (I even named it "THE LEGEND OF ZELDA"). But then I tryed the normal rom with the same name ("THE LEGEND OF ZELDA") and it worked. but when I clicked on a scene it error'ed this. Non-MQ Debug ROMs aren't really supported yet, especially vanilla ones that haven't been expanded/decompressed. I just tried it with a normal 32MB NTSC v1.0 and it didn't find any scenes, while any actor gives me the exact same error message. MQ Debug ROMs should work fine, regardless of their name... What error message do you get there? Link to comment Share on other sites More sharing options...
Three_Pendants Posted February 14, 2013 Share Posted February 14, 2013 Hmm, it seems pretty good, but the actor boxes themselves don't show up for me unless I go to Room Actors and scroll down to any given actor. Is there something I'm missing here since some of your other shots show all actor boxes showing up in a room. Link to comment Share on other sites More sharing options...
xdaniel Posted February 14, 2013 Author Share Posted February 14, 2013 Hmm, it seems pretty good, but the actor boxes themselves don't show up for me unless I go to Room Actors and scroll down to any given actor. Is there something I'm missing here since some of your other shots show all actor boxes showing up in a room. You did select a specific room, right? Because actors don't, and aren't supposed to, show when all rooms are rendered at once. Then again, you must have selected a room because otherwise you couldn't scroll through the actors on the Room Actors tab... Uhm, so after selecting a room, the actor selection under Room Actors is set to "(None)" and no actor cubes show (at which point they should show). Once you scroll down to an actual actor, the cubes and the selected actor's axis marker render. Am I getting this right? Link to comment Share on other sites More sharing options...
sairugoth Posted February 14, 2013 Share Posted February 14, 2013 Non-MQ Debug ROMs aren't really supported yet, especially vanilla ones that haven't been expanded/decompressed. I just tried it with a normal 32MB NTSC v1.0 and it didn't find any scenes, while any actor gives me the exact same error message. MQ Debug ROMs should work fine, regardless of their name... What error message do you get there? sorry for the delay. Its in the spoiler. but don't sweat it too much, I'm always having problems with this debug rom, I'm going to try downloading another one from a different sight, and see if that helps. Here: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.ArgumentException: Illegal characters in path. at System.IO.Path.CheckInvalidPathChars(String path) at System.IO.Path.Combine(String path1, String path2, String path3) at SorataVSE.ROMHandling.ROMLoader..ctor(RCPHandler r, String fn, LoaderStepEvent evnt) in C:UsersDanielDocumentsVisual Studio 2010ProjectsSorataVSESorataVSEROMHandlingROMLoader.cs:line 104 at SorataVSE.MainForm.openROMToolStripMenuItem_Click(Object sender, EventArgs e) in C:UsersDanielDocumentsVisual Studio 2010ProjectsSorataVSESorataVSEMainForm.cs:line 223 at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 (RTMRel.030319-0100) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll ---------------------------------------- SorataVSE Assembly Version: 0.0.0.0 Win32 Version: 0.0.0.0 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/SorataVSE.exe ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- OpenTK Assembly Version: 1.0.0.0 Win32 Version: 1.0.278.44921 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/OpenTK.DLL ---------------------------------------- OpenTK.GLControl Assembly Version: 1.0.0.0 Win32 Version: 1.0.278.44921 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/OpenTK.GLControl.DLL ---------------------------------------- TrackBar Assembly Version: 1.0.2486.37933 Win32 Version: 1.0.2486.37933 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/TrackBar.DLL ---------------------------------------- QuickFont Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/QuickFont.DLL ---------------------------------------- NanamiRCP Assembly Version: 0.0.0.0 Win32 Version: 0.0.0.0 CodeBase: file:///C:/Users/Sairugoth/Downloads/SorataVSE_test2-14022013-0246/Release/NanamiRCP.DLL ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.0.30319.1 built by: RTMRel CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. Link to comment Share on other sites More sharing options...
xdaniel Posted February 14, 2013 Author Share Posted February 14, 2013 sorry for the delay. Its in the spoiler. but don't sweat it too much, I'm always having problems with this debug rom, I'm going to try downloading another one from a different sight, and see if that helps. Here: ************** Exception Text ************** System.ArgumentException: Illegal characters in path. at System.IO.Path.CheckInvalidPathChars(String path) at System.IO.Path.Combine(String path1, String path2, String path3) at SorataVSE.ROMHandling.ROMLoader..ctor(RCPHandler r, String fn, LoaderStepEvent evnt) in C:UsersDanielDocumentsVisual Studio 2010ProjectsSorataVSESorataVSEROMHandlingROMLoader.cs:line 104 [...] Looking at the code, it seems to throw that exception while trying to form the path to the XML actor definitions. It uses part of the game ID for that, the two middle characters, which should be "ZL" for all OoT ROMs and might be characters that can't be used in a path in your ROM. Mind opening it in a hex editor and telling me the game title, ID and version byte? Those are at offsets 0x20, 0x3B and 0x3F, respectively. Or maybe just take a screenshot of how the beginning of your ROM file looks (both the hex values and ASCII text), where it should say "THE LEGEND OF ZELDA" - kinda like this (from my working Debug ROM): Link to comment Share on other sites More sharing options...
sairugoth Posted February 14, 2013 Share Posted February 14, 2013 Eureka, I found a working rom, YES, thank the gods. OK I'm good now. Looking at the code, it seems to throw that exception while trying to form the path to the XML actor definitions. It uses part of the game ID for that, the two middle characters, which should be "ZL" for all OoT ROMs and might be characters that can't be used in a path in your ROM. Mind opening it in a hex editor and telling me the game title, ID and version byte? Those are at offsets 0x20, 0x3B and 0x3F, respectively. Or maybe just take a screenshot of how the beginning of your ROM file looks (both the hex values and ASCII text), where it should say "THE LEGEND OF ZELDA" - kinda like this (from my working Debug ROM): here it is (the broken one) I dont really need it any more, but just to be safe I suppose. (sorry for the crappy Quality) Link to comment Share on other sites More sharing options...
Recommended Posts