TRAA basically works by using a history buffer, for example using the last couple of frames, all jittered a little bit to compute the pixel. There's still ghosting and smearing that can happen though because of this technique, so you have methods to counteract like subpixel correction where u increase temporal alpha when velocity is subpixel, but that can introduce some artifacts as well.
There's also SMAA T2x which the pmndrs team is planning on integrating into their postprocessing package[0]. This cryengine3 slideshow gives a nice overview of antialiasing methods if you're interested: http://iryoku.com/aacourse/downloads/13-Anti-Aliasing-Method...
The only thing even remotely related to graphics I found was references to "TrAA" in forum posts from 2006 (yeah) where I believe they referred to NVIDIA "Transparency AA" or something like that. "TRAA", "TRAA meaning", "TRAA graphics", "TRAA 3D" all gave fully irrelevant results :D
If you make the assumption that "AA" is some form of antialiasing, it's not too bad: first scholar[1] hit expands the acronym to Temporal Reprojection Anti-Aliasing
Generators are a subset of coroutines that only yield data in one direction. Full coroutines can also receive more input from the caller at every yield point.
I just don’t agree that it always becomes a state machine hell. I even did this in C++03 code before lambdas. And honestly, because it was easy to write careless spaghetti code, it required a lot more upfront thought into code organization than just creating lambdas willy-nilly. The resulting code is verbose, but then again C++ itself is a fairly verbose language.
C++ destructors and exception safety will likely wreak havoc with any "simple" assembly/longjmp-based solution, unless severely constraining what types you can use within the coroutines.
Not really. I've done it years ago. The one restriction for code inside the coroutine is that it mustn't catch (...). You solve destruction by distinguishing whether a couroutine is paused in the middle of execution or if it finished running. When the coroutine is about to be destructed you run it one last time and throw a special exception, triggering destruction of all RAII objects, which you catch at the coroutine entry point.
Passing uncaught exceptions from the coroutine up to the caller is also pretty easy, because it's all synchronous. You just need to wrap it so it can safely travel across the gap. You can restrict the exception types however you want. I chose to support only subclasses of std::exception and handle anything else as an unknown exception.
> Passing uncaught exceptions from the coroutine up to the caller is also pretty easy, because it's all synchronous. You just need to wrap it so it can safely travel across the gap
This is also how dotnet handles it, and you can choose whether to rethrow at the caller site, inspect the exception manually, or run a continuation on exception.
You could use the same trick used by glibc to implement unstoppable exceptions for POSIX cancellation: the exception rethrows itself from its destructor.
The reason why the release cadence of apps about AI has increased presumably reflects the simple facts that
a) there are likely many more active, eager contributors all of a sudden, and
b) there's suddenly a huge amount of new papers published every week about algorithms and techniques that said contributors then eagerly implement (usually of dubious benefit).
More cynically, one might also hypothesize that
c) code quality has dropped, so more frequent releases are required to fix broken programs.
Limiting the drawing distance and rendering as little geometry as possible is absolutely still a thing, devs just can afford to hide it better these days. The golden rule of graphics programming has always been "cheat as much as you can get away with, and then a bit more".
Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the rebase is completed, git moves mybranch to point to the new (detached) HEAD.) Which makes "ours" and "theirs" exactly the opposite of what the user expects.
It will checkout origin/master and replay the current branch on top.
P.S. I had to check the man page as I use Magit. In the latter I tap r, then u. In magit my upstream is usually the main trunk. You can also tap e instead of u to choose the base branch.
I have met more than one person who would doggedly tolerate rebase, not even using rerere, instead of doing a simple ‘git merge --no-ff’ to one-shot it, not understanding that rebase touches every commit in the diff between main and not simply the latest change on HEAD.
Not a problem if you are a purist on linear history.
reply