spinout

Why, we could do that last time I talked to you on IRC... However, in most cases, it is disassemble and reassemble, as there is no decompiling yet - decompiling is a very,very tricky process. http://spinout182.com/dodongo/ http://spinout182.com/mqd/a http://spinout182.com/mqd/ovl http://64.vg/dr/node/75

Whatever is fastest so long as it doesn't look absolutely horrendous. I *do* enjoy being able to see debug screen printing, though (map select, time display etc). I'm not into configuring GFX plugins, I think Zeth made a thread a while back which had a tutorial on how to configure Rice video.

You are linking to an archaic version of OZMAV (which also has contributions by cooliscool and myself). Also, don't do direct links - a page with a description of what the download is would be ideal. For ozmav, something like http://code.google.com/p/ozmav or for z64anim https://bitbucket.org/otehr/z64anim e.g. Why? Direct links are more likely to "rot" than links to project pages, which are updated, whereas old versions may be deleted or moved as they become older. There is probably other stuff but I don't have time right now. Edit: Most of the stuff you linked to on z64dev.git.sourceforge.net is all depreciated - that is, replaced with something better. And talk about direct links! also I corrected you earlier but you must have missed it - I am the only author.

Remove the direct64 dll if you don't want that error. I threw about 15 GFX plugins into that emulator package. I really don't care about the paths in hyrule field, though you can configure the GFX plugin as it suits you and I'm sure you can get it working. The flickering thing is due to Rice video being designed and tested on PJ64 and 1964 but Nemu 64 still has the same standard (Zimlar's spec iirc) for gfx plugins. Nemu's sound emulation is also better than all emulators, LaC spent tons of time making it work as near as he could get it to work as an N64.

hi you guys missed something https://bitbucket.org/ottehr/z64-tex-ext (LOTS of info!)

http://i.imgur.com/gGnTX.png or something. If you are using Sketchup Pro's exporter, do not colorize the image inside of sketchup, as sketchup will blend the color into the image when it exports the material.

New build Edit: So, uh, is there any interest in this? If not, why? I know I would have killed for this program when I was still into this stuff but nobody has given me any feedback directly related to this program so I don't know what direction it needs to be taken in. I added a lot to the UI and it is much more user friendly than the previous releases, and have many windows builds but there isn't any feedback yet. Is the format too complex to work with? Need I create a higher-level interface which simplifies the complex format so it is easier to work with at an animator's level? I certainly want to see custom NPCs or enemies in future Zelda 64 hacks; what is the limit to anybody who would be doing something of the sort? As far as I have tested the OBJ importing provided by libobj and used by z64anim and objn64tool is completely working, what is the current roadblock? I want to write programs to help get things done, but I need to know what needs to be programmed.

No, try my download. It is properly configured to work with the Debug ROM.

(somewhat off topic but) Look what I found: http://byuu.org/programming/bps/ I think this community should adopt this kind of patch, it is both a more advanced format than ppf and isn't archaic freeware. Additionally, it could be streamlined into makefiles, at is it is both a graphical and command line application.

Why don't you want to use any new textures? And by alpha I mean transparent - in this case, 100% transparent.

If you're doing a paining I would recommend using a 32x32 (or two 64x32) PNGs with an alpha channel where the paint isn't and placing that on top of the marble "face", or putting the marble texture where the paint isn't to be. Additionally, if the paint is only to be one color (but perhaps different shades), then do the texture in greyscale and apply a color to it. This will use 1/3rd the space that a RGB texture would use. Please tell me if I haven't been clear.

Yes, all "foe modifications" must be done through (at least partial) ASM hacking. Think of each "actor" as it's own executable. There is no "table" that says actor x has z health, actor y has n health. They each work in a different way. Don't think of it as "HP", either - Zelda! isn't an RPG. For all the actor cares, it could die depending on how well or how quickly you fight it. btw, Stalfos have an amazing AI, only it's "reaction time" is slowed down. After playing any enemy in OoT more than 10 times it becomes quite easy to beat it.

That's the most reasonable text format in a game that I've ever heard. Standard line breaks are 0x0A == '\x0a' == '\n'. Windows, of course, breaks this rule for some stupid reason and does "\r\n". xdaniel: Looking good, as usual.

Re: Boss doors http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches#Lifting_Door

objn64 Strictly converts obj -> GBI C (uncompiled) most of the code by marshallh, I added triangle optimization + png support (in some versions) objn64tool Converts obj -> F3DEX2 binary and optionally obj -> z64 collision completely coded by myself (except for normal calculation) Additionally I wrote most of the collision and actor code for SM64toZ64 I have made considerable commits to ZSaten (object_human and link rendering implementation) Where are OZMAV and OZMAV2? zdump and ziff were experimental and won't compile, and are terribad (good ideas, bad implementation) z-filenew is a powerful hack which goes with applications specifically for and part of it to compress your Debug ROM - thus it can be considered a tool. ZAP, ZLE, ZLE2, ZAP2, ZAP2MM? I can upload if all you can find are rotten links ZAV/UoT - http://spinout182.com/uot/ (memories: I remember when I leaked UoT_MNGE.rar on ZSO IRC back in April '08) I think you should also have a section for libraries, such as libobj, libbadRDP and n64tool Additionally, wiki please. I'll try and write how-tos for all my programs on the wiki within the next week or something.

Yes and no.It has been known for quite some time that the DMA table can be 0'd and many errors PJ64 or other emulators run into are avoided (once the ROM with a new CRC is recognized by that emulator). However, if you want to ever compress the ROM, at least using Yaz0 compression, the DMA table has to be completely up to spec - all offsets consecutive, none running into eachother - even in their virtual addresses (which differ when the ROM is compressed). If emulators had HLE as good as Nemu64 they would be happy to run my z-filenew hack which doesn't care about order/overlappping offsets. The only thing I know that hack works on other than Nemu is -get this- an N64 itself. PJ64 and M64+ both fail unless they use a pure interpreter, which only is fast enough to play on newer computers.

It must be the graphics plugin. I know other ones exist (and have quite good results), but I don't know if they have windows builds available for download. What specifically do you want M64P for? If you are concerned about having it for the URA Project, now is not the time to worry about that - there is going to be a custom release for the URA Project.

The wiki would, ideally, contain all of that. I just wrote an article for libobj/objn64tool (do note, objn64tool != objn64), and I updated a few other pages.

http://wiki.spinout182.com/w/Category:Software ? No need to do things twice, just keep the wiki updated. It is intended to be a 'one-stop-shop'.

Yes. Edit: Download Commit It's mostly just a few fixes (nothing fatal was happening, just wasn't running 100% as intended) Edit: utub

I added more HUD stuff to z64anim, it now tells you current animation and selection information. I also added some more keyboard shortcuts for the SDL window, run the help command to see them. Download Commit Going to edit this post in a second to give an image of it...

Try:clip.min.x = dl_min.x - draw_distance; clip.min.z = dl_min.z - draw_distance; clip.max.x = dl_max.x + draw_distance; clip.max.z = dl_max.z + draw_distance; You could also go around this whole problem by setting the 'far' display list to the same one as the near display list.

Strange. I don't care about the MS error window, but try: mupen64plus-ui-console.exe --emumode 0 ROM.z64

Updates on two of the things that this thread isn't (lol): z64anim has some new features: - hud display, from xdaniel's ozmav - getopt arguments (old drag & drop still works) - a few new screen controls (arrow keys to select child/parent/next/previous limb) Download Commit libobj has a new mirroring "solution" which solves the problem with mirrored textures: lack of support in modeling programs. ozmav2 got around this problem by literally mirroring on exports, but when re-imported, a texture could take 2x or 4x the space it originally did. xdaniel and I agreed upon a solution: putting the mirroring settings in the filename of the textures that are mirrored in the file but are to be halved on their height and or widths. For the end user, it should end up being completely out of their mind. I also had the call to the collision fixing code commented out in the last build of libobj, so here's the latest: Download Commit

From what I can see in that screenshot, it all looks good, but could you take another which has the last text in the cmd window? It looks like it isn't scrolled down all the way so I can't see what went wrong.