TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Page 76 of 98 FirstFirst ... 2631364146515661667172737475767778798081869196 ... LastLast
Results 1,876 to 1,900 of 2446

Thread: Thief 1/2 & SShock 2: DDFix and Enhanced Resolution Patch - discussion

  1. #1876

    Thanks for that link, now I have a better understanding of that values.

  2. #1877
    Member
    Registered: Nov 2001
    Location: Sunny Finland

    ddfix 1.5.2

    ddfix 1.5.2
    • Anisotropic filtering for the first stage only, linear for the second stage. For the second stage (light maps) anisotropic does cause some glitches after all.
    • Triple buffering.
    • FlipInterval option. Translates directly to DDFLIP_INTERVAL* flag in the Flip() call.
    • MenuUpdateDelay option.
    The new ini options are:
    Code:
    ;Triple buffering. Boolean. (Default 0.)
    ;TripleBuffer=1
    
    ;Number of vsyncs per flip. Increase this number to decrease frame rate. 1-4. (Default 1.)
    ;FlipInterval=2
    
    ;Menu screen update delay in milliseconds. This also enables PrintScreen with menu screens.
    ;(Default 14, 0 = no delay.)
    ;MenuUpdateDelay=14
    Flip interval is a better method of limiting the frame rate - better than FrameRateLimit, that is. FlipInterval is basically a divisor - with a 100Hz screen and FlipInterval=2, the maximum frame rate is 50 FPS. But this only works when vsync is on.

    At least for me, triple buffering seems to work quite well and it gives me noticeably smoother motion than double buffering. However, as a counter example, with certain settings while triple buffering provided a better average FPS, there was so much more variance that it looked much worse than double buffering with lower FPS - see the graph below. The same run through the starting area of "Ambush" with double and triple buffering.


  3. #1878
    hey jermi!

    thank you for your incredible dedication and yet another amazing update to ddfix - damn, I begin to run out of feature request ideas - and that says something ..

    "Anisotropic filtering for the first stage only, linear for the second stage."

    yeah, the glitches are fixed - just checked

    "Triple buffering."

    thanks for implementing it, I'll be testing/running with TB on and off, and see whether I can see (or rather feel) any difference. Though I run the game with 60 fps (VSync on) all the time - does TB yield any benefit in such a case? Have you noticed any (increased) input lag with TB on, BTW?

    about the graph: why is DB example capped at 30 fps - which settings have you used to get it (I understand it's a scenario where frame rate is consistently lower than 60 fps, and gets cut to 60/2 - but I haven't seen this in Thief 2 - except when PP is on - with bloom and AA, and I run out of fill rate on my old Radeon X1950; normally I get constant 60 fps @1680x1050 and AF/AA on - but PP off)? What about comparison (subjective) between DB and TB when fps is @ constant 60 fps (or whatever max fps allowed by VSync)? Would there be any difference between DB and TB, then (like smoother motion you mention etc)?

    Quote Originally Posted by jermi
    Flip interval is a better method of limiting the framrate - better than FrameRateLimit, that is.
    is FlipInterval an integer with allowed values of 1, 2, 3 and 4 only - or a float (i.e 2,2 etc)? Anyway, it doesn't work for me - when I set it to 2, I still get 60 fps (not 30 like I should). Vsync is on (set via driver). Why do you say it's a better method than FrameRateLimit (FrameRateLimit lets you set any fps you want (as it's a float), while FlipInterval is just a divisor of refresh rate)? Is FlipInterval related to TB setting in any way, or it should work with both DB/TB?

    speaking of VSync, I've noticed that currently there's no way to explicitly set VSync ON/OFF via game/ddfix - only in driver, and game "inherits" it - could you add an option to set VSync to ddfix, please (so that we don't have to go to driver and change global setting which might be OFF, while Thief practically demands ON on modern machines to avoid excessive game speeding).

    What about adding/allowing of setting texture LODBias via ddfix, specifically for Thief (I know it can be set globially via driver, but it's not too convenient to do/change it for 1 game etc)?


    re MenuUpdateDelay - I'll play with this option later to find an optimal setting for me - thanks for adding it as well...

    ps could you rename the option "UseCompatibleZBuffer" in .ini to be just ZBufferDepth (and allowed values: 16 (default), 24 (bits); 32 isn't supported on modern h/w, I guess) - it would make it more "legible" than now, I think.
    Last edited by Hiatus; 12th Sep 2010 at 07:05.

  4. #1879
    Member
    Registered: Mar 2001
    Location: Ireland
    Quote Originally Posted by Hiatus View Post
    speaking of VSync, I've noticed that currently there's no way to explicitly set VSync ON/OFF via game/ddfix - only in driver, and game "inherits" it - could you add an option to set VSync to ddfix, please (so that we don't have to go to driver and change global setting which might be OFF, while Thief practically demands ONN on modern machines to avoid excessive game speeding).
    Your drivers should have specific options for individual games. I know for a fact that the nVIDIA drivers let you specify any of the settings for a specific game, and I think the ATI ones do, too (it's been a while).
    Adding the option to DDFix won't hurt, though.

  5. #1880
    Member
    Registered: Mar 2009
    Location: underground cavern
    The new triple buffering has brought up my FPS w/ Post Processing, which is great!

    Jermi, you are amazing!

  6. #1881

    Thanks for the update, but sadly my ThiefGold still doesn´t support Post Processing or the Ntex-pack.

    Did you see now my posted screenshots? I was wondering because no one was referring to that...

    Has anyone else here a GeForce9800GT and ThiefGold tested with PostProcessing & Ntex?

  7. #1882
    Member
    Registered: Nov 2001
    Location: Sunny Finland
    I saw those, yes. I don't know what to tell you, especially if T2 is working. If you use the same settings with TG as you do with T2, you should get the same effect.

    Quote Originally Posted by Hiatus View Post
    Though I run the game with 60 fps (VSync on) all the time - does TB yield any benefit in such a case? Have you noticed any (increased) input lag with TB on, BTW?
    It depends, but typically even if the average frame rate equals the vsync frequency, there will still be a slower frame every now and then, and TB will eliminate those. And yes, I do notice the extra lag due to TB.

    Quote Originally Posted by Hiatus View Post
    about the graph: why is DB example capped at 30 fps - which settings have you used to get it
    It was "optimal quality", except AA was only 4x. Or something like that.

    Quote Originally Posted by Hiatus View Post
    What about comparison (subjective) between DB and TB when fps is @ constant 60 fps (or whatever max fps allowed by VSync)? Would there be any difference between DB and TB, then (like smoother motion you mention etc)?
    Like I mentioned, for me it is noticeably smoother, even though I'm capped at 60 FPS.

    Quote Originally Posted by Hiatus View Post
    is FlipInterval an integer with allowed values of 1, 2, 3 and 4 only - or a float (i.e 2,2 etc)? Anyway, it doesn't work for me - when I set it to 2, I still get 60 fps (not 30 like I should). Vsync is on (set via driver). Why do you say it's a better method than FrameRateLimit (FrameRateLimit lets you set any fps you want - step is 1 fps I think, while FlipInterval is just a divisor of refresh rate)? Is FlipInterval related to TB setting in any way, or it should work with both DB/TB?
    Integer, 1-4 only. If it's not working, there might be something wrong with your vsync, especially if you had speed problems that were solved by setting FrameRateLimit. FlipInterval is better because it's a feature of D3D with properly defined behaviour. With vsync on, FrameRateLimit is less reliable and actually less intuitive to use.

    Quote Originally Posted by Hiatus View Post
    ps could you rename the option "UseCompatibleZBuffer" in .ini to be just ZBufferDepth (and allowed values: 16 (default), 24 (bits); 32 isn't supported on modern h/w, I guess) - it would make it more "legible" than now, I think.
    I thought the default is 24. I'll check, at some point.

    As for vsync and LOD bias options - well, you are running out of ideas, aren't you? They do have game specific profiles, as NV pointed out.

  8. #1883
    Quote Originally Posted by jermi
    As for vsync and LOD bias options - well, you are running out of ideas, aren't you? They do have game specific profiles, as NV pointed out.
    - well, I agree LOD bias would be a bit too much maybe, as it isn't used too much nowadays (with Aniso being much much better etc), but still I think VSync option would be useful to have, just to set-once-and-forget (even across OS installs), like Aniso currently (too bad it can't be done with AA, btw). Many modern/older games have it, D3/TDM has it, too (heck, even console port Thief 3 has VSync setting in game menu!), besides while I agree NVidia has quite good game-specific profiles in their drivers (and there's always nHancer, if it's not enough), AFAIK ATI doesn't (it has profile manager but it's a joke - I wasn't able to make a profile for T2 with a specific Vsync setting just for this .exe - so it's useless), and you have to use 3rd party apps like ATT (ATI Tray Tools) for that (they add - like ATT - additional delay when starting/closing the game to change settings back and forth, so I don't use them, really). I don't have newest CCC as I have a "legacy" card (according to ATI), so maybe in newer versions something changed, but I doubt it. People have been clamoring for *proper* profile support/management in CCC (or whatever) for years now. And VSync is a very important option for Thief on modern(ish) hardware (without it you get hundreds of fps or more, and game speeds up incredibly so it's unplayable), so IMO it would be worth to add it. I sometimes look for this option in ddfix.ini, and can't believe something so basic/necessary isn't there. So adding Vsync option in ini would be probably my last major feature request (unless I can think of anything else *really* useful ).

    Quote Originally Posted by jermi
    I thought the default is 24. I'll check, at some point.
    always thought the default was actually 16, and UseCompatibleZBuffer=0 sets it to 24 (UseCompatibleZBuffer is 1, by default ie. 16 bits), I'm using UseCompatibleZBuffer=0 (24-bit) all the time anyway, without any noticeable glitches. I'm not sure though, which is really the default, so if you could look into it and clarify it (and rename this confusingly named variable), it would be fine.

    Quote Originally Posted by jermi
    Integer, 1-4 only. If it's not working, there might be something wrong with your vsync, especially if you had speed problems that were solved by setting FrameRateLimit. FlipInterval is better because it's a feature of D3D with properly defined behaviour. With vsync on, FrameRateLimit is less reliable and actually less intuitive to use.
    hmm, my VSync seems fine (works in apps like I set it to), and FlipInterval still doesn't work for me (I tried forcing VSync via driver, "always on" and it didn't help). And I'm capped at 60 fps (refresh rate of my LCD) in Thief, unless I set via driver (CCC/ATT) VSync to be "Always off". And FrameRateLimit works perfectly for me (btw, does it work with both VSync ON and OFF? And I've just noticed it's a float, not an integer like I assumed - my bad). Maybe DDFLIP_INTERVAL is broken in the driver I'm using - I wouldn't be much surprised, knowing ATI (and OS might be a factor, too - you are on W7, I'm on XP - maybe they broke it only on XP). Anyway, problems/issues like that are another reason why adding explicit setting of VSync via ini would be useful - to rule out "there might be something wrong with your vsync" etc.

    Quote Originally Posted by Hiatus
    Is FlipInterval related to TB setting in any way, or it should work with both DB/TB?
    you didn't answer that (I assume it should work with both, but can't check/test it as it doesn't work at all for me )


    Quote Originally Posted by Albert
    The new triple buffering has brought up my FPS w/ Post Processing, which is great!
    yeah, TB is especially useful for explicitly boosting your fps in fillrate-exhaustion situations - as shown in jermi graph above (when your average fps is consistently lower than your Refresh rate with VSync on - with merely DB it would get cut to the nearest higher fps divisor like 60/2, 60/3 etc - 60 is RR here - I experience it myself with PP/Bloom on along with AF/AA - my fps is exactly 30 (60/2) with AA 4x, and 20 (60/3) with AA 6x - that is with DB, TB should give a boost here to let have as many fps as your h/w can produce), like with PP+Bloom ON along with AF/AA, as jermi himself admited his PP/bloom implementation isn't very efficient, so it eats up your fillrate (and thus fps) quickly.

    ===

    ps for floats in ini one should use dots, not commas, (22.5 - not 22,5), correct?

    ps2 how exactly have you implemented TB in ddfix - using "page flipping" method (like in OpenGL) or "render ahead queue" technique (I'm just curious)? Quoting http://www.anandtech.com/show/2794/4 , is that article bit correct (that DirectX doesn't implement page-flipping based TB, only render ahead queues (with default value of 3), and there are differences between these 2 approaches?

    UPDATE: There has been a lot of discussion in the comments of the differences between the page flipping method we are discussing in this article and implementations of a render ahead queue. In render ahead, frames cannot be dropped. This means that when the queue is full, what is displayed can have a lot more lag. Microsoft doesn't implement triple buffering in DirectX, they implement render ahead (from 0 to 8 frames with 3 being the default).

    The major difference in the technique we've described here is the ability to drop frames when they are outdated. Render ahead forces older frames to be displayed. Queues can help smoothness and stuttering as a few really quick frames followed by a slow frame end up being evened out and spread over more frames. But the price you pay is in lag (the more frames in the queue, the longer it takes to empty the queue and the older the frames are that are displayed).

    In order to maintain smoothness and reduce lag, it is possible to hold on to a limited number of frames in case they are needed but to drop them if they are not (if they get too old). This requires a little more intelligent management of already rendered frames and goes a bit beyond the scope of this article.

    Some game developers implement a short render ahead queue and call it triple buffering (because it uses three total buffers). They certainly cannot be faulted for this, as there has been a lot of confusion on the subject and under certain circumstances this setup will perform the same as triple buffering as we have described it (but definitely not when framerate is higher than refresh rate).

    Both techniques allow the graphics card to continue doing work while waiting for a vertical refresh when one frame is already completed. When using double buffering (and no render queue), while vertical sync is enabled, after one frame is completed nothing else can be rendered out which can cause stalling and degrade actual performance.

    When vsync is not enabled, nothing more than double buffering is needed for performance, but a render queue can still be used to smooth framerate if it requires a few old frames to be kept around. This can keep instantaneous framerate from dipping in some cases, but will (even with double buffering and vsync disabled) add lag and input latency. Even without vsync, render ahead is required for multiGPU systems to work efficiently.

    So, this article is as much for gamers as it is for developers. If you are implementing render ahead (aka a flip queue), please don't call it "triple buffering," as that should be reserved for the technique we've described here in order to cut down on the confusion. There are games out there that list triple buffering as an option when the technique used is actually a short render queue. We do realize that this can cause confusion, and we very much hope that this article and discussion help to alleviate this problem.
    Last edited by Hiatus; 12th Sep 2010 at 11:03.

  9. #1884
    Member
    Registered: Mar 2009
    Location: underground cavern
    I should note that with post processing and TB, I get just a little bit of lag, but that it isn't so bad, seeing as my keypresses respond as well as ever. Unlike before I had TB.

  10. #1885
    Member
    Registered: Mar 2001
    Location: Helsinki, Finland
    Jermi is there something you can do to make Thief 1 & 2 like Fraps more? Menus don't show up at all in videos recorded by Fraps. Maybe windowed game mode could be a solution?

    Also with all these new features I think the ini is getting very crowded. Maybe a new UI program for DDFix would be in order?
    Last edited by Wille; 13th Sep 2010 at 03:44.

  11. #1886
    Member
    Registered: Mar 2009
    Location: underground cavern
    Quote Originally Posted by Wille View Post
    Jermi is there something you can do to make Thief 1 & 2 like Fraps more? Menus don't show up at all in videos recorded by Fraps. Maybe windowed game mode could be a solution?
    I think that problem lies with Fraps. It only records games that access the Direct 3D (Or Opengl, maybe) drivers. It doesn't recognize the games menus, which use DirectDraw.

  12. #1887
    Member
    Registered: Mar 2009
    Location: underground cavern
    Yeah, and by the way, has anyone found the ideal Post-Processing settings? I wound up making Three Crowns look like it was being played from the inside of a blue bottle.

  13. #1888
    Member
    Registered: Nov 2001
    Location: Drinking baby lemonade!

  14. #1889
    Quote Originally Posted by Wille View Post
    Also with all these new features I think the ini is getting very crowded. Maybe a new UI program for DDFix would be in order?
    updated GUI app for ddfix would be great, but please not using .NET framework this time (some people are still on WinXP, and have no need to install .NET generally, as very few (worthy) apps use it). Something small, fast and native (not depending on installing massive/bloated class libraries like .NET or Java).

    PP section from ini would especially benefit (and be more accesible) from GUI (settings there require some sliders, not only simple checkboxes).


    Quote Originally Posted by Albert
    Yeah, and by the way, has anyone found the ideal Post-Processing settings?
    yeah, I'd be interested in that, too. So far I've found that I like (192 is a bit too low for me, and higher are overly saturated for me):

    ;Saturation of the unbloomed frame buffer. 0-255.
    ;(255 = full saturation, 0 = pure grayscale.)
    BaseSaturation=224 // or 208 (can't decide yet)

    best. But I don't like Boom too much in its current form, because as people had already mentioned here, only light sources should be bloomed ideally, not everything "above" certain color value. So until Bloom algorithm gets a bit more intelligent/realistic, I don't turn it on usually.

    If I were to use Bloom permanently, I'd use some low value, to keep the effect subtle. From my testing I've found I wouldn't set it to any higher than 32 (decimal) or 48 at the most. 64 is already a bit too much/strong for me.

    ;Bloom intensity. 0-255. (0 = disable all bloom processing.)
    Bloom=32 // or 48; 64 already a bit too high/strong for pertmanent use (for my tastes)

    And I haven't played with

    ;Bloom saturation. 0-255. (255 = full saturation, 0 = pure grayscale.)
    BloomSaturation=128

    yet.


    Maybe playing with this value (BloomThreshold) would help a bit (but I don't know how to set it to "catch" only mostly light sources i.e things which shoulld be bloomed, but not anything else):

    ;Colors below this will cause no bloom. 0xrrggbb.
    BloomThreshold=0x202020

    ====

    @jermi:

    is there any max value for MenuUpdateDelay setting? default is 14 (ms) (btw why is 14 the default?), it was a bit too fast for me, so I've set it to 22 for now, I've also tried 33, and it was too slow on my rig. Is there any (practical/theoretical) max value for MenuUpdateDelay? What about the ability to completely freeze the object rotation?
    Last edited by Hiatus; 14th Sep 2010 at 09:30.

  15. #1890
    Member
    Registered: Nov 2001
    Location: Sunny Finland
    Quote Originally Posted by Hiatus View Post
    Maybe DDFLIP_INTERVAL is broken in the driver I'm using
    It's a device capability, which the driver doesn't necessarily support. It's such a simple thing that I assumed no vendor can possibly have an excuse to not support it, but apparently I assumed too much.

    Quote Originally Posted by Hiatus View Post
    you didn't answer that (I assume it should work with both, but can't check/test it as it doesn't work at all for me )
    FlipInterval works with both DB and TB.

    Quote Originally Posted by Hiatus View Post
    ps for floats in ini one should use dots, not commas, (22.5 - not 22,5), correct?
    Yes.

    Quote Originally Posted by Hiatus View Post
    ps2 how exactly have you implemented TB in ddfix - using "page flipping" method (like in OpenGL) or "render ahead queue" technique (I'm just curious)?
    The implementation was as simple as setting dwBackBufferCount=2 for the primary surface. That's it. DX does the rest as Flip() is called for each frame. I suppose in Anandtech's Book of Terms it's "render ahead queue".

    Quote Originally Posted by Wille View Post
    Jermi is there something you can do to make Thief 1 & 2 like Fraps more?
    I think so. In the menu screens Flip() is never called so Fraps doesn't have a trigger to record frames. If that's the only problem, it doesn't sound too hard to fix.

    Quote Originally Posted by Wille View Post
    Also with all these new features I think the ini is getting very crowded. Maybe a new UI program for DDFix would be in order?
    GUIs are lame. I don't think the ini file is too bad (especially since a lot of the options don't even have to be there if you just use the defaults). But maybe that's because I've implemented all the new options myself and I know exactly what they do.

    And Timeslip was trying to keep the ini file simple ... I've destroyed his legacy!

  16. #1891
    Quote Originally Posted by jermi View Post
    It's a device capability, which the driver doesn't necessarily support. It's such a simple thing that I assumed no vendor can possibly have an excuse to not support it, but apparently I assumed too much.
    I've just checked my DXCapsViewer output log file, and there's no trace of DDFLIP_INTERVAL string there. Which string related to this cap should I look for there? Maybe it's named differently - or only DX10 (and up) hardware has it? Can you upload your own DXCapsViewer log file somewhere, for reference/comparison (which caps I'm missing etc)? Do you want me to upload my DXCapsViewer output log file (would you need it)?

    ps please reply to my other questions you haven't answered ..
    Last edited by Hiatus; 13th Sep 2010 at 14:50.

  17. #1892
    Here's a good setting for bloom if anyone wants it. It's fairly nice while still being noticeable except in a few fully bright areas so far. Heck, I can even see the clouds/blue sky in Training instead of a giant blob. I just ran through Training and Bafford's with it so far. You'll probably need to decrease your gamma afterwords.

    Code:
    [PostProcessing]
    
    ;Enable postprocessing. Boolean.
    Enable=1
    
    ;Include overlay in postprocessing. Boolean.
    Overlay=0
    
    ;Modulation for the unbloomed frame buffer. 0xrrggbb.
    Base=0xffffff
    
    ;Saturation of the unbloomed frame buffer. 0-255.
    ;(255 = full saturation, 0 = pure grayscale.)
    BaseSaturation=226
    
    ;Bloom intensity. 0-255. (0 = disable all bloom processing.)
    Bloom=92
    
    ;Gain from bloom level to the next. 0xrrggbb. (0x404040 = zero gain.)
    BloomPersistence=0x404040
    
    ;Bloom saturation. 0-255. (255 = full saturation, 0 = pure grayscale.)
    BloomSaturation=128
    
    ;A per-level zoom-in factor. Integer. (0 = no spread.)
    ;This makes the bloom spread out (positive values) or in (negative values).
    BloomSpread=64
    
    ;Colors below this will cause no bloom. 0xrrggbb.
    BloomThreshold=0x555555
    
    ;Trailing and afterimages. 0xaarrggbb. (0 = no trailing.)
    ;The rgb components modulate the trail color, while the alpha component governs 
    ;how much of the bloom from the last frame is blended into the current frame.
    BloomTrail=0x80ffffff
    If you want it to be even more subtle, try increasing BloomThreshold to 0x606060, 0x656565, etc.

  18. #1893
    Member
    Registered: Nov 2001
    Location: Sunny Finland
    Quote Originally Posted by Hiatus View Post
    I've just checked my DXCapsViewer output log file, and there's no trace of DDFLIP_INTERVAL string there. Which string related to this cap should I look for there?
    It's DDCAPS2_FLIPINTERVAL, but at least the caps viewer from 2004 DX SDK doesn't show dwCaps2 at all, only dwCaps.

  19. #1894
    Quote Originally Posted by jermi View Post
    It's DDCAPS2_FLIPINTERVAL, but at least the caps viewer from 2004 DX SDK doesn't show dwCaps2 at all, only dwCaps.
    no such string in my log, I have DXCapsViewer from 2009, not sure whether it displays dwCaps2 or not - how to check it?

    ===


    btw I've noticed a bug with ddfix (1.5.2 - possibly earlier versions, too) and your t2skies mod: water changes color (gets more and less "highlighted") depending on the angle you look at it, the said mod is installed (and only then - no such bug w/o t2skies installed). Here are screens from Framed: water is darker or ligher, with only a small mouse movement.

    1) "light" water

    http://www.imgplace.com/viewimg153/7...creenshot1.png

    2) now darker water:

    http://www.imgplace.com/viewimg153/2...creenshot2.png

    Change of water color (from "light" to "dark") is instantenous (like switch), not gradular.


    Are you aware of this issue/bug, and have any idea what might be the cause? I like your t2skies mod, and would like to use it w/o side-effects on game world like that (but, btw, I don't like the look of water from your t2water mod, I vastly prefer the look of vanilla water, to be honest. Are you still working on this mod, to improve water appearance maybe (yes, I know it's a matter of taste, primarily)?).

    ===

    @Dresden:

    what does BloomSpread exactly do: could you show its effects on a screenshot (positive, 0, negative)?
    Last edited by Hiatus; 15th Sep 2010 at 11:33.

  20. #1895
    BloomSpread is an RGB value that tells DDFix what colors to effect. As I understand it, at 0x009999 (read that as a RGB value of 00,99,99), only red will be effected. At 0x989898, only very white textures will be effected, etc. The higher the value, the brighter the shade that will be ignored. I don't think it can be negative.

    Using my above settings (BloomSpread 0x555555)-


    Changing Bloomspread to 0x202020 -


    The top of the right pillar in the second image becomes bloomed because it's white enough to be effected by the new BloomSpread setting.

    EDIT: Brain fart. I was actually writing about BloomThreshold.
    Last edited by Dresden; 15th Sep 2010 at 12:30.

  21. #1896
    Member
    Registered: Jun 2001
    Location: Moscow
    Jesus Christ, Thief has always appealed to me visually because it's dark, gloomy and overall has a realistic color pallete. And now people are seriously using cartoonish bloom with it. This is nonsense.

  22. #1897
    Member
    Registered: Mar 2001
    Location: Helsinki, Finland
    Quote Originally Posted by d'Spair View Post
    Jesus Christ, Thief has always appealed to me visually because it's dark, gloomy and overall has a realistic color pallete. And now people are seriously using cartoonish bloom with it. This is nonsense.
    I think bloom is more like a proof of concept than a useful feature. Some fan missions that use colorful textures and wider range of colored lighting may benefit from proper bloom settings. For example DrK's Rocksbourg 3 looks even more athmospheric with bloom whereas Thief 1 levels generally don't benefit from it.

  23. #1898
    Member
    Registered: Jul 2006
    Location: Moscow, Russia
    Quote Originally Posted by Dresden View Post
    0x989898, only very white textures will be effected, etc. The higher the value, the brighter the shade that will be ignored. I don't think it can be negative.
    "0x" means hexadecimal value, so the maximum is 0xFFFFFF.

    Some fan missions that use colorful textures and wider range of colored lighting may benefit from proper bloom settings
    Not as postprocessing. Any HDR effects should be applied only to light-emitting objects, and not to other well-lit textures like paper or skin. But the post-processing filter uses only a brightness or color value as a threshold, so it can't tell one from another. The only thing an FM author can do about that is to assign all light colors to light sources, leaving all other objects much darker, thus reducing the brightness dynamic range, which it right the opposite of what HDR was designed for.

  24. #1899
    Ooooh thanks DJ! I should have known.

    Jesus Christ, Thief has always appealed to me visually because it's dark, gloomy and overall has a realistic color pallete. And now people are seriously using cartoonish bloom with it. This is nonsense.
    Nvidia was the way it was meant to be played.

  25. #1900
    Dresden:

    thanks for the explanation and pics, but I asked about BloomSpread (how it works, what it does), and you went on to explain BloomThreshold, which I understand how it works etc. So please explain why you set BloomSpread to 64 (default in ini is 0)?

Page 76 of 98 FirstFirst ... 2631364146515661667172737475767778798081869196 ... LastLast

Tags for this Thread

Posting Permissions

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