Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
entryway

Question about the bridge

Recommended Posts

Who knows how to compile level and by which program with which parameters to avoid visual bug, which can be seen in software mode of prboom? (Rendering is good in glboom).

Screen-shots demonstrating this bug are available here:
http://geocities.com/e6y/files/doom/my/soft01.gif
http://geocities.com/e6y/files/doom/my/soft02.gif
Level:
http://geocities.com/e6y/files/doom/my/e6y.zip (map02)

I am using the DoomBuilder with ZenNode1.2.1 compiler. My bridge seems like HellRevealed2's one on 19-th level, but there all correct as in prboom as well in glboom. But in case of re-compiling of 19th level by any of accessible for me compilers and then saving, visual bug appears in it too.

Share this post


Link to post

Although I haven't examined your level, it looks like only one side of the support linedefs refers back to the dummy bridge sector instead of both sides.

Share this post


Link to post

Make sure that the self-referencing sectors representing the invisible blocks used to walk over the bridge are closed and there are no overlapping lines involved. You just have isolated linedefs and with such a setup it is pure luck if a node builder manages to create usable nodes. If those blocks are closed there is no ambiguity to which sector the inside will belong to and the bridge will work. Make also sure the entire bridge is surrounded by lines belonging to the outside sector(s) (currently it is) so that the bridge blocks don't extend into areas they are not supposed to.

Share this post


Link to post

GL ports will often screw these things up (I know). If your level has 3D bridges I suggest you don't use a GL port at all (except for very few exceptions).

Share this post


Link to post

        4               4
   ooooooooooooooooooooooooooooo
   o 3           3           3 o
   o                           o
   o     1   1(3)  1(3)  1     o
   .---.---.---.---.---.---.---.
   o   | 1 |   |   |   | 1 |   o
   o   |   |  2|2  |   |   |   o
 4 o   |   |  2|2  |   |   |   o 4
   o   | 1 |   |   |   | 1 |   o
   .---.---.---.---.---.---.---.
   o     1   1(3)   1(3) 1     o
   o                           o
   o 3           3           3 o
   ooooooooooooooooooooooooooooo
        4               4
"--" both sides refer to sector 1
"|" both sides refer to sector 2 (tag 52)
o - sector 3
The visual mistake described above is present
http://geocities.com/e6y/files/doom/my/e6y_old.zip

But if the front side of "--"line refer to sector 3 - all works perfectly. But in all wads both sides of a handrail refer to the one sector
http://geocities.com/e6y/files/doom/my/e6y.zip

I would like to see concrete descriptions of my mistake in e6y_old.zip\map02

Share this post


Link to post

Overlapping lines are used, as there are meant to be no vertices connecting the self-referencing linedefs to the crossbeam linedefs.

btw, Zennode doesn't like 3D bridges much (it makes the self-referencing linedefs much thinner in terms of being able to stand on them), you're probably better off with DeepBSP.

Share this post


Link to post
kristus said:

IMO I suggest you use Boom specials. you get the same effect and it works in GL ports aswell.

It was always working in GL ports for me.
What is "Boom specials"?

Share this post


Link to post
entryway said:

It was always working in GL ports for me.
What is "Boom specials"?


Boom has one linedef special that transfers the floor height from one sector to another. It can be used to create invisible blocks without any self-referencing sector hacks. But this means the level requires a Boom-compatible source port to run, which with the sole exception of JDoom applies to all modern ports.

As for your bridge, you should do it like this (I made the space between the lines larger to fit in the numbers:

|                                      |
|4                                    4|
|                   4                  |
|--------------------------------------|
|               |   4       |          |
|         1    4|4    2    4|4 3       |
|     --------- | --------- | ---      |
|     |   1   | | |   2   | | | |      |
|4   1|1     1|1|2|2     2|2| | |3    4|
|     |   1   | | |   2   | | | |      |
|     --------- | --------- | ---      |
|         1    4|4    2     |4 3       |
|               |   4       |          |
|--------------------------------------|
|               ^   4       ^          |
|4              |           |         4|
|               |-These are the crossbeams

(1-3 are the parts of the bridge and 4 is the outer sector. The crossbeams of the bridge are part of the outer sector in this setup.)

Notice that the blocks which make the bridge are closed shapes with self-referencing sectors (i.e. same sector on both sides) but everything else is the outer sector. This configuration should work with every node builder out there.
The problems appear if there are overlapping linedefs from different sectors or as in your case isolated linedefs from a different sector inside another sector. These isolated linedefs don't create a closed shape which is required to reliably determine in which sector a certain point lies. With your setup, depending on the way the node builder works, any point on the bridge may incontrollably end up in either the lower sector or the invisible block.

Share this post


Link to post

Boom has one linedef special that transfers the floor height from one sector to another. It can be used to create invisible blocks without any self-referencing sector hacks.


It does? and i had just gotten fed up with trying to make the sector referenceing work too!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×