SoulofDeity

There are 5 skyboxes; dawn, day, dusk, night, and storm. Also, the reason why there are no stars is that the clouds are animated by rotating the skybox; so if there were stars they would be moving all over the place. You could use the GDS to hack in a secondary skybox that's slightly smaller and uses cloud textures; then adjusts the modelview matrix to make the original skybox remain stationary.

Yeah, there's a reason for that actually. Here's a rip from the game: The order is front, back, left, right, top. Notice the black seam on the bottom and right. The textures themselves are only 125x64 and 125x125. The visible part of the texture is scaled up to fit the full 128x64 and 128x128 size and cut into 32x32 tiles. The seam is most likely due to this scaling.

Finally, shader support! Btw, if it helps any since you stated you're a little new to GLSL, here's an easy way to visualize how OpenGL3+ works. I hate how most tutorials just throw code at you without explaining what each object does...

Thanks for the feedback It is a little difficult to get a good quality image in the game though because the textures use a 128-bit palette. Thanks to my discovery of the GDS earlier though, it's possible to change the texture format, color, or shape of the skybox as well if you wanted to. I'm working on writing a tutorial to modify the interface right now.

Just something I was tinkering around with for a bit; I replaced the daytime skybox texture in the game Was a little tricky because it uses an awkward palette size. EDIT: Trying out a sunset skybox

*Re-upload of fixed v4 Blender import script io_zelda64_v4 download (removes line added by RodLima that causes crash at bl_info block)

It doesn't name all of the files, but a program I wrote a long time ago called z64dump3 would probably help a lot. It decompresses and extracts roms into a data directory; the first 3 files are have the names: dk_NNN # XXXXXXXX - XXXXXXXX.zobj fk_NNN # XXXXXXXX - XXXXXXXX.zobj gk_NNN # XXXXXXXX - XXXXXXXX.zobj Where dk/fk/gk stands for dungeon/field/gameplay keep; N is the index in the object table of the rom, and X is the start / end offset of the file. There are also 3 subdirectories for actors, objects, and scenes. Inside the actors directory, there is a subdirectory for each actor type. They numbered in hexadecimal, but each folder should contain different types of actors. Each actor has the name format: AAA-OOO # XXXXXXXX - XXXXXXXX.zactorWhere A is the index in the actor table, O is the index of it's corresponding object in the object table, and X is the start / end offset. Likewise, inside the objects folder is a list of objects with the name format: OOO # XXXXXXXX - XXXXXXXX.zobjSo you should have no problem matching the actors to their objects. Inside the scene folder is a bunch of directories, where each directory represents an index in the scene table. Inside each directory is a single .zscene file and a subdirectory containing all of it's corresponding maps. Just drag and drop, works on any Zelda rom (OoT or MM). It only extracts the actors, objects, scenes, maps, and keeps; but it definitely saves a lot of time. You can download it here EDIT: Just some additional info, you might want to run it from the command line like: z64dump3 myrom.z64 >> log.txt As it prints the offsets of all the tables, so you can use them for reference later.

It depends. Just keep in mind I'm pretty rusty, I haven't even touched a rom in about a year.

Hey guys, I'm back. I have a goal in mind that requires a lot of mips experience and the need to reacquaint myself with the N64's RDP; so for practice-sake, I'm going to pick up modding again. To be honest, I've kinda missed the community. I think if I can find a good balance in my priorities, I may just end up staying permanently this time.

New theme is fappable. ~Deity approved~ Shoutbox doesn't seem to be working though. EDIT: And everyone's reputation seems to be reset. EDIT2: Aaaannnd lost profile picture...Site is losing it's fappability by the second...

I never said they shouldn't have a life. I made a point that 10 or so people working on a single project for nearly 2 years and should have at least something to show for it by now. You say you make no promises but progress is being made, you've shown no work but get mad when people ask if the project is cancelled after a questionable name change. --- Anyway, last post in this topic...I'm entering debate mode and I hate long and awkward fights. --- EDIT: Just wanted to say sorry for the bs. I get worked up easily, think too much, am too defensive of my opinions, and say one too many words. I'm also really bad at phrasing exactly what it is I'm trying to say without coming off as arrogant and bitchy.

No, the reason they seem unreasonable is because they've never been done. Anything is possible, it's "technically" possible to dissassemble the entire game and all it's resources into a project folder, change what you want, and rebuild the rom from scratch. The point is those things have never been done, and there is no one with experience doing so. And like I said. all custom (from scratch, not modified) actors to date have done nothing but stand there. Talking is cool, but it's not the same as interacting physically. Of course you do now X_X. If at least some of that stuff hadn't been found after 2 years of work, it'd be really pathetic. >_> The point I was making is that the information is not readily available to the public, and to a person starting with jack squat a lot of research would have to be made to get all the resources needed. ------------- And also, claiming to have made progress, but not showing anything is pretty much the same as making a promise. You make people expect to see something at some point in time. It's not about entitlement, it's about attention. You wouldn't walk into a hotel lobby and shout "EVERYONE LOOK OVER HERE!!" then question wtf they're looking at you

- Then name this cool stuff. I want to see where the things I've mentioned have been done. Yes, assembly modding is easy with practice, but possible != reasonable - It does depending on what you're searching for. stuff like actor spawning, dma'ing, file loading, and audio playing functions being some of your basic stuff (which you'll also have to figure out the fields for). you'll also want ram maps for things like player savedata and states which much of which can admittedly be reverse engineered from gs codes, and you'll possible want to find to good places to install hooks to get your code patched to the rom so the people don't have to enable 3000 lines of gs codes. - I am serious. When I first joined the team, I asked how long the project had been going before I joined and Mellow had stated around 6-9 months; that they just hadn't announced publicly yet. ~and I quit almost a year ago, I believe some time around early october last year ---------------- EDIT: I know this is coming off like I'm bashing this project, and I'm honestly not trying to. I'm just agreeing with something someone pointed out a few posts ago that if anything is in game at all, no matter how miniscule, show something. Let the people see that progress is being made, don't drag them to the top of the stair well by the nose with false promises and push them down say "we lied" or just blatantly disappearing / faking your deaths.

this project has been ongoing for like 2 years. those are not valid excuses for why nothing is in game yet. EDIT: correction: nothing ~shown~ in game yet. I'm not on the team anymore, so I have no idea what actually is or isn't in game at the moment.

Seems suspicious...

I know rite? ----------------- Great work on the UI Another cool think to add would be letting the user change the menu color. Would love to have a tool like this for OoT as well, gold is so much sexier than blue/red/green/yellow rock

I think this was before you joined the team. I left shortly after bobbo joined.

That was the main reason I decided to leave the team as well. Every time I tried to say something, everyone got pissed at me. After over a decade of modding OoT, assembly modding has never matured enough to do too much with. There have been no custom enemies, no custom weapons (just altered display lists and actor spawns), and there have been only 3 or 4 custom actors created, all of which did nothing but stand there. From a programmers perspective, it is possible to create custom enemies and weapons. It's also possible to make link turn into a fire-breathing Rito that farts rasenshurikens, but realistically speaking there is no one with any experience in doing such things. Especially on MM where there is literally no assembly documentation at all, and would require possibly several weeks of tedious hair yanking to get half the knowledge of that is known about the debug rom. Then you gotta take into consideration that most modding tools are made specifically for OoT, and while the MM engine is based on OoT, there are many differences which make the tools go apeshit. For example, MM uses 1-environment color for a majority of it's combiner instructions to contrast lighting to make the game feel bolder, which makes a lot of the maps and objects miscolored or even black. It also uses a different texture loading patterns such that palette are loaded before textures instead of after like OoT, which causes wacky texture glitches and crashes in programs like UoT. The scene table entires are 4 bytes smaller, the empty entries in the file table are marked differently. MM gets wacky with segment allocations using segments like 07 in maps which in OoT is specifically reserved for link animations. This turned into a bit of a lecture, but I just felt it needed to be stated there are a lot more differences between the OoT and MM game engines than people think, and assembly modding does not make you a god.

The first one I was like. "Dude! That's badass!! But why does Link sound like a girl..." The second one was just a jawdropping wtf

More creative and imaginative, yes, but to people who already knew it as "Project Antiqua" or simply "Antiqua" for short, the first thing that might register in their heads when they see a topic called "Fall of Antiqua" is that it's been cancelled... Least that's how I read it at first too until I saw the logo on the first page.

K, so the advice did come off as rude, but I agree the use of "Taint" made me rofl. Especially when the reiteration that "Unfortunately I have been able to confirm that she has perished from the Taint." XD Sorry, I've seen jackass a few times and mind just immediately jumps to the dark side... Anyway, this definately does seem interesting, and I can see the improvement with each page. I read a lot of manga so I'll probably be keeping an eye on this

I think this may be case closed for the motion blur mystery Guess it's on to the sepia / monochrome filters now? Obviously a full framebuffer color lerp would be too cpu intensive. The color combiner supports a YUV color conversion, so one thought is that they're just cranking down the UV. I tried looking for the instruction that does this before in OoT and only found one in the entire game, but I wasn't able to test it to see if that was it. (the sepia filter is only shown at the end cutscene, and I was lazy). Haven't looked into MM, but it might be possible. Isn't really a cross-platform thing though, any thoughts on what else they could've done?

Thats right O_O fog affects depth! so on top of gradually fading out the after image in the color buffer, it'll fade it out in the depth buffer, and if they multiply the stencil by the depth then when the depth of the afterimage reaches 0 it'll automatically be removed from the stencil buffer!

I just had another idea; what if they rendered all the objects to the stencil buffer, but only enabled the stencil for normal rendering and not fog? if it was done like that then the afterimages would stay onscreen and since fog is translucent, each frame would fade it more and more until it was gone. then it's just a question of knowing when certain things should be removed from the stencil buffer :/

The problem with that is that it requires at least 2 offscreen framebuffers since the game uses double-buffering, which adds up to 0.28Mb, and with TMEM limitations would require manual blending. I'd normally jump to the idea of combiner foreplay too, but each display list changes it so that can't be it either...