Jump to content
The Dark Mod Forums

revelator

Development Role
 View Profile  See their activity

  • Posts

    1177

  • Joined

  • Last visited

  • Days Won

    21

 Content Type 

Everything posted by revelator

  1. revelator
    Thats exactly what i mean damn someone finally understands. The GLSL backend is not hard you can copy it pretty much unmodified from BFG the hard part is all the damn special effect code like glasswarp etc in draw_common.cpp Then again looking at BFG it seems a good deal of those are not even used in vanilla as they have been removed from BFG, notice a certain printf in the above source file with a comment about contacting steve in case the thing blows up because of the lack of them . If need be and someone actually wants those effects we could copy of the non shader versions from the older backends, but that would be a step back that im not certain would be wise. The GLSL backend does however leave the door wide open for shader devs to fill in those spots in there own mods A fur renderer for instance woukd make for some extremely realistic hair (as long as it does not go as far as furmark, were not building a benchmark here hehe). But first we need to get the basics working, which i would be happy to help with.
  2. revelator
    That and to be frank the vanilla shaders are not Open source the GLSL versions are. A good deal of graphics mods actually break the eula by using modified id ASM shaders. Raynor ported the GLSL renderer and code for parsing GLSL - the gpu skinning part, it was still missing the interactions with the model shaders but that part is pretty easy, can pretty much use the code for that with no modification from BFG. The hard part would be getting the rest of the code in draw_common.cpp ported (mostly effects) GLSL uses a bit different code there.
  3. revelator
    3 actually. Reason i started digging deeper into BFG's thread handler is that vanillas thread code is not very mature. 1: It uses async threads which is ok for the most part if done right. 2: only a few functions in vanilla are threaded 2 actually. 3: i ran it through a debugger to see what kind of improvement i could expect. as for 3 i can say a rather substantial improvement, vanillas thread code spends a lot of time waiting for thread locks and that is causing some rather substantial lag i noticed. try gdebugger its free and its pretty handy when you want to find out where you can do the most good . as for BFG's GLSL code its still just filler, it might be nice filler but do we need it ? that was what i would like to know . Porting to BFG sure, but we still have the minor problem that it does not allow mods in the sense we are used to. + sides of BFG its faster no doubt about that. Its multi threaded by nature. Thanks to robert beckebans we have shadow mapping. Vertec buffers are a lot more mature. Not so nice. Menu's are in flash. Not able to make small changes to game code for personalization, could recompile the lot ofc but it would not be compatible with the unmodified version, unless you want to litter the code with #ifdefs and whatnot. This is ofc up to personal preference, but as a coder im allways looking to improve existing code rather than totally scrap it (i only do that when its completly broken). Lord Havoc could just have waited for the next big thing in the id source world but then we would not have darkplaces . Thats my reason. Everyone is entitled to there own though.
  4. revelator
    Well OpenGl still keeps compatibility with older abi versions but yeah support will get shoddy sometime in the future. ASM also has a few things its not capable of like motorsep said, the question is then can we live without those abilities ?. Reason BFG's glsl code is so massive is that besides handling GLSL calls it is also able to convert other types of shader languages like hlsl and CG to GLSL, Leving that part out it would shrink considerably, still it would fill a bit more than the assembler version but nothing close to what it does now. A donation page for getting a dev to solve these parts is a good idea ill donate when my paycheck rolls in tuesday.
  5. revelator
    Should be possible MH over at inside3d made a mixed mode ARB2 / GLSL renderer some time back, it only handles interactions though. A full GLSL renderer should also be possible copying of some of the BFG code for it. A few of its functions need some exports from BFG's idlib though. Maybe a simplified version can be made without copying those parts, still investigating ... im pretty new to C++ so i may still make silly mistakes heh.
  6. revelator
    That might actually be an oversight by me, thanks for pointing it out also i made a small mistake in my tutorial that i need to fix.
  7. revelator
    found a good read here on epsilons http://www.cygnus-so...m#_Toc135149455 To my surprise its actually stated that the best way for comparing float epsilons is with ints Oo the number for comparing can be any value actually depends on how fine a mask you want. The value it seems most use today is 0.00001 so way lower than vanillas 0.1 mask which may actually be to high.
  8. revelator
    Hehe is ok im interrested in whatever fixes turn up Changing idlibs FLT_EPSILON to DBL_EPSILON does not seem to have any adverse effects and i havent run into any shadow corruption yet because of this. Tbh i think its ok to use these, example FLT_EPSILON is used the same way as in vanillas code checking if the value is newer above 1F and newer below -1F same goes for DBL_EPSILON it checks 1.0F vs -1.0F though.
  9. revelator
    I changed the FLT_EPSILON in idlib to be DBL_EPSILON and reverted the above, so far all seems hunky dory ill test some more though, would be nasty to call it a day and then its not working correctly. Atm tracking where idlib uses it so i can pin the exact bugger.
  10. revelator
    Aye it should not have worked at all since the number im using is the same as defined for DBL_EPSILON and as you point out its for checking floating point rounding errors. BFG uses the floating point checks in idlib so a better fix would probably be to grab the code for that, vanilla also has some of the floating point checks but uses a rather old version with only single precision. should probably rename LIGHT_CLIP_EPSILON to PLANE_CLIP so that it does not confuse people to its real purpose
  11. revelator
    Played around with the EPSILONS for light and shadows (LIGHT_CLIP_EPSILON) original value was 0.1 which is a double so i changed it to follow DBL_EPSILON const float LIGHT_CLIP_EPSILON = 2.2204460492503131E-16; // as pr DBL_EPSILON result seems promissing i had some rather nasty shadow bleed in this map and its all gone now.
  12. revelator
    frag machine over at inside3d brought up something that might explain why 2013 breaks. We started discussing if the problem could be related to precision loss when casting doubles to float, made me wonder so i checked RBDoom3BFG and it works fine with 2013. Funny thing is that BFG uses double precision floats in idlib.
  13. revelator
    Reported via my msn account, so not sure. But same problem as i experienced debug builds work but release builds seem to break. My best guess is that 2013 optimizes something away that vanilla needs when doing release builds.
  14. revelator
    Its only temporary i will be merging my development copy with the one on github when we have tools that work crossplatform.
  15. revelator
    Still here, for some reason pm's are not forwarded to my email ? so i missed out on the discussion here. Still hard at work on porting BFG's features to vanilla, so far i been adding RBDoom3BFG's depthbounds testing for both lights and shadow volumes. Entity and Surface sorting (to prevent GPU pipeline bubbles), refining vanillas thread handler (runs 12 threads on my rig now). Replacing malloc with nedmalloc. Also discovered a nasty bug with msvc2013, compiling vanilla with 2013 causes shadow volumen cut off's. I reported the bug to microsoft but untill they have it fixed i recommend using an earlier compiler. Msvc 2010 works best. Copied out my own project to a new project also and removed all the editors so my new version is quite lightweight now, old version is still on github though, latest changes are in my new version but ill merge those changes when im satisfied that things work allright. Latest change, i created code to expose the code for copying depthimages to the game dll's so real ssao is possible now, unfortunatly im crap at shaders and sikkpins versions wont work correctly with it unless rewritten so someone would have to fix them before it will be usable.
  16. revelator
    Hello. I been working on and off to get this thing working and some parts are indeed working just not giving any noticable performance improvements yet. The last thing thats still keeping it from release is that the #pragma omp calls dont seem to work correctly on windows (patch originated from a linux user) and will hang the engine. I do have the Intel compiler though and it should be possible to set it up to point out where omp would give the biggest benefit and also provide the nessesary code changes. Ill post back if i get something going .
×
×
  • Create New...