Researchers Investigating Self-Boosting Vaccines
"...contrary to opinions from the anti-science crowd, "
Any article that begins with a put-down of a generalized segment of the population in my opinion is already tainted with bias. I'll look elsewhere for reliable information, thanks.
The article is "tained with bias", but only because just calling them anti-science is too damn generous. They're an anti-science child-killing cult. Just because someone has an extremely negative opinion of X doesn't automatically mean they're biased. You need to educate yourself on the matter before you can make the judgement. You might find the opinion is deserved.
Belief In Hell Predicts a Country's Crime Rates Better Than Other Factors
if you can affect A, but not B, and A is correlated with B, then you can affect B, [...]
I can change the time on my watch, but I can't change the actual time. The time on my watch is correlated with the actual time. Therefore, I can travel through time by setting my watch.
Ask Slashdot: What's Your Take On HTTPS Snooping?
Yea um, cisco doesnt make devices that do this. Google it.
Why would he have to Google it? There's a link to just such a device in this story. In fact, it's kind of what the article is about...
Why the GPL Licensing Cops Are the Good Guys
The law against murder CONTROLS what people can do with guns. Just admit that you believe in CONTROLLING people in the name of achieving a RESULT you like. If that's your position, I have no problem with it, but it's hypocritical to posture as an advocate of giving people complete freedom and believing that restrictions are wrong, and then try to defend yourself when I point a gun at you.
Database and IP Records Tie Election Fraud To Canada's Ruling Conservatives
The problem with political discourse in the US is that people always have to be on a team and can't think objectively like you just did.
No, the real problem with political discourse in the US is that too many people think what you think here, and they are too susceptible to confirmation bias. So complete scumbags can get away with enacting a policy for partisan political gain, as long as they accuse the other party's opposition to their policy as being for partisan political gain. By doing so, the provide a narrative that fits your preconceptions about how politics works and brings both sides down to the same level, so it's a stalemate. This cripples independent-minded voters' ability to punish bad behavior and the partisans can then win elections using their loyalists.
A photo ID requirement is not the only voting change the Republicans are pushing for. They've also been removing early voting and the ability to register to vote and vote on the same day. They're also trying to suppress voter registration drives by making regulations that are tough to adhere to perfectly and they are criminalizing violations of the regulations. See here.
It's all voter suppression. If the kind of Republicans we have in government right now learned of a genuine voter fraud problem, they'd first calculate whether it benefits or hurts them before deciding to do anything.
Next-Gen Game Consoles Still Years Off
In a sequential processing system, polling cannot begin until the last event has been fully processed. Which means that if you have a button that does something really complicated, NO other button can work until that process is complete.
None of the buttons do anything even slightly complicated. They just update some state data that will be used by the game loop. I explained this already, but you were too arrogant to pay attention.
In a threaded system, with CORRECT design, one event produces one interrupt produces one thread. That thread lasts the lifetime of that process, then dies. Thus, there isn't a thread per button, there's a thread per active event.
So more like a thread per button press, which lives until the action performed by the button press is done? As I said, all you need to do is update some state. That task can be completed in less time than it would take to create a thread to do the work. So I assume you must mean, for example, that if I press a button to throw a grenade, the game should spawn a thread to move the grenade through its trajectory, calculating collisions, exploding, and then the thread should terminate. That wouldn't be efficient, and it's not how games are programmed.
You seem to think that execution of game logic for events spans multiple frames. Games don't work that way. Such a thread could waste CPU time by updating its state more than once per rendered frame, or if it didn't get CPU time it might not run at all that frame, leading to glitches (not moving, not triggering a response to something, etc). To solve those problems, you'd have to make the routine's execution block after an update to wait for a frame to render. And at the same time, your render would have to block until all tasks have run so that everything runs exactly once.
And then congratulations, you've built a list of tasks and executed them once per frame. Which is what games actually do. But your method is convoluted and inefficient. Real games implement handler functions that do one frame worth of processing and then return. They execute each handler once per frame, and then render graphics.
You generally do not let threads run freely, updating the game state while you're trying to render. You can implement concurrency between rendering and execution, where you render one frame and process physics and logic for the next at the same time, but that's still calling each handler once per frame.
The only common exception is AI. Since it both sees and directs the game world at a high level, it doesn't require as much consistency. And it also does some things that might take a while, so you might actually need to run a task in its own thread over a period that spans several frames.
Event-driven designs almost invariably use this design because you get a flat latency (ie: you're not waiting for something else to finish, which will take a non-deterministic amount of time).
You can't just create additional processor resources by spawning a thread. Whether you have a thread per task, or you put them in a task queue, you're going to share time with the other tasks in some way. Either by letting everyone ahead of you go first, or by having every active task take turns round-robin until all are done. But the policy doesn't matter here, because you have to wait for all the tasks to complete before rendering the frame. So just use one of these.
My definition of real-time is indeed correct. The "short and bounded time" description of yours is the effect of guaranteeing N amount of runtime in M amount of wall-clock time (the time has to be bounded, as N cannot exceed M, and because latency has to be extremely tiny, M is classically small making N classically small.) Real-time means Extremely And Utterly Predictable, my definition says how that is achieved in real-time systems, your joke of a definition describes the consequences once it is achieved.
Excuse me? My definition is a "joke"? Yours was "there is a fixed relationship between CPU time and wall-clock time", and you didn't even define "CPU time". All I can infer from this is you're saying the CPU meets a certain guaranteed minimum performance. Sorry, but that misses the most important point about real-time: that you need to use good algorithms. You'll normally need to use O(1) algorithms for critical tasks, or otherwise limit your n. You can't just throw hardware at the problem. If you have an "Extremely And Utterly Predictable" CPU, but your scheduler is O(n^2), then you can't maintain real-time performance under load.
Clearly, you have not looked at any source code since no modern game will use polling. I suggest you try again.
If you've looked at source code, then cite some. I'll certainly cite code. For example, Open Arena. Look at engine/code/sdl/sdl_input.c, in the function IN_Frame(). This is called once per frame. (If you don't believe me, check the main loop in engine/code/sys/sys_main.c). IN_Frame() calls IN_ProcessEvents(), which gobbles up all pending input events using 'while(SDL_PollEvent(&e))'. After getting all the input events, the game loop calls Com_Frame(), which does game logic, then renders. Just like I said. I've now cited source. Your turn. Show me something that works the way you claim.
RASDIT is known to any - and I mean ANY - person who has even got as far as 1st year Comp Sci or Software Engineering.
Funny, because I have my degree and have never heard of it.
If you need to google it, you're not qualified to tell those of us who are professionals how we operate or how we define things.
I absolutely am qualified to tell you not to make up words and then act superior to anyone who's never heard of your made-up nonsense.
And you can't have googled very well, I found the definition from various university papers from the UK, US and Oz.
Prove it. Give links. I looked at all the search results for "RASDIT" (in quotes, so it won't return irrelevant results like "rasd it", and filtered for English). On page 8 Google tells me that the rest of the 406 results are mostly just duplicated content omitted for my convenience. So either you're calling this thing by the wrong name, or you made it up wholesale. I'm leaning toward the latter at this point.
You've never seen split-screen games with different framerates? You probably have, just not in the trivial sense. Try again. The level of changing detail (static detail is immaterial) on the screen has to be different enough for you to measure the difference, and judging by eye will be impossible so you should put the action onto disk and then run through it with an editor. Tell me then that the two players run at exactly the same rate. (No, an FPS counter isn't enough. it's trivial for games to reduce detail to increase FPS, so you actually have to go onto the screens and =measure= the level of change per user.)
I'm talking about the frame rate, and you start talking about the player walking speeds being different. They won't differ, but that's beside the point. Go ahead and rip this video and look at it in a video editor (such as avidemux). Starting at around frame 2212 (01:13.937), there's a lot of slowdown. The framerate drops below 30, so you can see multiple frames where the screen hasn't updated. Step through them and you'll notice that both players' screens always update in unison. If the players and their screens were handled by independent threads, you'd be able to see them updating at independent times when the framerate gets this low.
But games don't work like that. The split-screen multiplayer pretty much functions exactly like the single player, except that it accepts input from more controllers, and renders more views. The game still has one single game state, and it renders all views from that one consistent state, updating all screens together. If you want to prove otherwise, cite some source or post a video, like I have.