Two comments:

- Shadows on invisible models should be possible by using nontransparent models with an FFP effect that renders only into the z buffer, but nothing to the screen buffer. I haven't tried it, though.

- I don't think that it makes sense to use view entities for a 2D game. They are not meant for simulating level entities. All the collision detection and lighting functions work with level entities, so there's no real reason why someone would want to use view entities. You just need to restrict the movement of the level entities to 2 dimensions.

However, a useful feature could be to have sky layers at a certain z position, so that some level entities are in front and some behind the sky layers.

Setting a z-position for sky entities and allowing models to display behind them would be very useful indeed. However, to be truly useful for our purposes, sky entities would also have to be able to use planar images (in addition to cylinder, dome, and cube) that always face the camera and that can be easily animated without much hit to the framerate (using a bmap object pointer would be a start).

It would be useful if all sky entity types could be easily animated, as I imagine that many people would want to prerender a cycling animation of clouds to use as their sky texture, for example.

Ok, we'll implement a sky flag for camera-independent images. You can then also animate or run movies on that sky texture.

Awesome. Will that include distance from camera (z-position) to depth sort with level entities?

The obvious way to get around the need for this feature is to create a sprite at screen resolution, that always faces the camera, and that fills the whole screen. When it comes to scaling, I do this:

sprite.scale_x = ftan(camera.arc/2,distance_from_camera*2/camera.size_x);
sprite.scale_y = (camera.size_x*3*sprite.scale_x)/(camera.size_y*4);

And I notice that it has a curiously high margin of error. Checking the documentation, I see that scale_x and _y can only range 0.01..100! I get popping as the image tries to scale to the size of the screen at different distances, my layers of sprites never quite align, and I never get the sweet clarity of an image displayed at its native resolution, 1:1.

Camera-independent images in the level are the preferred solution, but increasing scale precision might work too? I look forward to features like this that will make 2.5D games easier to make.

I'm just using a simple shader that acts as if the rendering was paused, but dynamic objects can still move around...

works perfectly!

guitar, I'm not sure what you mean. Is your shader something like this?

VS_OUTPUT vs_main(float4 Pos: POSITION)
{
VS_OUTPUT Out;
Out.Pos = float4(Pos.xy,0,1);
Out.texCoord.x = 0.5*(1+Pos.x-viewport_inv_width);
Out.texcoord.y = 0.5*(1-Pos.y-viewport_inv_width);
return Out;
}

I'm not great with shaders, I'm afraid. Could you tell me if you can do each of the following?

Can level entities go in front of and behind your shader output? (Does this render plane have a z-depth in the level? If it does, how do you give it one?)
Can you stack multiple such render planes at different depths in the level with transparency?
Can you animate the texture, either from avi or from a single image like sprite animation?

I like that a solution that uses sprite or sky entities would come with the feature set that these types have. preload_mode and easy script control over position and animation...

(Come to think of it, does preload_mode apply to ent_createlayer?)

There's a thread in scripting started by me where he goes into a bit of detail about it.

If I interpret it correctly, he's simply creating a detailed level in WED (??), complete with shaders, or model based given the shaders. He sets his camera positions, and takes a snapshot of the level with everything turned on from the camera. This is his background, and his hidden scene geometry is in place and should match. I would suggest. XxX that you simplify the hidden geometry if non-visible geometry has an influence on the framerate. There's no reason to use the super detailed version for simple collision. Per Wintermute's techniques, the only parts of the collision hull that require extra detail are the portions that stencil shadows should cast on. Everything else can be simple cubes or whatever.

For go behind/go in front of object, he'll need to take snapshots of those isolated sections and place them via whatever method he chooses. Some kind of triggering method will need to be established if he uses panels and layers. If the player falls below a certain horizontal value then the player can walk in front of these objects and if they're above it then it can go behind it. I think Wintermute does this based on the origin which is generally located at the bottom center of the isolated sprite/panel element.

You can read all about how they do it in their latest manual:

http://www.mediafire.com/?em93txnmg3q

In cases where there are two level entities, one in front of the wall and the other behind it, guitar's method can work by using the geometry in his level to occlude the entities when they step behind objects. However, this is limited to cases where the image in the panels is a render of the level geometry at the same polygon count. (If he is not doing this, then you are right that he should use very simple stand-in geometry for collisions.)

My purpose for using panels is to use hand-drawn images or high poly count renders (souped up with radiosity and the like), and for this purpose, my stand-in level geometry cannot occlude correctly (at the sort of poly counts that can be rendered in real time).

There's a variation on that that might work, however. Have a view rendering entities in front of the wall to one panel and another view (positioned identically) rendering entities behind the wall to another panel. Then, arrange the layers for these panels versus the background and wall panels.

If an entity moves in front of the wall, it must switch views so that it is rendered to the panel in front of the wall. This should be possible using render_view to change the entity's material. Hopefully, the frame rate hit won't be too bad, since entities should only ever be visible in one view per frame.

I don't like that I will need n views per level, where n is the number of possible layers for the entity. I'm going to end up needing view_remove (which guitar requested not too long ago).

Of course, camera-independent sky entities or very precisely scaled sprites get around the problem entirely by virtue of being in the level and having transparency channels.