entryway Posted May 11, 2010 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? 0 Share this post Link to post
Graf Zahl Posted May 11, 2010 Can you send me the WAD? This should work. 0 Share this post Link to post
entryway Posted May 11, 2010 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. 0 Share this post Link to post
entryway Posted May 11, 2010 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. 0 Share this post Link to post
Graf Zahl Posted May 11, 2010 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. 0 Share this post Link to post
andrewj Posted May 12, 2010 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... 0 Share this post Link to post
phi108 Posted May 12, 2010 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. 0 Share this post Link to post
Graf Zahl Posted May 12, 2010 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. 0 Share this post Link to post
entryway Posted May 12, 2010 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) 0 Share this post Link to post
RestlessRodent Posted May 12, 2010 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. 0 Share this post Link to post
entryway Posted May 12, 2010 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 0 Share this post Link to post
hobomaster22 Posted May 12, 2010 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.. 0 Share this post Link to post
Gez Posted May 12, 2010 Doesn't really matter when for most people in the Doom scene, BMP == 8-bit paletted BMP and BMP == MS Paint. 0 Share this post Link to post
Enjay Posted May 12, 2010 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. 0 Share this post Link to post
entryway Posted May 12, 2010 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. 0 Share this post Link to post
Graf Zahl Posted May 12, 2010 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? 0 Share this post Link to post
DaniJ Posted May 12, 2010 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). 0 Share this post Link to post
Graf Zahl Posted May 12, 2010 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. 0 Share this post Link to post