GZDoom six-faces skyboxes

[entryway]

How to make six-faces hi-res skybox with gzdoom?

GLDEFS lump:

Skybox SKY1
{
  BIGDOOR1
  BIGDOOR2
  BIGDOOR3
  BIGDOOR4
  BIGDOOR5
  BIGDOOR6
}

Then I added my skybox faces between HI_START and HI_END markers with these names, but GZDoom does not want to use them. It uses standard BIGDOOR1..7 low-res textures from doom2.wad instead.

Is it a bug? Any chance to have it fixed in future?

[Graf Zahl]

Can you send me the WAD? This should work.

[entryway]

Graf Zahl said:

Can you send me the WAD? This should work.

Ah, probably I have outdated gzdoom on my work. Will try again right now.

[entryway]

I know what is wrong. Not sure it is a bug. GZDoom does not recognize my BMPs as hires textures (yeah, they should not be BMP, just forget to convert, but glboom-plus recognize BMPs as hires). I saved them as PNG and all is correct now.

[Graf Zahl]

BMPs are not a valid texture format for ZDoom. They are pretty useless, considering that they are uncompressed and have no means to store transparency. And unlike PrBoom-Plus (G)ZDoom does not use external image loading libraries.

The only reason I added PCX and TGA support was for model skins which often came in these formats. Without that there wouldn't have been any need to ever support anything but PNG.

[andrewj]

Graf Zahl said:

Without that there wouldn't have been any need to ever support anything but PNG.

One good reason to support (e.g) TGA is that loading PNGs is slow slow slow...

[phi108]

I did notice when cycling images in Irfanview that high-res PNGs cycle slower than BMPs. Also, in Direct3D ZDoom in a high resolution, 35 fps PNG weapon animations are laggy on their first cycle, while later iterations of animations go smoothly. Maybe another image format would eliminate this lagging, but PNGs give me the best compression, and on low resolutions or "vid_hw2d 0" (or a better computer), there is no lagging problem.

[Graf Zahl]

andrewj said:

One good reason to support (e.g) TGA is that loading PNGs is slow slow slow...

Huh? What? You must be using a really shitty image library if you get such results. I'm having no problems ever with ZDoom even when the PNGs are effectively double-compressed inside a Zip. JPGs, on the other hand - they are indeed slow in comparison.

phi108 said:

Also, in Direct3D ZDoom in a high resolution, 35 fps PNG weapon animations are laggy on their first cycle, while later iterations of animations go smoothly. Maybe another image format would eliminate this lagging, but PNGs give me the best compression, and on low resolutions or "vid_hw2d 0" (or a better computer), there is no lagging problem.

That has nothing to do with PNG. Uploading large textures to the video RAM is the main cause here. You'd get the same lag with other formats.

[entryway]

I think precache system does not precache skybox textures or probably something else is wrong.

I get very noticeable lag (~0.4 sec) on map01 when I try to turn round with this wad on my Core2+8800+Win7

My config: http://prboom-plus.sf.net/zdoom-entryway.ini
gl_precache is true.

EDIT:
This lag still occur after save/load: load map01 -> look in window (lag) -> turn away -> save -> load -> look in window again (lag again)

[RestlessRodent]

Graf Zahl said:

They are pretty useless, considering that they are uncompressed and have no means to store transparency.

Bitmap files can have an alpha channel.

http://sites.google.com/site/ghostlydeath/Untitled.bmp.gz

However, most image viewers and some editors ignore the alpha channel and don't usually provide support for alpha at all.

[entryway]

GhostlyDeath said:

Bitmap files can have an alpha channel.

http://sites.google.com/site/ghostlydeath/Untitled.bmp.gz

However, most image viewers and some editors ignore the alpha channel and don't usually provide support for alpha at all.

My editor (XnView) supports it.

SDL_image also has no problems:
http://prboom-plus.sourceforge.net/bmp_with_alpha.png

[hobomaster22]

GhostlyDeath said:

Bitmap files can have an alpha channel.
http://sites.google.com/site/ghostlydeath/Untitled.bmp.gz

Yeah, I noticed they had an alpha channel about a year ago, but I've never noticed anything to utilize it. 32 bit bmps have RGBA (stored as BGRA.. obviously and all pixel data bass-ackwards) and there's a field to specify compression, which I've never noticed to be used either..

[Gez]

Doesn't really matter when for most people in the Doom scene, BMP == 8-bit paletted BMP and BMP == MS Paint.

[Enjay]

Gez said:

Doesn't really matter when for most people in the Doom scene, BMP == 8-bit paletted BMP and BMP == MS Paint.

and, for most many people in the Doom community BMP == The Doom format.


And to be very clear THEY ARE WRONG.



And I wouldn't say loading PNGs are slow, slow, slow but I have noticed, on occasion, that there is a slight, very slight, additional load time compared with equivalent Doom graphics.


The load stutter with skyboxes has been mentioned before though, and I have experienced that myself.

[entryway]

DDS textures will load with max possible speed. GLBoom-Plus loads DDS dxt3/dxt5 hires textures about 2.5x faster than PNGs, because unpacking and mipmap building are not needed. It contains prepared for graphics-accelerator RAW data.

[Graf Zahl]

Concerning the original problem, it's just that the texture precaching code is from ZDoom's software renderer and doesn't work anymore with the hardware renderer.

However, remember the current status of that?

[DaniJ]

Graf Zahl said:

Concerning the original problem, it's just that the texture precaching code is from ZDoom's software renderer and doesn't work anymore with the hardware renderer.

However, remember the current status of that?

You tell us Graf. You haven't yet made clear what is happening with GZdoom (certainly no mention of the recent drama on the homepage).

[Graf Zahl]

I have done a handful of small fixes which I needed myself for playing but the current status remains: No work is being done on the GL renderer. I'm not motivated and even if I wanted to I just don't have the time to do larger work on it. And doing the precaching right sounds like a larger task.