Revelation Test

[toneddu2000]

you need to use the game dll's compiled from my sources else it will crash.

Yeah, used it

not entirely sure if its compatible wit the steam version either

probably not

EDIT: it crashes at same point (about 1/3 of loading bar during map open) even on Doom3 non Steam demo version

[revelator]

Sorry was away on family visit.

Hmm did you just copy the game dll's to base and d3xp ? or did you open pak003.pk4 and drop them in there ?.
Reason i ask is that if you just copy the game dll's to the folders they will get overwritten everytime you start a game by the game dll in pak003.pk4.
Better yet make a new zip file and name it pak004.pk4 with my dll in it, that way you can easily switch between vanilla and my version by just removing pak004.pk4

the map loading bug sounds exactly like its trying to load the old vanilla dll happens here to unless i do as written above.

[toneddu2000]

thanks revelator, removing all the game*.pak (on base and d3xp) and place the new gamex86.dll in the base e d3xp folders did the trick, thanks! Adding a new .pak doesn't work. Anyway I found another little strange thing. Revelation.exe doesn't load savegames made with Vanilla doom3! If you press the button, nothing happens! But, fortunately, it works with revelation savegames, so.. no big deal!
Did you know that, if you delete gamex86.dll but leave original game pak files in places and launch Revelation.exe, after it crashes (because can't find its game dll due to the pak mixup problem explained above), it creates a shiny new gamex86.dll in the base folder? That's weird!

Anyway, supercool man, loadings are much faster with Revelation Engine! Thanks a lot for the effort!
Can you please post somewhere a list of features/enhancements of your engine?

[revelator]

it creates a shiny new gamex86.dll in the base folder? That's weird!

That dll is the one comming from the pak003.pk4 try opening pak003.pk4 in winzip / 7zip / winrar. You will see it contains the gamex86.dll .
Forgot to mention its not enough to just make a new pak004.pk4 and copy gamex86.dll into it you also need a small txt file called binary.conf.

The contents of the binary.conf are just ->

// win32-x86
0

ill pack up the game dll's in the next update so you only have to unzip the contents to the doom3 dir.

[toneddu2000]

That dll is the one comming from the pak003.pk4

Ah ok

try opening pak003.pk4 in winzip / 7zip / winrar. You will see it contains the gamex86.dll .

no, no I knew that, it's only that I didn't know engine would have created a new dll file at runtime

Forgot to mention its not enough to just make a new pak004.pk4 and copy gamex86.dll into it you also need a small txt file called binary.conf.
The contents of the binary.conf are just ->
// win32-x86
0

Thanks a lot, it worked even this way!

ill pack up the game dll's in the next update so you only have to unzip the contents to the doom3 dir.

Thanks! There's a way to alter the source to make the engine search something like "gamerevelationx86.dll" instead of gamex86.dll? In that way both exes could coexist in same folder!

I tried also sikkmod and to make it work (even on Vanilla Steam installation) you have to delete game.pk4 on sikkmod but (nor Vanilla and neither Revelation) show softshadows, AO, bloom, etc. are not activated

[revelator]

My sources contain ported game dll's for sikkmod / sikkmodd3xp / grimm quest / classic doom so ill prepare a package with those

Making it look for a revelation.dll could work but would be a little messy code wise, ill see what i can do though.

[toneddu2000]

My sources contain ported game dll's for sikkmod / sikkmodd3xp / grimm quest / classic doom so ill prepare a package with those

Cool thanks!

Making it look for a revelation.dll could work but would be a little messy code wise, ill see what i can do though.

No, no it wasn't meant my intention to "force" you to do so. Just curious it could be done and how

[revelator]

should be doable even quite easy but revelation would not be compatible with dll's that use the gamex86 name anymore.
In regard to that its upto developers to make sure there game dll sources are compatible with revelation then.
As a bonus though they get an engine with less overhead due to the removal of the editors (if they prefer that) or else wait untill the tools are ported from MFC to WxWidgets.

[revelator]

Havent updated here in a while, been busy because of a bug in my new msys2 based compiler causing it to be unable to bootstrap gcc.
The bug has been forwarded to the Msys2 dev and is now investigated, so a fix might be out soon.
Ill return to making a new uodate package soon.
P.s i noticed a small whoops in my little tutorial,
one of the functions i told to add is the existing one not the one to add.
Ill cleanup the tut soon also.

[revelator]

Ok Msys2 bug found and squashed painfully

Also some news that might interrest people working on the vanilla Doom3 source or ports of it.
After some lenghty discussion on the darkmod forums i decided to take the question about some disabled shaders in BFG to the current BFG maintainer.
he confirmed that glasswarp was newer used (not even in vanilla) so remove at best pace (p.s the glasswarp shaders are the two only shaders with a .txt suffix instead of .vp / .fp or .vfp).
also if your port uses the arb2 backend only you can safely remove all the enums for the r200 and older nvidia shaders.
should not cause any bugs leaving them in but its confusing and unnessesary, the source will be a lot more readable as a result.

[revelator]

Big news.

After quite some brainstorming, me and steveL at the darkmod forums finally have a working way to Copy of the depthbuffer in vanilla.
This means its now possible to do proper SSAO / depth tested particles / and pretty much anything else that needs access to the depthbuffer .
steveL has created a test shader in ARB assembly so you can try out the effect allready.

!!ARBvp1.0
OPTION ARB_position_invariant;
MOV result.texcoord, vertex.texcoord;
END

!!ARBfp1.0
PARAM clipPlanes = { 0.4, 350.0 };
TEMP dpth, col, rng;
TEX dpth, fragment.texcoord, texture[0], 2D;
ADD rng.x, clipPlanes.y, -clipPlanes.x;
MUL col.x, dpth.x, rng.x;
ADD col.x, -col.x, clipPlanes.x;
ADD col.x, col.x, clipPlanes.y;
RCP rng.x, col.x;
MUL col.x, rng.x, clipPlanes.x;
MUL col.x, col.x, 2.0;
MOV result.color.r, col.x;
MOV result.color.g, col.x;
MOV result.color.b, col.x;
MOV result.color.a, 1.0;
END

[revelator]

Fixed about 90% of the problems with SSAO after we got working depthbuffer code, no outlines in skyboxes / heathaze anymore, but particles might sometimes still show outlines when SSAO is enabled,
and i introduced a new bug when changing sikkmods depthbuffer code to use our new function, causing sunshafts to look really weird (massive lighting bleed).
It only happens in sunshafts so i suspect its a bug with the code for it, but if someone can fix it the next release will be much closer.

[toneddu2000]

yay! Glad you keep working on it, great job!

[revelator]

Refined a few things in the original code for depth buffer access which means you can now suppress surfaces that may be problematic in a depth view, and i created a specialized function for creating the depth image instead of just using the rgba code path. Much of this code was created using the code in draw_exp.cpp.

The depth image is clamped to the border of the color image and no downscaling is allowed to avoid artifacts.
There are a few buggers with sikkmods old code though. Though theres no outlines in heathaze anymore i noticed that when crawling over a surface with lots of heathaze (lava) that a faint outline seems to curl up
into view. Sunshafts as mentioned earlier. And even though lensflares are disabled im still getting a lensflare effect hmm ???.