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

GZDoom six-faces skyboxes

Recommended Posts

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?

Share this post


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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


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

Share this post


Link to post

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.

Share this post


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

Share this post


Link to post

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)

Share this post


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

Share this post


Link to post

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

Share this post


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

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


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

Share this post


Link to post

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.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
×