revelator

Ok i think i got it in working order now, while fixing this up i also moved the vertex and fragment programs for megatexture support out of material.cpp and into draw_arb2.cpp in the chain that looks for custom shaders. ill commit it in a bit.

I can only guess that ms recently did some massive changes to msvc 2013 so be carefull when updating it, as they have stated that the old multibyte support libraries will be removed completely. well i got it to compile but it crashes when loading any mission, btw do i need a new shader for the changes you made ? also i had to make some workarounds in draw_arb2.cpp as newstage is not defined anywhere the compiler refused to compile it. i fixed that by looking at the code in draw_common.cpp to see how newstage was defined, which btw left some questions as it seems to disable certain parts, like ambient lighting. msvc2013 also needs recompiled versions of boost to be able to build darkmod, but if what you say is true i suspect greebo simply uses the 2010 toolset from the msvc 2013 interface.

Checked out your changes and i can report that it needs a few fixes before compiling. Also msvc 2013 is a complete nogo vanilla will newer work with it unless we change all the underlying functions to unicode (that will be a massive undertaking), the reason is that ms has removed multibyte support completely so all projects need to be unicode. I found something that might work though here http://www.microsoft.com/en-us/download/details.aspx?id=40770 this will install the removed multibyte support so that part should work again. There are also problems with vanilla being unable to find system headers such as windows.h and winsock2.h because the SDK paths are all wrong for msvc 2013. Im working on it though and i hope to have the changes in soon.

P.s im busted (black friday here in denmark) so ill take a nap before ill start investigating this.

MH moved most of the shader commands to the framebuffer if i remember correctly, and it was indeed interesting as he gained much more detail than normal in doom3 by doing it. I think there was also a few engine changes needed for it to work. Newer quite understood swizzle but ill see if i can find some documentation about it.

Cool m8 steve is also joining in on this branch to help btw.

Thanks guys

Actually starting on my new part time job tomorrow so a bit less time to work on this, no worries though ill still work on this.

Ok removed glasswarp. Added a function to clear matrix interactions that might interfere with the gui, one such is the POM shader from sikkmod, sliding may still happen but thats another problem caused by bad normals. Used idlibs clampFloat to clamp color variations. edit: this part - else if ( !token.Icmp( "glassWarp" ) ) { - ts->texgen = TG_GLASSWARP; - continue; - } was changed to else if ( !token.Icmp( "glassWarp" ) ) { - ts->texgen = TG_GLASSWARP; continue; } that way we wont get an error in the unlikely case someone do actually use it.

Whoops just noticed these are only defined for tdm_update so added /lib32 /usr/lib32 to sconstruct for darkmod, comitted changes.

Hmm scons actually does look in /usr/lib32 look here from sconscript. if ( g_os == 'Linux' or g_os == 'MacOSX' or g_os == 'FreeBSD' ): if g_os == 'Linux': if LINUX_TARGET_ARCH == 'i386': # get the 64 bit machines on the distcc array to produce 32 bit binaries BASECPPFLAGS.append( '-m32' ) BASELINKFLAGS.append( '-m32' ) # help 64 bit machines to find the compatibility 32bit libraries BASELINKFLAGS.append( '-L/lib32' ) BASELINKFLAGS.append( '-L/usr/lib32' ) BASELINKFLAGS.append( '-pthread' ) BASELINKFLAGS.append( '-lrt' ) # Add the __linux__ define BASECPPFLAGS.append('-D__linux__') something seems to be fubar

Allready works for windows just having a few problems with paths on the linux distros, glew is also located in /usr/lib32 on my 64 bit kubuntu and it does get picked up on my 64 bit kubuntu so not sure whats going wrong on your version :S the only problem i ran into was that the system supplied zlib version of my kubuntu 64 was incompatible with the devil version in darkmod so i had to move it out of the way when building so that it picks up the version from darkmod instead. im going to look into scons looking in the wrong place, hang on.

might be missing the x86 version or if you got it something might have acted up in the package installer ? try sudo apt-get -f install without any packages to let apt-get try to autocorrect problems.

Not yet thanks. Hmm sems you only have the x86_64 version of glew installed, you need the i386 version, or wait untill we have 64 bit support. Saw wrong btw my version of kubuntu is the 14.4 version, but i got it to compile on both the x86 and the x86_64 version now so its down to missing packages.

Final changes comitted. Allways uses system glew on linux now. Attempts to link statically to system glew. changed include path from the local glew/glew.h to the system include directory GL/glew.h. changed include path from the local glew/glxew.h to the system include directory GL/glxew.h. scons build scripts modified accordingly. So allways get the latest possible glew version for your distro from your package maintainer. Also remember the other dependencies, you can use my get-depends.sh for that.

Another way to get around the differing versions would be to simply remove the glew headers from darkmod's scons build chain so that it uses the system supplied version, that way it should work by just installing the glew version supported on your distro. you could simply delete them from the darkmod include dir and it should use the system provided ones.

Still has a few problems on older ubuntu like teis i suspect, working on doing glew as part of the build process and works here but may pick up the wrong library if you allready have glew installed. Unfortunatly its hard to take every little thing into account on different distros and more work may be needed before we can call it a day. Still it helps if you know the innards of a posix system and how to get the things you need .

Comitted changes to build glew as part of the scons build process and link it statically. Ho them gremlins sure are busy tonight

could do that but i would have to write the build process into scons and i would have to reorder some things so that glew is part of the build process, much like its done with devil or libjpeg. This might take a while to write and atm im more curious as to if the thing actually works if it does ill have no objection starting to rewrite stuff if not i would have wasted a good deal of hours. Ofc i hope it works but you newer know

ok for your old version of kubuntu get the glew source code here https://sourceforge.net/projects/glew/files/glew/1.11.0/glew-1.11.0.tgz/download and cd into where you unpacked it. i made a makefile to create the 32 bit version on 64 bit ubuntu just replace the one in the glew source dir with this one http://sourceforge.n...lew.7z/download Then just do make sudo -s make install make clean

Hmm damn then you have to build it yourself :S well should be pretty straight forward libglew itself is just 1 file glew.c for others with a newer version heres a script to get dependencies. #!/bin/bash # get build depends sudo apt-get install g++ scons libglew1.10-dev libglew1.10-dev:i386 libpng12-dev libpng12-dev:i386 libjpeg62-dev libjpeg62-dev:i386 sudo apt-get install m4 libxxf86vm-dev libxxf86vm-dev:i386 libopenal-dev libopenal-dev:i386 libasound2-dev libasound2-dev:i386 g++-multilib gcc-multilib zlib1g-dev zlib1g-dev:i386 libxext-dev libxext-dev:i386 save as get-depends.sh and run it like this, sudo sh get-depends.sh

if you want to build it yourself you need several packages ill see if i can get all of em into a script that will download them for you.

kubuntu 14.4 x86 and kubuntu 14.10 x86_64 mine are running in vmware, teis uses kubuntu 14.4

Darn seems the version installed as per the instructions here on the site are to old you need to sudo apt-get install libglew1.10-dev and sudo apt-get install libglew1.10-dev:i386 that should take care of it.