FL might support Bump Maps and other features

Materials may support specularity via Sc (specular color; float RGB) and Sp (specular power; float, presumably between 0 and 1).

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.

tomsons26 wrote:

tomsons26, wow, how to make that? Are there a tutorial?

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             

adoxa, is there some reference to have a Sc_flags and Sc_name node, too, so we could make specular maps rather than a plain color?

My initial bump mapping comment was in reference to w0dk4 somehow porting Freelancer over to DX9 as part of Freeworlds.

tomsons26 wrote:
NORMALIZENORMALS
NORMALORDER

normal 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

Those 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.

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