Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[SOLVED] - PRBOOM+ Skybox Question

Recommended Posts

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



This is if I define SKY1.

What if I define SKY2?


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.

Share this post

Link to post

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.



Share this post

Link to post

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_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:

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.

Share this post

Link to post

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?

Share this post

Link to post
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).

Share this post

Link to post

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


Still the behavior persists.

Any idea what I am missing?

Share this post

Link to post

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.

So it's got a structure like this




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.

Share this post

Link to post

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.

Share this post

Link to post

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

Share this post

Link to post

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.


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.

Share this post

Link to post

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 :)

Share this post

Link to post
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)

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