FL might support Bump Maps and other features
-
After browsing dll strings i found
Bump references in rp8.dll
0006B726: BUMPENVLOFFSET
0006B735: BUMPENVLSCALE
0006B7C8: BUMPENVMAT11
0006B7D8: BUMPENVMAT10
0006B7E8: BUMPENVMAT01
0006B7F8: BUMPENVMAT00Bump references in thorn.dll
0003F87C: BumpInPCurve
0003F929: BumpOutPCurveAntiAliasing references in rp8.dll
0006B268: MULTISAMPLEMASK MULTISAMPLEANTIALIAS
0006B4AD: EDGEANTIALIAS
0006B635: ANTIALIASEDGESJPEG references in rp8.dll
000605B9: JPEG datastream contains no imagePNG references
00060E26: PNG file corrupted by ASCII conversion
00060E36: Not a PNG fileList of supported MAPS
Specular
Emissive
DiffuseShadows in flmaterials.dll
000124CA: ShadowMaterial
000125E9: efxshadowAll supported dds compressions DXT1 DXT2 DXT3 DXT4 DXT5
Directx 8 supports bumpmaps if dx6 supports them http://en.wikipedia.org/wiki/Bump_mapping
http://www.xbitlabs.com/images/video/matrox-g400/bump-env.jpg
See text below DX6 -
Actually even if you get it to activate, DX 8 had problems with it. It had a real bad habit of not using the surface normals, making it show right only part of the time. Video cards have progressed a long way so hopefully those issues have been cleared up.
The format to do a bump in DX 8 is
txtr 0 - gray scale bump
txtr1 - base material
txtr2 - cube environment mapThe shadow map stuff is used in the SP campaign. You can watch for a darker gray area under Trent and Juni in mission 1 while they are walking in the launch bay.
-
Unfortunately making it work everywhere would be just as complicated as porting to DX9, so I’d rather have DX9 right away
-
-
tomsons26, you are mixing things up: This “bumpmap” is a normalmap, but direct3d 8 only supports grayscale bumpmaps, which are more like heightmaps.
Either way, unless you can set a flag for a material so that fl uses the texture as bumpmap I doubt it can be achieved that easily.
-
Here is everything that is read as part of [RenderPipeline] in dacom.ini (except MGSDB). Parameters are for you to discover…
FPU_PRESERVE ZENABLE WRAP3 MULTITHREADED FILLMODE WRAP4 PUREDEVICE SHADEMODE WRAP5 SOFTWARE_VERTEXPROCESSING LINEPATTERN WRAP6 MIXED_VERTEXPROCESSING ZWRITEENABLE WRAP7 HARDWARE_VERTEXPROCESSING ALPHATESTENABLE CLIPPING LOCKABLE_BACKBUFFER LASTPIXEL LIGHTING USE_SYSLOCK SRCBLEND AMBIENT HANDLE_SWAPLOSS DESTBLEND FOGVERTEXMODE TEXTURE CULLMODE COLORVERTEX LIGHTING ZFUNC LOCALVIEWER TEXTURE_LOD ALPHAREF NORMALIZENORMALS TEXTURE_ALLOW_8BIT ALPHAFUNC DIFFUSEMATERIALSOURCE TEXTURE_ALLOW_32BIT DITHERENABLE SPECULARMATERIALSOURCE TEXTURE_ALLOW_DXT ALPHABLENDENABLE AMBIENTMATERIALSOURCE BROKEN_MULTITEXTURE FOGENABLE EMISSIVEMATERIALSOURCE VIEWSPACE_LIGHTS SPECULARENABLE VERTEXBLEND CLEAR_COLOR ZVISIBLE CLIPPLANEENABLE CLEAR_ZDEPTH FOGCOLOR SOFTWAREVERTEXPROCESSING CLEAR_STENCIL FOGTABLEMODE POINTSIZE STATE_CACHE FOGSTART POINTSIZE_MIN BROKEN_MOD2X FOGEND POINTSPRITEENABLE BROKEN_FLIP FOGDENSITY POINTSCALEENABLE DEVICE_GEOMETRY EDGEANTIALIAS POINTSCALE_A TEXTURE_SQUARE_ONLY ZBIAS POINTSCALE_B TEXTURE_MAX_WIDTH RANGEFOGENABLE POINTSCALE_C TEXTURE_MAX_HEIGHT STENCILENABLE MULTISAMPLEANTIALIAS TEXTURE_CUBEMAPS STENCILFAIL MULTISAMPLEMASK DEPTH_BIAS STENCILZFAIL PATCHEDGESTYLE FOG_VERTEX STENCILPASS PATCHSEGMENTS FOG_PIXEL STENCILFUNC DEBUGMONITORTOKEN FOG_RANGE STENCILREF POINTSIZE_MAX FOG_W STENCILMASK INDEXEDVERTEXBLENDENABLE RASTER_ANTIALIASEDGES STENCILWRITEMASK COLORWRITEENABLE DEVICE_SUPPORT_LEVEL TEXTUREFACTOR TWEENFACTOR TEXTURE_TRILINEAR WRAP0 BLENDOP DEVICE_BAD_MODE WRAP1 POSITIONORDER DEVICE_BAD_4444 WRAP2 NORMALORDER -
NORMALIZENORMALS
NORMALORDERnormal maps?
and yes directx 8 and older dx’es support normal maps - source
http://developer.nvidia.com/attach/6681
The pdf was created in 2000.11.14 -
My initial bump mapping comment was in reference to w0dk4 somehow porting Freelancer over to DX9 as part of Freeworlds.
tomsons26 wrote:
NORMALIZENORMALS
NORMALORDERnormal maps?
and yes directx 8 and older dx’es support normal maps - source
http://developer.nvidia.com/attach/6681
The pdf was created in 2000.11.14Those two things deal with normals, which give a direction to which way a polygon faces. Those two don’t have anything to do with normal mapping.
-
Those two things deal with normals, which give a direction to which way a polygon faces.
This is only partially correct, since the direction a polygon faces is determined through the order of the vertices. Normals are used for lighting calculations and are given per vertex (i am not talking about normal maps here ^^).
-
Normal mapping is just a method of altering the direction of the normals across polygons, which in turn changes how light is cast on the surface and creates shadows/highlights that normally would not be there.
Unfortunately normal mapping and bump mapping require a far more advanced lighting system than what FL provides. You’re chasing after a ghost here guys. The only viable way I’ve seen is what w0dk4 is doing with his DX9 port.
Seriously, stop thinking you can just flip a switch that says “turn normal mapping on”. The devs might’ve been in a hurry, but they wouldn’t have left a perfectly functional piece of code unused.
-
If anyone wants to check the strings out i used this to get them
http://www.peid.info/
u will need the string view plugin http://www.peid.info/plugins/string-viewer-4peid-v0.02.zip -
Admittedly I’m dumb as hell when it comes to this sort of stuff, but I looked at localviewer in dacom.ini (specular highlights) a long time ago, it can be set true/false and is set as standard false, which I think is a much simpler form of reflective lighting that just takes into account a light source and a single side facing it for the effect. You “might” have to change a lot more than a setting if you wanted to make it work in the true state which from what I remember is a much more specific reflection which takes into account the viewing angle, multiple faces, angles and lightsources and such. The game might not even be set up for that sort of complexity for all I know so I didn’t pursue it. To be honest, I like to think it’s best that I listen to FF from now on, there’s is no magic switch (except for the one called Adoxa!)
-
The blue texture you showed was a normal map as was stated above. DX 8 does not support those except through shaders. Even DX9 does not support it in the fixed function pipeline (FFP).
The bump supported in DX 8.1 & 2 was buggy on alot of cards. On one of my cards (a dx 8 card) it worked perfectly all the time, on a newer card it work work about 30% of the time. I left the feature in my animation program but was unable to really use it due to the lack of proper support on dx 9 cards. I tested it again earlier this year on a dx 10 card, same thing as the dx 9 cards.
The main reason is the mesh format. Normal FL meshes do not contain the extra tangent info, the bi-normal can be create by a cross product of the normal and tangent. The bi-normal can also be provided in the mesh as well. But these are not part of the FVF. What this means is a shader is required since it does have support for those in the vertex declaration. You can get around that by assigning it to the extra texture uv maps but the critical code needed to render it isn’t in the FFP.
I ended up using per-pixel bump mapping in my game engine. I didn’t use the FFP though, I used a shader. The best bet is to wait until W0dk4 releases the DX 9 port and implement a shader for it.
Why I say that is for example, I can mix 1024 point lights, a base, detail, normal (bump), specular and glow maps any way I want, all on a per-PIXEL, not per-VERTEX basis.
So W0dk4, so if you release it, I will be one of the first to play with it
