Some screens of q-gears field background progress.

[Akari]

I just want to share my happiness and show you the screens with first layer rendered correctly. This is all field locations that I usually include in binaries.

To tell you the truth, the second layer too rendered correctly, but It was late when I leave work and I forgot sources and binaries there, so I have only this screens.

 

[Cyberman]

1) Woo... looks like you are getting there
2) Walkmeshs and background do not appear to be aligned correctly,  I assume this has to do with screen center versus walkmesh center issues?

Cyb

 

[Akari]

2) Walkmeshs and background do not appear to be aligned correctly,  I assume this has to do with screen center versus walkmesh center issues?

I don't even think about this yet. I planned to do this in 0.10 version together with scrolling and others. In 0.09 I must just implement background, their animation and related opcodes (there are more some minor things really).

 

[nope]

This looks awesome akari! You're a great coder :-D

 

[Cyberman]

2) Walkmeshs and background do not appear to be aligned correctly,  I assume this has to do with screen center versus walkmesh center issues?

I don't even think about this yet. I planned to do this in 0.10 version together with scrolling and others. In 0.09 I must just implement background, their animation and related opcodes (there are more some minor things really).

Oh... I see, LOL I thought "Wow it almost aligns correctly" now I can say DOH!
Erstwhile it does not appear to be just a simple case of alignment, it appears the camera information somewhat distorts things. I'm not sure if it's the perspective you are using for the walkmesh or not but I think it may be.  The scenes may alternatively apply perspective correction or not.  That might be what is at issue.

Cyb

 

[Fergus McMillan]

Holy crap this is awesome! Nice work. I wish I could get involved somehow but, alas, I'm only learning Java at school right now and my self-teaching of C++ isn't going very far.

 

[miketheman123]

I have a question about the different layers in the field screens.

You know how some parts are coloured green to show that that part will be shown *ON TOP* of the the characters, well what do the red ones mean and how do they recognise the fact that the character can be infront of and behind that object (An example would be a fence or a lampost.)

Thanks if anyone can reply.

 

[Akari]

I have a question about the different layers in the field screens.

You know how some parts are coloured green to show that that part will be shown *ON TOP* of the the characters, well what do the red ones mean and how do they recognise the fact that the character can be infront of and behind that object (An example would be a fence or a lampost.)

Thanks if anyone can reply.

AFAIK the green and red means nothing. There are two layers. The first one (bottom) rendered first, then model characters added and lastly rendered second layer that hide some part of models.
The green and red colors appeared when original pictiure was slice into two layers. They filll cuted place with green and red colors... maybe there are even more, but they dont have any special meaning.

 

[Synergy Blades]

Unless I've misunderstood you Akari, that isn't always the case, as Mike seems to be pointing out the same thing I've also wondered. That is - what about areas you can both disappear behind, as well as walk in front? For example - Chocobo farm. You can walk behind the house on the left hand-side, but you can also run in front of it (to go through the front door, for example). In this way you can both appear in front of and behind the same sprites making up that part of the background, depending on the Z-distance of your character; where is this information stored?

 

[Micky]

In this way you can both appear in front of and behind the same sprites making up that part of the background, depending on the Z-distance of your character; where is this information stored?

If I had to program this I'd store some kind of layer index on the walkmap's triangles. Like "if object is in triangle x, render it after compositing layer y before rendering the rest". Remeber, the PS1 has neither a Z-Buffer or a complicated pixel-shader system, so information stored in the texture colours is not easily accessible.

 

[halkun]

Actually, on the PS1, you did not have direct access to the VRAM *at all*. It was in a whole other bank of unconnected memory. You had to go through the GPU and ask it what was at a particular location in VRAM.

 

[Synergy Blades]

Well, for anyone thinking of looking, if you check the Chocobo farm any image areas where you can walk both in front and behind of them are all stored in the foreground layer, so I did wonder if it's not a particular property of those foreground sprites. I did a check on that theory quite a while back and there was a... four-byte? number I suspected of having some part of this, though I never went any further than just rendering out particular sets of tiles and inspecting their value. It seemed that the further away from zero the value was, the sprites that corresponded to areas further away from the walkmesh origin would render, but it could have just been a complete fluke as I didn't look into any more than that cursory glance.

 

[Akari]

Remember that there are some ununderstanded bytes in foreground layer and Z ordering of drawing sprites of the same layer didn't work propely yet. I think that kind of info stored there.

 

[Miketheman]

The Chocobo Farm place was the exact place I also began wondering about different layer positions.