TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 4 of 4 FirstFirst 1234
Results 76 to 83 of 83

Thread: NewDark T2 1.27/System Shock 2.48

  1. #76
    Registered: May 2004
    Location: Germany
    Thief 2 with a working Multiplayer again? Wow that sounds awesome! From what I read, this REQUIRES Hamachi and can't be used with the "global server" as is..?
    And we only install Thief 2 without TTfix, just NewDark, right?

  2. #77
    Registered: Aug 2009
    So I'm not sure if I'm missing something. I'm trying to use the cc-dither16.fx shader in Thief Gold, to emulate the original colour rendering, but it's not having any effect.

    I renamed it to cc.fx, put it into the 'shaders' folder in the directory, made sure "d3d_disp_sw_cc" was uncommented in cam_ext.cfg, but it makes no difference (neither do the other shaders for that matter)

  3. #78
    Registered: Nov 2003
    Location: NMONʞN∩
    Maybe this will help. This is in the new_config_vars.txt file.

        only has any effect in combination with "use_d3d_display", enables software gamma and color processing. The
        benefit of doing gamma in (shader) software rather than HW gamma, is that there is less quality loss
        because it can be applied on the higher precision floating point or 10-bit render data, before getting
        down converted to a displayable format. Whereas HW gamma is applied on the already downconverted displayable
        format. Another benefit is that gamma works in windowed mode, where HW gamma doesn't work.
        Enabling color processing comes with some performance loss.
        It's possible to override the CC shaders with custom ones. Either to customize the gamma or color processing,
        or to add additional processing like noise/dithering. When there's additional processing in the shaders, that
        should be done regardless of gamma/color processing being active or not, then define "d3d_disp_sw_cc 2". It
        will make sure the CC shaders are always used.
        For further details and example shaders see the "doc/sw_cc" directory.
    d3d_disp_sw_cc_bright <val>
        brightness level when "d3d_disp_sw_cc" is enabled, default is 0. A value of 1 would make everything white.
        This option is only provided for completeness, it's more appropriate to adjust gamma.
        Does not affect menu screens.
    d3d_disp_sw_cc_contr <0.0 - >
        contrast level when "d3d_disp_sw_cc" is enabled, default is 1. This option is only provided for completeness,
        it's more appropriate to adjust gamma.
        Does not affect menu screens.
    d3d_disp_sw_cc_sat <0.0 - >
        saturation level when "d3d_disp_sw_cc" is enabled, default is 1. A value of 0 is completely desaturated (b&w).
        Does not affect menu screens.
    d3d_disp_sw_cc_rgbfilter <0.0 - 1.0> <0.0 - 1.0> <0.0 - 1.0>
        RGB color filter when "d3d_disp_sw_cc" is enabled, default is 1 1 1 (white). For example to get a old photo
        type of look (sepia) you could do "d3d_disp_sw_cc_sat 0.25" and "d3d_disp_sw_cc_rgbfilter 1 0.7 0.3".
        Does not affect menu screens.
        only has any effect in combination with "d3d_disp_sw_cc", forces gamma to be applied by display HW like it
        does when "d3d_disp_sw_cc" is disabled, but other color control like saturation and color filter are still
        applied. This _might_ help reduce any performance hit (induced by "d3d_disp_sw_cc") slightly, at the expense
        of gamma not working in windowed mode and potential minor quality loss. Another potential issue is that
        contrast/brightness calculations are normally applied after gamma, with this option enabled gamma is applied
        after brightness/contrast (if brightness/contrast isn't used, i.e. set to default, this is of no concern).

  4. #79
    Registered: Apr 2011
    I renamed it to cc.fx, put it into the 'shaders' folder in the directory, made sure "d3d_disp_sw_cc" was uncommented in cam_ext.cfg, but it makes no difference (neither do the other shaders for that matter)
    That all sounds correct. An easy way sanity check is to add, just before the return vColor line: vColor.r = 1.0; if everything goes red, then the shader is being loaded and used ok. If it's not being used, then try setting d3d_disp_sw_cc 2 also to force it to use the shader pipeline.

    The dither16 effect is quite subtle and hard to see at modern screen resolutions, since it's operating per pixel. Here's a comparison from my tests:

    No shader, so no dither:

    Dither on (barely noticeable at this scale and gamma):

    Dither on, modified to be 4x scale:

  5. #80
    Registered: Aug 2009
    Thanks guys. Looks like it may just be the shader that's too subtle to notice. I ran the vColor.r = 1.0; test, and the game did turn red, so it's working. I was just expecting something closer to the original T1 colours

  6. #81
    Registered: Sep 2000
    Location: ZylonBane
    It's not emulating 256-color mode, it's emulating 16-bit mode.

  7. #82
    If Le Corbeau is watching, I'd like to bring up a particular bit of undesirable/erroneous(?) behavior. The issue is that a certain small number of config values which can be specified somewhere other than cam.cfg, get copied to cam.cfg whenever the game is run (and left there permanently), and this can cause non-obvious issues for users. The most pressing issue is that "somewhere other than cam.cfg" can even mean a fan mission's fm.cfg file. These files are supposed to be FM-specific and from my point of view at least should never modify a user's permanent, global config.

    The values I'm currently aware of that are subject to this copying are:

    -"fm_language" and "fm_language_forced"
    Say the user has an English Thief install, but puts "fm_language french" into cam_mod.ini. They run an FM; it runs in French. Then the user removes the line from cam_mod.ini and runs the FM again. The expected result would be the FM runs in English, but the actual result is it still runs in French because the "fm_language french" line has been silently copied into cam.cfg. The user would have to remove that too in order to get back to English.

    AngelLoader in fact handles this removal from cam.cfg automatically to ensure the correct and expected language is used in all cases.


    The fan mission Ascend the Dim Valley specifies these values in its fm.cfg, and they get silently copied into cam.cfg when the FM is run. The "sfx_channels" copy is only a minor issue; the user can always change that back in the UI and it's unlikely to cause much of a problem anyway. But the "character_detail 0" line in this FM's fm.cfg is far more of a problem; this line breaks texturing in many other FMs (some humans will be textured "backwards" with their face split into two on the back of their heads and the back of their hoods on their front etc. as can be seen in The Burning Bedlam with the hanging man, and in Calendra's Cistern on the antique guy's door guard when HDMOD is used). This breakage's cause is extremely non-obvious and I only stumbled onto it after a lot of trial-and-error and then remembering the language behavior described above that I happened to know from having written a mission loader.

    There may well be other values that get copied, but if so I wouldn't know what they are. Most config values don't get copied; it seems to be only a handful that do.

    Not being a NewDark dev, I can't say for certain if this behavior is intended or somehow required, but I can't think of a reason why it would be. But the per-mission fm.cfg file leaking its values out to the global cam.cfg seems erroneous to me, and counter to what one would expect and want.

  8. #83
    Registered: Nov 2001
    Location: Lille, France
    I have relayed your message on our board.

Page 4 of 4 FirstFirst 1234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts