Talk about a "joystick"...

Damn, that's the most intelligent post I've seen on Slashdot all day, and I mis-clicked and chose 'redundant' when moderating...

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.

Linkified that for you.

Sadly for your worldview, accessing fields at fixed offsets from a pointer isn't parsing. To say that it is redefines absolutely everything that software does as parsing.

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.

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.

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.

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.

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.

Funny, because I have my degree and have never heard of it.

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.

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.

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.

Sorry, but your post makes me more sure that you don't know what you're talking about than I was before.

Are you seriously telling me games have a thread for every button or axis on each controller? That seems to be what you mean by 'each event on one thread'. If so, wow... Do you understand how the controller input even gets to the system? The three major consoles have Bluetooth controllers. This is a serial connection. Only one input device talks at a time, and the Bluetooth chip sends the data to the system in serial. The threading strategy you discuss gains absolutely nothing, because you'd still have a thread somewhere reading the sequence of input events and selecting the appropriate thread to delegate handling to. You could instead just do that work in the original thread, and lose nothing (except some unnecessary overhead).

And usually, the only 'work' ever done by the input routine is updating controller state data used by the main loop. That's practically no work at all. If you had four players and they all hit every button and moved every stick and even made some motion for the accelerometers to pick up, all at the same time, it'd take mere microseconds of CPU time to process it all. Consoles max out at 60 FPS, and that means there are ~16 milliseconds between each screen update. There's absolutely no risk that a button press won't be processed in time to be handled in the next frame just because controller input handling wasn't multi-threaded.

You'd parallelize physics and/or AI just to utilize all the cores. But I'll bet most games synchronize their physics threads every frame. So no strange side-effects if one physics thread takes longer than the others. It'd just delay rendering as you wait for all physics to complete.

In the context of this discussion, it can just mean that the game feels like it's responding as you press buttons, instead of responding moments later, or it can mean that game time runs at the same speed regardless of framerate.

Your definition of realtime is wrong, BTW. Real-time just means that the hardware and OS are designed to perform certain operations in a short and bounded amount of time, so that response time can be guaranteed.

Sorry, I don't think any of this makes any sense. For one, if we go by your definition above of real-time meaning that "there is a fixed relationship between CPU time and wall-clock time", then if the framerate changes, shouldn't the game keep time correctly because this "fixed relationship" correctly accounts for the amount of time each frame takes? Regardless, having a real-time OS isn't going to stop a game from accessing the system clock. I bet I can install a real-time Linux kernel without messing up my games.

Both players get the same framerate, so both players get the same responsiveness. I've never seen a split-screen game where the framerate for one screen can be different from the framerate on the other screen. As I explained, it's going to take mere microseconds to process all controller inputs. After that, the game is running off of saved controller state data. Player actions are usually processed with physics, and physics are usually processed once per frame. So both players get a responsiveness based on the framerate and the framerate is the same for both players.

I've looked at some. Do you have a suggestion? I'd really like to see what it looks like to have a thread per event.

I have to admit, I don't even know what RASDIT is. Google doesn't seem to know either...

Uh... You clearly have misconceptions about how multiplayer games are programmed...

It may not be the stock OS, but it still has official support from the manufacturer, which is a similar situation. And even with that, the install and setup process isn't totally user-friendly. I'm looking at these instructions.

You have to do the partition setup twice. Once in MacOS to resize the existing filesystem and create a new partition, and again in the Windows installer to select the new partition as the install destination. Select the wrong partition, and you wipe out your data.

Then it comes up in low graphics mode. Connect to the Internet, let Windows Update run and reboot for the graphics driver. Then put in the Mac OS disc, run the install program and reboot. If sound isn't working, download drivers from realtek.com and reboot.

If Apple put the same effort into supporting Linux that they put into Windows, you wouldn't need the MacOS-side app at all. They'd upstream everything needed, so you can just boot the install disc. The partition setup done in the Ubuntu installer is essentially the same screen as the Boot Camp partition setup, except it directly leads into the install process without a reboot followed by a re-selection of the install partition. After the first boot of the installed OS, you'd have at most one more reboot to install a proprietary graphics driver in the case of nVidia/ATI graphics.

So you'd do partition setup once instead of twice, you'd reboot 0-1 times instead of 2-3 times (after OS install), and there'd be no "insert this disc and run setup.exe" or downloading from specific websites. Everything needed to run well (sound, power management, etc) would be integrated into the install disc (except proprietary graphics drivers, and Windows is no better on this matter).

So let me clarify my original statement: Any OS is likely to not run well on a system if there isn't official support for the OS from the system's manufacturer. Linux isn't immune to this rule, but it's far better at operating without official support than any other OS out there. To convey this as a failure on the part of Linux devs is absurd. If you want a system that runs an OS well, buy from a competent manufacturer that officially supports the OS.

No, it's the sort of thing that makes changing out the stock OS a poor choice on the desktop.