Placing panels behind the view...

This is an interesting feature, but I believe it can be realized with the current version. The SKY element is meant for just that, a backdrop bitmap on a layer behind the view.

We indeed plan to offer a 2.5 D template in the future. It is intended to use normal entities for the foreground (that can be walked behind), and sky layers for the background. This should work without new engine features.

Hmm, I actually considered the sky for background use, but I wasn't sure if it could be used for something like this. I'll have to experiment a bit. Thanks for the info. on the template.

The problem with sky is that you're going to want multiple layers in your scene (assuming there are things that the player can walk behind) and for the 3D player to be able to change layers relative to the 2D layers.

View entities are the way to go for this type of system as they can freely move above and below panel layers. The usual 3D level is run invisibly to provide collision detection. (The view entity positions are updated from the invisible level.) [I take it that this is basically the case for games like Final Fantasy 7 and 9.]

The advantage of using view entities over having the 3D level change layers is that each character can change layers independently (say, if you have one character in front of a wall and another behind it). The 3D level would treat all characters as though they were on the same layer and therefore as if they were at the same depth in your 2.5D environment.

If I understand, the difficulty that you are facing is in getting the collisions from the 3D level (the placement of walls, for example) to match the visual of the wall in the 2D image. This should be somewhat easier using the above approach. If you're making all of your backgrounds in a 3D application, this isn't too bad, as you have the 3-space coordinates of all of your scene elements. And if you're drawing all of your backgrounds, you're going to have to painstakingly match everything by hand anyway.

In the style of game that I am going for, it is important to relay depth information to the view entities (so that one can run to/away from the camera in addition to up/down/side), but there are times when a 2D collision-detection system for view entities would be helpful as well.

Here is where Conitec would have to help us out. Implementing this would likely involve having a 2D image mark the places where the view entity should not be passable. The image would scale as the entity moves to/away from the camera. There would be a similar scheme for panels, and the two would interact to create collisions. If you drew all of your background images, then, you would simply draw lines over them to mark impassible regions for the character. (And Gamestudio would gain a valuable tool for making more conventional 2D games in the process.)

Could you point me to those? I would be interested in reading.

I've scripted view entities to interact with level geometry (and to depth sort with panels and other view entities). I can do the same for lights as far as using their direction, intensity, and color for shading, though I'm still working on how best to handle shadows. Simple drop shadows are do-able, but the level approach definitely has an advantage for any sort of stencil or dynamic.

How would you get around all characters occupying the same layer using the level approach? Multiple copies of your level with layered view cameras?

I've wondered why the level doesn't treat rays that travel on to 'infinity' as transparent and then show panels behind.

I can't seem to find the old threads. I've tried all kinds of searches with different year ranges, but there's nothing. Here are my old bookmarks, but I can't figure out how to convert it (if you even can) to the new forum syntax. I think the first one was in User Requests and the second in Feature Requests, although I could be wrongs since these are ancient:

2D Zbuffer masking...: http://www.conitecserver.com/ubbthreads/...;fpart=1#365449

Zbuffer masking...2D gaming...: http://216.46.205.166/ubbthreads/showflat.php?Cat=&Number=398441&Main=377071

If I were to use a normal level along with panels, I wouldn't have to worry about NPCs since in most adventure games (what I'm interested in), the NPCs don't move around. The only time I'd have to switch panels on and off for the walk behind objects is when the player is at a certain part of the screen. If the player is above a certain predetermined section, I'd switch whatever panel(s) needed switching and then I'd switch back when the player crossed that threshold again.

I would think a major problem using view entities would be dealing with stencil shadows. I'm assuming you've gotten dynamic lights to look correct on an entity? For example, in the screen below, there's a dynamic light highlighting my character and because of my cast flag settings, I get that nice self shadowing across the face. This is an all 3D level and not 2.5. Can you get an effect like that with your view entity experiments?



The Wintermute Engine already has both of the features I've requested in this thread (the main one and the shadows one I linked to), but its 3D instruction set is young and nowhere near as mature as 3DGS. Plus, I don't want to use Blender or Cinema4D (the only two packages with a 3DS export that contains the info WME needs for collision, cameras, lights, etc).

Self-shadowing should be possible. It's getting the shadows to cast on other objects that is problematic at the moment. The only thing I can think to do is render the shadow from the 3D level to a texture and apply it to a depth-sorting panel. Maybe? The problem with that is that the character stand-ins in the 3D level will need to be higher poly to get good shadow shapes (and they'll also need to be animated). One of the original advantages to this method was that the 3D level entities could be extremely low resolution and not animated, as they would never be seen.

I am unable to view those threads.

The fact that those threads seem to be lost is irritating. There was some nice info pertaining to 2.5D techniques in them. I can't find them in a search, and I can't seem to convert the old format to the new forum syntax. I'm sure there's a way, but I've run out of variants.

Instead of bumping the shadows on none surfaces thread, I'll just post his here since it's related to it, but also to this one in some sense. The Animatrix short, "A Detective Story" from YouTube is copyrighted, so jcl once you view it, please remove the link if you don't want it posted on the forum. Sorry for posting it, but it best shows what I'm want to explain because 1. It's a black and white Noir work like The Disenfranchised (plus it kind of looks like it in places..the snow, this layering effect, the contrast, etc)), and 2. It shows the effect I've been playing with since the beginning:

http://www.youtube.com/watch?v=aMHCK5MTBOc

The relevant portion starts around the 53 second mark and ends at 1 minute 6 seconds. The parallax scrolling in the mid- and foreground layers is what to look out for, and specifically the part where the camera moves back and shows the telephone. My title will be using this effect a lot and I think it's what The Vampyre Story game I've mentioned does, too. That little piece of art is 2D in nature, yet it will be in a 3D world. As I've stated, I don't want to do a pure 2.5D game. If I wanted to, I'd be using Wintermute. I want to combine that aesthetic with realtime, so let's call it 2.75D.

Anyway, if I wanted to cast a nice shadow across that telephone, I can't do it in 3DGS right now (using stencil shadows I mean). In an actual level, the telephone sprite (or panel depending on how you do it) would be at that location and some invisible geometry that represents it would be just behind it. I'd want the shadow to adhere to this geometry, thus my shadows on none surfaces request.

I agree with your shadows on none request. Invisible objects should be able to receive shadows---that is, to have shadows appear in the level at the invisible object's position and conformed to its shape. Just as a thought, you want to make sure that the shadows appear only on the object's faces that are facing the camera (since the object itself is invisible you might see through to the shadow on the other side of the object) because when you position the shadow in front of a sprite or panel you're going to want only the 'forward' shadow shape.


It would be awesome if parts from threads like that (rather than disappearing) made it to the WIKI as discussions of why certain features in the engine are the way they are and what they can be used for.

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.

I only need one view and to render it one time.

Thats the purpose of the shader. It draws the models with that background image.

Basically: I'm just changing the skin of the model to match the background image


The depth info is already there. It's very easy and works quite well. The only problem I have now is that I'm a horrible level designer

but seriously, the only problem I've run into is aligning the image with screen coords. This would't be a problem, if it weren't dependent on camera arc and resolution.

The image needs to be aligned depending on the screen resolution and camera arc. While the resolution should be an easy [linear] equation, camera arc is quadratic, and through graphing has a noticable curve... I've got to remember how to find the formula, and get more statistics...

I must have missed that part...

Where/which coords do I multiply by the texture matrix though?

matOutTex = mul(matWorldViewProj,matTexTrans); // this creates a matrix...
OutPosTex = mul(InPos,matOutTex); // that converts the In.Position into appropriate coordinates for tex2Dproj to use in your PS.

julz

PS: i added your band on myspace

lol, thanks Julz. I'll make sure I confirm the add... You like the music? It's not so much of a band anymore, just me...

Also, thanks for the matrix info. I'll have to try it out. Right now I'm busy with a paid project, so my 2.5D game is on pause... or should I say freeze_mode = 3;

guitar, if I'm understanding correctly, your shader doesn't help with what I'm trying to do. My game concept hinges on using external scene elements---scans of hand-drawn images, digital paintings, or renders from other 3D software.

Using a render from a view, I am assuming that you are using depth information from the view to determine when an entity should be 'covered' by the view image. If this were modified such that a user-entered depth were assigned to the image and the image could be loaded from bmap, that would be a start. However, there would still be no system to manage animations. Perhaps a media stream could be assigned to the bmap that is passed to the shader? Otherwise, one would have to create a system to do what sprites or media streams already do to display animation.

Adding an animation stream is nothing...

As I've said a million times before, it's not rendering in the background of the level, it's rendering onto thye level geometry, so the depth info is already there.

It's simply like changing the skin of the entity to match a background image

You can use whatever method you want for the BG image. I'm rendering a high quality version of the level, and then saving it to a TGA. Then the level is set to low quality and draws the old image.

It would be possible to input the depth I suppose. Such as writing the depth factor to the alpha channel. But then the case of rendering the depth properly becomes a problem...

If you're technique works well and accomplishes the goals set forth in this thread, then I'd be willing to purchase your 2.5D kit (and provided I'm satisfied with the end result of course). You mentioned you might sell it cheap either in this thread or the other one. If it works on blocks, then that would be ideal. Given there's no updating of the level and it's simply taking a snapshot, the slow nature of shaders on non-model blocks shouldn't matter

I wouldn't recommend usinbg it on blocks, but it would work...

I'm working on a racing project with a small team for now, so all development of my project is on hold (I hvan't touched it in a week).

If I can find time to work on the shader, then I'll clean it up and send it yo you (OB). You can mess with it freely...

I just want credit for my work/time

That would be kind of you. Whenever my title gets released and if it uses your work then of course you'd get credit.

You never know...I could just drop my current tests and go back to all realtime at the drop of a hat. I've done it before. That's the problem with working on something for so long.