PrBoom-Plus, ver. 2.5.1.4

[TimeOfDeath]

Ok, I tried my other computer and 320x200 works good, but my laptop doesn't work with 320x200. :)

[entryway]

TimeOfDeath said:

Ok, I tried my other computer and 320x200 works good, but my laptop doesn't work with 320x200. :)

Modern drivers do not support 320x200 resolution and in case of software mode SDL will emulate it within 640x480 with black borders around 320x200 game window in center.

[Doom_user]

In the GL renderer's 5:4 aspect ratio the sky texture should be vertically stretched like it is in the software renderer's 5:4 aspect ratio, otherwise the sky can be seen tiling in places where it shouldn't.

http://img408.imageshack.us/img408/8273/compc.png

[entryway]

Doom_user said:

In the GL renderer's 5:4 aspect ratio the sky texture should be vertically stretched like it is in the software renderer's 5:4 aspect ratio, otherwise the sky can be seen tiling in places where it shouldn't.

http://img408.imageshack.us/img408/8273/compc.png

Fixed (for case when mlook is disabled).

[Jodwin]

I'm curious about one thing, I'm not really expecting a "fix" since it's probably an issue with SDL, but I'd like to have a confirmation if possible: prboom+ runs much slower than ZDoom on my laptop. I have Win7, Turion 64 TL-56 (1.80Ghz), 2Gb ram and Radeon x1270. In ZDoom pretty much everything works perfectly smooth in the native 1280x800 resolution (staring at multiple Boom-translucent walls up close causes some slowdown, and obviously Nuts is Nuts), but 1280x800 in prboom+ is pretty much unplayable because it stutters all the time. I have to drop my resolution to 800x600 and even then it occasionally stutters a bit. I've tried both windib and directx, and the former is slightly (but only very slightly, 0.7 fps difference on a nuts3 test demo I made) faster. All other features are on lowest settings (where as ZDoom is fine with a lot of transparent projectiles on screen, again on 1280x800).

So, is it really SDL that's causing these issues, or something else?

[entryway]

I do not know. For me prboom-plus (software renderer) is slightly faster than zdoom:

118 fps instead of 83 on epic.wad map05 at 1024x768
389 fps instead of 333 on doom2.wad map01 at 1024x768

In any case, software mode sucks in prboom and all sdl-based ports, because 'windib' does not support vsync, 'directx' does not work correctly at all on modern systems (I need to taskkill explorer to have correct colors in my Win7)

[Super Jamie]

Could it have something to do with the fact that the PrB+ optimisations are written with an Intel in mind, and Jodwin's running on AMD?

You could always run GlBoom and turn off sprite/texture filtering, though I tried that and went back to software mode as GL lighting is not my preference.

[Jodwin]

Super Jamie said:

You could always run GlBoom and turn off sprite/texture filtering, though I tried that and went back to software mode as GL lighting is not my preference.

Yeah, glboom runs just fine, but just like you the lightning just isn't my cup of tea. It's particularly bad for testing map lightning.

[entryway]

Super Jamie said:

Could it have something to do with the fact that the PrB+ optimisations are written with an Intel in mind, and Jodwin's running on AMD?

It could not, but you always can try MSVC plain build:
prboom-plus-2.5.0.6-win32.zip \ prboom-plus-2.5.0.6 \ add \ safe.zip \ prboom-plus_safe.exe

[Catoptromancy]

I rather like glboom-plus with glboom lighting, no filtering and certain texture format. No idea what texture format really is, A4 something. But it looks nice.

[entryway]

Catoptromancy said:

No idea what texture format really is, A4 something

If A4 is better than A8 (GL_RGBA), then why not A1?

1 bit for alpha should be better than 4 bits if 4 bits are better than 8.

[Never_Again]

entryway said:

If A4 is better than A8 (GL_RGBA), then why not A1?

1 bit for alpha should be better than 4 bits if 4 bits are better than 8.

*whoooosh* /Cato stares at the sky ;)

Jodwin said:

Yeah, glboom runs just fine, but just like you the lightning just isn't my cup of tea. It's particularly bad for testing map lightning.

prBoom-plus'es lighting is not 100% faithful to the original, but I suspect that you two are not talking about the same thing. I'd even go as far as suggest that you are not aware of the Fog Based lighting mode either.

Edit: transferred to next post.

[Jodwin]

Never_Again said:

prBoom-plus'es lighting is not 100% faithful to the original, but I suspect that you two are not talking about the same thing. I'd even go as far as suggest that you are not aware of the Fog Based lighting mode either.

I do know about the fog model in glboom, but IMHO it's even more ugly. For my (mapping) purposes prboom+ in 32bit mode is the best (looks pretty much the same as ZDoom, which unlike 8bit mode in prboom+ doesn't ignore my display drivers' settings (I use slightly decreased gamma because of an overly bright monitor on my desktop)).

[Never_Again]

I grabbed a few screenies and it looks like you are right, Jodwin.



All three shots 320x200 blown up to 640x480, the glBoom-plus ones have all filtering/resizing options off, with Fog Based lighting mode for GL.

[Revved]

I don't know if it's me, but for some reason, Prboom+ 2.5.0.7 for Mac seemed to be avant-garde, due to the only texture being various shades of black and white.



Since this is for Mac, I can't really find any .cfg files in the program. This is what entryway had told me, but I'm not so sure how to change it. Note that all of the other PrBoom+ prior to this one work fine, but this one didn't really seem like it was trying.

[entryway]

Revved said:

Since this is for Mac, I can't really find any .cfg files in the program. This is what entryway had told me, but I'm not so sure how to change it. Note that all of the other PrBoom+ prior to this one work fine, but this one didn't really seem like it was trying.

Ask MAC users where cfg is and how to change it. I do not know. I even did not see a MAC in my life.

[myk]

Jodwin said:
(I use slightly decreased gamma because of an overly bright monitor on my desktop).

Why use graphics-card gamma? Doesn't your monitor have hardware-based brightness settings?

[Graf Zahl]

myk said:

Why use graphics-card gamma? Doesn't your monitor have hardware-based brightness settings?

Graphics card gamma often yields better results. The controls on my monitor, for example, are rather useless. There's a contrast and a brightness control but no gamma. Strangely this has been the case with every monitor I ever had.

[Spleen]

Never_Again said:

I grabbed a few screenies and it looks like you are right, Jodwin.

All three shots 320x200 blown up to 640x480, the glBoom-plus ones have all filtering/resizing options off, with Fog Based lighting mode for GL.

With regards to the column brightness differing, that's the software renderer's funky tendency to shift around the brightness of absolutely horizontal/absolutely vertical linedefs. It doesn't seem too hard to emulate in OpenGL, though that's one of the things I like less about the software renderer because it doesn't work for more complicated geometry. But then again I am sure maps are designed with it in mind, which might make it important to emulate.

[Gez]

Spleen said:

With regards to the column brightness differing, that's the software renderer's funky tendency to shift around the brightness of absolutely horizontal/absolutely vertical linedefs. It doesn't seem too hard to emulate in OpenGL, though that's one of the things I like less about the software renderer because it doesn't work for more complicated geometry. But then again I am sure maps are designed with it in mind, which might make it important to emulate.

ZDoom allows for 1-points increments in brightness, and this let it generalize the fake contrast to any angle (that's the "smoothlighting" option). But with the standard 8- or 16-point increments, the only way you could have a smooth progression for any angle would be to dramatically exaggerate the light differences, and it wouldn't look good.

[cmart]

entryway said:

Ask MAC users where cfg is and how to change it. I do not know. I even did not see a MAC in my life.

Should be in library/application support/prboom-plus/ Same place as your iwads and save game files.

I myself can confirm the entryway's suggested fix works - I had the same problem and was about to make a post about it myself when I saw Entryway's response in the news thread.

[Revved]

cmart said:

Should be in library/application support/prboom-plus/ Same place as your iwads and save game files.

I myself can confirm the entryway's suggested fix works - I had the same problem and was about to make a post about it myself when I saw Entryway's response in the news thread.

Yep, it works now. Problem solved.

[entryway]

Revved said:

Yep, it works now. Problem solved.

If "gl_compatibility 1" works, then you should try to understand it more precisely, because "gl_compatibility 1" cuts many features and introduces some bugs in renderer.

Set gl_compatibility to 0 and try to change following default values:
gl_arb_multitexture 1
gl_arb_texture_compression 1
gl_arb_texture_non_power_of_two 1
gl_ext_arb_vertex_buffer_object 1
gl_ext_blend_color 1
gl_ext_framebuffer_object 1
gl_ext_packed_depth_stencil 1
gl_ext_texture_filter_anisotropic 1
gl_use_stencil 1
gl_use_display_lists 0

Probably changing some of them to 0 will fix the problem too. Tell me these variables.

In sorces gl_compatibility 1 does these things

  if ((compatibility_mode) || (gl_version <= OPENGL_VERSION_1_1))
  {
    lprintf(LO_INFO, "gld_InitOpenGL: Compatibility mode is used.\n");
    gl_arb_texture_non_power_of_two = false;
    gl_arb_multitexture = false;
    gl_arb_texture_compression = false;
    gl_ext_framebuffer_object = false;
    gl_ext_packed_depth_stencil = false;
    gl_ext_blend_color = false;
    gl_use_stencil = false;
    gl_ext_arb_vertex_buffer_object = false;
    GLEXT_CLAMP_TO_EDGE = GL_CLAMP;
    gl_version = OPENGL_VERSION_1_1;
  }

btw, ATI?

[entryway]

Revved said:

I don't know if it's me, but for some reason, Prboom+ 2.5.0.7 for Mac seemed to be avant-garde, due to the only texture being various shades of black and white.

Fixed. I'll re-release MacOS build soon.

-    glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP,
-      (gltexture->flags & GLTEXTURE_MIPMAP));
+    glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP,
+      ((gltexture->flags & GLTEXTURE_MIPMAP) ? GL_TRUE : GL_FALSE));

Some drivers are too accurate and do not allow any_non_zero instead of GL_TRUE.

[cmart]

entryway said:

Fixed. I'll re-release MacOS build soon.

Cool, thanks. Glad you could find the problem.

[entryway]

cmart said:

Cool, thanks. Glad you could find the problem.

It is already uploaded (2.5.0.7a), but some old Mac hardware still report about support for non power of two textures and fail at MIPMAPs building. "gl_arb_texture_non_power_of_two 0" in config for such ATI drivers.

[JPL]

Not sure if this is the right place for this, but I couldn't find an official forum for PrBoom+ anywhere.

I wasn't able to compile the latest (2.5.0.7) from source on Linux (Ubuntu 10.04) from the .zip provided on SF.net - there's no configure script already there, and autoconf fails to generate one.

Comparing the contents of that zip to the tar.gz for the previous version, it looks like some files might have been left out - 2.6.0.7.tar.gz for example includes an already-generated configure script.

Is this a simple mistake, something I'm doing wrong or is the 2.5.0.7 source zip just for compiling on win32? If so, is a source archive for other platforms planned?

[entryway]

JPL said:

Is this a simple mistake, something I'm doing wrong or is the 2.5.0.7 source zip just for compiling on win32? If so, is a source archive for other platforms planned?

tar.gz is already there

[printz]

my downloaded Mac PrBoom+ 2.5.0.7 version doesn't even start up. It crashes at startup. Here's what it says:

Process:         Launcher [4275]
Path:            /Applications/PrBoom-Plus.app/Contents/MacOS/Launcher
Identifier:      net.sourceforge.prboom-plus
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  launchd [193]

Interval Since Last Report:          4073601 sec
Crashes Since Last Report:           29
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   6

Date/Time:       2010-08-23 15:19:04.903 +0300
OS Version:      Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:  64F2E7DC-6E04-44B4-9C6A-DDEDEA9385E4

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  unknown required load command 0x80000022

System configuration tab:

Model: MacBook4,1, BootROM MB41.00C1.B00, 2 processors, Intel Core 2 Duo, 2.1 GHz, 1 GB
Graphics: kHW_IntelGMA965Item, GMA X3100, spdisplays_builtin, 144 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x88), Broadcom BCM43xx 1.0 (5.10.91.21)
Bluetooth: Version 2.1.9f10, 2 service, 0 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: FUJITSU MHY2120BH, 111,79 GB
Parallel ATA Device: MATSHITACD-RW  CW-8221
USB Device: Built-in iSight, (null) mA
USB Device: Apple Internal Keyboard / Trackpad, (null) mA
USB Device: IR Receiver, (null) mA
USB Device: Bluetooth USB Host Controller, (null) mA

But judging from how things are going here, no one is going to help. Fuck it.

And as for 2.5.0.7a? The downloaded disk image from sourceforge doesn't even work.

[Gez]

Seems like some debug code has not been cleaned out of the release build, since the reason it crashes is because it has reached a breakpoint.