revelator
-
Posts
1177 -
Joined
-
Last visited
-
Days Won
21
Everything posted by revelator
-
Its an optimization for shadow volumes to turn off clipping against the near and far planes. Theres some info here http://books.google.dk/books?id=odgdAAAAQBAJ&pg=PA354&lpg=PA354&dq=GL_DEPTH_CLAMP&source=bl&ots=waLuC1bYNc&sig=TCnBhoYRflRUrImZhq6EAOX0Itc&hl=da&sa=X&ei=W9xcVOCRG8XLaPLogPgL&ved=0CFMQ6AEwBzgK#v=onepage&q=GL_DEPTH_CLAMP&f=false
-
Yep works quite nicely like this no shadow bugs whatsoever and it took a bit of the strain off the stencil shadows, runs really well actually. Not sure if its useable with the light volumes also, but it seems the culltype is autoset to CT_TWOSIDED for things like flares / sprites and generally disables shadows hmm ???. // twoSided else if (!token.Icmp("twoSided")) { cullType = CT_TWO_SIDED; // twoSided implies no-shadows, because the shadow // volume would be coplanar with the surface, giving depth fighting // we could make this no-self-shadows, but it may be more important // to receive shadows from no-self-shadow monsters SetMaterialFlag(MF_NOSHADOWS); } its also disable for CT_BACKSIDED so it seems only CT_FRONTSIDED is valid for shadows.
-
So far it seems to work hmm can anyone confirm ?
-
Uh oh if i where you id stay clear of that part from ljbade as it causes shadows to behave allmost the same as with msvc2012 and newer (rather funny actually as the two bugs have nothing at all to do with eachother). Im investigating a means to get this working correctly and i might have the solution allready but its up for testing. /* ==================== GL_Cull This handles the flipping needed when the view being rendered is a mirored view. ==================== */ void GL_Cull(int cullType) { if (backEnd.glState.faceCulling == cullType) { return; } // enable depth clamping when face culling is off if (cullType == CT_TWO_SIDED) { glEnable(GL_DEPTH_CLAMP); glDisable(GL_CULL_FACE); } else { // disable depth clamping again when face culling is on if (backEnd.glState.faceCulling == CT_TWO_SIDED) { glDisable(GL_DEPTH_CLAMP); glEnable(GL_CULL_FACE); } if (cullType == CT_BACK_SIDED) { if (backEnd.viewDef->isMirror) { glCullFace(GL_FRONT); } else { glCullFace(GL_BACK); } } else { if (backEnd.viewDef->isMirror) { glCullFace(GL_BACK); } else { glCullFace(GL_FRONT); } } } backEnd.glState.faceCulling = cullType; }
-
And a very big calculator Looks interresting though i hope someone some day feel pity enough on me and helps me learn enough about shaders that i might go from there
-
Time for some testing then best way to see the performance hit.
-
Hmm should be some info around the net but as far as i could understand it it uses the zbuffer (depthbuffer) by copying everything into a depthimage, and then comparing every point copied,so that if you look out from a lightsource then everything is in the light and any object in the path of that light will be in shadow. Its not as precise as shadow volumes but its a good deal faster
-
True shadow volumes are pretty CPU intense, they are infact negative ligth rays casting darkness instead of light and the calculations are a bitch because they have to take into account geometry that might stop stop a raycast. Early attempts had versions that had problems with the shadow being thrown through solids like walls and tbh looked quite ghastly and at that time literally no cards had the muscle to run an engine that used this technique at a reasonable framerate. I had a geforce 3 back then and it did not like vanilla on ultra in the least 3 - 6 fps urgh.
-
I noticed a few devs here use linux environments and since i maintain a posix environment for windows this might be of interrest for them. https://sourceforge.net/projects/cbadvanced/files/CB%20Msys2%20version/x86/ this one uses the 32 bit version of Msys2, and is mostly intended for compatibility with non 64 bit OS like XP. https://sourceforge.net/projects/cbadvanced/files/CB%20Msys2%20version/x64/ this one uses the 64 bit version of Msys2, and is the one most users should get in case they do there work on 64 bit vista and up. installer has an option of setting the just in time debugger to drmingw in case this will be your default coding environment you should choose that. If however you use msvc by default then you should untick this option as it will break msvc's JIT debugger setting. Compiler also has an IDE which should be recognizable by many ubuntu users namely codeblocks. My version is a bit old but im working on a new version. Reason it uses an older version is that mine was patched to support the non multilib MinGW64 compilers and my old patchset does not apply to the newer versions anymore. It still works well though . Happy coding
-
You might be able to reuse the sunbeam shader from sikkmod for moonbeams could actually have both. Theres also a lens flare effect in sikkmod allthough i doubt it would fly well with a game that simulates the dark ages
-
Could be gfx drivers i actually had to buy an AMD card because my previous engine ran like a snail on AMD :S AMD does a few things different same with intel, and yeah intel sucks when it comes to gfx cards there cpu's rock though xD. Sadly i sold my nvidia cards so cannot help on that :/ but maybe i can persuade one of my pals to try it out, he has a nvidia card.
-
Aye just a damn shame that management in 3dfx sucked so much :S could have been rather interresting to see where they would have been today.
-
Feel free to use my code if its not to much work porting the darkmod features to it. The change to EPSILONS was an attempt at fixing a shadow bug vanilla had when using newer msvc compilers eg. > 2010. Microsoft changed floatiing point values in msvc 2012 to use SSE math instead of FPU math and that change caused the bug where vanillas shadows sometimes dissapeard. The fix helped but shadows still dont work correctly when compiled with anything newer than msvc 2010.
-
Actually doom3 could run on a voodoo2 using the ARB ->note not the ARB2 renderer, there was a demo showing it somewhere on the net. But since i removed all the older backends this is not possible with revelation. So yup the voodoo cards rocked btw did anyone know that a lot of the devs from 3dfx actually work for nvidia now ?.
-
http://sourceforge.net/projects/cbadvanced/files/gtkradiant/Revelation-src-27-10-2014.7z/download latest source here, there are a rather large list of changes to the renderer so ask if not sure notable. all editors are gone. MH's ARB buffer range optimization polished up a bit. MH's FPS counter (more accurate). Convoluted DepthBoundsTesting into a wrapper function which is also used for light now, was only used for stencil shadowing originally. Removed all unused features leftover from the old backends. Removed the Fallback code for cards not able to use vertexshaders so do not try this on a voodoo2 Changed EPSILON values to double instead of float. RB_SetStageTexGen new function to avoid the messy state changes the old code had. Removed Glasswarp (not used). Added Texture functions for accessing the depthbuffer. Clamped depthranges. Removed an ugly hack in the texture manager that was caused by the removed editor code. Moved a huge part of the stencil shadow code into a struct to make use of pointers. Stencil shadow code changed interaction to defered (part of a linux patch to use openmp in vanilla sadly i had no luck porting the openmp code). Fixes from BFG to original vanilla code merged. TGA changed to TGA2 code, fixes the need for rotating TGA images so that part was removed also. JPEG upped to version 9a and code changed to fit. Added nedmalloc to idlib (fast malloc version). Changed a few functions in nedmalloc to C++ allocation. updated ogg and vorbis to latest. merged all fixes that dont change the way vanilla works from dhewm3. merged more fixes from dante. all glColor calls are now handled by C++ classes (wrappers for opengl's C interface). a crapload more i cant remember right now. source compiles with msvc2010 and i included ports to a few mods like grimm quest cdoom sikkmod and sikkmod-d3xp.
-
Ah thats a chip of my shoulder then i guess unless sikkpins shaders are straight forward that they might need some work to fit darkmod, i kinda like the effect when seen from a distance though. Finally got over that darn flu but drowning in work on my MinGW64 based compiler suite porting everything to Msys2 fixing build scripts aghhh. Atleast when its done it will be a nice addition for those who are used to work in a unix environment. Also need to update my special CodeBlocks IDE which i have put of for some time now because the changes needed are in the category freaking insanely hard and evil so im probably not not doing much work on revelation this week . If anyone wants the latest source for it i can upload it to my sourceforge page, keep in mind that i removed all the editors from it untill we can get the code ported. The depthbuffer code is also in it.
-
Woa yeah that looks a bit like it, not sure if its just a small bugger in my code that showed up there or if its the shader ?!?. gDebugger is a great tool but when theres loads of calls it can freeze so set it to break on deprecated calls and use frame stepping from there. It can be a bit hard to learn all its capabilities, but it sure is worth it
-
Correct outdated functions might not nessesarily mean bad performance but in a few cases its worth taking a look at. For instance to bring down the calls to glColor3fv 4fv or whatever i created classes in revelation that are able to handle most color calls as one function insted of 4 or more, did it help then you might ask ? yes but not as much as i had hoped for, still all things count in love and war. I also convoluted a few other functions in classes. as for glProgramEnvParameter4fvARB (OpenGL 2.0 spec) its not even close to the same age as the glColor calls (OpenGL 1.1 spec) but it can probably be optimized some anyway
-
Aye loads of deprecation in vanilla, worst offenders from my own profiling where the old opengl 1.4 calls like glColor4f (makes litterally thousands of calls each frame yuck) but also other parts that need attention like thread handling and some of the AI code also seems to be a huge drag on resources. To get a reliable profile make a debug version and then try running that in gDebugger, remember to set it to render windowed in gDebuggers params for Doom3.exe, you can also hook up to msvc's debug symbols for a little more in depth analysis. You can get rid of quite a load of them by removing the fallbacks and cvars (even though modern cards have no problem with what these cvars originally turned off and can use the hardware based functions instead), still even with those parts gone theres still some functions left that need updating badly like the fog function and a few other parts.
-
I think the old ARB shader in BFG was the one that was missing from vanilla, for the draw_exp.cpp shadowmap renderer. Checking and yep its that one . BFG does not use ARB at all only CG or GLSL so as motorsep said if theres only the CG files left it will convert those to GLSL, it cannot convert them to ARB as far as i can see.
-
nvidia's parser should also be able to convert GLSL to ARB its not seamless though so the shaders will most likely need some work after conversion, still its a great tool
-
Heh thanks allthough atm i think im getting more than my fair share of sleep. Flu is all over denmark because of humid cold weather just got unlucky and caught some
-
Still bed ridden but ill make a compile as soon as im able to sit in front of my PC for more than a few minutes again.
-
Ah was worth a try. Now that you have it you should play it its a refreshing game and quite a bit insane hehe. The story is not bad either, its so far out it makes it allmost sound plausible that something like that could have happened. Takes a bit to get used to the gravity differences and running topside down though.
-
Well if you knew how many times i was misinterpreted for writing stuff to help others out..., sometime they took it as an attack on there pride as coders, other times they wanted me to finish up there work for them. which would not help them next time they ran into a problem (im not online 24/7) also im not paid to do there homework but mostly i help where i can. I cant even say i was free of those flaws myself, because i sometime made a huge effort to get something to work, but the code was a mess i still felt hurt when someone pointed it out. At a point i began to look at things differently because even if my code was flawed it did sometimes solve something that the experienced programmers had tried to work out and the experienced programmers could then clean up my work and make something truely usefull out of it. So they where happy and even though my initial work was a mess i had contributed something. As for my pride i can only say its not my daily work (im educated as a radio technician) i do this for fun and learning and i have and still am learning.
- 1127 replies
-
- 2
-
-
- idtech4
- development
- (and 1 more)
