Well heh im not that good but thanks just picked up some stuff from the many years on the scene, mostly due to people like MH and lord havoc who also helped me in the right direction when i got stuck.
Reminds me that it must be close to my 15 or 16 year anniversary on the quake scene (damn im getting old ).
R200 renderer on my R9 270x card above works great but shadows are non shader based on the R200 still they work well.
Motorsep is welcome to pitch in if he feels like it, all help is welcome patches to.
I kinda like BFG's rendermatrix compared to vanillas old school code but porting it is something that is going to take a while and it will probably only work with the arb2 path and glsl.
Seems like carmack got some inspiration from darkplaces on that one even hehe.
Slowly adding stuff and keeping track if it breaks things, so far a good deal of BFG's entity sorting algorithms have made it into revelation and seem to work allright.
Not using the SSE code from BFG as it seems to make vanilla even slower than before, not sure why though .
maybe related to changes in idlib (now uses templates for allmost anything).
changed the old glColor3f / glColor4f / glColor3ub and glColor4ub to use a C++ wrapper function. GL_Color can now handle all these types by itself.
reverted SSE code.
clamped glColor calls to min 0 max 1 for floats or min 0 and max 255 for byte.
Hehe yeah been busy but the main reason the commits sometimes get so large is that msvc insists on formatting my sources itself, needless to say it does a rather awfull job at it especially with the inline assembler calls so i have to run astyle continously to get it back to a readable format allbeit i have to format some stuff by hand also urgh.
Can check out the source its pretty stable now had to cut back on the lightdpethbounds checking because it did awfull things to the shadows also a lot more clean now.
Hmm seems i uncovered a bug in vanilla's depthbuffer code
checked BFG's version and it calls the projection matrix on the depthbuffer vanilla does not so i tried yanking it in and the weird bug i had with
ghostly depthbuffer images in the shadow volumes have now gone extinct.
I also changed the solution names from DoomDLL to Revelation same with props.
reverted the smartflt resampler to the old one, the smartflt version makes some surfaces look blocky which was imho nasty to look at.
If anyone would be willing to lend a hand i still need to fix sikkmod for ressurection of evil.
I fixed most bugs like unreachable paths etc, but there are a number of places where sikkpin used functions to compare certain conditions where he should have used strcmp instead.
And a few other things also need looking at.
This is a small macro for visual studio that you can run on the MFC sources and it will convert a good bit of them to WxWidgets.
You will still have to fix logic etc but its a nice start .
Quick progress update: I spent all morning struggling with geometry that I haven't had to use since school. But before breaking for lunch I did finally manage to get the renderer to project a 3d occluded space from the silhouette of an arbitrary 2d shape on screen, and to use that to close visportals. If I had more space around my desk, I'd have done cartwheels. I'll be writing new tests for the renderer to use after all, not just using old ones. The existing ones typically do more work than we need them to, because they are not looking for yes/no answers, they need precise measurements.
So, so far so good for anti-portals. On to entities next. I've taken another look at the code and it won't be as simple as blocking entities from being picked up by the routine that discovers stuff in view through portals. Turns out that that's only the first opportunity that an entity gets to put its name on the render list for the current frame. Front-end rendering is a multi-pass operation, to reduce the overall work done. For example, we don't want to update animated meshes for AI that won't be seen this frame, but we sometimes won't know for sure whether they'll be seen until we've updated their animations. So we do a rough test to see whether the AI's max bounding box (or shadow) could be in view, then update its animations, then do the final pass.
The stages I've spotted so far that need to be taken into account:
Entities and lights that are possibly in view through portals are discovered. That's where I suggested occluding them originally. If any entities are partly occluded through a VP so that they can be cut down using a simple on-screen rectangle to define their "viewable area", then they get that rectangle attached to them in this step.
The shadow-fix discussed above: unseen entities being hit by viewable lights get put on the list, if their shadow might hit something that's in view. They have an empty view rectangle because the model itself won't need showing.
Finally, animated entities in view get their animations updated and get tested again.
So simply hiding entities in step 1 won't help if step 2 puts them back on the list for shadowcasting purposes and step 3 resets the viewable region after updating animations. Not sure if whether it will yet, but I'm about to find out. And if so, there are what look like a couple of flags available to block further rendering for an entity for the current frame in a given view. I've not checked those out yet. So plenty to test / look at.
This part of the code is a pleasure to work with. It was written by someone with a remarkable talent for clarity and elegant design, and a gift for writing brief but illuminating comments. There are hardly any ugly bugfixes sticking out. For the most part it's the pristine work of a very talented coder.
just picked up some stuff from the many years on the scene, mostly due to people like MH and lord havoc who also helped me in the right direction when i got stuck.
).
patches to.
.
