I'm designing a Resident Evil clone using OpenGL. I'm curious how the older Resident Evil games used a static pre-rendered background with 3D models roaming around:

Resident Evil 2
(source: spong.com)

Here, if the main player (Claire) moved a few steps back, she will overlap with the pay phone booth. But if she keeps moving alongside the phone booths, she'll still be overlapping them until she is adjacent to the second phone booth.

Conceptually, how is this done and how can I replicate it? I'm not interested in the implementation technicalities on any particular platform. Just the concepts.

  • 1
    \$\begingroup\$ AFAIK you guessed right, layered 2D planes with 3D character moving between them. It can be pixel-perfect, why not? Just don't let 3D character intersect them. Alternative view on the task is a single 2D image with additional channel for depth. Which is kind of the same thing. \$\endgroup\$ – Kromster says support Monica Nov 11 '14 at 5:26
  • \$\begingroup\$ @KromStern, it would then be almost like implementing a Z-buffer of sorts? At every frame, check the Z-buffer and determine whether to move the tile up/down? \$\endgroup\$ – mrkotfw Nov 11 '14 at 5:35
  • 1
    \$\begingroup\$ @mrkotfw: And you better take advantage of GPUs processing powers. Feed it with z-buffer values and let it do the determining what goes above what. Another point of interest are character walkable areas (governed by a kind of navmesh) and character depth shrinking (you need to set up a perspective) \$\endgroup\$ – Kromster says support Monica Nov 11 '14 at 5:59

The simple solution is to not pre-render the background at all. Draw everything live, in 3D, with a fixed camera angle. Modern GPUs can achieve live results that look better than what we often had to pre-render for back in the day (especially with good art).

That said, if you want to reproduce the technique for "authenticity," efficiency, or simply to achieve something even better than what you could do live, it's fairly straightforward in concept: pre-render the scene and save both the color and the depth information.

This will allow you to know the depth of every pixel in the scene, which you can reconstruct into a world-space position of every pixel in the scene (also as a pre-computation step, since the camera angle is fixed). This means you can know when the character is in front of or behind that pixel (render characters and dynamic objects live, in 3D, with the same camera transform used to render the scene). You can use this information to slice the scene into 2D layers which can be drawn back-to-front.

You'll also want to bake out the collision information for props in the 3D scene, such as (in your example), the payphones. Otherwise the player will phase through them, either instantly (in the case of a layer-based rendering) or "smoothly" (if you only work with the pixel depths). Both cases will look very unusual in practice and you'll want to prevent them.

As Krom says, you'll probably also want a simple navigation mesh to define where the player can and cannot walk; this can also be exported from the pre-computed scene baking pipeline. There is, in fact, quite a lot of optimization you can do do with this approach in terms of pre-computing data (the downside, of course, being that iteration on the specific details of the room may require re-exporting through the entire pipeline, which may be costly).

  • \$\begingroup\$ Thanks for the explanation. When calculating each pixel's position in world space, would it be ideal then to convert all the pixels to vertices? My issue is projecting both the pixels and 3D models into one camera. I can sort of see how it can be done with "two cameras" -- one being perspective, the other being orthographic. \$\endgroup\$ – mrkotfw Nov 11 '14 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.