FL might support Bump Maps and other features

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.

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

adoxa wrote:
Here is everything that is read as part of [RenderPipeline] in dacom.ini (except MGSDB). Parameters are for you to discover…

FPU_PRESERVE
MULTITHREADED
PUREDEVICE
SOFTWARE_VERTEXPROCESSING
MIXED_VERTEXPROCESSING
HARDWARE_VERTEXPROCESSING
LOCKABLE_BACKBUFFER
USE_SYSLOCK
HANDLE_SWAPLOSS
TEXTURE
LIGHTING
TEXTURE_LOD
TEXTURE_ALLOW_8BIT
TEXTURE_ALLOW_32BIT
TEXTURE_ALLOW_DXT
BROKEN_MULTITEXTURE
VIEWSPACE_LIGHTS
CLEAR_COLOR
CLEAR_ZDEPTH
CLEAR_STENCIL
STATE_CACHE
BROKEN_MOD2X
BROKEN_FLIP
DEVICE_GEOMETRY
TEXTURE_SQUARE_ONLY
TEXTURE_MAX_WIDTH
TEXTURE_MAX_HEIGHT
TEXTURE_CUBEMAPS
DEPTH_BIAS
FOG_VERTEX
FOG_PIXEL
FOG_RANGE
FOG_W
RASTER_ANTIALIASEDGES
DEVICE_SUPPORT_LEVEL
TEXTURE_TRILINEAR
DEVICE_BAD_MODE
DEVICE_BAD_4444
ZENABLE
FILLMODE
SHADEMODE
LINEPATTERN
ZWRITEENABLE
ALPHATESTENABLE
LASTPIXEL
SRCBLEND
DESTBLEND
CULLMODE
ZFUNC
ALPHAREF
ALPHAFUNC
DITHERENABLE
ALPHABLENDENABLE
FOGENABLE
SPECULARENABLE
ZVISIBLE
FOGCOLOR
FOGTABLEMODE
FOGSTART
FOGEND
FOGDENSITY
EDGEANTIALIAS
ZBIAS
RANGEFOGENABLE
STENCILENABLE
STENCILFAIL
STENCILZFAIL
STENCILPASS
STENCILFUNC
STENCILREF
STENCILMASK
STENCILWRITEMASK
TEXTUREFACTOR
WRAP0
WRAP1
WRAP2
WRAP3
WRAP4
WRAP5
WRAP6
WRAP7
CLIPPING
LIGHTING
AMBIENT
FOGVERTEXMODE
COLORVERTEX
LOCALVIEWER
NORMALIZENORMALS
DIFFUSEMATERIALSOURCE
SPECULARMATERIALSOURCE
AMBIENTMATERIALSOURCE
EMISSIVEMATERIALSOURCE
VERTEXBLEND
CLIPPLANEENABLE
SOFTWAREVERTEXPROCESSING
POINTSIZE
POINTSIZE_MIN
POINTSPRITEENABLE
POINTSCALEENABLE
POINTSCALE_A
POINTSCALE_B
POINTSCALE_C
MULTISAMPLEANTIALIAS
MULTISAMPLEMASK
PATCHEDGESTYLE
PATCHSEGMENTS
DEBUGMONITORTOKEN
POINTSIZE_MAX
INDEXEDVERTEXBLENDENABLE
COLORWRITEENABLE
TWEENFACTOR
BLENDOP
POSITIONORDER
NORMALORDER

Looking at most of what’s in this list and then checking up on microsoft and directx, it seems it might be mostly related to graphics drivers and hardware and a case of whether either can actually support the particular d3drenderstates or not. Maybe it ties into the flconfigdatabase.ini and allows for disabling of many of these features when the driver or hardware are unsupported.

These below are in the list you put up and exist in the dacom.ini for all to play with already.

[RenderPipeline]
MGSDB= FLConfigDatabase.txt

;DEVICE_GAMMA = false ; forces gamma control off
;TEXTURE_ALLOW_DXT = false ; forces dxtn support off

ALPHAREF = 0 ; d3drenderstate: default alpha ref
ALPHATESTENABLE = true ; d3drenderstate: basic alpha test
ALPHAFUNC = 5 ; d3drenderstate: D3DCMP_GREATER
LOCALVIEWER = false ; d3drenderstate: specular highlights
zfunc = 4 ; default z compare func is D3DCMP_LESSEQUAL

;FPU_PRESERVE = false ; should Direct3D save and restore the FPU state every time it needs to modify the FPU state.
;MULTITHREADED = false ; request multithread-safe behavior. This causes Direct3D to take the global critical section more frequently.

; vertex processing flags are mutually exclusive
; regardless of what the user asks for if the device cant support hw-tl the user gets sw-tl
HARDWARE_VERTEXPROCESSING= true
;MIXED_VERTEXPROCESSING= true
;SOFTWARE_VERTEXPROCESSING= true

;LOCAKABLE_BACKBUFFER= false ; should the device allow the backbuffer to be locked
USE_SYSLOCK= false ; should resources (vb, ib, texture) take a windows wide critical lock when in use
HANDLE_SWAPLOSS= false ; should rp attempt to handle device loss internally? ; a poor substitue for app-side management but makes tool building easier
;VIEWSPACE_LIGHTS = false

;TEXTURE_CUBEMAPS = false

Adding entries for the antialiasing states to the list and true/falsing them has no effect….
Would be highly interested in knowing if there are any offsets for the antialiasing, i.e if it can set to 2x,4x,8x,16x or whether they are simply capable or not scenarios for the driver and graphics card. Somehow I have a feeling it would be the latter.

Oh hell, just read this, it will explain everything in that list and the relevant states. D3D renderstates

Animated textures…. like in D3’s moving walls (disgusting hellspawn lava pools made from pic’s of internal organs)

Unfortunately that’s a DX9 trick, but i’d love to have ships that seemed alive (think vorlon folks…) few other DX9 tricks that I’d like to see implemented that would help the game break through the DX8 drudgery and limits…

Yes i too would love to see a DX9 port… & i see nothing in that list that would support bumpmaps

DIFFUSEMATERIALSOURCE
SPECULARMATERIALSOURCE
AMBIENTMATERIALSOURCE
EMISSIVEMATERIALSOURCE

but no

BUMPMAPMATERIALSOURCE

or anything of equivalence in a DX8 environment

FL supports animated textures so your in luck….
Look at the explosion FX for examples.

I knows that m8… just not the type im looking for

those animations are simple… placed on texture map like sprites… what im after im after is the Full texture ones like in D3 that are actually one large rolling texture… I know’s mini-me has done this on billboards but im looking more for asteroids (bio) & ship textures… be great just to load the texture via UTF and then add a anim node telling it wich way to “roll”… like a marque mainly…

dont think i can link a .ALE animation to a shipmat … just yet anyway lol

Gisteron wrote:
is there some reference to have a Sc_flags and Sc_name node?

Nope, just Sc and Sp. You’ll have to add SPECULARENABLE = true to [RenderPipeline], but I still don’t guarantee they’ll work. For a bit of a laugh, try FILLMODE = 2 - that’ll draw everything as wireframe (making text illegible).

guess the zoom in and zoom out has been enabled in FW:TOW, right?

The DBG_ keys don’t exist, the other keys aren’t used. Here is the complete list of keys that aren’t used.

USER_BUTTON                  USER_ENGINE_TOGGLE   USER_RADAR_ZOOM_OUT        
USER_EVENTS                  USER_SET_THROTTLE    USER_STATUS_MODE           
USER_STACKABLE_CANCEL        USER_THROTTLE_0      USER_TOGGLE_MAINFRAME      
USER_NO                      USER_THROTTLE_10     USER_NN                    
USER_YES                     USER_THROTTLE_20     USER_NAVMAP                
USER_SAVE_GAME               USER_THROTTLE_25     NN_TOGGLE_OPEN             
USER_USE_ITEM                USER_THROTTLE_30     USER_ACTIONS               
USER_ACTIVATE_ITEM           USER_THROTTLE_40     USER_MANEUVER              
USER_NEXT_ITEM               USER_THROTTLE_50     USER_SET_MANEUVER_DIRECTION
USER_PREV_ITEM               USER_THROTTLE_60     USER_MANEUVER_WINDOW       
USER_SET_TARGET              USER_THROTTLE_70     USER_MANEUVER_AFTERBURNER  
USER_NEXT_WEAPON_SUBTARGET   USER_THROTTLE_75     USER_MANEUVER_CRUISE       
USER_PREV_WEAPON_SUBTARGET   USER_THROTTLE_80     USER_MANEUVER_TRADE_LANE   
USER_ZOOM_IN                 USER_THROTTLE_90     USER_ACTIVATE_MANEUVER     
USER_ZOOM_OUT                USER_THROTTLE_100    USER_JAMMER                
USER_ZOOM_TOGGLE             USER_RADAR           USER_STEALTH               
USER_VIEW_RESET              USER_RADAR_ZOOM      USER_CLOAK                 
USER_CHASE_CAMERA_MODE       USER_RADAR_ZOOM_IN   USER_TURN                  
USER_WARP                    

```Some keys are used, but have no effect; the only one I know for sure is USER_FULLSCREEN.

Not surprised they scrapped those shadows, they have to be the worst I’ve ever seen in any game

p.s - STENCILENABLE = true (should enable shadows)

Gisteron wrote:
guess the zoom in and zoom out has been enabled in FW:TOW, right?

tomsons26 wrote:
yup so is DBG_INFO DBG_FPS n DBG_FPS_GRAPH

Erm, no. They’ve never worked and never will. w0d didn’t just find switches and re-enabled them; HE CODED THE ENTIRE THING MANUALLY.

Gosh guys didn’t you get my previous message? Unless you’re willing to get your hands dirty with code, all you’ll find is a bunch of dead code and leftovers. Or wait… Do you think you’re the first ones to do what you’re doing? HA! There’ve been other people in this game’s 7 years of shelf life. They’ve done the same digging as you are doing and came to the same conclusion as I’ve been saying all along: you’re wasting your time.