But the pop in system doesn't relate to this at all. Peekers advantage still exists with this system on or off in exactly the same way, and both players will see exactly what they would have seen previously without the culling system
It isn't an unsolvable problem though, there's only jitter because the implementation isn't very good
Implementing a more conservative anti wallhack cheat where player positions start streaming in slightly earlier still significantly cuts down on the efficacy of wallhacking, while entirely avoiding the jitter problem. Characters in CSGO move at a fixed speed, so you can calculate exactly how many ticks in advance you need to start sending that data in, before they will become visible to another client around a corner - and add a margin
There's also no excuse for sending player positions through a smoke for example - the server should be performing visibility culling
With the two combined you could cut the utility of wallhacks by 80%, in a way that would be completely unnoticeable. The real reason that this has never happened is that valve's investment into anticheat has always been pretty minimal compared to what's necessary for it to be effective (VAC has generally been the least effective anticheat). They're a small company which largely develops steam as a platform, not VAC or anticheat solutions for games
I'm glad someone's calling this out for what it is. These twitter influences are professional horseshit mongers that pretend to be acting in good faith, but flip what they're saying 180 degrees to fit whatever will drive maximum engagement in the moment. Its something that tends to slide by unless you stop and actually try to reconcile all the disparate things that someone has said, at which point you realise literally none of it makes any sense
Also, it seems like almost nobody here has actually read the entire article: the whole point of this is dissecting whether or not the author of odin truly believes what they are saying, which it seems like they don't
>Say what you want about EA, but they not only tolerated Open RA
They also don't have a choice though. There's nothing illegal or actionable about OpenRA. At most EA could have potentially forced them not to refer to CnC on the github, but even then its not clear that that's enforceable
The incredible laggyness of that website does not inspire confidence. Much of the text selection is also broken, and chrome consumes nearly a full core trying to render.. something?
Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes
I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record
>if 60% of the pixels within a region on a higher dpi display would be lit, then that is best approximated* by a single pixel emitting the same number of photons as those pixels would (which is 60% as many photons as there should be in the situation where all pixels on the higher dpi display would be lit).
This assumes that the output from the coverage process represents a semi transparent line with a light shining through it, which isn't what font rendering outputs. It outputs a perceptual brightness, because if a cell is 50% covered, we want it to be 50% dark. Not emitting 50% of the photons
>Whatever color space you do your blending in, 40% black onto white should look the same as 60% white onto black.
What you want is 40% black onto white to have a similar difference in intensity as 40% white onto black, otherwise your darkmode font will look significantly different at the same intensity as your lightmode font. This is why it doesn't make sense to do it in a linear colourspace
Note that the wikipedia article is wrong, given that photoshop uses a nontrivial gamma exponent
>When antialiasing, I think you do want to model light: a fully black object occluding 40% of a pixel should cause it to emit 40% less light. Linear intensity representations of colour should therefore be used.
The antialiasing value you get represents how much the pixel is covered by the glyph in question, and directly represents a desired change in perceptual brightness. There's no physical underlying lighting process, so it doesn't make sense to use physical light units
Blending in linear RGB models different strength lights being mixed together. This is why you do want to blend images together in linear RGB, but not fonts - because its not an underlying light based transport process
To take a direct example: Imagine two cases
1. We blend a white font on a black background
2. We blend a black font on a white background
Using perceptual blending, the antialiasing will be exactly the same efficacy in both cases. Using blending in linear space, these two test cases will look very different and render incorrectly!
This article contains some pretty major errors, which is kind of surprising to see!
>The transformation used to represent the physically linear intensity data either generated synthetically via an algorithm or captured by a linear device (such as a CMOS of a digital camera or a scanner) with the discrete values of the perceptually linear scale is called gamma encoding.
This isn't super correct, and it underscores the biggest issue in this article:
sRGB (and its gamma encoding function) has absolutely nothing to do with perceptual linearity. sRGB is not perceptually linear! The original gamma encoding as far as I'm aware was made to compensate for the nonlinear transfer function of CRTs back in ye olde days. Its true that human vision is nonlinear, but sRGB is not a particularly good match to the perceptual linearity of human vision. Its a really common error to make, and leads to people wondering why we can't use sRGB to blend in if the reason why it was invented is because its perceptually linear
The article goes to compound on this mistake, which is why this is such a problematic misconception:
> Interestingly, Photoshop antialiases text using γ=1.42 by default, and this indeed seems to yield the best looking results (middle image). The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should.
This is where the mistakes start to add up
Consider what you're trying to achieve during antialiasing: when rasterising a line, lets say we discover that a pixel is only 40% covered and want to darken it. This means that we want our pixel's brightness to decrease by 40% to a human being. We don't want to emit 40% less light, because that's not what antialiasing is trying to achieve!
Both sRGB and linear colour are the wrong colour spaces to use. You want to blend in a perceptually linear colourspace, and photoshop's 1.42 gamma exponent probably maps better to human vision than 2.2 or 1.0 while being cheaper than a LUV conversion
>The standard gamma (γ) value to use in computer display systems is 2.2. The main reason for this is because a gamma of 2.2 approximately matches the power law sensitivity of human vision
The gamma transfer functions are also wrong. Its worth getting hung up on because it actually causes nontrivial errors, especially in the age of hardware accelerated sRGB conversions where doing it correctly is free
I've been programming in OpenCL for 10+ years. This article is clearly AI generated, and its also completely wrong
OpenCL did not fragment into a mess of vendor specific extensions. I don't know where that even comes from, the extensions in the 1.1/1.2 days were very minimal. The story goes like this:
1. OpenCL 1.2 turned up. This was the first really viable version of OpenCL, although 1.1 was usable. It started to gain a fair bit of traction
2. As OpenCL increasingly started to eat at Nvidia's cuda dominance, Nvidia deliberately killed OpenCL support by neglecting it. There literally did 0 technical development on it for years, with long running critical bugs remaining unfixed
3. At some point, OpenCL started to gain prominence in machine vision stuff in the embedded world, especially for cars and that space. Nvidia's poor OpenCL support became a liability, and so they heavily invested in OpenCL, fixed all the old bugs, and implemented OpenCL 3.0 support
4. Apple dropped OpenCL support because their anti competitive market strategy is vendor lock in, so a cross platform cross vendor API is bad for them. There's some kind of long running legal clusterfuck going on between Apple, and Khronos, the details of which are not public
5. AMD's OpenCL support was absolutely great. A+_best in class, would recommend. It had a fair bit of buggyness/jankyness, but it was an order of magnitude better than Nvidia's support back when Nvidia was deliberately hamstringing it. Then they started developing ROCm
6. Around this time, Vulkan was standardised. Khronos had been considering merging OpenCL into vulkan to force vendors to support it properly, but this was killed. Instead, we got the absolutely insane OpenCL-specific SPIRV format that nobody has ever used for anything
7. With the advent of ROCm, AMD abandoned OpenCL. They swapped over their good OpenCL compiler, to a new compiler that is much shitter and still has way worse performance. OpenCL is now badly implemented on top of ROCm, but some of it is so buggy its clear that nobody has ever used it. They refuse to implement 3.0 support, even though Nvidia supports it
8. The tables have turned: AMDs GPU compute support sucks donkeyballs, and Nvidia is lightyears ahead of them
OpenCL is not a story of fragmentation. Its a story of how vendors deliberately independently set out to kill it, along with AMD's incompetence, and Khronos making several boneheaded decisions during its standardisation that lead to it being cut off at the knees
Despite this, OpenCL 1.2 is still by far the best cross platform cross vendor GPU Compute API, because it is the only one that exists. Vulkan still doesn't support everything you need. Its a nightmare all around
AMD's entire software development strategy is insane. OpenCL was doing reasonably well, and then AMD have just fully dropped support for some reason. For the - albeit not huge - but actual cross platform API that people were using to develop for their GPUs. For a while, a few cross platform tools had OpenCL backends, but nobody has been able to get AMD to fix any of the damn bugs. In my testing, bug latency for even the most trivial but important bugfixes is often 4+ years, which is utterly mad. Some parts of their compute stack is so broken its clear that nobody has ever used it. There are exploitable privilege escalation vulnerabilities caused by threaded race conditions that are wontfix
They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most
Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?
Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money
As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point