Z Order of background tiles.

[Akari]

I think I get how tiles z-ordered and how game deside where draw tile (in front of character model, or behind)

There are such thing as Z value. Its Uint16 and it set distance from screen to tile. If character is on distance 300, then all tiles with Z value larger than 300 will be rendered first, then character model is rendered, after that rendered tiles trom 300 to 0 in descent order.

I must rewrite a lot part of managers again -_-

But at last CHORACE got rendered correctly.

[Cyberman]

I think I get how tiles z-ordered and how game deside where draw tile (in front of character model, or behind)

There are such thing as Z value. Its Uint16 and it set distance from screen to tile. If character is on distance 300, then all tiles with Z value larger than 300 will be rendered first, then character model is rendered, after that rendered tiles trom 300 to 0 in descent order.

I must rewrite a lot part of managers again -_-

But at last CHORACE got rendered correctly.

Cool, however this brings up an interesting problem.  This means the game does do depth sorting of the components.
I'm fairly certain the field characters are scaled where obviously the static layers are not.  So back to the 'stupid' thinking from the Q-gears forum.  Since we aren't using 3d models in the field etc yet this hasn't become an issue.  I guess it will be now.  The surfaces/textures that are the sprites and bits of the background are likely orthogonally projects whereas the characters are not (perspective).

Anyhow the Z value information brings this out that they used that for depth sorting.  They must have put fake information in for the layers OR did some weird scaling. (I doubt the latter)

Cyb
                                                                                                                                                                                                                                                                                                                       

[Akari]

Cool, however this brings up an interesting problem.  This means the game does do depth sorting of the components.
I'm fairly certain the field characters are scaled where obviously the static layers are not.  So back to the 'stupid' thinking from the Q-gears forum.  Since we aren't using 3d models in the field etc yet this hasn't become an issue.  I guess it will be now.  The surfaces/textures that are the sprites and bits of the background are likely orthogonally projects whereas the characters are not (perspective).

Anyhow the Z value information brings this out that they used that for depth sorting.  They must have put fake information in for the layers OR did some weird scaling. (I doubt the latter)

They used 0x7c 16x16 Sprite GPU packet. So the really don't use any projection, it rendered as is (or you can say it is orthographic projection which i use in Q-Gears ^_^). While 3d models rendered with perspective projection that set with camera information from field dat file.

Now the next main trouble with background will be palleted animation and backgrounds where one part stay as is while other moves (climbing to shinra building) and scripted background moves (elevator in Junon). I'm not ever look at this yet.

[Cyberman]

They used 0x7c 16x16 Sprite GPU packet. So the really don't use any projection, it rendered as is (or you can say it is orthographic projection which i use in Q-Gears ^_^). While 3d models rendered with perspective projection that set with camera information from field dat file.

Well the reason I mention  again is because Wii err We will probably need to swap between ortho and perspective... or something in order to render .. stuff. Hmmm Now that I'm thinking about it they probably ordered the rendering. IE drew the background then found out what objects were next to draw (3d 'stuff' or more static).  So how can we get a 3d object to move around this world .. might be something to look into.

Now the next main trouble with background will be palleted animation and backgrounds where one part stay as is while other moves (climbing to shinra building) and scripted background moves (elevator in Junon). I'm not ever look at this yet.

I thought the Junon elevator used a MOVIE? In fact I am very sure it does use a movie (\MOVIE\JUNELGO.STR \MOVIE\JUNELIN.STR), one for going up (in) and one for going down (go).  While the movie plays cloud's position is updated.  I've noticed that whenever they mix movies and 3d the people are set so they it's not possible for them to have anything in front of them (save other 3d characters).

Cyb

[Akari]

Well the reason I mention  again is because Wii err We will probably need to swap between ortho and perspective... or something in order to render .. stuff. Hmmm Now that I'm thinking about it they probably ordered the rendering. IE drew the background then found out what objects were next to draw (3d 'stuff' or more static).  So how can we get a 3d object to move around this world .. might be something to look into.

It's easy really. I already know how to do this, don't worry =)
The hardest thing is to understand 3d model and animation format. After that I need week to implement it all =)

I thought the Junon elevator used a MOVIE? In fact I am very sure it does use a movie (\MOVIE\JUNELGO.STR \MOVIE\JUNELIN.STR), one for going up (in) and one for going down (go).  While the movie plays cloud's position is updated.  I've noticed that whenever they mix movies and 3d the people are set so they it's not possible for them to have anything in front of them (save other 3d characters).

I'm not talking about elevator to lower part of JUNON. I'm talking about JUNONL2. It uses BGPDH and BGSCR opcodes.

[Synergy Blades]

I'm talking about JUNONL2. It uses BGPDH and BGSCR opcodes.

Want me to look at them for you?

[Cyberman]

It's easy really. I already know how to do this, don't worry =)
The hardest thing is to understand 3d model and animation format. After that I need week to implement it all =)

Animation format... hmmm don't know where this stuff is. Let me compute something.  First there are 2 or 3 sections to the BCX/BSX files.
This means my guess is one section is the actual model.  The next section is likely the animations.  The animation format may be like the battle however I don't think it's likely.  First there are only a few animations used.  Idle, dead, walking, pondering.  The eye blinking is likely to be seperate. Heck I'll just bang on FF7 and find out for sure. LOL

I'm not talking about elevator to lower part of JUNON. I'm talking about JUNONL2. It uses BGPDH and BGSCR opcodes.

Hmmm I thought that was a movie also... you are refering to when Rufus and people get into that weird thing outside after the parade?

Cyb

[Synergy Blades]

Hmmm I thought that was a movie also... you are refering to when Rufus and people get into that weird thing outside after the parade?

Perhaps a more memorable example of these two opcodes at work is the animated/scrolling motion blur-effect background in the Cloud/Zack flashback, in the old guy's truck when he's taking you both to Midgar.

[Akari]

I'm talking about JUNONL2. It uses BGPDH and BGSCR opcodes.

Want me to look at them for you?

Of course! ^_^

you are refering to when Rufus and people get into that weird thing outside after the parade?

Yup =)

[halkun]

The BGPDH opcode was probably last to be implemented as those two scenes were not in the original Japanese release of FF7.

I'm always reminded of this because to load ZTRUK from the debug room, Aerith always said "Works now"

It't funny because out of all the scenes in FF7, the part where Zack and Cloud are on the truck are in all The FF7 movies/games I've seen so far. Not only the scene, but the line where Zack says...

"Tomodachi.... Daro?" (We're friends....right?)

It's in ZTRUCK in FF7, Advent Children, and Before Crisis.

[Synergy Blades]

Not sure about that, since BGPDH is used in 19 fields. I don't have much time at the moment so I took a cursory glance at those two opcodes, I'll take another look later.

BGSCR does what you'd expect it to, scrolls the background with particular speed. It does repeat if the background goes off the screen but I wonder if it has to be a certain width to make sure the repeat works correctly; as you can see with del3, the ocean part isn't wide enough (about the same width as the ocean is blank before the ocean repeats and comes back on the other side of the screen):

Code: [Select]

BGSCR( Bank/Bank, ??, X, X, Y, Y )

X and Y may be signed, so that negative values scroll left/down. I'm not sure what the second argument is; often 3, but occasionally 2, it isn't the same "background area" one finds with BGON/BGOFF opcodes, so it doesn't just scroll background areas. I checked with Aeris on this background and it doesn't have the water there so maybe it's an ID for a particular part of the background data. What does Q-Gears come up with Akari?

BGPDH seems to set at what layer/depth the area is drawn at. Again, it uses the same "ID" that BGSCR uses, so we're not talking BGON/BGOFF background area IDs. As for the last two arguments... not sure yet. I tried with del3 and any other value than the one given gave this effect, where the water is now over the top of Cloud where it's normally underneath:

[Cyberman]

Simplified

Cyb

[Synergy Blades]

Cyb, if I may, I think you're barking way up the wrong tree (wrong forest, even?) I'm 99% certain the blue effect on the models you're talking about is a KAWAI with subop 9, the arguments of which dictate how the effect is set up on the model.

[halkun]

Yup, I was just gonna say that that's the KAWAI opcode at work....

They have a sample in the debug room

[Akari]

BGSCR does what you'd expect it to, scrolls the background with particular speed. It does repeat if the background goes off the screen but I wonder if it has to be a certain width to make sure the repeat works correctly; as you can see with del3, the ocean part isn't wide enough (about the same width as the ocean is blank before the ocean repeats and comes back on the other side of the screen):

Code: [Select]

BGSCR( Bank/Bank, ??, X, X, Y, Y )

X and Y may be signed, so that negative values scroll left/down. I'm not sure what the second argument is; often 3, but occasionally 2, it isn't the same "background area" one finds with BGON/BGOFF opcodes, so it doesn't just scroll background areas. I checked with Aeris on this background and it doesn't have the water there so maybe it's an ID for a particular part of the background data. What does Q-Gears come up with Akari?

Hmm I didn't found BGSRC on DEL3 map. Only BGPDH and BGON/BGOFF.

by the way... I analized background info from DEL3.DAT file and I found one more background block. But this one is a bit strange (at least for now ^_^). The most strangest thing - its seems use not 16x16 block but 32x32 instead.
I'll take more close look at this a bit later.

The base structure of this block are the same as 1st and 2nd blocks.

1st
xxxx yyyy src_x src_y clut

2nd
xxxx yyyy src_x src_y clut 8A00 10000000

3rd
xxxx yyyy src_x src_y clut 8101

BGPDH seems to set at what layer/depth the area is drawn at. Again, it uses the same "ID" that BGSCR uses, so we're not talking BGON/BGOFF background area IDs. As for the last two arguments... not sure yet. I tried with del3 and any other value than the one given gave this effect, where the water is now over the top of Cloud where it's normally underneath:

BGPDH seems set depth for 3rd block since data from DAT file doesn't contains this info. And Id has something to do with this block.

[Synergy Blades]

Ahah, I had wondered whether they were IDs for some type of background I wasn't aware of.

Hmm I didn't found BGSRC on DEL3 map. Only BGPDH and BGON/BGOFF.

Yes, that's right, I put in BGSCR myself to experiment with it.

[Akari]

I'm not sure what the second argument is; often 3, but occasionally 2, it isn't the same "background area" one finds with BGON/BGOFF opcodes

It seems like I've got it. The third can have one or more subblocks. It is addressed as 2 or 3... or maybe even 4 =)
They don't have depth by itself so it needs to be set through opcodes. And we can move this thing. I don't know if we can move animation from block 1 (for example propeller on MD1_1). It's up to you to check =)

DEL3 don't have 3rd block... only 4th. There are FF7F FF7F twice not once as usual =)

BGPDH seems to set at what layer/depth the area is drawn at. Again, it uses the same "ID" that BGSCR uses, so we're not talking BGON/BGOFF background area IDs. As for the last two arguments... not sure yet. I tried with del3 and any other value than the one given gave this effect, where the water is now over the top of Cloud where it's normally underneath:

By the way it looks like last two bytes in BGPDH are depth itselt since it two bytes in background data.

[Synergy Blades]

DEL3 don't have 3rd block...

Howcome it uses BGPDH with argument as 3 then? Anyway, this looks good, I'll check it when I get back from uni later today.

[Akari]

DEL3 don't have 3rd block...

Howcome it uses BGPDH with argument as 3 then? Anyway, this looks good, I'll check it when I get back from uni later today.

It's count from zero. Zero - bottom layer. One - layer with defined depth. Two and Three are blocks without depth.

[Synergy Blades]

So are we saying now that this new layer (3 in del3's case) can have both BGPDH/BGSCR applied to it, and be assigned scripted areas to be used with BGON/BGOFF? This must be the case, since del3's "wave" entity uses both BGPDH to (presumably) set its depth, as well as BGON/OFFs to animate it. I had kind of assumed that the BGON/OFF only applied to the foreground layer (layer one, in your analogy) but then I guess it must work on all layers; perhaps even layer 0 if it had the right area ID assigned to it? (though this wouldn't really make sense on the very back layer as it would be blank if you turned it off).

I don't know if we can move animation from block 1 (for example propeller on MD1_1)

No, this doesn't seem possible. Nothing from layer 0/1 moves if you give BGSCR zero or one as an argument. I could try this with BGPDH but I think since it uses the same argument I think we can safely assume these opcodes only work for layers 2+.

Now we (think we) know what the layer argument deals with, I'll have a look at BGPDH, and also at that field with both layer 2 and 3. It's ztruck that has both 2 and 3, btw, I seem to recall you asking; that might be a good place to test.

[Synergy Blades]

Cool, looks like we were right about depth. This one is del3's ocean, layer 3, set to 0xE0 rather than its original scripting, at 0x100. As you can see, at the point I'm standing is the part where Cloud comes "in front of" the ocean layer - you can just see his chest and head which is infront of the layer, and the rest of the model, which is behind it. If you walk further down (to the bottom of the screen), Cloud is drawn totally infront of the ocean. If you move up, he is underneath the ocean. 

[Edit] Just as I'm updating the Wiki; is it possible they meant BGDPH, as in DePtH, rather than PDH? So either it was a spelling mistake for whoever wrote the opcode names (found in the PS version), or for whoever ripped the list from it? Not sure what else PDH could stand for 

[Cyberman]

I think the original scripters desired to use it the way you are using now. However the reason they didn't is the results didn't look good and had unexpected results.  So they used another method and used an opcode to shade the vertices a different color (KAWAI  code). He is normally on top (which before I was changing the response but really it made no sense to even put anything else at all LOL).


Cyb

[Akari]

So are we saying now that this new layer (3 in del3's case) can have both BGPDH/BGSCR applied to it, and be assigned scripted areas to be used with BGON/BGOFF? This must be the case, since del3's "wave" entity uses both BGPDH to (presumably) set its depth, as well as BGON/OFFs to animate it. I had kind of assumed that the BGON/OFF only applied to the foreground layer (layer one, in your analogy) but then I guess it must work on all layers; perhaps even layer 0 if it had the right area ID assigned to it? (though this wouldn't really make sense on the very back layer as it would be blank if you turned it off).

I dont think this could be even called layer now, cause the second one have many layers itself =)

1st background - always rendered first. It doesn't have animation or depth. (maybe depth could be set with opcodes?)

Info in dat files are X position, Y position, texture X, texture Y, clut, texture flags.


2nd background - contains fixed depth tiles. It can have animation.

Info in dat files are X position, Y position, texture X, texture Y, clut, texture flags, depth info, animation info.


3rd and 4th background - contains movable tiles. It has no depth by itself (it needs to be specify by opcodes), but can have animation. there only two of them.

Info in dat files are X position, Y position, texture X, texture Y, clut, texture flags, animation info.

As I can see 3rd and 4th background contains 4bpp textures and have size 32x32. This needs to be implemented =)

Now we (think we) know what the layer argument deals with, I'll have a look at BGPDH, and also at that field with both layer 2 and 3. It's ztruck that has both 2 and 3, btw, I seem to recall you asking; that might be a good place to test.

Mmm I looked at this... nothing unusual. 2 movable layers with animation. 32x32 size tiles. Now I need to implement new tile size first =)

[Akari]

It seems that layer 3 and 4 always have 32x32 sprites. I add support to them. But I need to check all others backgrounds.

2 Synergy Blades: could you tell me names of location that uses BGPDH?

ps: It seems that animation index used in BGON and BGOFF is not the index itself but offset to byte. Animated tile have one byte mask. If some bits set to one - tile will be enabled with BGON seted to this bit.

Tile with animask 0x20 will be activated with BGON (00,01,05) as 1 << 5 == 0x20.
This may be used to set one tile shown in different frame of animation.

[The SaiNt]

Looks like I arrived in the thread too late to have saved you the effort of having to guess all of that the hard way.
Ah well.