DRD Team

Eruanna wrote:Your card supports OpenGL 3.0. It should perfectly support the render buffer features just fine. I don't know - I'll leave this to one of the main programmers, or another techie, to figure that one out, because from what I can see there's no reason this shouldn't work.

Yes, it's really strange. The effects was working fine some versions ago (g2.2pre-2067-g2f893af for example, from Aug 24).

Does it report the presence of GL_ARB_uniform_buffer_object? This extension is a requirement to get the 'modern' render path, without which the postprocessing is disabled.
This wasn't the case in the earlier revisions. I had the choice between making a clear distinction between 'legacy' and 'modern' or allowing mixed configurations to run. I chose the former because it means a significant reduction in workload and was really the only solution to get the 'modern' render path working on macOS. Your card may just have been caught square in the middle of it.

Graf Zahl wrote:

5thdefender wrote:

_mental_ wrote:Post your spec, graphics hardware in particular.

Ram: 2.00 gb
Intel Core 2 E8400 Duo
GPU: Intel Q45/Q43 express chipset
OS: Windows 7 64 bit

That hardware is too old and does not support any of the postprocessing options.

Does buying a better GPU alone will help or not?

If you can get a decent graphics card installed in that system, sure. It not only will have more features but also be a lot faster. Even the lowest of low end cards, like a Geforce 610 would do a lot here.
The intel Q43/45 is among the weakest chipsets still supported and the feature set is dismal.

Eruanna wrote:

fr1dd wrote:Has the following been removed completely and can no longer be controlled as a global setting?

gl_lights_size=
gl_lights_intensity=

Yes, it has.

Ok. And there is no alternative/workaround for this?
Reason for asking is because I think that dynamic lights with lights.pk3 generate too much light and doens't look realistic or create the right atmosphere in dark maps.

Graf Zahl wrote:Does it report the presence of GL_ARB_uniform_buffer_object? This extension is a requirement to get the 'modern' render path, without which the postprocessing is disabled.
This wasn't the case in the earlier revisions. I had the choice between making a clear distinction between 'legacy' and 'modern' or allowing mixed configurations to run. I chose the former because it means a significant reduction in workload and was really the only solution to get the 'modern' render path working on macOS. Your card may just have been caught square in the middle of it.

Oh... there is any way to know if I have this extension?

If this is the problem, what could I do? I need to buy a new card or it's something that I can solve with a download/update?

GZDoom prints the list of extensions to the console when starting. You can log that to a file with the '+logfile' command line parameter and then search the created text file. If this is the reason, a hardware upgrade would be the only way to get the modern features - I hope this isn't a laptop where such things are often impossible.

So all I have to do is to find a good GPU card and possibly a power supply. Thanks, everyone!

Here you go.

• Fully functioning Line and Sector Portals
• Roll Sprites
• Flat Sprites
• Sprites Facing Camera
• Bloom
• Multisampling
• Stereo 3D VR
• Quad Stereo
• Tonemap Setting
• Lens Distortion Effect
• DECORATE Anonymous Functions
• Lots of new ZDoom development features

Graf Zahl wrote:let's better highlight the biggest feature in here: Fully functional interactive portals, both of the line and sector variety.

Any way I can make a portal sector portal that doesn't allow sound through? So far all enemies from either stacked sector get woken up, which isn't ideal in a lot of cases.

Unfortunately not. This is something I already had on my list, but forgot to implement.
I hope it gets into 2.2.1...

Question, will you be adding tags to 2.2.0 or 2.2.1?

Is 2.2.1 going to be that aforementioned bugfix release? I'm thinking of tagging an official release of GZDoom-GPL against that bugfix release...

Is the openAL sfx library shipped with the x64 build the 32-bit version of that library or does the numeric suffix of the file name signify a version number? Regardless of which is the case, would it not be easier for the library to be dropped from the official build and distributed separately, á la fluidsynth?

Bad naming conventions. In fact this is extremely annoying because this prevents both 32 and 64 bit builds from coexisting in the same directory.

As for distribution, no. FluidSynth is an entirely optional package while the sound backends are to be considered part of the engine.

Yeeeh. New version of port is here.)

And you know I'm playing on 2.1.1 x64 port on video chip Intel HD 4600 which is built into the processor i5 4690 - and I feel self great. Connected effects Lights.pk3 and Brightmaps.pk3 added around 20 3D models. Windows 10 x64; 8GB RAM; 1080p 60fps. Сool port.