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.

Many engines do exactly that.

http://gafferongames.com/game-physics/fix-your-timestep/

>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.

>Both get a little carried away, but the main melody is clear and pretty interesting.

In case it wasn't clear, "Death Waltz" is just a cover of "U.N. Owen Was Her?" from the Touhou games (as are many of the more popular black MIDI songs from what I've seen).

https://www.youtube.com/watch?v=SyC5eWJhCr8&list=PL_I1U99bY0...

Circus Galop was cool, though. That's the first original black MIDI piece I've enjoyed so far.

You can certainly have both types, but it's annoying and sad that the people whose jobs are to write about video games can't tell the difference between the two, and routinely write articles judging mechanically innovate games by their fluff.

The Souls franchise became popular solely because it dared to provide complicated mechanics and harsh trial-by-fire instruction in a time where the vast majority of AAA games are dumbed-down handholdy themepark rides with all of their edges filed off. The kind of people that play games only for their stories would never have suffered through any Souls games if it weren't for the massive hype that the "mechanical gamers" generated around it.

Likewise, Starcraft had a story, as did Command & Conquer. But one of those games is played to this day, both in its original incarnation and its sequel, on a massive scale that makes people question their definitions of the word "sport." I don't think this author would have cared to write filler about the story of Command & Conquer today.

He used Renderdoc, which lets you pick a frame apart draw call by draw call, inspect shader bytecode, etc.

https://github.com/baldurk/renderdoc

From part 3:

>Links

>The tech that built an empire: how Rockstar created the world of GTA 5 featuring an interview of Aaron Garbut. http://www.techradar.com/news/gaming/the-tech-that-built-an-...

>GTA V NVIDIA Performance Guide with details about the different graphics settings. http://www.geforce.com/whats-new/guides/grand-theft-auto-v-p...

>Renderdoc which made picking into GTA V internals a breeze. https://github.com/baldurk/renderdoc

Isn't trivializing their ideology a good thing?

No perceptible performance hit on a modern machine? Absolutely. I'm sure you can run 100 copies of Doom simultaneously in Javascript or whatever.

No perceptible performance hit on a 486? Somehow, I don't think that the 486 is an especially important target for the LLVM or Rust developers (though such chips are used in embedded applications to this day).

But the real reason that the comparison makes no sense is that the bulk of the processing time (but not the bulk of the code, mind you) is spent in those tightly optimized assembly loops. Either you keep it as such and it's not really much of a battle between C and Rust any more, or you rewrite the critical sections in Rust and you'd lose as hard or more as if you wrote them in C.

Thank you for not taking it that way. From-scratch recreations of games and renderers are always cool, and you're absolutely right to not obsess over the performance of a Doom level renderer in 2015. I just wanted to make it clear that this is not the right candidate for a "C vs. Rust" benchmark.

Original game:

An entire game, written mostly in C for a (comparatively) extremely primitive CPU with a similarly primitive compiler. Performs all rendering in software, with tightly optimized x86 assembly targeted towards said extremely out of date architecture, and was the absolute bleeding edge of what was possible when it was released. On top of that, DOS was the target, which meant that a fair part of the codebase is dedicated to what programmers today would think of as an operating system, from device drivers to interrupt handlers to memory managers.

This:

A level renderer with none of the game logic, written in a higher level language that, nonetheless, has access to a much, much more sophisticated compiler and target hardware than the original game had, that offloads most of the rendering to the GPU anyway, whose author was never once required to think about optimizing anything because any computer made in the last decade could render such scenes in its sleep a thousand times over without so much as a snore.

I'm not at all trying to poo-poo the author here, but there is no meaningful comparison you can draw from this.

That's not how I saw it, but in any case, it should be clear that the guy is not above lazy, sensationalist clickbait.

Jason "the Dragon's Crown Sorceress is a 'lolicon fantasy'" Schreier?

I hate to link to reddit (and KiA at that) but here you go: https://www.reddit.com/r/KotakuInAction/comments/2on4la/last...

As long as Disney is around, nothing will ever enter the public domain again.

That's what really pissed me off about this charade. It would have been the perfect opportunity to talk about how fucked up our school administrations and their "zero tolerance" policies are, and instead everyone wasted their time rehashing the same old arguments about race that we have every day, that everyone has already made up their minds about.

>It's just the incidences of slaughter they - perhaps optimistically given the US status quo - believe may be reduced through gun controls are actually happening on a not infrequent basis, whereas the Second Civil War scenarios are wildly unlikely fantasy.

That's a reasonable opinion, but one I disagree with. A second secession movement and full-blown Civil War will probably never happen, but martial law ordered in response to protest or active resistance of a law is not unthinkable. The risk of death by gun violence in the United States is dwarfed by the risk of death by automobile accident, heart disease, and so on. I would absolutely rather live in a country of ~320 million with a few thousand deaths per year due to gun violence, than in one with no weapons to deter martial law. I'll take a small (blown out of proportion by the media) threat over an existential threat any day.

And that's even assuming that you could make gun violence disappear entirely overnight. Revoking access to registered firearms could very well reduce the number of spree shootings, but would do little to affect the black market supply used by criminals in robberies and turf wars, and probably increase the amount of gun violence used in robberies (as criminals would then be sure that no one would be able to resist them).

That's another good bit of cognitive dissonance. I'd wager that many of these same people are aware of and support movements like #BlackLivesMatter, that use social media to spread awareness of instances of police brutality to massive audiences. Yet they never stop to consider how effective those same tactics could be in a theoretical armed resistance. Imagine someone recording a group of teenaged American rebels being slaughtered by the military, the media running with it and getting statements from the bereaved families, further polarizing would-be rebels while sparking dissent amongst the other side, growing lack of respect with the military, etc.

There's some weird cognitive dissonance going on where many of the people that love to point out that the US military can't possibly succeed against guerrilla combatants in the Middle East are the same people that laugh at "gun nuts" for "thinking their small arms would do anything against the military's tanks, artillery, airstrikes, etc."

The 6502 core in the 2A03 and 2A07 is the only I know of that had the BCD support removed, which reduced licensing fees as the BCD circuitry was the only patented part of the 6502. That's my guess as to the meaning of the ".7"