xdaniel

This program itself isn't capable of adding anything right now, but once importers either directly support adding of waypoint data or leave enough space in the header and elsewhere in the file to do it manually, then SayakaGL should be able to let you edit them - that is, once it's compatible with custom maps anyway, which it currently (still) isn't.

This is great, and I totally disagree with Falco that "this is horrible"

DigitalZero Domain [V4] Not really updated in two years, besides an obligatory "sorry for the lack of updates!" news post this January, and hal(?) of it is in German.

Should be doable, but might take some time, so I'm not going to tackle this right away. It really is a good idea tho, as should be obvious from the carpenter's floating boss Also, not really anything new to report for now, besides that I turned 24 and because of that haven't had the chance to work on the program over the weekend. Fixed a few minor bugs this evening, but nothing earth-shattering or anything.

First of all, see if there's already a program that might be capable of loading the models you want to view. Consoles/handhelds with filesystems tend to use standardised file formats for models, textures, videos, sounds, etc., recognizable by the file extension or the first few bytes in the file (often an ID of a few letters) Not all developers use such, however, so chances are that there isn't a tool for that specific file type yet. If there's no tool, check if there's at least existing documentation about the format (maybe incomplete, otherwise there would probably be a tool) which should help when starting out writing a model viewer; technical docs about the system itself are useful, too. Then - unless you know your way around emulator's debugging functions, if they even provide some that might help here - poking around the files with a hex editor tends to be the next step. Identifying what files contain what and where is easier nowadays, because of file extensions, in-file IDs and plain filenames, as compared to ex. N64 ROMs which are, at the first glance, just big binary blobs. Hypothetically speaking, you've got a 3D adventure game or RPG, and there might be a file called "twn001.lvl". The filename already implies that it might be related to a town ("twn"), and that it might be the actual level data ("lvl"). Using a hex editor, inside you might encounter short ID tags like "LEVL", "TXTR", "VRTX", "POLY" or so, which denote what kind of data follows - after "LEVL" might be things like the level's in-game name, "TXTR" might be followed by the level's textures, "VRTX" could be followed by the vertices that make up the model's polygons, "POLY" might be the actual polygon definitions. It's more or less about recognizing possible structures inside a binary file - "similar looking" bytes of data, repeating in a specific pattern of maybe 16 bytes of length, might - for example - be a list of vertices; a vertex on the N64 looks kinda like this, 6 bytes of X/Y/Z position, 4 bytes of S/T texture coordinates, two null bytes, 4 bytes of R/G/B/A coloring (or vertex normals, but that's another subject). Byte alignments are another thing to look out for; to take the N64 as an example again, depending on what kind of data it is, it has to start on an even number - display list commands, for example, are 8 bytes long each, and have to start at either x0 or x8, so ex. offset 01A28 is okay, while 01A2A or 01A23 aren't. I hope that helps somehow, and doesn't sound too difficult or anything. It is difficult if you've got nothing to base your work on, like documentation etc., but even then it's not impossible - the first emulators to come out didn't have the luxury of leaked official documents to tell them how things worked, either

Complain to the original developers, they've always been like that Also, general little overview video for the program:

Uhh... well... uh... ...the interview is over! >.<" No no, just joking Well, the thing's supposed to become a good, user-friendly level editor for the N64 Zelda games, which is probably obvious. Basically OZMAV2 with a UoT-ish interface and its editing features. UoT is pretty good, but somewhat buggy and also practically dead, and OZMAV2 is too complicated for the casual user (and maybe for its own good). This is kinda to be a replacement for both, or that's what I hope it might become someday anyway. Problems are mainly me trying to get around in C#, because this is just my second real project made using that language, and despite many similarities with C, it's still somewhat different. Also there's some rendering quirks most viewers/editors for Zelda have, such as the missing transparency with ex. the paths in Hyrule Field or incorrect texture repeating/clamping in many of Majora's Mask's maps.

Handhelds don't have that 50/60Hz difference that consoles have, because it stems from the PAL and NTSC television broadcast formats. DS games, for example, of different regions all run at the same speed on hardware of different regions. Japanese game on European DS, no problem, same speed as the same game as a European version would have on an American DS. On handhelds, it's pretty much all down to how well the developers know their way around the hardware, getting the best possible speed out of it. The one thing that the 3DS does have is region coding, so you won't be able to play an imported game on your domestic system, unless some kind of hack comes out at some point. No idea about how or if that affects backwards compatibility with DS games.

You're so not going to get any objective answers on that one. Everyone appears to have one rock soild opinion, that is that one of them is shit and the other is the greatest thing since sliced bread. I have an opinion, but (while not that severe) it's still not objective at all, so I'm not gonna state it - people can probably guess, tho.

Fixed up something that hasn't been in one of my viewers since the original OZMAV: selecting which scene and room header to use. For comparison, first is a screenshot from Adult Link's Kakariko and the old guy walking back and forth there, second is basically the same thing shown in SayakaGL: The scene header is selected via the dropdown list in the brand-new toolbar, the room header is selected by right-clicking the room in the room list, and then selecting the room header in the menu. Still have to properly test if saving works correctly when, say, trying to modify actors defined in different room headers... Oh yeah, another minor addition, you can now tell Sayaka to render all rooms at once via the menu, instead of having to select all the rooms in the list manually. I believe that was a suggesion from Naxylldritt, so yeah. It's in now Also, something only semi-related - Nemu "crashing" earlier today, while I was messing around with the game. Note that the game still ran, complete with controls, despite the "nemu64.exe has caused a problem and has to be shut down" message box and the messed up graphics: http://i.imgur.com/U3IBS.png

Well, then I'd like the title "Haruhi Suzumiya", because it's shorter than "ultimate supreme etc." and still basically implies god Anyway, yeah, while I was looking for something completely unrelated, I stumbled across those. I do not yet know how the game knows which path to assign to which actor, tho. At least for the carpenters in Kakariko, it's the first byte of the actor's variable. Messaged spinout earlier with my findings, and maybe he's got an idea, or even knows more about those waypoints already. I'll look into adding editing of those for the next tester build. Also, Majora's Mask is full of those - literally:

I'll just leave this here:

...yes, you did. I didn't know you could edit PM replies o.O Well, gotta go and read~

Alright, recent changes... - Ucode interpreter slightly improved; mainly GeometryMode, OtherMode_L and texture coordinate generation - Command editors for OtherMode_L, Vtx, Tri1 and Tri2 added, one for GeometryMode started but is still slightly broken - New class for text printing, as used for the FPS display, because the old one (included with the texture library I'm using) basically wasn't really to my liking - Some other changes under the hood Also, would the testers please speak up? (Because if I progress much more, I need to send you a new build to test )

Uh, hello? This mainly concerns Hudson Entertainment, NOT their parent Hudson Soft in Japan! The Mario Party games were developed in Japan to begin with, and Nintendo published them. Of course it's sad to see their US branch go (again), and how Konami wants to shift Hudson Soft's focus to social games, but it doesn't spell the end of the company as a whole. And as for Mario Party, even if Hudson Soft won't make them anymore because of the social games crap, I don't think Nintendo would let a profitable series like that just die off - if anything, they'll just develop them in-house instead, or give them to HAL or whoever else.

Salvage66: Skype of all things I'm not giving out to / accept everyone on, sorry. Feel free to contact me ex. here via PM or so, tho Also, started the OtherMode_L command editor - basically a list with checkboxes to enable and disable its settings -, for example, here I disabled Hyrule Field's water's Z_CMP option (that is, depth testing):

While waiting for feedback, I've been messing around with the Display List and combiner editors... not changing the editors, but actually using them. Got something a bit more impressive than yellow castle walls this time around: Excluding the now enabled skybox, the coloring and transparency effects were all done using SayakaGL alone. I think this looks pretty nice, doesn't it?

The green tinting on the last two screenshot (and the red stuff before, I changed the color) is actually the currently selected Display List, color editing only came with that last status update Anyway, next update: First, a big speedup because I changed my rendering method around, now you can load up the whole Fire Temple at once and still move around it with relative speed. Overall, OZMAV2 is still faster, but it's not as severe of a difference anymore. Hope it stays that way. And second, the combiner editor is pretty much done, allowing you to play around with each combiner setup. The labels in between each element are wrong, as I just noticed looking at the screenshot again, but they'll be fixed right away =P Saving still isn't coded in yet, tho - I will start working on actor placement next (with just cubes for now), then look into saving. Shouldn't be too big of a deal to implement. EDIT: Now with our old friends, the actor cubes! ...I soo need to get the texture of the Weighted Companion Cube XD EDIT 2: Actor editing and saving changes to ROM is in; but still needs some testing EDIT 3: Screenshot-less update this time, actor selection via mouse is now in as well; still need to implement moving them that way. And while not copy and pasted directly (doesn't work anyway, with VB vs C#), much of the code was based on UoT's

Zeth: I'm probably going to work on it again, but I have no idea when. I've kept myself busy with other new projects, instead of fixing up old ones, which is quite typical of me... We'll see about it, I guess. Now, as for this one: Editing PrimColor and EnvColor is in and working correctly; just click the colored box in the lower right to pick a color, change the alpha value with the numerical selector if you want, and press the button. The changed colors should be visible in the level right away - well, at least if your geometry's color/alpha is determined by what you changed anyway, there's plenty of other ways after all Haven't coded up any saving routines yet, so it's still a temporary change for now.

The texture loader is done, the combiner is done, GeometryMode and OtherMode_L are in a presentable state, what's left for now in terms of the Display List interpreter is mainly RDPHalf and DList branches using that (used in, if I recall, Kakariko for the well, and Gerudo Valley for the river area). I also started working on the DList editing part of the program, it's so far capable of finding the selected command in the stored Display List; next will be the implementing of the actual editing part, writing the Display List back to the room file, and then saving the modified file to ROM. A significant bug that I'm not yet able to track down is related to OpenGL's lighting - for some reason, the lighting setup I've been using for OZMAV2 doesn't work right here, which results in way too much darkness around the maps, as you can see on the right of the screenshot.

Maybe this helps: http://msdn.microsoft.com/en-us/library/system.componentmodel.design.byteviewer.aspx - Not sure if it allows editing, tho, haven't tried it yet. You might also be able to find a premade hex editor control for VB somewhere, otherwise it's gonna be quite a bit of work, I'd imagine.

Uhm... define "hex box"? What exactly do you mean? A textbox to enter hexadecimal values into? If so, what programming language and/or GUI library are you using? C++, VB, C#?

Salvage66: I actually haven't been talking to him recently (that is, via YouTube messages or comments and such), I've just been looking at UoT's source to get an idea of how he did stuff, compared to how I did it in OZMAV2. He does seem to still use YouTube regularly, tho, so you might be able to get ahold of him that way.

It's kinda OZMAV2's internal design, plus a GUI styled after and certain technical elements (data management, etc.) inspired by UoT, written in C#. I'm basically trying to make a more user-friendly OZMAV2, comparable in features to UoT, and it's going rather well so far. There's still a bunch of stuff to do, but it's already capable of loading and identifying ROMs, reading the DMA table and the scene table, loading, interpreting and rendering scenes and their rooms, proper camera movement and some more. All that said, here's another screenshot with (finally, mostly) proper textures - next up will be finishing up the rest of the Display List interpreter, mainly GeometryMode, OtherMode_L and _H, the combiner and a few other bits and pieces: Showing the Dodongo's Cavern main hall, with one of its Display Lists highlighted - I really have to give credit to cool for quite a bit in terms of ideas and the like here