Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pheidian]

Hi!

I'm a lead designer and AD of a new project we've started around a month ago. It seems that our own engine developer possibly vanished from the earths surface since no one can get hold of him, so we're trying to find alternatives to continue the work.

Few questions that regard our game creation methods:

- Does  FIFE support pre-rendered backgrounds and color ID layering for depth sorting (background, object layer, always on top) - We don't want to do all of the assets pre-rendered, since we are animating the shit out of all entities (butterflies, trees, grass patches waving in the wind). But we dont want to go to full tile based planning, to be able to make more handcrafter looking backgrounds and worlds - architectural wise as well as nature design wise.
- If it does, how efficient the engine is for big background maps of roughly sized 8192x8192 - naturally engine / we can split it up to smaller textures as well if this is becoming a performance issue.
- Is there a possibility to implement new depth sorting methods for FIFE engine, for example taking the generated zbuffer from pre-rendered background and use is together with ground level "depth gradient" to sort height differences and depth dynamically troughout the map.

Thanks in advance, I'm not one of our coders so my explanations may be "graphics designer point of view" more than technical knowledge stuff.

Here's a little preview test image to show what we mean (trees are going to be animated sprites so they wiggle in the wind) - but the statue for example needs to be depth sorted and we don't want it to be separate tile.

[helios]

Hi Pheidian,
welcome and nice that you've discovered FIFE

I'll try to answer your questions.
FIFE uses a layer based system for sorting. So a higher layer will render over the lower. It's possible to use pre-rendered backgrounds. So you can use your background as the first layer (ground layer). The possible size and performance of those big backgrounds depend on your hardware. But I would recomment to use only 2048x2048 textures because some older or onboard grafic devices can't handle larger textures. But the rest is more or less tile based.
There is currently no way to load the depth map of a pre-renderer texture. You can modifie the z values but only for entities not for pixels and you can change the z to height transformation. Example is here: http://www.youtube.com/watch?v=KwGDrBlBjE8

I hope that answers your questions. If there are still open questions, feel free to ask.

[Pheidian]

Thanks! Yeah, sure thing it's not a problem to use the zbuffer, we haven't actually experimented with it with our current engine either...

Does it support color ID codes, so we could make top layer from the background layer as well (that would draw those colored areas always on top layer)? In the example image, if your character walk under the corner roof to enter the shop, it would be needed to do so, that it disappears under that "hood".

We can also get other id maps out of the 3D renders so that's not gonna be a problem.

[helios]

The term color ID code confused me a little. I know it only in connection with colors, like text color as hex value.
But I think I understand what you mean.
Thats currently not supported. But you could split your background image in two or more images. One for the ground, then on the next layer only title based stuff like agents or other interacting object and on the third layer your roofs. Maybe you need one more layer to distinguish between roofparts which can be hidden when a room is entered.

[Pheidian]

Ah, no worries. our old engine used the style, where we had pre-rendered background, and according color map which had different colors meaning different layers (background, middle and top) - which we could extract easily from the 3D renders. So what I understand, it might need a bit more "manual hands on work" to get the same results now with FIFE, but that's ok.

We might as well go and change the style a bit, doing just backgrounds pre-rendered and then adding most of the stuff with sprites -even buildings, that's not a problem either. Does FIFE sort depth well with big sprites that occupy more than just one tile (for example a building that spands up to 8x8 tiles) or does it need to be broken up into different tiles to sort it out?

[helios]

The depth sorting on the same Layer uses the z value. So one z value per Instance (a Instance is the object you see ingame). The Instance exists on a cell, so if the image is larger as the Cell it can come to sorting problems. The z is always calculated on the real Instance position, without offsets the center of the image. You can also change the stack position, e.g. if you have two Instances on the same Cell one can thus determine what is on top.
FIFE have support for multi cell objects. It's mainly designed for moving objects but should also works for statics like buildings.
Long story short of it. If you use a texture atlas, then you can create virtuell subimages that have the size of a cell. Then create a multi object and assign the subimages to the respective object. The result is a object that looks solid but have a bunch of subimages/objects and each part (Instance) will have a own z value.

[Pheidian]

Hi!

Thanks for the answers. As you've probably understood, the game is in development with FIFE engine, and we're quite happy with how it works. Just wanted to update you on the matter that we've actually started working on the game with FIFE, and it's coming up well. We hope to show you guys some techdemo video of the progress at some point during next month.