Comment Re:Every Integer? (Score 3, Funny) 170
7 + 2 = 9
Damn, that's the most intelligent post I've seen on Slashdot all day, and I mis-clicked and chose 'redundant' when moderating...
7 + 2 = 9
Damn, that's the most intelligent post I've seen on Slashdot all day, and I mis-clicked and chose 'redundant' when moderating...
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.
Yet without any of the customary safety we come to expect by using natural compounds! Where can I sign up to have my head drilled into rather than trusting the wisdom of the ancients?!
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.
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.
Sorry, but your post makes me more sure that you don't know what you're talking about than I was before.
Standard multiplayer games use event-driven I/O (because polling is bloody awful) and if you want simultaneous action then each event will be on one thread. You don't queue them up. Some multiplayer games opt to have one thread per player, rather than one thread per event, but that means that user input is non-deterministic. Pressing up and firing should perform exactly the same operation no matter which button made contact first. That's a parallel operation, not a sequential one.
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.
There is generally one core engine doing the heavy lifting, but even there you parallelize the hell out of it. (You could timeslice, I suppose, but only an incredibly moronic imbecile would use 40-year-old serialized and painfully slow simulations of threading when true threading is available.)
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.
As for the other post, no you do NOT want the perception of realtime in gaming. Realtime in software engineering has a very specific meaning (there is a fixed relationship between CPU time and wall-clock time)
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.
and that is exactly what you do NOT want in a single-player game. In a single-player game, the most important thing is that there is a fixed relationship between game time and wall-clock time. This is NOT, however, realtime. Realtime can vary the relationship between game time and wall-clock time since it fixes CPU time and less CPU intensive scenes would therefore run faster than more CPU intensive scenes.
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.
With non-networked multiplayer games, the slight variations are going to be unimportant in comparison to each player having equal CPU resources. The intensity of processing needed for one player should not alter - by any degree whatsoever - the responsiveness of the controls of the other player. (And, yes, again you have to do that multithreaded. You can't sequentially read and process because that would add enough latency to kill the opponent right off the bat.)
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.
My guess is that you've not looked at the source for a lot of multiplayer (or even single-player) games.
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 would also guess that you've very little parallel processing experience, RASDIT, or low-level engineering. (Trust me, low-level engineering is a terrifying experience if you're not a master of parallelization.)
I have to admit, I don't even know what RASDIT is. Google doesn't seem to know either...
If you're playing two-player console games, you want absolute smoothness between the threads.
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.
This is the kind of thing that makes linux a poor choice on the desktop.
No, it's the sort of thing that makes changing out the stock OS a poor choice on the desktop.
Had you bothered to read the post I linked to it was clear that it wasn't intended for people to be using their 3G connection to be surfing the web.
Maybe you should read your own link:
"Experimental web browsing is free to use over 3G or Wi-Fi."
Yeah, that's some pretty serious "not intending for people to use 3G for web browsing". The author is misinterpreting a fairly standard anti-abuse clause. Obviously "service" includes the 3G web browsing that's being advertised by Amazon. If they advertise and supply a web browser that works over 3G, they're supplying 3G web browsing service. It's something pre-installed on the device. The web browser, complete with a link to Google and other sites, is ready to go when you first turn on the device. You have to deliberately go out of your way to not use 3G when you browse, by setting up Wi-Fi first.
What isn't part of the service would be something like ripping the 3G module out of the Kindle and hacking it into your laptop. That's the kind of action that violates the ToS.
I hear that release comes with a free Slurpee.
That's good.
I don't blame him for creating PulseAudio. I blame the distribution maintainers for having the poor judgment to make it the main sound system for so many distributions. It would be one thing to have a sane default like ALSA and then have PulseAudio available in the repositories for those who really want it.
For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using PulseAudio. If so, I remove it and replace it with ALSA. Suddenly issues related to audio playback go away and everything just magically works. Oh and they easily have a proper mixer without jumping through hoops, too, which is handy considering some of them are using 5.1 surround sound and/or bluetooth headphones.
The first headache I had with PulseAudio was when I tried to run something as a different (normal) user account and audio wouldn't work. There was no meaningful error message. There was only a "connection refused" error in the terminal. As it turns out, this is because PulseAudio has to be run by the user and it is recommended not to run it as a system-wide daemon. User A was running the user-daemon and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used ALSA since PulseAudio didn't do anything I needed it to do that ALSA couldn't do with none of the hassle.
What would you think of the following hypothetical complaint?
I don't blame him for creating X. I blame the distribution maintainers for having the poor judgment to make it the main interface for so many distributions. It would be one thing to have a sane default like text consoles and then have X available in the repositories for those who really want it.
For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using X. If so, I remove it and replace it with screen. Suddenly issues related to mice go away and everything just magically works. Oh and they easily have a proper task switch without jumping through hoops, too, which is handy considering some of them are using international keyboards and/or aalib.
The first headache I had with X was when I tried to run something as a different (normal) user account and graphics wouldn't work. There was no meaningful error message. There was only a "cannot open display" error in the terminal. As it turns out, this is because X has to be run by the user and it is recommended not to run it as a system-wide server. User A was running the X server and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used screen since X didn't do anything I needed it to do that screen couldn't do with none of the hassle.
Surely you know enough about X to understand the errors and mis-diagnoses made in the third paragraph. Well, they are exactly analogous to your own error and misdiagnosis about PulseAudio. First, the error message is actually very meaningful. It's telling you it can't talk to the server. So right away you should know to check that the server is running, that the app is trying to talk to the right server, and that it has permission. But you instead mis-diagnose that you need another server running and waste time trying to set up a configuration that won't work.
You'd have that same attitude toward X that you have toward PulseAudio if X was as new and unfamiliar to you as PulseAudio is.
Hello again.
PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA.
So is dmix. I explained this to you before.
How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot.
You are conflating ALSA, the clean efficient kernel API for using sound hardware, with ALSA the user-space API that adds on a complex system of plugins that can be inserted in place of, or before, sending sound to the hardware. It's this complex plugin system (and the mixer built on top of it) that is inherently flawed and has fundamental limitations. There's no dynamic routing or hot-plugging for starters (and I mean while an application is running). Fixing these limitations requires a rewrite.
If there are such horrible problems with Dmix [...], that kind of development effort should be put towards fixing Dmix
Dmix is being fixed, via a rewrite called 'pulseaudio'. You may have heard of it.
...they want their proprietary format back. Another GD-ROM style abortion? Hopefully they don't think that the awkward size will prevent piracy. Sega made the same mistake, until pirates just reduced video quality on FMV and fit it the games on a standard 800mb CD-ROM (old, I know).
Uh, you do realize this is probably the exact same tech as Blu-ray but without paying for the trademark, right? And even if it's not just Blu-ray, don't you realize that ALL consoles use proprietary formatting in their discs anyway?
Seriously, I don't get why you're portraying this as such an extreme negative. If you tried two consoles, one with proprietary discs and the other without, you wouldn't be able to tell which is which from how much fun you're having... Because there is no difference.
I really hoped they would step up to the big boys in console gaming
How?
You'd think differently if English didn't allow you to use the words 'broke', 'stole', and 'attack' to describe their actions. Stop being controlled by language.
With your bare hands?!?
