xdaniel

That might already work, actually... If no filename table has been found before reading the DMA table, it assigns a default name of "V<virtual start>_P<physical start>" (see DMATableEntry.cs, "Name = string.Format("V{0:X}_P{1:X}", VStart, PStart);"), both in hex, not prefixed and without leading zeroes, so something like ex. "VCA8930_PBAC0B0". Insert the correct values and try that as the filename.

Something I'm trying to improve with SorataVSE is something that's been a problem with many of our tools, and is something that's been brought up by sakura and others before: they are too complicated. I mean, they're great tools for sure, but they're either too complicated for casual users to use, ex. SharpOcarina I guess, or missing vital features, ex. SayakaGL, I'd say. cooliscool was on the right track with UoT regarding all the things you can do with it, all wrapped up in a (relatively) simple GUI. Now I very likely won't be able to single-handedly turn everything around, create a program that's both really, really simple to use but also powerful in what it can do, as well as spread the word around enough to make people switch from the antiquated UoT R10 (or older!). I am going to try my best tho, trying to look at the bigger picture from the casual end user's perspective, to make sure that it'll be easy to do things that, when done with existing tools or manually, would normally involve looking up lists on the wiki and/or busting out the calculator. That's where I got the inspiration for the actor editing UI being described by XML files from, which allow the program to build the GUI around the actor, as opposed to squeezing the actor into a number, position, rotation and a variable. Another - albeit much less significant thing - is actually finding the area you want to edit. Assume you're a "newbie" who wants to edit the Forest Temple. Where do you find the main hall? I know that temple's files are prefixed Bmori1, and the hall is room file Bmori1_room_2. They likely don't know. So here's my solution to that problem - a really simple one at that: XML files that "translate" the scene and room filenames into human-readable names in the program. Thus this... ...becomes this... The room names aren't covered yet, but the code for that should be easy enough. The other thing is actually writing those human-readable descriptions, tho... Scenes are easy, there's plenty of lists already, plus most locales in the game have a descriptive name. Rooms on the other hand... well, some are easy like the aforementioned main hall in the Forest Temple - hands up if you don't know what room I mean - but nondescript corridors...? Well, that part's something for another day, I guess.

Dark Link's an easy fix: http://magicstone.de/dzd/random/ZSaten2-POC-b.rar if (ObjectFN.ToLowerInvariant() == "object_link_boy" || ObjectFN.ToLowerInvariant() == "object_link_child") goto dolink; ...became... if (ObjectFN.ToLowerInvariant() == "object_link_boy" || ObjectFN.ToLowerInvariant() == "object_link_child" || ObjectFN.ToLowerInvariant() == "object_torch2") goto dolink;

To fix the game... To be. Still have much to do in life... Shigeru Miyamoto. Played Kojima's MGS, ZoE and Boktai but played and liked Miyamoto's works more. Android or iOS?

Blast Processing. If someone really did the math on the Jaguar, they'd see that only a fraction of the hardware is actually "64-bit". Sega logo jingle (Seeeeeegaaaaaa~) or US Sega scream (SEGA!)?

Animated textures: If I can figure out how they work, sure. If not, well, no. Actors in maps: Especially now that I've got the joints thing pretty much cracked so to speak, I'd say yes. Also, on another subject, a side effect of sorts that's broken in the build I posted above: I'm not working on this game; anything you might be able to do in it is an unintended side effect, although I'm not actively preventing this by only allowing Zelda ROMs to load or somesuch. (Not to mention a "side effect" that's "broken"? Awkward wording for sure)

Happy Birthday, sakura!

I'm actually developing on Windows 7 HP 64-bit, so that shouldn't be a problem. Are you getting an error message or something? If so, could you post any details etc.? Now as for feature requests and such, I'll look into them when the time comes to integrate and clean up this code for use in Sorata. There's even code in already this that's not being used yet, like a C# "port-ish variant/rewrite" of spinout's mips-eval as used in ZSaten.

Is one supposed to know this Kenny Strawn? Anyway, while you could say I "hate" the Apple of today and their products (in contrast to that of the iMac and G3/G4 days), I don't launch tirades like that. Plus, I have to admit I like the, from what I've seen, unified look of GUI applications on iOS - on Android, depending on the apps you have, you potentially get a jumble of 5+ different styles.

There's a fundraiser going on for ROM releases of a PAL prototype of Perfect Dark (built two days before the final), a NTSC prototype of PD (March 22nd 2000), a "Debug" build of Conker's Bad Fur Day (October 25th 2000), and an ECTS demo build of Conker with apparently lots of differences. A few short videos of the two Conker builds have been posted by Borman, who's in charge of the whole thing: http://www.youtube.com/user/ptoponline?feature=watch I have nothing to do with it - nor have I even played much of the games in question - but I'd still like to spread the word around. I also am actually interested in that ECTS Conker build despite that, and am considering to donate at least a few bucks to the cause.

Download: http://magicstone.de/dzd/random/ZSaten2-POC.rar Program & library binary (ZSaten2ZSaten2binRelease), program source. No library source yet, still very much WIP and will instead be released with SorataVSE in presumably a few months. Potentially buggy proof-of-concept, read and heed the Help/About message.

I guess program and source code are forthcoming, but don't expect clean code - the program's was was supposed to become "ZSaten2", but turned into a testbed of sorts when I started work on SorataVSE (see other threads). I will also document this properly, as opposed to just leave it at the code; here's the gist of it, as program/source release and proper documentation will take a bit longer: The "magic" is basically creating the contents for RAM segment 0x0D at runtime, which holds the matrix data for each limb that has a display list attached. I'm preparing the segment by parsing the hierarchy in advance before actually rendering the model. The basic modelview matrix is identity multiplied with the global translation (the first 3 shorts in the rotation index data), then the limbs are parsed starting at #0 and address 0 in segment 0x0D. The limb parsing function makes a local copy of the previously loaded matrix - so at limb #0 the aforementioned (identity * global translation), at the first child (identity * global translation * limb #0), etc., at the first sibling (identity * global translation), and so on - and then generates the current limb's matrix based on its translation and rotation values (depending on selected hierarchy, animation and frame number). Now, if the current limb has a display list to be rendered, it writes the current matrix to the current address in segment 0x0D and then increases the address by 0x40; if it's not supposed to be rendered, the matrix is not written to the segment, the address not increased. Lastly, if there is a child, the function recursively calls itself again, with this limb's matrix as a parameter, to parse the child, and if there's a sibling, it calls itself with the previous matrix as a parameter. The matrix data's format as written to segment 0x0D is explained in the Functions Reference, on the gSPMatrix page. Now the actor's display lists that use gSPMatrix (0xDA) commands - so those with joint vertices connecting two limbs - will happily read the matrix from the segment, which can then be used to transform the vertices loaded by gSPVertex (0x01) commands. My ucode interpreter library thingy has a matrix stack, which is filled/emptied by gSPMatrix and gSPPopMatrix, the matrix at the top of which is taken whenever a vertex gets loaded and applied to the vertex position. What I'm also doing to get any actor display lists to render that do not contain gSPMatrix commands - ex. the whole Stalfos, Saria's body and head, Zelda's body, head and boots if I recall - is that, right before a display list is given to the interpreter library for parsing/rendering, the corresponding matrix is manually pushed onto the matrix stack. Display lists without gSPMatrix commands get the correct matrix, while those with them will get the limb's matrix, then (usually) directly load another limb's matrix for the joint vertices, then reload its own limb's matrix again for the rest of the display list. No need for manual glTranslate/glRotate/glPushMatrix/glPopMatrix in OpenGL, as used in ZSaten and likely every other viewer as well as described on the wiki, anymore. Whew, hope that's making some sense already... again, program, source and some better documentation (probably with an example or so) coming a little later, next week or so at the latest - I hope.

Well, EX-FUCKING-CUUUUUUUUSE ME, PRINCESS! And for the moment, I'm so unbelievably sick of matrices, RAM segments, overlay files and all the other shit. Taking a bloody well-deserved break of this for a day or two or three.

From the looks of it, there are actors that do position the display lists via matrix operations, like the cow. Most (if not all) of its display lists first load the previous limb's matrix to position the joint's vertices, then they load the current limb's matrix to position the rest of the display list. If I'd now render it the "usual" way as done by ex. ZSaten, I'd get limbs that have been translated and rotated twice, once by the matrix command, and again by the viewer's hierarchy rendering, resulting in a sort-of exploded view of the actor. That also doesn't cover actors that appear to be using both variants (with and without matrices) at the same time, like the bazaar guy (object_ossan). His torso and head do not appear to use matrices, while his arms do - rendering him by relying just on the matrices, the torso doesn't get transformed and his head is stuck to his right hand, the last matrix to be loaded before the head is supposed to be rendered, like so: But wouldn't that mean there's matrix data stored for each limb and each animation frame? That's something like (((0x40 bytes per matrix * limb count) * frame count) * animation count) I think, and a huge waste of space.

Came back from the usual 1st Sunday flea market earlier, here's what I've got: 2x Sony PlayStation SCPH-1002: both appear to have dying lasers, as neither has successfully ran a game further than the intro; one of the two is also making strange noises - dead drive controller in addition to the laser or something? Pokemon Pikachu Color pedometer: pretty scratched but works fine; display seems kinda weak... maybe that's just the battery, tho Super Robot Spirits (N64, JPN, loose): works fine, but a pretty meh game Aero Fighters Assault (N64, ASIA, loose): "Asian Version" with ID "NUS-NERE-ASM", US ROM inside Japanese-style cartridge, also a bit of a meh game (Photo on Twitter)

I'm no good with MIPS assembly at all and wouldn't even know where to start, so I'm hoping someone else here who's more versed in it can help me out... Basically, I'm trying to get actors to render properly in a viewer, including ex. their limbs' connecting vertices being positioned correctly, if applicable. I know that actors that do have such smooth connections between their limbs, like most human(oid) actors, achieve this by translating/rotating certain vertices of one limb according to the translation/rotation of another limb. They get the other limb's modelview matrix from RAM segment 0x0D via a Mtx (0xDA) command near the start of their display list, then load the connecting vertices (thus positioning them using that matrix), then get their own matrix to finally position and render the rest of the vertices like normal. Now, after much trial and error I've succeeded in correctly rendering the cow... ...but only the cow. Everything else is more nightmare fuel than actor... I (most likely!) correctly create OpenTK-side matrices from each limb's/animation's translation and rotation values, relationships between childs, parents and siblings included, and I can create valid "N64-format" matrix data - there's not a single glitch with the cow, as far as I can see. I partially emulate the gSPMatrix / 0xDA Mtx command (not the projection stuff, not needed here; works for the cow and ex. Jabu-Jabu's wobbly walls, albeit rendering them stationary of course), I correctly transform the position of each vertex loaded according to the current modelview matrix (bless OpenTK's Vector3d.Transform). There's two big problems I'm seeing or anticipating: Problem 1: At what address in segment 0x0D does each limb's matrix have to be stored? I'm currently writing each limb's matrix data into the segment successively, so that limb #1's is at 0x0, limb #2's at 0x40, limb #3's at 0x80, and so on. That's working fine for the cow, but for none of the other actors I've tried so far, like Sheik, Stalfos, Saria, young Zelda, Wallmaster and a few others. Problem 2: I'm currently relying solely on the Mtx commands to try and position each limb correctly, however some actors don't appear to have any inside their display lists, like the Stalfos. How does the game render those? Or rather, how does the game know to render those differently from actors that do contain Mtx commands? Well, by this point I'm stumped. I imagine I'd find some more answers if I look into the actors' or the game's code, but as mentioned above, I'm no good with MIPS at all. So I reluctantly have to ask: Has anyone else looked into any of this before, and has something to share about how this all works?

Yeah, those are the two options possible: basically, either modify an emulator to play external music files when a game tries to play SNES music, or modify the game to play music via the MSU-1 add-on instead of its original soundtrack. Besides the fact that both of those are gonna be difficult, there's some drawbacks. The first method locks your ROM hack to that specific emulator and, while it'll work with others, people won't get your custom soundtrack with them. The second method requires people to use either bsnes, or play the game using a sd2snes flash cartridge on a real SNES, as I believe no other emulators or flashcarts support the MSU-1 yet. Again, people should be able to play the game using other emulators/carts, but they won't get your soundtrack.

Once again dragging this thread out for a PSP screenshot... but taken on my PC: It's Lumines, one of my first PSP games from back when I got the system, running in PPSSPP, a PSP emulator for a bunch of platforms. This game runs at pretty much full-speed with the Dynarec core enabled, and often full-speed with the faster interpreter - only problem are some missing graphics ex. in the menus. I also tried the Android version on my phone, but even with the Dynarec, it was kinda slow... not to mention, I can't stand those on-screen buttons. Even in Pokemon Emerald in My Boy, I keep walking in the wrong directions...

Heh, thanks Also, I've decided to do something relatively unusual for me. Usually, I'm only willing to release something if it's up to a certain standard, even if the end result isn't very pretty internally (like SO)... whatever that standard might actually be, I don't have a definition handy. Not to mention that must sound weird coming from me, the master of sloppy code and horrible design decisions... Anyway, the big change here, however, is that I'll be posting random WIP builds of the program from time to time, starting right now: SorataVSE v0.0 "test0", very early, no editing and saving, only really tested with the MQ Debug ROM, etc., etc. You won't be able to do anything useful with it yet, but there's still plenty in there already to keep you occupied for... uh, ten minutes? You can look around scenes, have an early look at the whole XML actor definition stuff I've been talking about, you can try to load and render objects from the filesystem separately, as well as load files without rendering them (good for loading gameplay_keep and then something that uses textures from there, like GI models)... and that's about it. Still, let me know if and how it works!

First things first, I will get back to Model2N64, its model conversion library, etc. sometime, but for now I'm focusing on my PSX game and both Sayaka's and ZSaten's possible future replacement, SorataVSE. I posted about it in the SayakaGL thread before, but I think it's better suited here. And so, an update on Sorata. I mentioned the XML-based actor definitions or templates the program uses to create the actor editing interface, but only had a highly generic definition to show - actor number, position, rotation and variable, the classic stuff. Well, I've worked on the definition reader and the interface creation code some more today, and here's how it stands now: Notice how the interface changes between switches and treasure chests? Once actual editing and saving is implemented, this should make building "dungeon infrastructure" easier, however, so far it's just a fancy viewer. Edit: now with checkboxes. ...man, I don't want to bring people's hopes up, that it'll be finished soon and really awesome and all, but I do by posting stuff like this, don't I? -.-

Not in ol' Sayaka, but I will do so for Sorata. Also, the reason why I stayed up until now... 6:25 am, that is: ...becomes... What does that mean? External user-editable XML files, which tell the program the makeup of the actor data, according to which it will assemble the actor editing interface. A simple example, take the ambient sound effect actor (0x003B). Instead of all of its data being displayed as numeric values, including IIRC in this actor's case "useless" things like the rotation, this will... or, well, should someday make the program instead only display the actor's number, the position, and a drop-down list of all possible effects - no more (or at least less) messing around with variables and actor lists. ...hope that made sense; again, it's past 6 am now over here, and I'm quite tired EDIT: Sorata & Nanami talk (that is, the program and library ) continues here: http://www.the-gcn.com/topic/1815-n64zelda-hacking-tools-dlist-conversion-etc/?p=30025

Did you google or are you watching, too? NanamiRCP comes from Aoyama Nanami, too. Also, thanks for the encouragement so far, I do appreciate it

Three rewrites I started, give or take one, that never went anywhere later... one did go somewhere. Started in early December last year, stalling before Christmas, then being worked on again on and off during January, the thing is actually getting places. It's still not done, it's still not out, in fact there's still a whole lot of functionality missing, but the core components are - for a change - actually reasonably easy to work with, as opposed to the hackjobs that were SharpOcarina and the released SayakaGL. Please don't take this as an official announcement or anything, tho. I'm posting about this now for two reasons: first, to gauge interest. It's supposed to become an editor for existing scenes - moving actors, spawns, waypoints, the works, editing other header settings, etc. , as well as potentially actors - mainly moving around bones in hierarchies. Is there any interest in something like that, with Sayaka, OZMAV2, UoT, etc. existing? And the second reason for posting, simply so that I don't forget about it. Now that it's out in the open, and as I have a good feeling about this thing, it'll hopefully drive me to keep working on this, although PanelFlip for PSX is still the #1 priority because of the contest I want to enter with it. Anyway, two rather early WIP screenshots. The graphics/Ucode interpreter library (NanamiRCP) is working quite well already, while the OoT/MM-related stuff in the editor itself (SorataVSE) is still in its infancy, in the "rudimentary map/model viewer" phase to be exact. Once again, I have no idea when, or if, this'll be ready for release, just like with the previous Sayaka rewrite a few posts above. I am feeling better about this one tho, so... take that however you want. Although considering my awful track record with these things, who knows if anyone's actually still interested in the programs I write and post about... (Also, cookies for anyone who gets the reference in the names)

Thanks! Also, have a new video showcasing some Memory Card stuff:

A bunch of work has been done since I last posted here about this... more on the inside than on the outside, but there's still some stuff to show. SVN commit log first (January 13th to today), some screenshots and an album after that: Beginning of the visual style change, going from cartoonish to sleek/simple; big font changed, panel style changed (will re-add the previous one as an alternate), still more graphics to change Added gamemode for main menu; made Start on title screen advance to menu; tiny modifications to big font (some letter heights, fixed lowercase E) More main menu work, minor changes elsewhere (title BG) Modified big font, slightly improved menu graphics; added controls to menu; made menu actually -work- and get the player in-game; rearranged startup menu Added some background behind main menu entries Fixed fade brightness glitch in system code; improved mode change logic in main menu, ex. to allow return to title; other minor code/visual changes Started in-game overhaul: backgrounds & pause function added so far Minor AI changes; game now keeps track of occupied field height Added color-cycling to field BG as a height warning indicator; fixed date in GMSS startup debug message Updated makefile, emulator now expected in psxtools; added support for both controllers in GMSS & in-game 2P Versus Minor changes Preliminary stub code for memcard handling & message boxes Having slight slowdown issues (at least in part) due to the tiled scrolling BG; moved game logic processing to vsync, helped somewhat; need to rethink and rewrite the BG Improved memcard infrastructure & message box handling, game can detect and format cards, find, load and save its file, and continue without saving; still need to split some memcard code from src/modes/logo.c and turn into reusable functions for system/memcard.c Refactoring & expanding memcard support; created game-specific MC functions and structures, added calls to them to game code; cleaned up logo.c somewhat; still need to replace MC icon with an original one Improved error handling for memcard operations; added checksum and data ID to game data structure, game now checks file integrity ...and more memory card-related screenshots in here: http://imgur.com/a/HnNe8#0