[HN Gopher] An Adventure in Pre-Rendered Backgrounds (2019)
___________________________________________________________________
An Adventure in Pre-Rendered Backgrounds (2019)
Author : pizzapim
Score : 21 points
Date : 2022-09-02 19:55 UTC (1 days ago)
(HTM) web link (www.jmeiners.com)
(TXT) w3m dump (www.jmeiners.com)
| droptablemain wrote:
| Not sure how the author wrote an entire article on pre-rendered
| backgrounds in gaming without once mentioning Baldur's Gate /
| Infinity Engine games, of which the developers largely pioneered
| this with DirectDraw API.
| dahart wrote:
| There might be a certain threshold of foreground/background
| integration in your favorite example, but the games mentioned
| as examples predate Baldur's Gate, which kind of answers your
| question, right? If we're talking about just the concept of a
| pre-rendered background, games have done that since the early
| 70s or earlier.
| [deleted]
| koshergweilo wrote:
| Great write up! I still don't really see the point in pre-
| rendered backgrounds for PC/console games anymore though. GPUs
| nowadays are powerful enough and storage space is limited enough
| that you can just render everything realtime and it will look
| great.
|
| The technique does seem like it would be a great fit for mobile,
| where users have limited control and efficiency is really
| important.
| bsenftner wrote:
| The point is an ability to pre-compute a complex environment,
| playback that complexity at runtime, enabling the runtime's
| compute load to include that while devoting more compute to the
| real time rendered characters and effects than would be
| possible otherwise.
|
| I did a pre-rendered background 3D game on the PlayStation 1.
| We had an operating steel mill as an animated background, with
| high resolution characters pre-rendered to 3D cards, plus
| z-buffer data for both so the characters could pass behind
| background set elements, and when characters fight their
| geometries overlay/penetrate correctly. Using the PSX MDEC
| video, we could have up to a dozen background frames. That
| enabled the giant rotating gears and assembly lines of the
| steel mill to 'operate' with 3-6 frame loops, and each game
| level to support multiple perspectives (camera views) of the
| action. Each camera view could be hundreds of millions of
| polygons, all precalculated to 2D elements, and the final game
| engine treating the hardware as more of a real time compositing
| engine (with a 3D simulation running logically in parallel.)
|
| The game was not popular, misunderstood at the time, and the
| studio was a film VFX studio whose staff did not like being put
| on the game production. There were 75 levels and it had quite
| the large team for the time, about 45 animators, 15 level
| developers, and 6 engine developers.
| https://www.youtube.com/watch?v=n9w1e7D5ucY
| aschearer wrote:
| We're using Blender to pre-render 3D assets into 2D ones for our
| upcoming top-down survival horror arpg. (Link in bio for the
| curious.) It's worked well for us overall. That said, it
| definitely adds a lot of complexity, and if you're ultimately
| making a 2D game it adds a whole new, complex tool to learn and
| integrate. Case in point the incredible efforts described in this
| article to create the cube map or depth buffer!
|
| I will say, we solved the draw order problem a different, easier
| way by adopting a fixed ortho perspective and rendering objects
| as spritesheets/tiles. We can then author levels using
| conventional 2D methods. Objects now sort by their pivot's Y
| value, more or less, so walking behind things isn't an issue.
|
| Seeing the Cave Story screenshot has me thinking, there might be
| an especially good opportunity for pre-rendered side-scrollers...
| Just entirely eliminate whole classes of problems, plus you
| easily bring back some of that animation-inspired
| back/mid/foreground goodness.
___________________________________________________________________
(page generated 2022-09-03 23:01 UTC)