Water Animation (generic texture transition)

[Airikita]

 

Water display list:

 

From testing, removing DE000000 08000000 stops the waterfall from animating and DE000000 09000000 is what controls the pond water texture animation. These appear to be generic texture transitions, as these can be found in actor models as well (possibly Like-Likes would have this).

[xdaniel]

Not "generic" in the sense that you can put those commands into any display list and expect the texture to animate. If these RAM segments (0x08, 0x09) aren't set up, or not to what the game expects at this point, undefined behavior will happen, crashes being likely.

 

Scenes set up these according to the barely documented "scene configuration" part of the scene table entry. There's another table elsewhere which that "scene configuration" value is an index into or somesuch. Forgot the details, but I remember posting about this before, either here or on z64. Dunno how actor models work, but I assume that each actor's code sets up RAM segments, etc. if needed.

 

EDIT: First two spoiler blocks, also DeathBasket's post two posts later: https://www.the-gcn.com/topic/600-xdaniels-random-junk/page-4?hl=0x08&do=findComment&comment=10695

[Airikita]

Well, it works to some actors to some degree, as it is within object_rr as well. But, it could be akin to having to have a proper rendering function, such as it is with rendering matrices in some actors while others do not have the same rendering.

[xdaniel]

As I was saying, if those RAM segments aren't set up the way they should, it won't work, and if something already contains commands that call segments 0x08 or 0x09, then they obviously are.

 

I just mean that you shouldn't expect something that does not already use animated textures - say ex. the gravestone actor model or anything else like it - to suddenly animate if you just insert one of those commands into their display lists. I'm 99% sure you'll have to modify the actor's code for that.

[Airikita]

Well yes, because the actor does affect its inline model, but when it's an external zobj like the Like-Like, I can't be sure on that, but it's possible.

[Jason777]

From what I remember, you can set RAM segments up with DB commands (though one commonly uses "DB06"). You can find more information about it in the z64-tex-ext hack made by spinout. It also makes much use of segment table at 0x80166FA8, the current display list command pointer at z_ctxt + 0x2C0 (0x802122E0), and the other z_ctxt + 0x2D0 (0x802122F0) where z_ctxt is 0x80212020.
 

Although z64-tex-ext does successfully implement an animated texture hack, I wouldn't recommend using it because it isn't too flexible; you can't have multiple animating textures in the same map using the hack and you are limited to using only a single texture. Also, from my experience with writing an automated tool that compiles, modifies, and inserts the hack for you, it doesn't work reliably with all maps.

 

However, the hack is a great thing to study concerning the subject of animated textures.

 

Links of interest:

• z64-tex-ext: https://bitbucket.org/ottehr/z64-tex-ext/wiki/Home
• Look specifically at the functions "set_segment" and "dl_write" contained within this source file -- they setup RAM segments by adding display list commands: https://bitbucket.org/ottehr/z64-tex-ext/src/f4efd2eb0fc098185c029a787ce47b97bcb3be67/run_code/run_code.c?at=default
• Some information on DB commands: https://www.the-gcn.com/topic/1089-would-it-be-possible-to/

 

A long time ago, I had asked Flotonic how he got animated textures working in custom maps. I would have to dig up the old chat log (I know I still have it), but the gist of it was...

• Replace a scene that already had animated textures (this was probably done so that the original scene configuration as scene in the scene table would still have references to the animation code)
• Make the texture you want to replace part of an entirely separate display list... try placing the display list at the end of the map file so you can make modifications/insertions without disturbing other pointers within the map
• Insert a "DE 00 00 00 XX 00 00 00" where XX is a RAM segment 08+ somewhere after a definition of the texture. You might have to play around with the values in order to get it working

 

Any other information is probably linked to by xdaniel in the other topic you made about animated textures.

 

EDIT: Also, if you're trying to find special graphical effects in actors, I would recommend looking for instructions that utilize z_ctxt or contain opcodes like "lui 0xDB06" or "lui 0xDE00", etc.

EDIT2: Not much else and I'm sure you're well aware of this topic... but just in case: https://www.the-gcn.com/topic/2883-water-animation-mystery-solved/

[Airikita]

I think it falls back to the values scenes use in the list of scenes, such as how Kokiri Forest has this entry:

0288D000 0289E240 01A4D000 01A4F880 0004 0000

 

Then where 0004 is, that would indicate the type of animation to that map, and then whichever display list contains DE000000 08000000 or DE000000 09000000 would animate the water for that value, since that is what the scene would imply.

[Jason777]

Exactly. However, if you wanted to make "new" animations for textures to use, DB commands would be the way to go. The only part where I'm a little stuck is the placement of the DE command in relation to other commands in the display list.

[Airikita]

Yeah it is a bit odd, huh? It's not like it's creating the position factor before the texture. But perhaps the texture has to be created before positioning it.

[sylux102]

It may not be of much help, but looking at the technical design of most older games, and the fact that OoT follows many other logical coding points, its most likely that the texture animations are already predefined (probably in code.zdata) and the scene is configured in such a way that when the game loads the scene config, it tells the console that addresses 08 and 09 have a particular effect.

[Zeth Ryder]

It may not be of much help, but looking at the technical design of most older games, and the fact that OoT follows many other logical coding points, its most likely that the texture animations are already predefined (probably in code.zdata) and the scene is configured in such a way that when the game loads the scene config, it tells the console that addresses 08 and 09 have a particular effect.

I definitely agree and hope some of our ASM Hackers/programmers will look into it! There is also a reference to animating textures in the scene table as well. It was how I fixed the beta castle courtyard forever ago, it is also the reason the textures do not animate and there is graphical glitches relating to animating textures. I've also been able to use it get scene/maps imported from MM into OOT to animate properly by changing the scene index number for dynamic textures.

 

 

[scene entry offset] [scene ending offset] [Location entry offset] [Location ending offset] XXYY {insert few more digits unrelated to discussion}

YY being the digits that effects and enables animated/dynamic textures, with it disabled to 00, nothing gets animated. Also in that video, That scene is animated on spot 120, Syotes which has -no animating textures- normally.

 

Example of the scene table used at 120 that I did for the video:

03FD 7B50 03FF AF10 01A1 7000 01A1 9880 0008 0000

 

As you can see the value 08 was used to get the textures animating properly for the MM scene. Also during my tests, I've used MM maps with OOT scenes, while the textures became garbage, they however animated -properly- at speed and movement direction. I am hoping this info will help anyone willing to look into this issue that has gone long overdue to being completely figured out. It would honestly be great to see maps using native animating textures.