lispit

I guess the flip side of "don't contribute to a project unless you are intrinsically interested in it" is "don't contribute to a project you aren't interested in unless you are capable of significantly helping it."

Someone inexperienced but strongly interested in a project can be taught to be useful. And a knowledgeable resume-padder can very well spearhead useful changes. But if you are both uninterested in the project and incapable of helping it, you're more likely to hurt the project than help it. And, sorry to say, but if you don't know where to help, then you're most likely on the "not imminently useful" side and should be looking for things you're legitimately passionate about instead of wasting peoples' time.

EDIT: Does anyone remember an article or comment from a few weeks ago about how many open source projects tend to lose their focus and become more about justifying the existence of a social group than achieving a goal? It seems kinda relevant to me.

Both the Z80 and the 68000 were launched in the 70s.

>Tying simulation to framerate is often the best choice, when you consider that most hardware is average, it minimizes latency for the average user, and results with a more accurate simulation

It can be, if you either are on a fixed hardware platform or have both modest demands and a framelimiter in place to keep things from going off the rails. But in return you pay with a great source of nondeterminism that can cause maddening bugs, break replays, and hinder synchronization in networked games.

>so long as people keep vsync on (why do you need framerate greater than your monitor's refresh rate anyway...)

Two things going on here. Vsync is theoretically a great idea (that worked perfectly in practice on countless simpler platforms in the past), but due to driver flaws and the realities of preemptive multitasking introduces a noticeable additional frame or two of latency on every PC I've used in the past decade or so, whether playing a game or just using regular desktop applications. My guess is that the OS scheduler isn't precise enough to keep applications from barely missing a present deadline (thus causing unnecessary stuttering), so driver devs force triple buffering when vsync is enabled to compensate, giving you a smooth but unresponsive presentation. It really sucks that I have to toggle desktop composition (and thus, vsync) on and off to fix stuttering in one application or tearing in another, but somewhere in the Lovecraftian horror that is Windows, someone screwed up.

The other is "why do you need framerate greater than your monitor's refresh rate anyway," and the answer is "to provide the lowest latency and smoothest presentation possible within the constraints of a preemptive multitasking OS." In a perfect world, a game would know exactly how long it would take to simulate and render a frame, and would wait as long as possible before doing so, so that the most up-to-date input from the keyboard, mouse, and network could be used to display a frame with the least amount of latency factored into it to the player. This is not a perfect world, but you can get a similar effect (at a greater CPU and GPU cost) by rendering multiple superfluous frames, so that whichever one happens to be presented is much closer to the ideal than the one you'd see if you rendered the frame at the start of the 16ms then yielded for the rest of it.

This is part of why you often see "pro e-sports" types turning the graphics settings down to comical levels, by the way. Not only to lessen the threat of a completely missed frame due to a spike in visual complexity, but also so that they can run their game with the framelimiter off.

>Physics are always tied to framerate. There is not a game physics library in wide use that is independent of update rate. In practice what usually happens is that the physics library has an internal tick rate (say every 1ms or every 2ms) and every frame N physics ticks occur to catch up. Without this, the physics sim would be dangerously unstable (and in practice, it still is).

This is called a fixed timestep, and is not what people mean when they say "physics is tied to the framerate", referring to the rendering framerate and generally instead meaning that you pass the actual delta time elapsed between rendering frames into the physics simulation, which can cause bugs at extremely high or low framerates. I have no idea if FO4 works this way, but many engines do (even if it is usually a bad idea), so it's not completely outside the realm of possibility.

This is a valid question, not sure why you're being downvoted.

  How to Pick a Meditation App (well.blogs.nytimes.com)
  13 points by delambo 1 hour ago
  user: delambo
  about: My real-name HN handle. Web developer at The New York Times. @delambro

I think I get it.

>That too was known for ages, and still no light changing apps for it like flux

How is Joseph Programmer von Notasleepscientist supposed to know that a blue-light dimming filter is something that he might want before he sees the effect in action? I'll give some credit to f.lux for popularizing the idea, but once the idea is out there, there are only two ways you can implement it: postprocessing in software, or postprocessing in the CLUT. You wouldn't need to know anything about how f.lux works to come up with one of them yourself, once you are aware of the idea.

I could kinda see your point of view in your other posts ITT (though I disagree), but what? The entire point of this discussion is that their patent application is discouraging other people from creating "competitors" (if you can call them that).

How else would you reduce the amount of blue light emitted by a monitor using a CLUT except by changing it to reduce the amount of blue light emitted?

I said "obvious and trivial thing to do once you know that blue light affects melatonin production." In the past people did other hacks with CLUTs (like some early 3D games baking gamma correction into the CLUT so that proper linear lighting could be displayed without an expensive postprocessing pass). If you were aware of the blue light effect (I'm not a sleep scientist, I don't know how long they've been aware of it) and had some low-level graphics programming knowledge, I don't think it would require great leaps to come up with this solution. It's just that no one else was interested in or aware of this problem.

Regardless of whether it was obvious or not, I hate the idea of extremely simple solutions being locked up behind patents, keeping the world today worse for the sake of hypothetical future innovations. It seems especially scummy the way they're trumpeting over social media about the harm that blue light causes while quietly trying to profit over an extremely simple solution to it. More than likely they know that Apple will never allow this on their app store because of the potential for abuse the necessary APIs would provide, and their end game is hoping the angry mobs will convince Apple to implement this as an official feature (and thus, pay them royalties). And more than likely, Apple would have implemented this years ago, had f.lux been an open source student research program with no patent applications attached.

Monitors are not perfectly calibrated, so if you send one a raw sRBG image, the result will look subtly wrong. To fix this we have monitor profiles (mappings from sRGB colors to the values needed to accurately display said colors on a particular monitor) and CLUTs (color look-up table, a table that the graphics chipset uses to perform said transformation on the fly as it synthesizes the video signal. It was implemented in analog video signals with RAMDACs, now with digital signals we don't need the "DAC" part, but you get the idea).

What f.lux does is (ab)use the CLUT to change the color temperature of the video signal sent to your monitor, cheaply and without requiring any modification to existing software. This is great if you trust f.lux, however clearly Apple cannot trust random apps with persistent access to the CLUT, because people could use it to do things like, say, completely blacken the screen.

It's the "patent pending" part that sucks. They're trying to patent the idea of changing your video card's CLUT (color look-up table) to reduce eye strain, which is a fairly obvious and trivial thing to do once you know that blue light affects melatonin production.