SoulofDeity

that could be used for some things like but for stuff like not so much... at least I know for sure there is a stencil buffer though now

So I've been working on a high-performance game engine for quite some time and have spent the day trying really hard to understand how the sepia / monochrome filters and motion blurring effects work in Zelda games. Mostly, the later of them. In OpenGL, there is something called an accumulation buffer which can be used to create motion trails through vector calculations. Buuutt...the N64 doesn't have one...nor do many pc ATI gpu's. The more I think about it, the more it seems like black magic... What is known about the N64: It has a 16-bit color buffer It has a 16-bit depth buffer most likely has a 1-bit stencil buffer. I've digged through the sdk a little and don't remember seeing anything about a stencil buffer, but effects like and suggest this is in fact true. ----------------------------------------------------------------------------------------- For those who don't work with 3d graphics a short explanation; there are 3 main types of framebuffers in 3d graphics. The first is what you actually see like in the pictures above and is called the color buffer. The second is called the depth buffer, and is used to keep track of the depth of 3d objects that have been rendered. A visual example of what this looks like is Basically, whatever is brighter is closer and whatever is darker is further away. So, when rendering an object, if the new depth is "brighter" than the current one then the pixel gets drawn, otherwise the previous pixels are in front of the new ones. The third is called the stencil buffer, and as the name suggests acts like a stencil to determine what should and shouldn't be rendered. A visual example of what this looks like is When the stencil is enabled, whatever part of the color buffer that line up with the white parts of the stencil will be rendered, and whatever lines up with the black won't. Typically, stencil buffering is used to create shadows, masks (like the lens of truth eyehole), screen transition effects *cough* and dissolving effects like ------------------------------------------------------------------ BUT BACK ON TOPIC.... How does Majora's Mask achieve motion blurring? Some possibilities: Answer: The just don't clear the last depth buffer Problems: Some maps that make use of blurring like the inside of the moon have skyboxes, which would overwrite the previous frame anyway. Answer: They don't clear the last depth buffer AND render a translucent clearcolor or skybox Problems: Even if the skybox doesn't occlude the model, the map and other objects will still overwrite them. Answer: They render to offscreen framebuffers as textures and layer them Problems: Even for a poor resolution of 320x240, a single offscreen framebuffer would be 0x25800 bytes in size, or 0.14Mb, while the N64 only has 4Mb of ram (8Mb with the expansion pak). Offscreen layering requires several of these buffers and wastes a lot of what little precious ram the N64 has to offer This method requires altering the framebuffer manually which is cpu intensive. It may not be a big deal for your 2.3Ghz pc, but for an N64 running at approximately 6.1% of that speed struggling to maintain a mere 20fps, this would be a nightmare. Most N64 plugins don't support proper framebuffer emulation but still manage to somehow pull of the motion blur effect Answer: They don't clear the color buffer and render everything at partial opacity Problems: The only way to control the opacity of the rendering would be to control the environment or primitive alpha colors and mux every display list the game with them properly. Of course, anyone who screwed around with combiner modes can tell you this just doesn't happen. ~My First Theory: They are using a stencil dissolve effect between frames. By alternateing checkered patterns, they could be interleaving the current frame with the last one, leaving afterimages and producing a motion blur effect. ~My Second Theory: They are stenciling the depth buffer to prevent certain objects from being rendered over. Possibly clearing with a bright translucent color, or darkening the preserved portions of the depth buffer to fade them ======================================================== So, thoughts? Are there any problems you see with my theories, or have any of your own? I'm really interested in finding a fast solution for cross-platform motion blurring for my game engine, so chip in!

Yeah. Audio files are pretty big, and with speech you can't downsample it too much before it becomes illiterate. Adding new audio to the game would also require relocating and resizing the audio table. Dialog for all cutscenes in the game might not fit into the unused space of the rom.

XDAN. Just had this idea. Suppose you had a combiner mode of Color 0: (TEXEL0 - 0) * 1 + 0 Alpha 0: (0 - 0) * 0 + 1 Color 1: (COMBINED - 0) * SHADE + 0) Alpha 1: (COMBINED - PRIMITIVE) * 1 + 0 Basically, the idea is to combine the texture normally for cycle 1, then subtract the primitive color for the alpha and apply shading for cycle 2. I haven't tested it yet, but if it works like I think it might, it'd allow for soft color keying with the primitive color as the index. Then you could have alpha with any texture format without requiring a mask. This seems kinda redundant with the CENTER / SCALE combiner muxes, but I think I remember reading somewhere in the sdk manual that it was only a planned feature and never actually implemented.

well...I'm just saying, but the physical memory map of the n64 in the sdk states that 248MB of address space is for the cartridge data. a decompressed zelda rom is only 64MB, and even much of that it unused as well. wouldn't be easy, but I'm sure its possible. whether or not there are any emulators that can support rom sizes > 64MB is another question. EDIT: just want to put on record: OoT and MM are both 64MB. (64MB + 64MB = 128MB) < 248MB.

Relevant. Seriously though, my worst injury was when I was attacked by my jack russel. Fucker ripped my wrist, knees, and stomache open. Small dog doesn't always mean all bark...

made a video showing off the last 3 mods I posted

Got bored and redone some of my older mods, 2 of which I never uploaded because I was going to use them in my own project before. All are for OoT 1.0 (U) Megaton Hammer -> Iron Knuckle Axe - Fixed the combiner mode so the blade is silver instead of green and stopped it from giving UoT trash display lists OoT Hookshot -> MM Hookshot - Added an icon, made independant of the hero bow, and managed to import it without having to scale down the textures by using one of the fairy bow's vertex data as a buffer and redirecting them to the hi-poly fairy bow. Fairy Bow -> Hero Bow - Added icons and inventory text, made independant of the MM hookshot, and managed to import it without having to scale down the textures. As the names of the files suggests, there's no GI items made for them, but whatev. Might do those later if I'm still bored

He has 100 posts. If he was a bot, he'd have been banned a long time ago. :S I didn't notice the post count until after I replied. Just the way it was worded sounded exactly like the 200-300 other bot advertisements I've seen on youtube and the mangahere comments section

XD A little too much... I vote unicorn, it reminds me of Mr. Toots from Red Faction

Afaik, she's only hooking it for the intro scene and final battle, not replacing it.

if you are human...*skeptical* o.o ....then nice contribution...else gtfo we don't need ur kind

... (pic below not 4 teh kiddies)

Was talking to the guy I've been helping out and he was having trouble importing scene 008 from MM into blender. Kept getting a blank mesh. Realized that scenes could actually have several headers, so I fixed z64dump3 to locate all the headers within zscenes for zmap exporting. Also changed the naming scheme for maps to: mmm # mapname.zmap where 'm' is the index of the map's entry in the scene header's map list. Download Fixed Version

Sorry, I misread that and thought you were meaning like gyroscopic projection or immersive 3d like In that case, I agree that the use of a gyroscope is pointless with parallax 3d because you can hardly focus. To be honest, I don't like gyroscopes in gaming at all. I hate motion controls.

You obviously have no idea how the 3ds works. It's not a gyro effect, it's parallax screen diffusion. There's a there's a thin filter over the screen that refracts the light such that at a distance of between 1-3ft half the light will only be seen by your left eye and half only by your right, meaning your left and right eyes are seeing the same images but from 2 slightly different angles. This difference confuses the brain into percieving depth. This is why the 3d effect of the 3ds doesn't require glasses. It doesn't pop out of the screen, it extends into it.

O_O is...is that...could it be? If that's what is, I love you long time <3 Seriously, I would do anything for OoA 3D ;_; Made this this morning just for GIMP practice Now, back to fapping at Bobbo's Hyrule throneroom...

Oh, Nintendo 2DS.... Original Poem by SoulofDeity Pure Brilliance. A slate, a plate, a paperweight. Sturdy, bolstered, charges in toaster. Lightweight, simple, and doesn't bend. In dire moments a shuriken. It's flat, and gay (in a good way). A cheap gimmick...wait...that's not optimistic... $129? I know where they can stick it.

yeah, I tried modding SSB64 once and ran into the same problem. it's because a lot of the developers were retards and used virtual addresses with the RSP instead of using the segment table like the manual tells them to do.

technically...they're just the original names of the source files that make up code.zasm

I cleaned up after you with the pooper scooper cause you're my dog. touche. I wrap the hill the aluminum foil because I hate cats.

Probably because YY00 is actually 'YYYY', an s10.5 fixed point value like most coordinates in game. the coordinate range is -1024 to 1023, so I can see a value of 0x1000 (128), possibly engulfing kakariko EDIT: And to answer the question, it's probably more likely that they are 2 bytes, since registers are loaded and stored 16-bits at a time in mips (though it is possible, yet tedious, to load/store single bytes)

Sucks to be you...

I shat on the top of the hill. As you were.

Finally done Download z64dump3 Download source What it does: byteswaps the rom if needed locates the code file locates the file, scene, actor, and object tables using smart search techniques (no hardcoded addresses) extracts scenes, maps, objects, and actors and decompresses them if needed. uses the name table for file names if one exists What it doesn't do: extract files that aren't inside the scene, object, or actor tables (because it's intended to match actors to objects and maps to scenes. if I wanted to write a rom decompresser, I'd just be reinventing the wheel since zdec already existsThe output is a file tree of the following format: - data | :- actors | | | '- # (hexadecimal group number for each actor group) | | | '- aaa-ooo # name.zactor (hex actor#-object# and file name for each actor) | :- objects | | | '- ooo # name.zobj (hex object# and file name for each object | :- scenes | | | '- # (decimal scene number for each scene) | | | :- maps | | | | | '- name.zmap (for each map file in this scene) | | | '- name.zscene (scene file for this scene) | :- gk_ooo # name.zobj (gameplay_keep) :- fk_ooo # name.zobj (gameplay_field_keep) '- dk_ooo # name.zobj (gameplay_dangeon_keep) I'm sure those who want to work with the OoT 1.0 or MM roms will find this tool an invaluable asset.