Loading ...
Sorry, an error occurred while loading the content.

3D-maze engine (was: TutorVision)

Expand Messages
  • a_chevallier
    ... Richard, I was thinking again about your 3D-maze suggestion. I guess you were talking about a Doom-like or Wolfenstein-like 3D engine, is that correct?
    Message 1 of 59 , Aug 1, 2003
    View Source
    • 0 Attachment
      --- In intvprog@yahoogroups.com, R A Worthington

      > I had also pondered the possibility of doing a crude 3d maze
      > game using coloured squares mode as a bitmap with BIG pixels.

      Richard,

      I was thinking again about your 3D-maze suggestion.

      I guess you were talking about a Doom-like or Wolfenstein-like
      3D engine, is that correct? There's little point in using
      colored-squares for a Dungeon-Master-like display (as Joe Z.
      pointed out, you're better off using predefined GRAM cards in
      this particular case).

      I think that such a 3D engine is doable. It's certainly going to
      be damn slow --even with a lot of optimizations and precomputed
      stuff-- but it should be doable... and maybe playable.

      I've never studied this kind of engine in details, but below are
      some preliminary thoughts about it.


      ==========================
      Walls
      ==========================

      A wall is defined by 4 points:

      Z-axis
      ^
      |
      |
      P3-----------P2
      | . . . . . . |
      | . . . . . . |
      | . . . . . . |
      | . . . . . . |
      P0-----------P1------> X-axis

      with:
      P0=(x0,y0,z0), P1=(x1,y1,z1), P2=(x2,y2,z2) and P3=(x3,y3,z3)

      We can assume the following:
      z0 = z1 = 0 or negative constant
      z2 = z3 = positive constant
      x3 = x0, x2 = x1
      y3 = y0, y2 = y1

      So, all we need to handle is (x0,y0) and (x1,y1).

      Now, let's assume there are only 2 kinds of walls on our map:
      - 'vertical' walls with x0 = x1
      - 'horizontal' walls with y0 = y1

      Finally, a wall is defined by:
      - a flag telling whether it's a vertical or horizontal one
      - 3 coordinates: (x0,y0,y1) or (x0,x1,y0)


      ==========================
      3D operations
      ==========================

      We can assume there are "only" 3 different operations:

      - rotation around the Z-axis --> the character is turning

      - translation on the X-axis |
      - translation on the Y-axis |--> the character is walking


      ==========================
      Display rendering
      ==========================

      Once the rotation, the translations and the 2D-projections have
      been computed for a particular wall, we get something like that:

      PP3
      | .\
      | . \
      | . .\PP2
      | . .|
      | . .|
      | . .|
      | . ./PP1
      | . /
      | ./
      PP0

      with:
      PP0=(xp0,yp0), PP1=(xp1,yp1), PP2=(xp2,yp2) and PP3=(xp3,yp3)

      Once again, we have some equalities:
      - xp0 = xp3
      - xp1 = xp2

      To render this wall we need to draw several consecutive lines,
      starting for instance with (PP0,PP3) and ending with (PP1,PP2).

      Since the middle of the wall is a rectangle based on the (PP1,PP2)
      edge, it can certainly be drawn more quickly:

      PP3
      | .\
      | . \
      A----\PP2
      |xxxx|
      |xxxx|
      |xxxx|
      B----/PP1
      | . /
      | ./
      PP0

      In this case, we have to draw two set of smaller lines:
      from (A,PP3) to (PP2,PP2) and from (B,PP0) to (PP1,PP1).

      Also, we need to use at least two colors (green and dark green,
      let's say) depending on the walls orientations.

      I guess all these things should be done in a separate RAM area
      before we actually apply the final result on the Backtab, because
      it's gonna take several frames (yeah... maybe many, many frames!).

      I know there are several other problems:
      - we have to evaluate which walls have to be drawn for the current
      position in the maze
      - they have to be drawn in a particular order
      - we have to detect collisions
      - ...

      But anyway, I'd be willing to bet that many things can be
      optimized and/or precomputed.

      I may attempt to code a prototype with just one or two walls to
      see how things are going.

      Thoughts?

      Arnauld
    • R A Worthington
      ... I know, but what I was saying is that you might need the floor colour on the FIRST card on that row, if the maze is big enough, and the first card might
      Message 59 of 59 , Aug 6, 2003
      View Source
      • 0 Attachment
        On Wed, 6 Aug 2003, Joe Zbiciak wrote:

        > Richard,
        >
        > I think Arnauld was suggesting that at least one card along the horizon
        > line will have all four pixels w/ equal color, so you could scan for it
        > and use that.

        I know, but what I was saying is that you might need the floor colour on
        the FIRST card on that row, if the maze is big enough, and the first card
        might not have all four squares of equal colour - in fact, it could
        concievably have three colours (light wall, dark wall and floor).

        -
        Richard
      Your message has been successfully submitted and would be delivered to recipients shortly.