Codename: Drakan 10th Anniversy
Codename: Drakan 10th Anniversy
My current project is create new, very special "upgrade" to Drakan to make it shine in new era of computer games. Codename of project is Drakan: 10th Anniversy Patch. So, what it will be exactly?
I am working on hooks for Drakan calls to DX 6.1; I want to translate via custom DLL all calls to that library to DX 9.0c, so game will be able to use full power of modern hardware (including injected pixel- and vertex shader code that enable such effect as bump mapping). This is hell the lot of work, but it is possible to do even by single person. Of course if you are interested to help, feel free to drop me mail (but, please, be serious. You need to know at least object C++ and basic of /DX 6.1/DX 9.0/Shaders/Win32Hooks).
This are screenshots from *very* early tests on hooking some DX 6.1 texture funcs:
http://img511.imageshack.us/img511/5480/drakan01.jpg
http://img215.imageshack.us/img215/3227/drakan02.jpg
http://img441.imageshack.us/img441/2010/drakan03.jpg
And in-game screen (poor Arokh [;)]):
http://img524.imageshack.us/img524/6618/drakan04.jpg
Ah, and one more info: hooks for DLL are completely legal in every known to me law (Polish and USA for sure). I do not modify any part of game, nor I disassembly any part of it. I only intercept calls to DX and inject my own code here.
<i>Edited</i> Added in-game screens.
I am working on hooks for Drakan calls to DX 6.1; I want to translate via custom DLL all calls to that library to DX 9.0c, so game will be able to use full power of modern hardware (including injected pixel- and vertex shader code that enable such effect as bump mapping). This is hell the lot of work, but it is possible to do even by single person. Of course if you are interested to help, feel free to drop me mail (but, please, be serious. You need to know at least object C++ and basic of /DX 6.1/DX 9.0/Shaders/Win32Hooks).
This are screenshots from *very* early tests on hooking some DX 6.1 texture funcs:
http://img511.imageshack.us/img511/5480/drakan01.jpg
http://img215.imageshack.us/img215/3227/drakan02.jpg
http://img441.imageshack.us/img441/2010/drakan03.jpg
And in-game screen (poor Arokh [;)]):
http://img524.imageshack.us/img524/6618/drakan04.jpg
Ah, and one more info: hooks for DLL are completely legal in every known to me law (Polish and USA for sure). I do not modify any part of game, nor I disassembly any part of it. I only intercept calls to DX and inject my own code here.
<i>Edited</i> Added in-game screens.
-
- Dragon
- Posts: 87
- Joined: Sun Jul 29, 2001 2:35 am
- Location: Russia
- Contact:
Riot Engine uses internal T&L... so i think most easy is only apply shaders to existing polygons...
i think Riot Engine sends to DX for rendering completely transformed to screen coordinates triangles and already vertex-lited...
ofcourse it is easy to catch vertex lighting data and replace it to whatever you want... also at the rendering stage it is easy to change light interpolation between triangle vertices to any math you want...
but - to make more advanced lighting scheme render engine must know normal vectors (and also light sources position and direction) - and i not sure if you can export this data from the already ready for render transformed and lit tiangles data (sent by RE to DX where you can catch it)...
there may be possible to reverse-engineer 3D objects mesh data using transformed vertices data send to DX - for example if you completely sure all vertices belongs to the same object (and may be even using all objects data to seach and guess what (non-animated) object this triangle data belongs to and also using currently setted Texture)... though it is hard task like realtime OCR ... also with transparent objects RE uses internal Z-coordinate sorting for proper on-screen trianles rendering (also this still has some bugs in curent Drakan:OOTF RE)... so the triangle stream sent by RE to DX may not belongs to the same object from first to last object's polygon...
also i not sure if you can improve visual appearing of low poly objects in projection... i.e. if you only have tiangle-based 4-sides pyramid (object) it is hard to get a round projection of it...
in the newer games with external T&L everything is much more easy for modding - the game only sends full mesh and light data to external render and call 'render it now' function...
the Drakan:OOTF's RE internal T&L engine is nice enough and i thnk it is was significally better in lighting in compare with many more other realtime game renderers (lighters) in 199x years... but the modding it is also much more harder...
i think Riot Engine sends to DX for rendering completely transformed to screen coordinates triangles and already vertex-lited...
ofcourse it is easy to catch vertex lighting data and replace it to whatever you want... also at the rendering stage it is easy to change light interpolation between triangle vertices to any math you want...
but - to make more advanced lighting scheme render engine must know normal vectors (and also light sources position and direction) - and i not sure if you can export this data from the already ready for render transformed and lit tiangles data (sent by RE to DX where you can catch it)...
there may be possible to reverse-engineer 3D objects mesh data using transformed vertices data send to DX - for example if you completely sure all vertices belongs to the same object (and may be even using all objects data to seach and guess what (non-animated) object this triangle data belongs to and also using currently setted Texture)... though it is hard task like realtime OCR ... also with transparent objects RE uses internal Z-coordinate sorting for proper on-screen trianles rendering (also this still has some bugs in curent Drakan:OOTF RE)... so the triangle stream sent by RE to DX may not belongs to the same object from first to last object's polygon...
also i not sure if you can improve visual appearing of low poly objects in projection... i.e. if you only have tiangle-based 4-sides pyramid (object) it is hard to get a round projection of it...
in the newer games with external T&L everything is much more easy for modding - the game only sends full mesh and light data to external render and call 'render it now' function...
the Drakan:OOTF's RE internal T&L engine is nice enough and i thnk it is was significally better in lighting in compare with many more other realtime game renderers (lighters) in 199x years... but the modding it is also much more harder...
-
- Dragon
- Posts: 87
- Joined: Sun Jul 29, 2001 2:35 am
- Location: Russia
- Contact:
>Are you sure Drakan uses internal T&L?
we live with Drakan since 1999 and rememeber how it do not get any gain in performance when mirgating from pure texture-only-rendering cards (like Voodoo and S3 Sagave 3 cards) to some newer like Geforces and Radeons with hardware T&L blocks...
also Drakan:OOTF RE can run with cards without hardware T&L ...
*damn - shame on me - i forgot the name of the populair '3D accelerator' PCI add-on card in 1998..1999 year with 8 Mb (or may be even 4 Mb !) memory onboard*... from readme.txt -
--cut--
Drakan should run well on almost any Direct3D compatible 3D accelerator card that
supports Z-Buffering, Bilinear Filtering, and Alpha-Blending. Drakan has been
tested with and supports the following 3D accelerated graphics cards:
3Dfx: Voodoo Graphics, Voodoo Rush, Voodoo Banshee, Voodoo 2, Voodoo 3
NVidia: Riva128, TNT, TNT2
ATI: All-in-Wonder, XPERT, Rage Pro, Rage 128, Rage Fury
3DLabs: Permedia 2 and 3
Intel: i740 and i740 with video capture
Matrox: G200 and G400
Number Nine: Revolution
PowerVR: PowerVR (PCX2)
Rendition: V2100 and V2200
S3: Virge DX & GX, Savage 3 & 4
--cut--
even at poorest S3 Virge !!! with down to 2 Mb memory - card of 1995 year - http://en.wikipedia.org/wiki/S3_ViRGE
also Drakan:OOTF was designed for the very first consumer '3D accelerator' cards with very small texture memory... so is the poor texture resolution - it really uses only 16 bit textures and only 256x256 max textures size... (may be the limitation of the max texture size for old voodoo cards)...
sadly most of 'world' textures are even smaller - like 64x64...
so is the really fuzzy/not_sharp resulting render on 1024x768 or high resolution monitors... Drakan:OOTF runs nicely in 800x600 mode on 14inches monitor - but poor on 20inches and more...
so one more simple but effective design effort may be in simple increasing most textures resolution to the max possible 256x256 and adding detailed maps where possible...
i tried to make higher resolution terrain textures but i poor even 2d designer and result was not really very better in compare with original low-res terrain textures...
may be the reason for so small terrain textures resolution was in that damn too small texture memory in old cards 10+ years old... because it is anyway required to load a lot of terrain textures to render most of Drakan:OOTF scenes...
the 32bit is only lighting data... so user really sees difference when he switches from 16 bit to 32bit rendering mode...
>Direct3D 6.1 Immediate Mode (that one used in Drakan) has hardware support for T&L, hasn't it?
DX6 may have some sort of T&L support but application has to use it... i completely not sure if RE has both options to run with internal T&L or use hardware T&L... at least in the passed 10 years since Drakan:OOTF release i never read if anyone could run Drakan:OOTF with hardware-accelerated T&L...
we live with Drakan since 1999 and rememeber how it do not get any gain in performance when mirgating from pure texture-only-rendering cards (like Voodoo and S3 Sagave 3 cards) to some newer like Geforces and Radeons with hardware T&L blocks...
also Drakan:OOTF RE can run with cards without hardware T&L ...
*damn - shame on me - i forgot the name of the populair '3D accelerator' PCI add-on card in 1998..1999 year with 8 Mb (or may be even 4 Mb !) memory onboard*... from readme.txt -
--cut--
Drakan should run well on almost any Direct3D compatible 3D accelerator card that
supports Z-Buffering, Bilinear Filtering, and Alpha-Blending. Drakan has been
tested with and supports the following 3D accelerated graphics cards:
3Dfx: Voodoo Graphics, Voodoo Rush, Voodoo Banshee, Voodoo 2, Voodoo 3
NVidia: Riva128, TNT, TNT2
ATI: All-in-Wonder, XPERT, Rage Pro, Rage 128, Rage Fury
3DLabs: Permedia 2 and 3
Intel: i740 and i740 with video capture
Matrox: G200 and G400
Number Nine: Revolution
PowerVR: PowerVR (PCX2)
Rendition: V2100 and V2200
S3: Virge DX & GX, Savage 3 & 4
--cut--
even at poorest S3 Virge !!! with down to 2 Mb memory - card of 1995 year - http://en.wikipedia.org/wiki/S3_ViRGE
also Drakan:OOTF was designed for the very first consumer '3D accelerator' cards with very small texture memory... so is the poor texture resolution - it really uses only 16 bit textures and only 256x256 max textures size... (may be the limitation of the max texture size for old voodoo cards)...
sadly most of 'world' textures are even smaller - like 64x64...
so is the really fuzzy/not_sharp resulting render on 1024x768 or high resolution monitors... Drakan:OOTF runs nicely in 800x600 mode on 14inches monitor - but poor on 20inches and more...
so one more simple but effective design effort may be in simple increasing most textures resolution to the max possible 256x256 and adding detailed maps where possible...
i tried to make higher resolution terrain textures but i poor even 2d designer and result was not really very better in compare with original low-res terrain textures...
may be the reason for so small terrain textures resolution was in that damn too small texture memory in old cards 10+ years old... because it is anyway required to load a lot of terrain textures to render most of Drakan:OOTF scenes...
the 32bit is only lighting data... so user really sees difference when he switches from 16 bit to 32bit rendering mode...
>Direct3D 6.1 Immediate Mode (that one used in Drakan) has hardware support for T&L, hasn't it?
DX6 may have some sort of T&L support but application has to use it... i completely not sure if RE has both options to run with internal T&L or use hardware T&L... at least in the passed 10 years since Drakan:OOTF release i never read if anyone could run Drakan:OOTF with hardware-accelerated T&L...
-
- Dragon
- Posts: 87
- Joined: Sun Jul 29, 2001 2:35 am
- Location: Russia
- Contact:
-
- Dragon
- Posts: 87
- Joined: Sun Jul 29, 2001 2:35 am
- Location: Russia
- Contact:
also a task to check for hacker - as i remember it may be additional bug in RE - it can not use trilinear texture filtering if it even selected in RE options (just check it - when i try to select 'trilinear' filtering in drop-down list i got still 'bilinear' selected)...
so it may be another point for update mod - use 'multi-point' or even fractal-like texture upsizing right at render stage (via pixel shaders) to form as sharp picture as possible with current Drakan:OOTF textures...
so it may be another point for update mod - use 'multi-point' or even fractal-like texture upsizing right at render stage (via pixel shaders) to form as sharp picture as possible with current Drakan:OOTF textures...
-
- Dragon
- Posts: 87
- Joined: Sun Jul 29, 2001 2:35 am
- Location: Russia
- Contact:
also that is definetly possible and may add to the Drakan:OOTF looking is DOF simulation... it is really hard to compute in realtime - but todays video card has much enough processing units for it...
Drakan:OOTF runs nicely with many stereo-renderers so it definetly sends Z-coordinate of the all triangles to DX right...
Drakan:OOTF is not first-person game but third person - so it definetly possible to select the main plane and third planes in a scene (both near and far) based on the Z-coordinate value... also the camera-to-Rynn distance is mostly fixed... in the fly mode camera-to-Arokh distance is larger, but may be it is possible to detect this mode (may be simply by analyse bits data in Drakan.exe process memory or may be even directly found camera-to-Rynn/Arokh distance)...
so is the DOF simulation alrorithm - if the Z-coordinate of vertex (or even screen pixel - calculated from 3 XYZ coordinates of given triangle vertices) is in the 'focus plane' (i.e. equal to Z-coord of the 'focus plane' - do nothing
if the Z-coordinate of vertex is not equal to the 'focus plane' Z-coord (Zfocus) - blur the texture _and_ trianlge edge in some proportion to (Z-Zfocus)...
currently with low-res enough textures it works by itself - the char's objects edges are sharp and many 'world' textures are not... but all objects edges are also sharp (i.e. object's edge sharpness do not depends on Z-coord) - and this ruines the 'auto-DOF-effect' in some way...
Drakan:OOTF standart render -
DOF-simulated -
Drakan:OOTF runs nicely with many stereo-renderers so it definetly sends Z-coordinate of the all triangles to DX right...
Drakan:OOTF is not first-person game but third person - so it definetly possible to select the main plane and third planes in a scene (both near and far) based on the Z-coordinate value... also the camera-to-Rynn distance is mostly fixed... in the fly mode camera-to-Arokh distance is larger, but may be it is possible to detect this mode (may be simply by analyse bits data in Drakan.exe process memory or may be even directly found camera-to-Rynn/Arokh distance)...
so is the DOF simulation alrorithm - if the Z-coordinate of vertex (or even screen pixel - calculated from 3 XYZ coordinates of given triangle vertices) is in the 'focus plane' (i.e. equal to Z-coord of the 'focus plane' - do nothing
if the Z-coordinate of vertex is not equal to the 'focus plane' Z-coord (Zfocus) - blur the texture _and_ trianlge edge in some proportion to (Z-Zfocus)...
currently with low-res enough textures it works by itself - the char's objects edges are sharp and many 'world' textures are not... but all objects edges are also sharp (i.e. object's edge sharpness do not depends on Z-coord) - and this ruines the 'auto-DOF-effect' in some way...
Drakan:OOTF standart render -
DOF-simulated -
This screen comes from DX 9.0c renderer:
http://img153.imageshack.us/img153/2346/screenbih.jpg
It was exactly as you said, Drakon Rider, Drakan uses internal T&L and gives DX already pretransformed vertices's. However this still allows me to inject post processing effects and some pixel shaders. I am doing research for faking normal maps without direct knowledge about light sources (it won't look that good, but initial results are pretty interesting ). More than half work is done now, and I expect I could start injecting custom effects in week or two. I have almost completely working DX 9.0c based renderer (the only exception are missing shadows and drastic fps drop when fog comes into field of view).
The project is very late, 'cause I spent last few months in hospital (and I am still hospitalized, but I am now on weekend pass, so I have some Internet access)
http://img153.imageshack.us/img153/2346/screenbih.jpg
It was exactly as you said, Drakon Rider, Drakan uses internal T&L and gives DX already pretransformed vertices's. However this still allows me to inject post processing effects and some pixel shaders. I am doing research for faking normal maps without direct knowledge about light sources (it won't look that good, but initial results are pretty interesting ). More than half work is done now, and I expect I could start injecting custom effects in week or two. I have almost completely working DX 9.0c based renderer (the only exception are missing shadows and drastic fps drop when fog comes into field of view).
The project is very late, 'cause I spent last few months in hospital (and I am still hospitalized, but I am now on weekend pass, so I have some Internet access)
- Arokhs Twin
- Site Admin
- Posts: 1295
- Joined: Wed Jul 18, 2001 9:36 pm
- Location: United Kingdom
- Contact:
Yes, but I keep going better, and it's expected that I'll finish my treatment in about week or two. I am on third pass right now, so I have again some spare time
Currently I am fixing one last bug in my DX9.0c renderer (huge drop in FPS when fog is in the field of view along with fog glitches) and than I'll begin working onto final stage. The fake normal maps will work on that way: normal maps will be generated procedurally from diffuse channel and they will be fictional dynamic light source directly above camera which will be used only to simulate shadow into surface (so any camera move will move light source as well which should give nice looking but perhaps a bit unrealistic effects of fractures on surfaces)
There will be nice configuration dialog which will allow to turn this effect (and many more) on and off, as well as patch some additional hotfixes on devices that will need them. There will be also raw, text files containing two pixel shaders - one of them will be put onto every surface, where another one will be used to postprocess screen. I will prepare few variants of each one (selectable from metioned Launcher), but also give chance to modify them both via ordinary notepad (in case someone knowns HLSL shader language, it's not that hard, and there are tons of examples in Internet).
Stay tunned for beta tests!
Currently I am fixing one last bug in my DX9.0c renderer (huge drop in FPS when fog is in the field of view along with fog glitches) and than I'll begin working onto final stage. The fake normal maps will work on that way: normal maps will be generated procedurally from diffuse channel and they will be fictional dynamic light source directly above camera which will be used only to simulate shadow into surface (so any camera move will move light source as well which should give nice looking but perhaps a bit unrealistic effects of fractures on surfaces)
There will be nice configuration dialog which will allow to turn this effect (and many more) on and off, as well as patch some additional hotfixes on devices that will need them. There will be also raw, text files containing two pixel shaders - one of them will be put onto every surface, where another one will be used to postprocess screen. I will prepare few variants of each one (selectable from metioned Launcher), but also give chance to modify them both via ordinary notepad (in case someone knowns HLSL shader language, it's not that hard, and there are tons of examples in Internet).
Stay tunned for beta tests!
There is now official ModDB profile for this mod:
http://www.moddb.com/mods/drakan-10th-anniversary
Where I'll put screens and news from develeopment. Beta tests will probably start at late november/december.
http://www.moddb.com/mods/drakan-10th-anniversary
Where I'll put screens and news from develeopment. Beta tests will probably start at late november/december.