Note to dev build maintainers

[Graf Zahl]

Please note that I changed the setup of GZDoom to require GLEW from now on. At least version 1.10 is required to get support for GL 4.4 features.

This has a few implications:

1. Without setting up GLEW in CMake you won't be able to build an executable anymore.
2. GLEW.dll must be distributed with GZDoom.exe
3. All pre GL 2.0 support has been removed.

The reason for this is that I plan to use a few GL 4.x features on modern hardware and supporting them with the manual extension mechanism is quite annoying.
GL 1.x support was removed because this only concerns some old Intel integrated chipsets, everything else this old should have been vanished by now. But this support makes it far more problematic to add code to support mode modern features.

There may be a few more upcoming changes affecting older hardware. As it currently stands, the existing vertex buffer support only has a positive effect on GL 4.x cards, so improving its usability by requiring some 4.x features seems a good idea. Of course this means that some of it won't be usable anymore on older hardware, but since it doesn't provide any benefit there I don't consider it a problem.

[Blue Shadow]

To clear my own confusion, what is the minimum required OpenGL version to run new GZDoom builds? Is it 3.x or 4.x?

[Graf Zahl]

The minimum required version is 2.0, it previously was 1.3.
For full feature support 3.0 is needed, for older hardware some fallback options are in place.

Unsupported features on 2.x are:

- brightmaps
- real texture warping - it will use the software method of altering the texture image
- full screen colormap effects - a limited fallback option is in place but it looks different
- some limitations of dynamic lights
- desaturated light settings are ignored
- subtractive blending of sprites is limited in foggy areas

Any further feature removal is not expected for the foreseeable future. It'd only make sense once GL 4.x reaches a market share where everything else becomes irrelevant.

[Enjay]

I assume the confusion came from the test build thread. As Graf stated there, the test build was intended for 4.x machines (and crashed for me on my 3.x card). However, my own build from a Git checkout works on my machine. So, as I understand it, the only 4.x-only build was Graf's test build. Other builds should be in line with Graf's post above.

[Blue Shadow]

@Graf: Thanks for the rundown. It's all clear now.

I assume the confusion came from the test build thread.

Heh, yeah, that was pretty much what got me confused; you've got the test build in one hand, and the upped requirements for the 'normal' builds and future releases in the other happening at the same time.

[Enjay]

Can I ask where (or even if) Visual C++ 2010 saves map files?

In a situation like this, where I have perhaps got my manual builds up and running but there is a delay with the automatic system, I'll happily upload my builds as a stop-gap. However, there doesn't seem to be much point without the map files to help crash investigations. Unfortunately, I simply can't find them. I've searched in the source directory, the CMake directory, everywhere I could think of. No map file turns up. Does 2010 use a different file extension? Is it something to do with CMake? Is it me?

[Graf Zahl]

You have to enable map file generation in CMake. They should be in the same directory as the EXE.

[Enjay]

I wonder if you could point me to somewhere that tells me how to do this? I looked through CMake last night and there was nothing obvious there. I did a bit of googling and I did find one page that seemed to provide an answer but when I followed their instructions and set up an additional key, it didn't work.

[Graf Zahl]

The ZDoom config for CMake contains a setting to generate a mapfile.

[Enjay]

Right in front of me all along.

OK, it's been a while since I hand-cranked a build for upload to the site but I think I put all the relevant files up. One thing I did notice, the auto builds are "G1.9pre" (e.g. gzdoom-G1.9pre-584-ga4076ff) whereas mine is gzdoom-g1.8.1-597-gcd6d653. Have I messed up my config somewhere along the line?

Anyway these files:

gzdoom-g1.8.1-597-gcd6d653.7z
gzdoom-g1.8.1-597-gcd6d653.map.gz

are online in the usual place and built from code checked out today.

[Graf Zahl]

Make sure you fetch/pull all the tags from the remote. Git requires this to be set manually.

[Enjay]

Sorry for being a n00b but I can't figure out where to do this in TortoiseGit (I know Git is much better for you guys than SVN but, for all I need it for, SVN was far simpler - basically, I don't really understand Git in the way that I did with SVN).

Anyway, I "fixed" the issue with my copy of GZDoom simply by deleting it and downloading from scratch. However, I'd rather not do that for my own modified code. I mean, my changes are minimal so it wouldn't take long to do them again but I'd rather learn how to do things properly. I've poked around in all sorts of places, messed around with all kinds of settings and yet things still don't seem to be doing what I try to ask them. I even get a hint that I've done it right; when I compile, I get this:

Code: Select all

2>  src/gitinfo.h is up to date at commit G1.9pre-659-g68c4aaf.

But when I run my exe, I get:

Code: Select all

This file was generated by GZDoom g1.8.1-651-g68c4aaf on Wed May 14 22:41:13 2014

Sorry, I realise that this is a little away from the original purpose of the thread.

[edit]I think that I may have sorted it out. there was a gitinfo.h file in the original (not CMake) directory. Deleting it made a new one appear at compile time with the G1.9pre prefix. Of course, I don't know why this file is generated in the original source/pull folder rather than the CMake generated project. I don't know if it's meant to be like that or not. [/edit]

[Enjay]

Yeah, basically it looks like I just needed to clean my copy.

Anyway, to avoid confusion with numbers, I've put gzdoom-G1.9pre-605-gcd6d653.7z up.