Jump to content
The Dark Mod Forums

revelator

Development Role
 View Profile  See their activity

  • Posts

    1529

  • Joined

  • Last visited

  • Days Won

    26

 Content Type 

Everything posted by revelator

  1. revelator
    I could use some advise on getting around the renderCrops problem though fhDoom scales them in the exact same spot so i guess it wont be easy. Not giving up i was close to having something at a point but it broke other parts of the framebuffer code like we saw with msaa etc. atm i changed it to this -> renderCrops[0].x = 0; renderCrops[0].y = 0; FB_Resize( reinterpret_cast<GLuint *>( &windowWidth ), reinterpret_cast<GLuint *>( &windowHeight ), r_fboResolution.GetFloat() ); // duzenko #4425: allow virtual resolution renderCrops[0].width = windowWidth; renderCrops[0].height = windowHeight; which works but is still located in the backend, and so is not much of an improvement. I tried a simple solution like this // update screen resolution on scaling if ( renderSystem->GetScreenWidth() != renderWidth ) { glConfig.vidWidth = renderWidth; } if ( renderSystem->GetScreenHeight() != renderHeight ) { glConfig.vidHeight = renderHeight; } unfortunatly this crashes pbo's, so i guess ill have to isolate it.
  2. revelator
    sorry one earlier version before i removed it originally so yeah 7704. Yes i know svnlog, was just a bit tired at the time, took me all night with those changes. Havent completed the r_fboResolution refactoring yet cause i ran into a snag with renderCrops, this caused some viewport issues which i am still investigating the cause of. the PCF change was from a working example, i noticed when softshadows where not on that some objects had some rather nasty jaggies when using SM (lego block size), so i tried with the working PCF codepiece and it did soften them up some. The depth color change was from looking at how the original did it (alpha tested vs not) since the original used immediate mode i was not sure if still correct so i left a comment to remove it if not. original code below // skip the entire stage if alpha would be black if ( color[3] <= 0 ) { continue; } glColor4fv( color ); // alpha tested glAlphaFunc( GL_GREATER, regs[ pStage->alphaTestRegister ] ); // bind the texture pStage->texture.image->Bind(); // set texture matrix and texGens RB_PrepareStageTexturing( pStage, surf, ac ); // draw it RB_DrawElementsWithCounters( tri ); RB_FinishStageTexturing( pStage, surf, ac ); } glDisable( GL_ALPHA_TEST ); if ( !didDraw ) { drawSolid = true; } } // draw the entire surface solid if ( drawSolid ) { glColor4fv( color ); // not alpha tested globalImages->whiteImage->Bind(); // draw it RB_DrawElementsWithCounters( tri ); } And yes i should have kept it seperate for readability, at some point while working on it i just entered auto mode and before i knew i had done multiple unrelated changes. Note to self dont code when tired.
  3. revelator
    To 7707 and only for FrameBuffer.cpp, but i keept a copy of the newer revision of it so that i could write back the stuff that worked in that one. RenderSystem.Cpp i just copied back the code i removed from a local copy of the 7707 revision. If changing from SS to SM, shadows do not allways come back immediatly, i noticied. Guess the framebuffer needs some time to update.
  4. revelator
    Curlies dont throw warnings ofc, the cast warnings where here int thisCount = idMath::Imin( static_cast<int>( lightOrigins.size() - i ), MAX_LIGHTS ); and here backEnd.pc.c_interactionMaxLights = idMath::Imax( static_cast<int>( backEnd.pc.c_interactionMaxLights ), static_cast<int>( lightOrigins.size() ) ); whitespace change as you correctly assumed was from removing #if defined(_MSC_VER) && _MSC_VER >= 1800 && !defined(DEBUG) //#pragma optimize("t", off) // duzenko: used in release to enforce breakpoints in inlineable code. Please do not remove #endif So i guess that even after moving it to FramBuffer.Cpp you wanted to keep it handy in case it was not enough. Woot they work here shadowmaps with no softshadows or 0 same with softshadow quality 96 r_fboresolution now seems to scale correctly without pixelaltion, but it blurs the view somewhat at lower settings.
  5. revelator
    Also using vs 2017 the warning was a cast from size_t to int. Not sure if warning level is set lower on your builds ?. Msaa is broken now is that whats causing these fishbone patterns to appear ?, i was unsure as to what caused it but maybe if i revert the two files modified to the previos versions from svn i can see if there is any difference. If by some chance croppedWidth or croppedHeight leaks wrong resolutions to msaa i might need to use a seperate set of msaaWidth and msaaHeight to isolate it. Else i took great care in asuring that FB_Resize only used scale when told to, so that it emulated the orginal code, but something is definatly fubar if it kicks us out of the framebuffer when softshadows are on. Ill se what i can do about it.
  6. revelator
    Added some curlies and typecasts to avoid some warnings, not sure i would call that formatting only changes. Its just my style with curlies, old habits are hard to get rid off :/ but ill make a note of it.
  7. revelator
    Done refactoring the code to the best of my abilities, took me more work than anticipated but in the end it came out quite ok. Now i reeeealy need some sleep been burning the midnight oil on this one. r_fboresolution can now scale above and below 1 but dont get cocky and set values like 100 unless you want to burn out your gfx cards it will become rather heavy on values above 4 on a decent card. Theres a small bug with shadow maps on which i been unable to fix, the shadows themselves look fine but some surfaces (like stolen paintings) will show a fishbone pattern where the painting was. This does not happen often so it is hard to track down what might cause it ( alpha blended surfaces ? ).
  8. revelator
    No pixelation with my current code just uploaded. Or did you want it to pixelate ?. Hmm preferably there should be no difference between the bounds, but somewhere along the line this might go out of whack if something modifies the md5 bounds behind our backs. So i guess we have to figure out where that would happen. Hmm i seem to remember a recent snapshot of dhewm tried to get around this, let me have a look.
  9. revelator
    Thats strange so i did a small check to see if it was actually modifying the width and height and it does here. r_fboresolution 2 https://ibb.co/hhfoe9 r_fboresolution 4 https://ibb.co/bFNUmp granted i refined it a bit in the meantime, but the underlying code is still the same, so im a bit baffled by it.
  10. revelator
    Ok moved virtual resolution to frameBuffer.Cpp and refactored it, still needs a little refinement but it allready works quite fine. It now also updates resolution on mode changes.
  11. revelator
    So it was a combination of the same optimization bug that turned up after switching to msvc 2013 and globalinteractions having an invalid value, heh that one was rather irritating back then i remember. Been a busy week so it took me longer than i might have liked to get to the bottom of it, not sure i would have guessed that the optimization bug was also affecting SM's, good job. Sure ill be looking it over just remember i been out of the loop for a while so i might take longer than you might like to wait, last time i did some serious coding was in 2012 where i had to call it because i simply couldnt take the pain anymore. Even forgot stupid things like the OpenGL string length bug for a time, that one bugged the hell out of me when i tried to get up to speed by doing some work on an old quake project, untill i got reminded about it So its slow going atm.
  12. revelator
    I checked against how fhDoom does it and seems he ran into some problems in certain areas as well, so he created an enumerator to determine or set shadow modes based on game data (material flags etc), namely stencil / shadow map, or noshadow. In the problematic areas it auto switches to shadow volumes based on the above if the map has problems with shadow maps. The downfall is that we would need to add alot of code possibly rewriting large parts of especially the GLSL renderer and the light editor, as well as the dmap optimizer. If it gets things to work im all for it, but before i start anything i wanted to hear your opinion. also // generate a lighted surface and add it if ( shader->ReceivesLighting() || r_shadows.GetInteger() == 2 && shader->SurfaceCastsShadow() ) Is rather different from his way // generate a lighted surface and add it if ( shader->ReceivesLighting() ) { instead he moved those checks into the function below which is stencil only like this // if the interaction has shadows and this surface casts a shadow if ( lightDef->ShadowMode() == shadowMode_t::StencilShadow && HasShadows() && shader->SurfaceCastsShadow() && tri->silEdges != NULL ) I tried with a minimal approach of the way he does it to see if it fixes anything, but it causes massive Z-fighting in the shadowmaps on some objects (sawtooth syndrome), and do not seem to fix the problem properly though the skybox bug got a little better. Granted i only used a minimal part of the code, and it seems it relies on more than just the tinkering in interaction.cpp
  13. revelator
    So it's surface shadows that causes this when these conditions are enabled ?, wow thats a strange one . Ok ill check conditions.
  14. revelator
    Not sure it can be fixed on renderer level, but we could try with nbohr1mores suggestion. Maybe its the same bug i have in crucible of omens, in that one it is just a far away solid object that acts like a portal untill you get closer. Unfortunatly it is hard to see in screenshots in that particular map, but what happens is that a solid object "a wall in this case" lets the skybox shine through at a far away distance. Hmm this could indeed be caused by a bug with transparency after further thought, ill have a look at the commit in question.
  15. revelator
    Trying to get a hold on a standing workstation cause im having problems sitting down in front of my PC atm. well strange thing happens here, world is now fullbright edit: had to delete DarkMod.cfg its back to normal now. atleast it allowed me to clearly see where the skybox goes bonkers. It seems to be a map bug to me cause even with SS on, this map clips off the top of the buildings "no better way to describe it im afraid". Should be rather noticable with high gamma just try and walk around while looking at the top of the highest buildings. with SM on i still get the dark block in skybox to in that map, looks like farclip is messed up but it only affects a few maps.
  16. revelator
    Been away for some days due to training but interresting Have to check the commits to see what was done
  17. revelator
    Yeah would be bad to break other stuff by fixing this one wrongly.
  18. revelator
    Not sure what the best way to get around this one would be, id propose a distance check so that we do not draw shadows further than a set distance, or in another word only close to the players view. Does this sound ok ? After i finally found out what this bug was it turns out it is caused by bad geometry of the map, this is also why it was so inconsistent, since not all maps are affected.
  19. revelator
    https://s8.postimg.cc/u3sy40ncl/rightful_2018-09-12_09.52.23.jpg kept it full size because it can be hard to see on screenshot links. notice the edges of the the moon where it should cast a lightray.
  20. revelator
    Its the freaking moon well actually its a combination of some unlucky circumstances, the maps affected seem to have a world box that is no bigger than the highest building (checked by noclipping) in fact those maps have places where the world actually is smaller than the highest object, causing some weird shadow glitches like the moon now casting darkness instead of light.
  21. revelator
    Was mentioned in a thread elsewhere with shadowmap pitfalls, bias etc. Just making sure its not related before i go bughunting It does not seem to be a thing at all, that is why im a little mystified about it. In fact i do not think its a shadow at all now cause the other map i mentioned witht this bug had a blue square in the sky not a black one, but else they behaved the same.
  22. revelator
    Not good with shaders so im going to ask some questions. Am i right when assuming this is not peter panning ? if i understood it correctly peter panning just means the shadow newer connects fully with the ground (or floats a bit above it). But peter panning the sky would just be rediculous, or might this actually happen ?. The weird thing is the outline is a perfect square (a huge one even) and does not seem to represent any object in the world. The rendertool for shadowcasting does not show anything that should cast a shadow with that form unless it was actually throwing a shadow of the whole map onto the skyportal, if that is the case ouch. noclipping a few maps showed a few others who had this bug, but it does not seem to be consistent, so finding out which conditions cause this is going to ruin my sleep lol.
  23. revelator
    Yeah that would affect more maps then, it seems to only happen in a few, though it might be because you need to noclip above obstructions to notice it in other maps. Ill see if that is the case, but tbh it looks like the viewport is not resetting properly when shadowmaps are on. i noticed a comment in duzenkos code mentioning that, so this might actually be it in visible terms.
  24. revelator
    with stencil shadows with shadowmaps Its a bit hard to see but it should be noticeable
  25. revelator
    Hmm no blinking here so at first i thought everything was ok, but then i changed back to r_shadows 1 and there is definatly something fishy going on. r_shadows 1 looks fine, r_shadows 2 also looked ok but then i noticed a huge black outline covering parts of the starscape. It also seems its not static cause if i move a certain distance it dissapears. this resembles the bug i had in another map, but there the outline was blue not black, so easier to notice. But if this is a portal bug would it not affect stencil shadows as well ?
×
×
  • Create New...