revelator

Not yet though ill start work on it by the weekend. trunk compiles but crashes atm after reverting the light commits by nbhor1more, think i forgot something but have not had the time to look into it. I hope to get it back in working order again by the weekend.

Cool m8

i saw a build script in the boost libraries for darkmod i think you can use that to update the builds, i used the batch file here to make versions compatible with 2013 and the bash build script seems to fill in the same function.

Standard libraries are by definition messy because they are so complex, that said they do offer more control over what you want to accomplish in comparison with standard C. A rather large chunk of boost functionality is allready availiable in C++11 but we might run into other snags if we start using this as some things have changed meaning in the newer standard libraries. feks. null is a keyword in C++11 and not a NULL pointer (well tbh NULL was newer a pointer in C++ as NULL is defined as simply 0 and not like in C where its (*(void *)0), and there might be other stuff to take into account. Still we may be able to make our own functions to do what boost was doing in the few places where its actually used.

A good deal of the boost functions can probably be replaced by modern standard library functions, boost does have a few things that modern STL does not but im not 100% on which parts exactly.

Might still be a few quirks i suspect, if anyone spots something out of the way in the linux scons build ill be happy doing the nessesary corrections. If you allready have a github account and want to work actively on my branch let me know and ill add you as collaborator with full access.

Ok then removal of all backends beside ARB2 in next commit Need to investigate a crash after i reverted nbor1more's test code, seems i overlooked something after i fiddled with it.

Most of it left in backends for the nv20 and the r200 as they do have some shader capability and still work on modern cards, but you're right we should just scrap those to, its not worth the effort to keep them alive anymore and they add to the complexity rather a lot. BTW the ARB backend had no shader support at all, it was just ment as a fallback in case all else fails but it did have one unintended side effect -> you could actually play doom3 on a card as old as a voodoo2 . Sadly the r200 and nv20 backends are from an era where gfx card manufacturers could not agree on a commmon interface so they used ATI specific and nvidia specific opengl pointers for the funny stuff, if you'd try running the r200 backend on a nvidia the engine would crash and vice versa. ARB2 solves that as it uses the standardized versions that where added to the spec later. The reason i belive it will take a bit more than a few lines of code is that vanilla allready uses a rather large heap of the code to support per pixel lighting because that part is old and at the time when it was build it still needed to support the older gfx cards as well, in fact the portion of the shaders directly involved in light are not much bigger than shadow.vfp which consists of about 4 lines of shader code :S the rest is handled by the support code which is much much larger -> (tr_light.cpp tr_lightrun.cpp interaction.cpp tr_stencilshadow.cpp etc.) and its not really all that programmable, but enough to be used for most things by using material code (used for specifying color / reflectiveness etc). As i see it we could do this by digging out the parts for lighting from interaction.vfp and load customized versions via material scripts, but that would break backwards compatibility, or we could try to come up with a way to override the defaults in interaction.vfp with the shaders we specify in materials using a keyword, like if _customLight skip reading from interaction.vfp and read from where i tell you. This might also work for other stuff like Parallax occlusion mapping which does not behave nicely with all kind of surfaces.

If we go full shader hum yes if we still want support for older cards then no hell no, but atleast your optimistic . Take a rather convinient engine as an example, if you ever heard of an engine called tenebrae ? it was the first quake engine out there with support for PPL bumpmapping specular pretty much the works. It had one downfall though at the time OpenGL really didnt have much in the shader support department but it did have some ARB support, the shader part took up about 100 lines of code, the support code took up 5000+ lines of code and it was very very buggy and extremely slow. Darkplaces took some of the ideas behind that engine and refined them cooking down the support code to a few hundred lines instead but darkplaces also support GLSL besides ARB, and you need to have a card that supports at least ARB2 for it to work to its strengths. So it will be quite a lot of code in case we want this on cards with suboptimal shader support, but it can be cooked down considerably with shader capable cards, still it will take some work Btw the guy who made the tenebrae engine back then, should know what hees talking about since hees the lead dev on enemy territory quake wars imagine my shock when i found out that was the reason he let the tenebrae engine die back then.

There are a few crossbreeds between directx and opengl so its not unheard off also pretty much any rendering code can be moved GPU side if your gfx card supports the OpenGL version needed, even bumpmapping (tesselation).

Was starting to wonder myself why it got flipped on, does vanilla allready use the customLight token somewhere ?. But yeah better to put it off for now untill we can make some headway into doing this correctly.

Exactly and thats why if we want this to be fully able to control all light via custom shaders that i ment it would have to be early on in the shader process, it will be one hell of a coding nightmare but it should be doable. And as you pointed out the engine can allready use custom shaders and theres nothing keeping them from defining a lightsource but there will be drawbacks. Im pretty much 100% that if we want this in we wont be able to do it with a few lines of code i suspect something in the line of several hundreds of lines of code hehe.

Yep used the test material supplied by nbohr1more, still crashes if i remove the interaction code in draw_arb2.cpp it works again though. so i suspect we need some code to check if the material is active or else fallback to the normal, strangely enough the IsCustomLight check allways returns true even if theres no material

Hmm that was my first try unfortunatly while it compiles it crashes the engine on map load.

Darn i had a hunch that might be the case as far as i can see only ARB is passed to draw_arb2.cpp so that seems correct, as for the custom light shader i would think we have to pull out the big guns to get that one working, all my attempts have failed miserably . Looking at material.cpp we have foglights blendlights and ambientlights normally, while foglights and blendlights dont interact ambientlights seem to do so hmm.

Hmm question what kind of lights are you intending to customize with this ? i had a look at the blendlight code and it might be possible to make a clone specifically for this. Its also a rather misleading function as its called by fogalllights but has other uses than just fog. Its a bit of a weird one though as it blends 2 surface lights together so the other one would need to be from the custom light shader.

Urgh this will not be an easy fix, im running through methods of doing this but the only place that will likely work is by doing this early on in the interaction code. Lights are done by precalculated constant registers which are a hard read as they are not exactly descriptive, but i think this one is for light -> OP_TYPE_LT. Problem here is that to yank in custom light definitions it would need a rather hefty rewrite. We would need to replace those precalculated values by the ones parsed from the custom light shader instead. This would also mean that any small error in the shader would crash the engine unless we can dig out a way to fall back to the precalculated ones in case it fails. We also need to get the types for view origin / projection and falloff correctly. My head is spinning from reading this

Hmm so you want this to accept a non prebound shader, oki not quite sure how vanilla handles that but ill see what i can find out about it. Will probably require a lot more code than this i suspect. Ok looked around and seems this is what allows non predefined shaders to be parsed from materials. for (int i = 0; i < newStage->numVertexParms; i++) { const float parm[4] = { regs[newStage->vertexParms[i][0]], regs[newStage->vertexParms[i][1]], regs[newStage->vertexParms[i][2]], regs[newStage->vertexParms[i][3]] }; glProgramLocalParameter4fvARB(GL_VERTEX_PROGRAM_ARB, i, parm); } for (int i = 0; i < newStage->numFragmentProgramImages; i++) { if (newStage->fragmentProgramImages[i]) { GL_SelectTexture(i); newStage->fragmentProgramImages[i]->Bind(); } } glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram); glEnable(GL_FRAGMENT_PROGRAM_ARB); which btw is in the same function where you turned off processing things such as customLight.def So if i understand this right the fix is simply removing // prevent stage processing of ARB programs in customLight def if (backEnd.vLight->lightShader->IsCustomLight()) { return; } and remove the code in draw_arb2.cpp ? looking further this same process is used in material.cpp to parse definitions out of unbound shaders.

Ok i think i have something down that might do what you want without the game code changes. Created a new function for using cubemapped light from textures, a bit like the ambient code. new shader will use _custom def from light and the shader uses a customLight token.

Hmm no there a bit more than cvar toggling to it as far as i can see it uses JC Dentons code for custom ambient lights, and theres a lot of code for it mostly by grayman. From what i can glean it seems to use a table to make sure the ambient light values are keept in check so as to not allow silly values. Look for grayman #3584 in the code to see all the places where ambient light is parsed.

Hmm changes break the engine, not sure if its because im missing the shader but unless it finds the token "customLight" it should actually just skip over it but seems it does not. Makes testing a bit hard tbh :S if you spot the bug feel free to make changes as you see fit. Ill commit in a bit.

Aye i hate messy code besides we need a lot more code for this to work after having a look at rebb's chain for ambient light it seems we also need game code changes and ive done a few of the changes now but the rest of the interface someone else will have to finish as im really bad with game code hehe.

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.