duzenko
-
Posts
4149 -
Joined
-
Last visited
-
Days Won
50
Posts posted by duzenko
-
-
6 hours ago, Abusimplea said:
Well, we all get older and our eyes can't read the fine prints anymore...
But 3 is still twice as large as what i would call small at 2160p on a 32" screen. So it probably is three to four times greater than small for the majority plaing at 1080p.So while the restriction is okay, it also has no reason to exist since 2010.
And even the most conservative standard should go for at most 4 (also since 2010).
The size is in relative screen units, so it will be the same physical size no matter the screen resolution. Quite few people have 32'' screens honestly.
I can see your point however there should be some protection from making the font too small so that user can no longer set it even back
-
1
-
-
2 hours ago, Abusimplea said:
Thank you!
As con_fontSize 1 (the lowest setting) isn't actually tiny, i suggest setting the standard value to the next higher value - which oddly is 4 (wonder, why 2 to 3 are just aliases for 1, while 5+ works fine).
It's capped to min of 3, which was deemed as "ought to be enough for anybody"
Related cvars are con_legacyFont, con_fontColor, r_smallCharSpacing, con_noWrap
-
1
-
-
18 hours ago, datiswous said:
Is there a benefit of putting the onboard graphics on the secondary monitor instead of using the external gpu for both?
The only reason could be port incompatibility between monitor and video card.
-
Where is USE_INTRINSICS defined? I can't see it anywhere in .h files or solution settings
It seems to be defined somehow for the tools project but not for the no-tools one
-
8 hours ago, datiswous said:
It was not about zombies, it was about melee combat. All that skull-crashing bone-breaking pulp-mashing RAGE!11 if you know what I mean
Oh, well, I suppose you did not experience that suppressed frustration thing like I did at the time when the game was released.
-
The starting location seems to need some optimization.
-
- Conversation subtitles: at some points two phrases overlap and jump over
- Depth fighting
3. This GUI could use some margin on the right
Spoiler
SpoilerHow do I progress after I'm tasked to get the railway codes? I found a grate door but no idea how to open it without cheating
-
21 hours ago, lowenz said:
the same happens @1280x720, the "right" resolution @which you can play the game with the UHD 750 - with integer upscaling to 2560x1440
->
I wondered if Intel got their shit together with that new chip. Apparently not (as expected).
Their "market targeting" is utter nonsense. They put 96EU into 25W or even 15W chips and the 125+W chips only include 32/24/16 EUs.
-
While I can't offer any wisdom on Apple ecosystem, assuming we're talking about the same person you've recently had a son with, I'd play it safe and just go with the one they want - and speak up my opinion on the matter one time only at the most. I'd think your son would agree with me when he can speak.
-
1
-
1
-
-
2 hours ago, stgatilov said:
I simply wanted to understand: how does projection and falloff texture influence the old fog lights, and what is the desired behavior (if it is different) ?
But nobody has answered any of these questions yet.
Currently I have no idea how the new volumetric-based fog relates to old fog lights in terms of textures
Let's first decide where we are and what we want, and then discuss how to achieve that
LOL the fog lights are the worst
I converted them from texgens to GLSL, and in the process I realized I don't want to spend any time on analyzing the math behind it. Feel free to dump the generated fog texture to a .tga and try to make something off it. I think mappers never liked it too.
I suspect (!) that whatever implementation D3 had was a compromise they had to settle on because they were limited with texgens. I want to think about it as a rudiment, that we're better off without.
And we'll save on draw calls too.
Talking about desired behavior, I'd love the fog to account for diffuse texture alpha. This way we'd be able to fog translucent objects properly.
-
2 hours ago, stgatilov said:
Mmm... I imagine "fog light" is a special kind of light, which does not light any surfaces, but instead applies some "fogging" on everything.
With the recent change, one can switch implementation of "fog light" to exactly the same code as in volumetric lights but setting "volumetric_*" spawnargs.
It is clear that shadows are ignored in this case because they are never generated for a fog light anyway.
What is no clear however: what about projection and falloff textures?
What is the meaning of these textures for a fog light?
Is this meaning correctly handled by the volumetric implementation?With the way @duzenko did it, shader just takes average texel color of each texture, and multiplies output color on both of the averages.
What it does now is not ideal of course
Initially I tried to revise "new fog" path in fog.fs but quickly realized we already have a superior solution in volumetric
We might want to copy-paste it into the fog shader and further tweak it there
-
15 hours ago, SeriousToni said:
First, thank you very much for your help.
But I think I don't quite understand, I'm sorry! I need to use this exe for the new fog but what happens if my mission gets released later on?Should be in the next beta. The exe is for quick feedback.
-
1
-
-
14 hours ago, SeriousToni said:
@duzenko Wow! This is creating a perfect fog with no seem! It works like a charm!
Thanks, I'm sure there's going to be at least some issues with it.
Credits due to stgatilov, his work in the volumetric shader isIused here. Perfect on first try is not my style, lol
-
1
-
-
Try this exe
with this fog light
{ "classname" "light" "name" "light_fog1" "_color" "0.114 0.082 0.063" "light_center" "0 0 0" "light_radius" "496 400 64" "nodiffuse" "0" "noshadows" "0" "nospecular" "0" "origin" "432 696 -184" "parallel" "0" "shaderParm3 " "800" "texture" "fogs/delta1_fog" "volumetric_light" "1" "volumetric_noshadows" "1" "volumetric_dust" "0.0001" }Use volumetric_dust to control fog density
It still gives noticeable banding though, especially with postprocessing and 32 bit color
Regret your test map is missing a lot of brushes and materials, is mostly black for me
-
18 hours ago, SeriousToni said:
I already extended the range beyond the walls. However that's not the problem. Problem is, when you go upstairs, before crossing the border of the fog light, it looks like a water surface. This doesn't seem to apply if you use a very bright light source after the border (which may be in your case), but this doesn't help me much, since I need this area to be dark for gameplay reasons.
I'll send you a PM. Thank you very much for having a look. We should not stop the conversation here and update this thread still, for everyone else who might come into the same situation in the future.
EDIT: Even with the spawnarg "noFogBoundary 1" the effect is not completely gone. It gets rid of the "water surface", however the brushes above the fog boundary are now clearly darker than the ones within.
Do you prefer control over fog via light material keywords or spawnargs?
-
The math behind the Doom3 fog frankly makes little sense
Ideally we should tweak the fog shader so that it's not giving seams, etc
Do you have a test map with the that bug for me to look at?
-
1 hour ago, SeriousToni said:
In version #9648 I tried to follow the wiki and insert my first volumetric light. However I can't see any difference in game. I set it up with the volumetric_light = 1. After seeing no difference, I added the additional spawnargs and even created a new light as a spot instead of omnidirectional.
In my game settings I have got shadow maps enabled (not stencil). The console command r_volumetricSamples is unknown to the game however.
I just see a normal light. Even after a whole new dmap.
Your best map would be to attach a test map
-
1
-
-
2 hours ago, stgatilov said:
I think the main reason is that internally there is huge difference between the two modes (Uncapped FPS: yes or no).
Up to the point that "Uncapped FPS" mode has been considered experimental for many releases.
I don't remember when we last had a problem with it, but we always wanted to have a way to switch it off, and doing so on "Max FPS = 60" is almost the same as not providing any way to configure it in the main menu at all.Another thing is that "Max FPS" was not intended to exist initially, uncapped FPS should just work as fast as it can.
But then we noticed that high FPS causes issues (e.g. some sounds disappearing), and we did not manage to fix it properly. We just put a "sane" limit of 166 FPS, since that felt the safest way.
Then came people with high-frequency monitors, and they wanted to change this limit to a bit higher that their monitor frequency. At the end someone decided it is important enough for everyone and added it to menu settings.It seems to me that people with high-frequency monitors can live well with both Uncapped FPS and V-sync on, without the need to tweak the FPS limit which was never intended to be visible to end user. If yes, then we can remove "Max FPS" from the menu.
I'd remove the fixed tic option completely
Vsync + fps limit should cover all possible situations
-
26 minutes ago, HMart said:
Sorry if I came a little obtuse It was not my intention but at lest made you guys discuss the subject. ;D
Same from me
Quote"Fps limit only works with vsync off"
Is that a general fact or only a TDM (idtech 4) fact? I have games where I have both on and they seem to not conflict, but perhaps those games just disable one or the other behind the scenes?
TDM only of course, last time I checked it was like this
Quote" it excludes everything except 60Hz monitors"
Like I said it was just a suggestion, not trying to exclude high-frequency monitors, specially because I have one!
A 165hz FreeSync monitor.
And wouldn't people be able to set their own frequency? Also honest question, can't you detect in the engine code at what frequency player monitor is at and set accordingly?
No idea how it works with freesync, never had one
-
20 hours ago, HMart said:
IMO uncap fps in the menu feels totally redundant and something the player shouldn't even need to set manually. I ask, why not have, set max fps only, with default at 60 and if you then set a Max FPS above 60, the engine automatically uncaps the fps? IMO sounds more logical and user friendly that way, just my two cents.
Sounds like you're opening an opinion discussion
Fps limit only works with vsync off. So with vsync on, you're basically forbidding free tics. Not only it excludes everything except 60Hz monitors, you'd also cause microstuttering due to monitor-cpu 60-herz sync-up.
-
Ok, i think i get it now
Better late than never
-
13 minutes ago, stgatilov said:
Technically, no light source should be allowed to light anything outside its light volume, because of the conflict with frontend culling/scissoring/triangle filtering.
Ordinary lights are no exception. I don't really see why projected lights should be special here.But light texture coordinate transformation does not mean anything will be lit outside of the volume. The texture could be e.g. a sinusoid.
At least for ambient lights
-
1 hour ago, stgatilov said:
There is projection texture and falloff texture.
For projection texture, mapper can/should set zeroClamp and the problem of going outside frustum by U or V won't happen.
For falloff texture, mapper has no control over its clamping, it is just "clamp" right now. I guess the end values of falloff are not zero, because I see excessive lighting on test map due to falloff texture.Can we reliably do texture projection in vertex shader? I'd think that any perspective division can only happen in fragment shader
Maybe zeroclamp on projection lights only?
-
31 minutes ago, Dragofer said:
The security camera required that fix to two-sidedness and also to proper falloff. The spotlight now works perfectly in both those regards.
Wasn't the two-sided thing and falloff the same issue?
Beta testing 2.10
in The Dark Mod
Posted
I get a crash in driver with the reported .cfg (but not with mine)
The breaking difference seems to be
r_glCoreProfile 0 vs 2 andnew backend 0 vs 1_Darkmod.cfg