Jump to content
The Dark Mod Forums

revelator

Development Role
  • Posts

    1174
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by revelator

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. Its only temporary i will be merging my development copy with the one on github when we have tools that work crossplatform.
  12. 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.
  13. 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...