[SOLVED] - PRBOOM+ Skybox Question

[Tolwyn]

Anyone care to share with me the reason why skybox textures won't work unless they are explicitly named:

CEMENT1
CEMENT2
..
..
CEMENT6

??

This is if I define SKY1.

What if I define SKY2?

WTF??

Tolwyn making an edit... It's becuase this example PWAD doesn't need to edit/manipulate/or create a new PNAMES and Texture1 lump. So you can see the example in action by simply adding it to any existing PWAD that is using SKY1.

[Tolwyn]

Ok. I got it.
WOW. Searching GOOGLE for Documentation is a little hit and miss.
:)

Documentation is good... and I fully realize it takes a lot of effort to document. :)

If you're going to use a SKYBOX in PRBOOM+ (GL) you define it using the GLDEFS lump.

It can be named ANYTHING; however...

You have to make sure the 6 (or 3) skybox textures (PNG) are included in a TEXTURE1 lump.

CEMENT1 - CEMENT6 happen to just be textures in the IWAD.

That's why MY example with a custom GLDEF Skybox name wasn't working.

Ok.

Geeze.

[40oz]

Are you making maps, Tolwyn?

[scifista42]

Tolwyn said:

WOW. Documentation is poor in the community.

Excuse me?

doomwiki said:
Source ports with skyboxes
GLBoom+ — using the GLDEFS method from GZDoom

http://zdoom.org/wiki/GLDEFS#Skybox_definitions

[Tolwyn]

I stand corrected and SHOULD have said: Instructions and tutorials when searching through Google are difficult to aggregate. I found this after my initial post, but Google had a hard time directing my question to this WIKI. Believe me, it's bookmarked now!

I PRINTED that wiki page as a PDF and am taking my own notes and and my own example wad.

So... I'm working on supplementing.

left = N
back = E
right = S
front = W
up = NEEDS to be VERTICALLY flipped for many skyboxes
down = WORKS AS-IS with the above order unless your rotate the X-axis of your sky. Rotate in 90 degree increments (+/-) to accomodate a modified orientation around the X axis.

The SEQUENCE "direct out of most skybox archives" in the GLDEF to work for most skyboxes is:

Skybox SKY1
{
  TSKY2_RT // SOUTH
  TSKY2_FT // WEST
  TSKY2_LF // NORTH
  TSKY2_BK // EAST
  TSKY2_UP // This must be VERTICALLY FLIPPED (not mirrored) to work with the initial order.
  TSKY2_DN // NO CHANGE OUT OF BOX ROTATE to Accomodate your chosen initial order of S, W, N, E
}

scifista42 said:

Excuse me?
http://zdoom.org/wiki/GLDEFS#Skybox_definitions

40oz said:

Are you making maps, Tolwyn?

I'm getting ready to start Tolwyn04, yes. ;)

NEW music
NEW textures*

*not new, but not out of the IWAD. Supplemented textures is more accurate.

Will work for:

PRBOOM+ and I'll release one that works with Doomsday.

Should work for GZDoom, too.

[Reisal]

What about replacing the ZZZFACE# textures used for the Icon of Sin wall face in Doom 2? I also don't recall software Boom ports being able to use skyboxes. However, using 4 256x128 patches could do the job if skyboxes are not able to be utilized.

Someone clarify my wording if I'm wrong on software skyboxes, or was Quake and Quake 2 examples of it?

[andrewj]

Glaice said:

I also don't recall software Boom ports being able to use skyboxes.

Yeah this GLDEFS feature will not work in software rendering, only OpenGL rendering.

Quake 2 was the first id engine with a real skybox (six images forming a cube).

Quake 1 had a special two-layer scrolling effect, using a single image (split into two halves for the layers).

[Tolwyn]

Ok. Using PRBOOM+

I have created a PWAD with a GLDEFS lump defining SKY1, SKY2, and SKY3.

The skies (png files) work great.

I tested in Doom2.

But when I use the PWAD in other maps (MM15 for example or Plutonium map32) some sidedefs arent rendered, holes in tge map, etc.

I figured it was a nodes issue so i tried rebuilding the nodes using

zennode
glbsp
etc.

Still the behavior persists.

Any idea what I am missing?

[plums]

But when I use the PWAD in other maps (MM15 for example or Plutonium map32) some sidedefs arent rendered, holes in tge map, etc.

This was a bit unclear, do you mean you tried use the wad that has only a GL sky in combination with other existing maps?

Anyhow, hard to say what the problem is without seeing it, maybe it's the way you've arranged your skybox resources? (You are right, the documentation for this kind of thing is a bit lacking at times and often comes down to "find a wad that works and copy it".) Here is how I have done it:

* Patches in-between PP_START and PP_END are always in Doom graphic format. These patches should be a different name than SKYx.

* High-quality PNGs go between HI_START and HI_END. They have the same name and dimensions as the patches in PP_START and PP_END. For GL skyboxes, you might put in some dummy patches that are just all black to match the HQ PNGs to.

If this doesn't make sense I'll whip up an example shortly.


edit: Here's an example I had already, ignore how ugly it looks. No map but it works on the first sky of doom2.wad or whatever.
http://www.mediafire.com/download/n5v9iz67kbybmyi/sbsky1.wad

So it's got a structure like this

HI_START
RBOW_1
RBOW_5
RBOW_6
HI_END

GLDEFS

PP_START
RSOFT
RBOW_1
RBOW_5
RBOW_6
PP_END

TEXTURE1
PNAMES

So the normal-quality patches and textures are pretty standard, except RBOW_* are just temp patches that I stole from epic2.wad. They appear in the texture/pnames lists but they never get used for anything. The SKY1 texture uses the RSOFT patch, so that's what you see in software mode.

In between HI_START and HI_END the RBOW_* graphics are high resolution PNGs, and GLDEFS references them for building a skybox. So that's what you get in GLBoom+ or GZDoom for any map that uses SKY1 for its sky.

You probably had 95% of this figured out already but since I'm not sure what you're doing wrong I tried to be more thorough.


edit2: Oops this isn't the problem at all, oh well, leaving it for reference.

[Tolwyn]

my skies work fine as skies.
When I load:

prboom-plus.exe -iwad doom2.wad -file t_skies.wad -warp 15

looks great.

prboom-plus.exe -iwad doom2.wad -file mm.wad -warp 15

the SKY is fine... but some walls are see-thru etc.

Thats why I think it must be a caching issue with prboom or nodes.

The sky pwad is fine. all resources are right...

I am out of town and typing on my phone. when I get back I will post the pwad and screenshots.

[plums]

Oh ok you probably have TEXTURE1/PNAMES lumps in both t_skies.wad and mm.wad and they're conflicting. Those lumps aren't cumulative, you've got to define every texture and patch you plan on using in the last wad you load. So if you wanted to have mm.wad textures with t_skies.wad you have to copy TEXTURE1 and PNAMES from mm.wad into t_skies.wad and then add the extra textures and patches to those lumps in t_skies.wad

[Tolwyn]

plums that was it!

Thank you.
I forgot that the PNAMES and TEXTURE1 Lumps aren't AGGREGATORY (meaning they don't aggregate into one long list — the last PWAD will replace the previous one).

This makes sense and ALSO answers my first gripe about that first example PWAD. That's WHY that person used CEMENT1-5 patches... there's no need for a PNAMES or TEXTURE1 LUMP in the example.

Ok.

Now I wonder if compiling in a ZIP or PK3 in the patches and textures directory would work? Hmmm.

In any case, I was able to solve my problem by understanding the limitation.

I appreciate you taking the time to respond.

[plums]

Welcome, and thanks for the better choice of word - this is a problem that comes up often, so I'll be sure to use it next time :)

[Tolwyn]

plums said:

Welcome, and thanks for the better choice of word - this is a problem that comes up often, so I'll be sure to use it next time :)

Cumulative is accurate as well! They are synonyms.

(today's vocabulary brought to you by Readers Digest)